Why would Assembly.GetExecutingAssembly() return null?

I am using a xml file as an embedded resource to load an XDocument. We are using the following code to get the appropriate file from the 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
}

So when the code is deployed, we occasionally will go to the page and nothing will be loa开发者_如何学Pythonded from the embedded document. When we check the event log, there is no error. If the user just refreshes the page, it'll load fine. This has lead me to think that, for some reason, assembly = Assembly.GetExecutingAssembly(); is ocassionally returning null, and the way the code is written this isn't an error. So, my question is why would Assembly.GetExecutingAssembly(); be returning null? I found a couple articles talking about there being errors sometimes with unmanaged code, but this application is written in C# and deployed via setup project.

The code was originally written without error avoidance code. It was added to keep the users from getting error screens. The exceptions are written to the event log of the server.

---

This is a perfect example of why it's an almost universally bad idea to eat exceptions, especially the top-level System.Exception. The problem could be anywhere; more likely than not, the real problem is in your logging code.

Take out those empty catch blocks (or rethrow inside them with throw;) and see where the exception is really occurring. And once you find the real problem and rewrite your code, rewrite it to catch only exceptions that you actually know how to handle.

GetExecutingAssembly will not return null, period.

---

go to the properties of the file whose path is mentioned and change the buildAction from content which is the default one to EmbeddedResource. Recompile and it should work.

---

That can return null if you are launching your code from an unmanaged application (e.g. the NUnit Test runner): Try the following using the console:

[Test]
public void att()
{
    Assert.NotNull(Assembly.GetExecutingAssembly());
}

Seeing as you've tagged it embedded, I'm guessing you're using some sort of bootloader, or interpreter to run your .Net app? That would probably be unmanaged (i.e. not .Net interpretted) and hence would return null.

See the documentation, section "Remarks: http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly.aspx

---

When faced with a situation like this I try to really prove that the value returned was null. Try this:

try
{
    assembly = Assembly.GetExecutingAssembly();
    Log.Write("Executing assembly is null: " + (assembly == null))
}
catch(Exception ex)
{
    //Write exception to server event log
}

I suspect it will always write "false", and something else is actually the problem - perhaps something you didn't include in your code snippet.

---

This could be one of the reasons - http://winterdom.com/2003/04/assemblygetexecutingassembly

---

If you are trying to access a file, go to that file, right click on it, go to it's properties, change it's Build Action to "Embedded Resource", then make sure the path your providing to the "GetManifestResourceStream" has the correct spelling. The nullability happens mostly when the spelling of the path/file is wrong.