Extermely nasty bug with the way .NET handles references

  • Thread starter Thread starter Andrew Baker
  • Start date Start date
A

Andrew Baker

If you have every had the following error when trying to use load a
form in the IDE then read on!!!

An exception occurred while trying to create an instance of
GSL.Windows.Forms.BrowserFormBase. The exception was "Method Validate
in type GSL.Shared.GridFilters.GridFilter from assembly GSL.Shared,
Version=1.0.1804.21512, Culture=neutral, PublicKeyToken=null does not
have an implementation.".


I has taken me ages, but I have worked out why this happens and I don't
believe there is a work around.

I have a Windows project called "GSL.Windows.Forms" this references an
assemly called "GSL.UI". Both these projects reference another project
called "GSL.Shared". Seems straight forward... yet this causes a big
problem in .NET.

Unfortunately due to the annoying way .NET handles file locking you
have to set "Copy Local" to true for the "GSL.Shared" reference in the
"GSL.Windows.Forms" and "GSL.UI" projects. Otherwise the "GSL.Shared"
and "GSL.Windows.Forms" projects will lock the "GSL.Shared" dll and
prevent you from rebuilding it.

So both "GSL.Shared" and "GSL.Windows.Forms" have to have their own
private copy of "GSL.Shared". Which should be fine, I always rebuild
both of these if I change "GSL.Shared". However, the killer is that
when I open a form in "GSL.Windows.Forms" which has a component on it
that uses "GSL.UI" you will get the error I posted above. It seems that
even though there is an identical copy of the "GSL.Shared" assembly in
both projects, the designer gives you a "method validate error"!!!!

If I set "Copy Local" to false for the "GSL.Shared" reference, in both
"GSL.Shared" and "GSL.Windows.Forms" it works fine, except I can never
rebuild "GSL.Shared" since the dll will always be locked by the other
two projects!!!!

The problem never arises at runtime, since this will always be using a
single copy of all the references.
 
this is only a bug if you run your app from the same directory that you
compile it from.
I don't know about you, but if I'm running my app, it is usually after I've
installed it (either on a local machine or a test machine or a Virtual PC).
That would put the app into an actual installed directory.

In that case, rebuilding is fairly straight forward.

--- Nick
 
I am not getting the precise error that you describe, but I do see behavior
that might be symptoms of the same bug. It seems as the VS.Net isn't very
good at unloading dlls during a build. Frequently, I will be working and
get a bad build. If I scan the output, I will inevitably come upon an error
message (or a few) that say something to the effect that xx.dll could not be
copied because another process has it locked. It seems that the only
workaround for this (if you can call it a work around) is to close and
re-open Visual Studio. It seems to happen more often if you have to object
browser open, or if you have a form open in the form designer. When I get
this error, I generally will close all the files in the editor (or at least
the forms) and then restart Visual Studio.

I also find that this problem seems to come up after I refresh code from
source control by performing a "get latest version" operation at the
solution level. Very, very irritating.
 
I think you have misunderstood my post. I am not running the app, I am
using Visual Studio to design an application using a solution that
contains multiple projects. Several of the project reference each other
and the Form designer is having serious problems with this. It seems to
steam from the fact that I am using visual inheritance and the
inherited base components are in the same project as the components
that are deriving from them. This couple with the other information in
the previous post gives me a big headache!

I have used the Assembly Binding Log Viewer to look for the binding
errors, plus checked the temporary files in ..\Application
Data\Microsoft\VisualStudio\7.1\ProjectAssemblies are correct and still
haven't got to the bottom of this...

This is going to take someone with a serious knowledge of .NET to
solve. Have been using a million tools to watch what is going on, but
it seems so random!!!
 
you are correct. I was not aware that the problem was that these components
were being loaded by Visual Studio in the design environment.

Once VS loads the library that contains your component, it cannot easily
unload it. This is because VS cannot create an appdomain for a visual
control. You will need to close out of VS and reopen it on occasion. This
will allow the dll to be unloaded and will let VS compile the new version.

--- Nick
 
Back
Top