How to use and debug Shared DLL Assemblies

[Guest]

Since I started using .NET I never thought I would say these words, but I almost miss DLL Hell, because I'm having even more trouble with Assembly Hell

Here's the scenario... I have three classesâ€
Class A has no references other than system assemblie
Class B references Class
Class C references both Class A and Class B.

We originally ran into problems when we were not using strong names, and were "auto-incrementing" build versions. This caused the classic “Unable to copy Class A in Class C because Class A is being used by Class B†error. Since then we have had much better luck since we use specific version numbers for our strong named dll’s and have them registered in the GAC

The new problems/questions that we now haveâ€

1.) How do you consistently debug a GAC assembly? Sometimes the GAC class will come right up even if you didn’t ask it too while debugging. Other times even adding a test project to the same solution won’t allow you to debug it
2.) We continually have the problem of the Reference Path (Under project Properties) becoming populated with older reference paths. After clearing these out, things seem to work better, but somehow, the old references start creeping in again
3.) In many cases, fixing a bug in a Shared GAC assembly requires us to recompile every class and project that reference that assembly, even if the interface hasn’t changed and we use the exact same version number. We have tried incrementing the version number, but even that doesn’t allow the existing classes to recognize the new shared GAC dll. Is there a best practice document that I’m missing on how to “truly†share .NET assemblies

Any assistance or insight on this would be greatly appreciated. How do others get shared class libraries to work? The environment we work is not very static, and full rebuilds of everything will not be possible once code is in production

Thanks in advance

 

[Mickey Williams]

Private deployment is the preferred way to distribute assemblies.

The GAC is really not part of the development lifestyle - it's a deployment
thing. There are only a few edge behaviors that require you to place an
assembly into the GAC during development, and I'll argue that you can defer
those during most of your development cycle.

Giving an assembly a strong name does not require you to place it into the
GAC. Stay out of the GAC unless you have a compelling need to be in the GAC.
It's much easier to version assemblies by just copying them where they're
needed. If you need versioning, use a strong name, but realize that this
requires proper discipline WRT the strong name. Giving an assembly a strong
name, then modifying its behavior without changing the version number will
cause surrealist experiences, especially if you're trying to build against
assemblies that are in the GAC. If you reference version 1.0.37.42 of your
assembly, and that assembly is in the GAC, the GAC'd assembly will be used,
even if a local assembly is available - the GAC is searched first absent
redirection by configuration.

--
Mickey Williams
Author, "Microsoft Visual C# .NET Core Reference", MS Press
www.servergeek.com

Since I started using .NET I never thought I would say these words, but I

almost miss DLL Hell, because I'm having even more trouble with Assembly
Hell.

Here's the scenario... I have three classes.
Class A has no references other than system assemblies
Class B references Class A
Class C references both Class A and Class B.

We originally ran into problems when we were not using strong names, and

were "auto-incrementing" build versions. This caused the classic "Unable to
copy Class A in Class C because Class A is being used by Class B" error.
Since then we have had much better luck since we use specific version
numbers for our strong named dll's and have them registered in the GAC.

The new problems/questions that we now have.

1.) How do you consistently debug a GAC assembly? Sometimes the GAC class

will come right up even if you didn't ask it too while debugging. Other
times even adding a test project to the same solution won't allow you to
debug it.

2.) We continually have the problem of the Reference Path (Under project

Properties) becoming populated with older reference paths. After clearing
these out, things seem to work better, but somehow, the old references start
creeping in again.

3.) In many cases, fixing a bug in a Shared GAC assembly requires us to

recompile every class and project that reference that assembly, even if the
interface hasn't changed and we use the exact same version number. We have
tried incrementing the version number, but even that doesn't allow the
existing classes to recognize the new shared GAC dll. Is there a best
practice document that I'm missing on how to "truly" share .NET assemblies?

Any assistance or insight on this would be greatly appreciated. How do

others get shared class libraries to work? The environment we work is not
very static, and full rebuilds of everything will not be possible once code
is in production.