Can reflection ever fail in C#?

Question

We have an application which we are developing in C#. We store all resources in a central resource DLL, the resource contains images, icons and strings from which we support multiple cultures.

We access the resources from any project in the solution using the following code;

private ResourceManager ResMan;
ResMan = new ResourceManager("libResx.Resource", Assembly.ReflectionOnlyLoad("libResx"));

Then we access any element of the resource using;

btnClose.Text = ResMan.GetString("btnClose");

Apart from the Resource DLL being missing, is there anything that could cause reflection to fail to find the resource DLL (assembly). So far in testing it has been flawless, is there anything we should be aware of when this is eventually deployed into the wild?

Can reflection fail?

Answer 1

Look at the reference documentation for each of these APIs, to see the list of exceptions which each API can throw.

Answer 2

To my experience, I found that instead of depending on an assembly name, specifying full path is more reliable. You can use Assembly.ReflectionOnlyLoadFrom instead.

Answer 3

It can fail. You can attribute an assembly to prevent reflection from another assembly outside of the same namespace.

Answer 4

Im no dotnet developer but isnt the questioner talking about resources and not reflection ???

Answer 5

Reflection is extremely useful however it can fail for more practical reasons as well.

This has happened to me very recently in a MVC Web application (Castle MVC, Windsor, Brail & Boo). When the boo script compiles & accesses a List from the propertybag it uses reflection to identify the signature of MyModel so that it can then reference the attributes for the View.

Where reflection had failed in this instance is that older database records of MyModel were no longer in sync with the new model as the old data had null values for some of the new attributes or properties of MyModel. This wasn't a problem for new records which had values in the new attribute fields.

As a general rule of thumb I would be registering your assembly as a dependency, and putting the namespace in your using clause. This gives the compiler clear dependency chains when compiling. It also makes it easier for other developers to identify what a particular library depends on rather than having to trudge through a heap of code to find a hidden Assembly.Reflection.OnLoad call to an external dll.

Additionally if you expect your ResourceManager to change a lot you should think about separating it into a separate dll entirely on its own. (In keeping with SOLID OOP Design Priciples). This makes your application more modular and if you ever need to update your resource assembly you recompile only the libraries which are affected.

Uncle Bob - Principles of OOD (SOLID)