Just to follow up.

I don't know why this happens and it seems really silly to me but I went ahead and tried starting from the beginning with empty projects, leaving the default name Class1 as the class name (and .cs filename) and added it as a reference to a brand new windows application. Voila!

It seems that in the process of renaming the class to Gmapper then renaming the source file caused .NET to NOT change some internal flag appropriately and was possibly still looking for Class1.DLL or something similar took place that .NET couldn't resolve.

I have know idea why something so fundamental to the IDE is that sensitive to naming things. Each time a class is added as a reference, all paths, class names and file locations should be rewritten to reflect the latest information regarding a class.

Oh well. It only took 4 hours to understand this problem.


>Eric,
>
>Don't know why you're having so much problem with this. It's typically pretty much straightforward. A question on your Gmapper DLL ... does it NEED to go in the GAC? I'm wondering if that's where your problem lies? Try to avoid if that possible.
>
>~~Bonnie
>
>
>
>>No matter what I do I get this error when trying to test a DLL project in a winform project.
>>
>>

>>An unhandled exception of type 'System.IO.FileNotFoundException' occurred in WindowsApplication1.exe
>>
>>Additional information: File or assembly name Gmapper, or one of its dependencies, was not found.
>>

>>
>>There are no compiler errors and intellisence can clearly see the DLL after I add the DLL reference to the winform application project and add code to create instances of Gmapper. However I get the above error even if I copy the DLL into every possible location in the file system.
>>
>>Also, why doesn't .net show my assembly in the list on the .NET tab of the Add Reference dialogue window after I add my DLL to the GAC using gacutil.exe? This whole issue should be a no brainer yet it is ambiguous at best to understand how .NET handles DLLs. It is especially dumb founding when the DLL in question is part of the same solution as the form's project.
>>
>>Finally, why is this such a hassle? It seems to me that adding the DLL's class project as a reference in the winforms project should supply enough information to begin testing code yet I'm spending hours plodding through unclear documentation and Google links.