Multiple Assembly Version Maintenance

  • Thread starter Thread starter jnoody
  • Start date Start date
J

jnoody

My environment is such that I have multiple assembly versions in the
GAC on multiple servers. Different applications use different versions
of the assemblies which is no problem with the GAC. I use VSS to track
my source code so I can roll back changes if I need to edit the source
code behind an older DLL version and redeploy it as necessary.

The challenge I have run into is that sometimes I need to make the same
changes to a method across multiple DLL versions. A good example is
when I find a bug or needed algorithm improvement that came about a
couple of versions back. Now I have to fix my code, roll back, fix my
code, roll back, fix my code, and so on, then redeploy all of the
DLL's. Another good example is when I add a new method to the newest
assembly, but want to make that method available to an application that
is using an older version of the assembly.

What would be great, is if I could have methods with the same
signature, but specify an attribute that would tell the compiler what
assembly version to use. Then, multiple versions of the DLL would be
created and I could just drop them all in the GAC.

Does anyone have any ideas of how to accomplish this best? Do I need
to use a special compiler or some tools? Can VS.NET accomplish this?
I was thinking that maybe I could define some identifiers and then use
the post-build events to create multiple assemblies or something? Can
that be accomplished?

Thank you in advance for any help.
 
Hello, (e-mail address removed)!

IMO you're breaking the sole purpose of versioning.
If something has changed in the assembly then the indication of that change
will
be incremented version, right?

Did you consider what will happen if you will release DLL with
same method set, but changed methods behavior? Since version
number is not changed applications that are not aware of new
behavior can stop working.

j> My environment is such that I have multiple assembly versions in the
j> GAC on multiple servers. Different applications use different
j> versions
j> of the assemblies which is no problem with the GAC. I use VSS to
j> track
j> my source code so I can roll back changes if I need to edit the
j> source
j> code behind an older DLL version and redeploy it as necessary.

j> The challenge I have run into is that sometimes I need to make the
j> same
j> changes to a method across multiple DLL versions. A good example is
j> when I find a bug or needed algorithm improvement that came about a
j> couple of versions back. Now I have to fix my code, roll back, fix
j> my
j> code, roll back, fix my code, and so on, then redeploy all of the
j> DLL's. Another good example is when I add a new method to the newest
j> assembly, but want to make that method available to an application
j> that
j> is using an older version of the assembly.

Without recompile/rebuild that application won't be able to access
newly added method.
You can add new method to DLL, increment its version and
then rebuild the application that wants to use new method.

[skipped]
 
I am changing the version number, and thus creating a new assembly
side-by-side each time. That's exactly the problem. Now when I fix a
bug in this new assembly version, it doesn't fix the same bug in old
assembly versions.

Take the following example of assembly release sequences:

Release Version 1.0.0.0 - Contains a bug that causes a bad performance
hit that I am not currently aware of. One application uses this
assembly.
Release Version 1.1.0.0 - Change some method signatures. One new
application uses this assembly, using the new method signatures.
Release Version 2.0.0.0 - Fixes the newly found bug that increases
performance by 500%

The applications that are using the first two assemblies do not benefit
from this bug fix. If I want to make the application using 1.1.0.0 use
the bug fix, I now need to recompile it to use 2.0.0.0 and redeploy it.
To make the application using 1.0.0.0 benefit from the fix, I need to
roll back my source so that the method signatures are the same that the
application is using, add the same code into my source, recompile, and
redeploy, or rewrite the application that is using 1.0.0.0 to use
2.0.0.0, recompile, and redeploy. I've just done all the work I was
trying to avoid by using shared assemblies! Right?

Is this making sense?


Vadym said:
Hello, (e-mail address removed)!

IMO you're breaking the sole purpose of versioning.
If something has changed in the assembly then the indication of that change
will
be incremented version, right?

Did you consider what will happen if you will release DLL with
same method set, but changed methods behavior? Since version
number is not changed applications that are not aware of new
behavior can stop working.

j> My environment is such that I have multiple assembly versions in the
j> GAC on multiple servers. Different applications use different
j> versions
j> of the assemblies which is no problem with the GAC. I use VSS to
j> track
j> my source code so I can roll back changes if I need to edit the
j> source
j> code behind an older DLL version and redeploy it as necessary.

j> The challenge I have run into is that sometimes I need to make the
j> same
j> changes to a method across multiple DLL versions. A good example is
j> when I find a bug or needed algorithm improvement that came about a
j> couple of versions back. Now I have to fix my code, roll back, fix
j> my
j> code, roll back, fix my code, and so on, then redeploy all of the
j> DLL's. Another good example is when I add a new method to the newest
j> assembly, but want to make that method available to an application
j> that
j> is using an older version of the assembly.

Without recompile/rebuild that application won't be able to access
newly added method.
You can add new method to DLL, increment its version and
then rebuild the application that wants to use new method.

[skipped]
Click to expand...
 
It seems that nobody is reading this thread anymore, but just in case
someone finds this in a search down the road, I found the following
article describes my dilemma in the Custom Version Policy section quite
well. The next page in the tutorial seems to be blank, so you have to
skip a page to find an explanation and then another page for examples.

http://www.informit.com/guides/content.asp?g=dotnet&seqNum=363&rl=1


I am changing the version number, and thus creating a new assembly
side-by-side each time. That's exactly the problem. Now when I fix a
bug in this new assembly version, it doesn't fix the same bug in old
assembly versions.

Take the following example of assembly release sequences:

Release Version 1.0.0.0 - Contains a bug that causes a bad performance
hit that I am not currently aware of. One application uses this
assembly.
Release Version 1.1.0.0 - Change some method signatures. One new
application uses this assembly, using the new method signatures.
Release Version 2.0.0.0 - Fixes the newly found bug that increases
performance by 500%

The applications that are using the first two assemblies do not benefit
from this bug fix. If I want to make the application using 1.1.0.0 use
the bug fix, I now need to recompile it to use 2.0.0.0 and redeploy it.
To make the application using 1.0.0.0 benefit from the fix, I need to
roll back my source so that the method signatures are the same that the
application is using, add the same code into my source, recompile, and
redeploy, or rewrite the application that is using 1.0.0.0 to use
2.0.0.0, recompile, and redeploy. I've just done all the work I was
trying to avoid by using shared assemblies! Right?

Is this making sense?


Vadym said:
Hello, (e-mail address removed)!

IMO you're breaking the sole purpose of versioning.
If something has changed in the assembly then the indication of that change
will
be incremented version, right?

Did you consider what will happen if you will release DLL with
same method set, but changed methods behavior? Since version
number is not changed applications that are not aware of new
behavior can stop working.

j> My environment is such that I have multiple assembly versions in the
j> GAC on multiple servers. Different applications use different
j> versions
j> of the assemblies which is no problem with the GAC. I use VSS to
j> track
j> my source code so I can roll back changes if I need to edit the
j> source
j> code behind an older DLL version and redeploy it as necessary.

j> The challenge I have run into is that sometimes I need to make the
j> same
j> changes to a method across multiple DLL versions. A good example is
j> when I find a bug or needed algorithm improvement that came about a
j> couple of versions back. Now I have to fix my code, roll back, fix
j> my
j> code, roll back, fix my code, and so on, then redeploy all of the
j> DLL's. Another good example is when I add a new method to the newest
j> assembly, but want to make that method available to an application
j> that
j> is using an older version of the assembly.

Without recompile/rebuild that application won't be able to access
newly added method.
You can add new method to DLL, increment its version and
then rebuild the application that wants to use new method.

[skipped]
Click to expand...
Click to expand...
 
Back
Top