When to Strong Name

[Derrick]

Long story short: I've been working on a project which includes both
designtime and runtime components, for both the PC and Pocket PC. While
testing, I've been having problems with Visual Studio loading several
versions of the DLLs, resulting in Invalid Cast Exceptions.

A solution which was suggested to me was to make sure all my designtime
stuff is strong named and placed in the GAC. This sounds like it should
work, and I am about to begin testing of this approach.

I know *how* to strong name an assembly, but I'm not quite sure what goes on
behind the scenes. Is there any downside to me generating the key files,
building my solution, and placing the appropriate DLLs into the GAC a bunch
of times while testing? I'm assuming there is no other way to test than to
do this, and that others are doing the same

Thanks,

Derrick

 

[Christopher Kimbell]

I can't quite see how it can load several versions of the same dll at the
same time. The assembly knows which version it was build against, and should
only load that version. The InvalidCastException occurs if you try to cast
something to a type it could not possibly become. E.g casting a winform
button to an int. I suppose you could get problems if you have a large
amount of assemblies with complex dependency relations and something didn't
get recompiled that should have been.

You should only put assemblies in the GAC if they are used by several
applications. If you only have one application, place them in the same
folder as the executable/dependent assembly and they should be found without
any problem.

If you are in control over all the assembly build projects, put them all
into one solution, then add project reference between them. When you build
the solution VS will automatically copy assemblies to where they are needed.
As you change things in one assembly, all the assemblies that depend on it
will also get recompiled. I would reccoment this approach instead of having
several independent projects that you have to manually remember to compile.


Chris

 

[Derrick]

Thanks Chris,

It's not just the fact that I'm getting invalid cast exceptions. As my post
implied, my project includes custom controls that can be added to a form.
The invalid cast exceptions are dependant on what order I add the controls;
i.e., if I add Control A first, followed by Control B, everything works
fine. If I add control B first followed by Control A, I get the exception.

I posted more details about my problem here:
http://www.windowsforms.net//Forums/ShowPost.aspx?tabIndex=1&tabId=41&PostID=18953,
which includes the reply I mentioned about Strong Names and the GAC.

As you mentioned, since my project is really a Controls Library, I should be
putting it in the GAC anyway, correct?

One other thing, I originally had everything in a single VS.NET solution,
but during the build process bad things were happening - for instance,
VS.NET would delete one of the DLLs that another project was referencing.
I've since switched to using NANT.

Thanks,

Derrick

 

[Christopher Kimbell]

Sorry but I cannot explain why the sequence of adding controls makes a
difference.

I would say it is reasonable to put a Controls Library in the GAC, as it may
be used by several applications.

When you had everything in the same solution, did you add references by
explicitly selecting the dll, or did you select the project that made the
dll.
If you selected the dll itself, VS doesn't know that the projects depend on
each other, then the build sequence becomes important. The best solution is
to use project references, then VS can figure out which project to build
first. Alternatively you can set the build order and dependencies manually.

Chris

 

[Derrick]

I always use project references when I have multiple projects in a solution,
never static.

No one seems to understand why the sequence of adding controls matters.
Very frustrating

In the link included with my last post, I was told that when a DLL is added
as a reference in a VS project, VS itself creates "shadow copies" of any DLL
that is referenced by the DLL that was added.

The theory with my problem is this:

I have 3 DLLS - A, B & C. B contains a reference to A. C contains a
reference to A and B. If I add only B as a reference in my test project, it
automatically adds a reference to A as well. If I add only C as a reference
in my test project, it will automatically add a reference to A and B. The
problem seems to lie in the "overlapping" of the B reference: if I add C
first (therefore Visual Studio automatically adds a reference to B),
everything is fine. If I add B first, bad things happen.

All I can do is try different variations, I guess

Thanks for your time,

Derrick