我使用xml文件作为嵌入式资源来加载XDocument。我们使用以下代码从Assembly获取适当的文件:
XDocument xd = new XDocument();
Assembly assembly = null;
try
{
assembly = Assembly.GetExecutingAssembly();
}
catch(Exception ex)
{
//Write exception to server event log
}
try
{
if(assembly != null)
{
using(StreamReader sr = new
StreamReader(assembly.GetManifestResourceStream("assemblyPath")))
{
using(XmlTextReader xtr = new XmlTextReader(sr))
{
xd = XDocument.Load(xtr);
}
}
}
}
catch(Exception ex)
{
//Write exception to server event log
}
因此,当部署代码时,我们偶尔会转到页面,并且不会从嵌入的文档中加载任何内容。当我们检查事件日志时,没有错误。如果用户只是刷新页面,它将加载正常。这让我认为,由于某种原因,assembly = Assembly.GetExecutingAssembly();
偶尔返回null,并且编写代码的方式不是错误。所以,我的问题是为什么Assembly.GetExecutingAssembly();
会返回null?我发现有几篇文章谈到有时会出现非托管代码的错误,但是这个应用程序是用C#编写的,并通过安装项目进行部署。
最初编写的代码没有错误避免代码。添加它是为了防止用户获取错误屏幕。例外被写入服务器的事件日志。
答案 0 :(得分:7)
这是一个完美的例子,说明为什么吃异常几乎普遍不好,特别是顶级System.Exception
。问题可能在任何地方;更可能的是,真正的问题在于您的日志记录代码。
取出那些空的catch
块(或用throw;
重新填充它们)并查看真正发生的异常的位置。一旦找到真正的问题并重写代码,重写它就只能捕获实际知道如何处理的异常。
GetExecutingAssembly
不会返回null
,期间。
答案 1 :(得分:5)
转到提到其路径的文件的属性,并将buildAction从内容更改为EmbeddedResource的默认内容。重新编译,它应该工作。
答案 2 :(得分:3)
你使用错误的划桨在小溪上,GetExecutingAssembly()永远不会返回null。通过删除所有错误避免代码(包括空检查)向自己证明。偶尔失败通常是一个线程问题。
答案 3 :(得分:2)
答案 4 :(得分:2)
如果从非托管应用程序(例如NUnit Test runner)启动代码,则可以返回null:使用控制台尝试以下操作:
[Test]
public void att()
{
Assert.NotNull(Assembly.GetExecutingAssembly());
}
看到您已将其嵌入标记,我猜你是否正在使用某种引导程序或解释程序来运行您的.Net应用程序?这可能是不受管理的(即不是.Net解释的)因此会返回null。
请参阅文档,部分"备注:http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly.aspx
答案 5 :(得分:1)
当面对这样的情况时,我试图真正证明返回的值为null。试试这个:
try
{
assembly = Assembly.GetExecutingAssembly();
Log.Write("Executing assembly is null: " + (assembly == null))
}
catch(Exception ex)
{
//Write exception to server event log
}
我怀疑它总是会写“假”,而其他东西实际上就是问题 - 也许你的代码片段中没有包含这些内容。
答案 6 :(得分:0)
如果您尝试访问文件,请转到该文件,右键单击它,转到其属性,将其构建操作更改为“嵌入式资源” ,然后确保您提供给“GetManifestResourceStream”的路径拼写正确。 可空性主要发生在路径/文件的拼写错误时。