We Keep Coding

FileNotFoundException on MethodInfo.GetCustomAttribute

My goal is to display information about the methods of some classes in an uploaded dll. Loading the assembly, finding the desired classes and their methods was already successfully done. Now I was trying to show whether a method is declared "async" or not.
I found a thread that tells me how to do it: How can I tell if a C# method is async/await via reflection?
Anyway, while testing, when I call this
(AsyncStateMachineAttribute)methodInfo.GetCustomAttribute(typeof(AsyncStateMachineAttribute))
I got a System.IO.FileNotFoundException - "Could not load file or assembly '{assembly identifier}' or one of its dependencies. The system cannot find the file specified.".
I found this exception in an unanswered thread, but it did not help me: How to prevent MemberInfo.IsDefined from throwing FileNotFoundException on irrelevant attributes?
I understand that the method I am looking at has an attribute that my code does not know. I do not want to load that reference because it is only a test case and many other different attributes can be found in the same situation.
So, I need an answer to one of two questions:
Is there a way to get the attribute "AsyncStateMachineAttribute", if it exists, ignoring the errors on other attributes?
Is there another way to check whether a method (from MethodInfo) is async?
Thanks in advance! :)

Result of "is" expression returns false when run, but true when inspected

I have the following code. The CustomControlHelper generates an instance of an object via reflection. At this stage we don't know what type of object we are dealing with. We do know it will be a CustomControl, but we don't know if it implements any particular interface or if it extends any other classes. The following code is trying to establish whether the loaded control implements the IRichAdminCustomControl interface.
Object obj = CustomControlHelper.GetControl(cc.Id, cc.ControlClass);
if(obj != null)
{
bool isWhatWeWant = (obj is IRichAdminCustomControl);
return isWhatWeWant;
}
That's all fine, but I've noticed that when I know I have an object that implements IRichAdminCustomControl, the expression evaluates to false.
Okay, this is where it gets really weird. If I inspect the code when debugging, the expression evaluates to true, but then if I immediately let the code run and inspect the result, it evaluates to false (I've attached an animated gif below to illustrate).
Has anyone come across weirdness like this before and if so, what on earth is causing it?
Incidentally, I believe the product I'm using uses Spring.NET to provide dependency injection in the CustomControlHelper.

If you are using Visual Studio 2010 SP1, I came across this bug:
Misreporting of variable values when debugging x64 code
There is a workaround on that page, posted by Microsoft:
You can either set all projects to compile to x86, or create an intermediate initialised variable declaration to ensure the debugger reports the correct value of the variable being examined.
Try this as a workaround:
bool isWhatWeWant = true;
isWhatWeWant &= (obj is IRichAdminCustomControl);
bool finalValue = isWhatWeWant; // this line should fix isWhatWeWant too in the debugger
return finalValue;
EDIT: seems like VS2012 also encounters similar problems in specific conditions.

Two possibilities come to mind. The first is that your interface name is generic enough that it could already be in the namespace somewhere. Try fully qualifying the interface in the is clause. The second possibility is that you might be running the code as part of a constructor, or being called indirectly by a constructor. Any reflection like stuff needs to be done after we are certain the application has fully loaded.

So I found the answer. It was because I had two copies of the dll in different locations. I had one copy in the bin of my back-end application and one in a shared external directory that gets dynamically loaded by the backend app.
I should explain; this application consists of two apps running in tandem, a frontend app and a backend app. Ordinarily, you place "Custom Controls" into your frontend app. These controls are then copied on application start to a external directory that is accessible to the backend app.
In this case, I had logic in my Custom Control library that needed to be accessed in the backend app - so I had to make a reference to it... which ended up with the backend app having two references to the same class. D'oh! And OF COURSE that's going to work when you're debugging.
Solution was to split my extra logic into its own project and reference THAT in the backend app.
I'm not going to "accept" my own answer here because, although it solved my specific problem, the solution is a bit TOO specific to the apps I'm working with and would be unlikely to help anyone else.

This happened to me once and even though I never came to a conclusion as to why it was happening I believed the PDB files that were being loaded with the debugging symbols where out of sync. So, by "cleaning" the solution and then rebuilding the solution this weird issue went away.

How is compiler dealing with these Generic Plugin Interface instance methods?

I'm working with some, unfortunately largely undocumented, existing code and I'm having trouble understanding how it calls upon the methods of the plugins it loads.
My aim at the moment is simply to step into one of the methods loaded via the plugin manager, as it's causing an exception. However I had to rebuild the pluginManager from the source to get debug symbols and when I reference this new DLL version the compiler throws up arms.
The code appears to load the plugin into plug.Instance and then access the specific methods like so plug.Instance.ReturnLeaNumber();
This compiler error makes sense, because it doesn't know the details of the plugins. What confuses me is how the compiler ever knew these where valid before run time, when no plugins are initialized. I can step through the code that doesn't work now with the older DLL!
This is an example of where the program loads up a plugin.
plug = GenericServicePlugins.AvailablePlugins.Find(Application.StartupPath + "\\Dlls\\SchoolInterface.dll");
// Compiler doesn't like this next line anymore though
plug.Instance.Initialize(null, null);
If there are any differences between my rebuilt library and the previously working one, I can't tell how as the versions match up with the ones in our source control. Would appreciate some advice on where to start looking!
public interface IGenericPluginMasterInterface
{
String returnName();
void Initialize(ExceptionStringResources.Translate ExceptionStrings);
Object ExecuteFunction(String macAddress, bool log, String functionName, LoginCredentials logonCredentials, WebConfiguration webConfig,
Int64 dataLinkId, DataLinkParam[] dataLinkParams, String dataName,
DataParam[] dataParams, Object[] additionalParams);
}
Rest of Manager code on PasteBin
How does the compiler know about these plug.Instance.Method() methods before runtime?
Edit:
I've not quite worked this out yet, but there was a "PluginsService" file I missed which partly mirrors the "GenericPluginServices".
I think this error could have been caused when I removed parts of this class that related to an now defunct plugin, which I am looking into. However I figured posting this other code snippet would help the question.
PluginService.cs code
GenericPluginService code

Find returns AvailablePlugin, so .Instance is of type IGenericPluginMasterInterface; if so, indeed; that .Instance.ReturnLeaNumber() can't possibly work...
The only way that could work (without introducing some generics etc) is if .Instance actually returned dynamic. With dynamic the name/method resolution is happening at runtime. The compiler treats dynamic very deliberately such as to defer all resolution to runtime, based on either reflection (for simple cases) or IDynamicMetaObjectProvider (for more sohpisticated cases).
However, if the code you have doesn't match what was compiled, then: we can't tell you what it was. IMO, the best option is to get hold of the working dll, and look at it in reflector to see what it is actually doing, and how it is different to the source code that you have.
Actually, strictly speaking it could still do that with the code you've pasted, but only if plug is typed as dynamic, i.e. dynamic plug = ...

Visual Studio c# compiler does not notice a changed method name

I have a really strange problem in a c# program:
I have an interface which declares a method and a class implementing this interface. When I change the methods name (in the interface and in the implementation), visual studio compiles the code, but if I run the code, I get a method not found exception. If I manually delete the target dll and recompile the project/solution, all works fine.
However, there are a lot of other methods and properties, also declared in the same interface and implemented in the very same class. If I change the name of one of them, all works fine!
Has anyone an idea, what this can be?
public interface INode{
//...
IEnumerable<INode> Ancestors();
//...
}
public abstract class NodeBase : INode{
// ...
public IEnumerable<INode> Ancestors(){
}
// ...
}

While trying to resolve the problem, I have removed the reference to the problem-assembly from the UI-project and then re-added. From this time on, the issue has been gone.
Sadly, I can not say what the reason for this really strange problem was, and now I have no more the opportunity to look at the issue.
It must have been something corrupted within the project, however I can not imagine what this could have been, because really only one method signature was concerned (independent of the position in code and the name of the method).
Thanks to anybody who posted an answer so far (+1), leading me to a solution. I hope I will never see this weird behaviour again! For those having the same problem: try to recreate the references to the issuing project.

Have you tried doing a Build > Clean Solution/Project?

I get this problem all the time...
Usually I get save, close down VS, open the solution back up, and then build. This process keeps the issue at bay for a little while.
When you "Clean" a solution it deletes all the compiled and temporary files associated with a solution. It ensures that the next build will be from scratch.
I believe the problem lies with VS not properly building the solution and something gets "stuck". I also believe there are extensions for VS that help clear this problem.
This article maybe be a bit extreme for what you need, but you may find it useful: http://www.neovolve.com/post/2010/08/02/Cleaning-a-VS2010-solution-with-a-sledgehammer.aspx

C# says my namespace causes a NullReferenceException

So I got the dreaded "yellow screen of death"(? that's what the .NET guys called it) with the error message:
[NullReferenceException: Object reference not set to an instance of an object.]
OK, that's fine, I can understand that, but the error references a line of code which reads:
<namespace1>.<namespace2>.XMLDohickey responseXML =
new <namespace1>.<namespace2>.XMLDohickey();
(names obscured to protect the innocent (: ).
I can easily see how the line after, Session[<value>].ToString();, could cause this error, but I don't understand how the error could be caused by the line it claims to be caused by.
So, is it that C# is telling me the wrong line number, or can a namespace actually be null?
As a side note -- this seems to work fine locally, on my company's DEV and QA servers, but it seems like it failed on our client's QA server...
EDIT
So... here's the deal.
Apparently, when .NET crashes, sometimes it returns the last successful line called instead of the line which actually held the error. In this case, the Session[<value>] was null (Why? No idea. that "Should never happen").

A namespace can never be null, it will never generate any runtime errors of any kind (in the way you are describing it). So your null reference is probably in Session[key].ToString(), or the constructor of XMLDoHickey. I would consider checking if the value in the session state exists before calling a method on it.

Are you sure the exception doesn't come from inside the XMLDohickey constructor?

You need to force a recompilation and probably also clear the temporary internet files.
THere are often mismatches in the line numbers and the actual instruction causing the exception when source and binaries get out of sync and this must be the case here since namespaces surely dont cause null reference exceptions :)