NullReferenceException when loading rebuilt dll via Assembly.LoadFrom

[Shannon Lloyd]

Hi,
We have an application with a main form which loads an indeterminate
number of dlls from a local directory at runtime via Assembly.LoadFrom
and stores references to them in a Hashtable - sort of a pluggable
module scenario. Under normal circumstances this all works fine, but
we've noticed that if the assemblies are rebuilt (without also
rebuilding the base application) and then the application is run, we get
NullReferenceExceptions in the main form at the point where the
assemblies are loaded. This makes me wonder if there is something going
on with dll versioning...? Both the main application and the
dynamically-loaded assemblies reference a number of "common" utility
dlls which we have also created. All references to these dlls have been
marked in VS .Net 2003 as Copy Local = false to avoid different
copies/versions of these shared dlls being built whenever the main app
or the dynamically-loaded assemblies are rebuilt.
In short, if I do a complete rebuild on the entire solution, everything
works perfectly, but if I come back the following morning and rebuild
just one of the assemblies, the main application won't load it at
runtime. Obviously we would like to be able to update our clients'
handhelds by just giving them the updated assemblies, rather than having
to reinstall the entire application every time we modify a single method.
Any ideas what we are doing wrong?
Thanks,
Shannon

 

[Sergey Bogdanov]

I've tried to reproduce this issue but no luck. I created an application
that loads assemblies with forms through Assembly.LoadFrom:

Assembly a = Assembly.LoadFrom(@"\Program Files\Test\Test.dll");
Form f = a.CreateInstance("Test.Form1") as Form;
f.ShowDialog();

Modified Form1 and deployed to Test directory again and assembly was
loaded normally with new changes. The only thing that could cause
NullReferenceException is absence of "Test.Form1" then the variable "f"
will be null and f.ShowDialog() will cause an exception.

Can you send us a reproducible example?

Best regards,
Sergey Bogdanov
http://www.sergeybogdanov.com

 

[Shannon Lloyd]

I've tried to reproduce this issue but no luck. I created an application
that loads assemblies with forms through Assembly.LoadFrom:

Assembly a = Assembly.LoadFrom(@"\Program Files\Test\Test.dll");
Form f = a.CreateInstance("Test.Form1") as Form;
f.ShowDialog();

Modified Form1 and deployed to Test directory again and assembly was
loaded normally with new changes. The only thing that could cause
NullReferenceException is absence of "Test.Form1" then the variable "f"
will be null and f.ShowDialog() will cause an exception.

Can you send us a reproducible example?

Best regards,
Sergey Bogdanov
http://www.sergeybogdanov.com

I'll see if I can come up with something that isn't overly long
soon-ish. In the meantime, though, I should point out that the error
only occurs if I do a rebuild on the assembly a substantial period of
time later, eg the next day. If I make changes to the assembly on the
same day as everything else is built, then I rebuild the assembly, it
all works fine. But if I come back to it the following morning and
rebuild it (without rebuilding everything else), it falls over at runtime.
Shannon

 

[Alex Feinman [MVP]]

I'll see if I can come up with something that isn't overly long soon-ish.
In the meantime, though, I should point out that the error only occurs if
I do a rebuild on the assembly a substantial period of time later, eg the
next day. If I make changes to the assembly on the same day as everything
else is built, then I rebuild the assembly, it all works fine. But if I
come back to it the following morning and rebuild it (without rebuilding
everything else), it falls over at runtime.
Shannon

Aha! Chances are that it means the build number in one of the referenced
DLLs gets incremented. So in runtime, since a previous version of such dll
is loaded by the main app, the plugin fails to load. You need to change your
build process. E.g. in your plugin project replace project references with
file references to avoid them being rebuilt. Otherwise you could also keep
each of your plugins in a separate directory and deploy it with all
dependent modules, which is not a very good idea for many reasons.

 

[Tihomir Ignatov]

Hello,
I think, that the problem is assembly version. Change
[assembly: AssemblyVersion("1.0.*")] (by default in AssemblyInfo.cs)
to
[assembly: AssemblyVersion("1.0.0.0")] (for example)
and rebuild the project.

Regards
Tihomir Ignatov

 

[Alex Feinman [MVP]]

That would be my guess too

 

[Shannon Lloyd]

Hello,
I think, that the problem is assembly version. Change
[assembly: AssemblyVersion("1.0.*")] (by default in AssemblyInfo.cs)
to
[assembly: AssemblyVersion("1.0.0.0")] (for example)
and rebuild the project.

Regards
Tihomir Ignatov

Ah! Indeed, this would make perfect sense. Well, I've set the versioning
of my assemblies to 1.0.0.0, and done a few rebuilds (after skewing my
system clock by a few days), and everything seems to work.
Just out of interest's sake, how does the 1.0.* versioning work? Does VS
just look at the existing dll version number (if it exists) and
automatically increment the "*" part for each subsequent build?
Thanks,
Shannon

 

[Daniel Moth]

Just out of interest's sake, how does the 1.0.* versioning work? Does VS
Major=1, Minor=0, the build number is the number of days since January 1st
2000. If memory serves me right the revision is the number of seconds since
midnight divided by two.

Cheers
Daniel
--
http://www.danielmoth.com/Blog/

Hello,
I think, that the problem is assembly version. Change
[assembly: AssemblyVersion("1.0.*")] (by default in AssemblyInfo.cs)
to
[assembly: AssemblyVersion("1.0.0.0")] (for example)
and rebuild the project.

Regards
Tihomir Ignatov

Ah! Indeed, this would make perfect sense. Well, I've set the versioning
of my assemblies to 1.0.0.0, and done a few rebuilds (after skewing my
system clock by a few days), and everything seems to work.
Just out of interest's sake, how does the 1.0.* versioning work? Does VS
just look at the existing dll version number (if it exists) and
automatically increment the "*" part for each subsequent build?
Thanks,
Shannon