How to handle versioning, referencing, building, and deploying assemblies for multiple releases

  • Thread starter Thread starter loretta.stokes
  • Start date Start date
L

loretta.stokes

I manage our nightly builds for all of our products. Since we have
added our .NET assemblies to our nightly build, it has been a learning
process. I have come across a couple of situations that I am not sure
how to handle without rebuilding or redeploying some of our common
assemblies. First let me explain what we do:

1. Version all assemblies with 1.0.0.*
2. All assemblies are strong named
3. We use project references

In version 1.0 of our product we are releasing some common assemblies
in the GAC( GAC1.dll) and other small .NET apps that use GAC1.dll. We
have a 1.1 we will also release. We have several new assemblies that
reference GAC1.dll. I can't figure out how I build the version 1.1
assemblies without rebuilding the GAC1.dll or generating a publisher
policy file for the assemblies released in 1.0? The GAC1.dll is
unchanged. As a general rule we do not rebuild something that has not
changed unless it is a major release. I would appreciate any
suggestions or I would just like to know how other people are handling
this.
 
I manage our nightly builds for all of our products. Since we have
added our .NET assemblies to our nightly build, it has been a learning
process. I have come across a couple of situations that I am not sure
how to handle without rebuilding or redeploying some of our common
assemblies. First let me explain what we do:

1. Version all assemblies with 1.0.0.*
2. All assemblies are strong named
3. We use project references
Click to expand...

We don't change the AssemblyVersion for dlls unless there's a reason to
(like new or changed classes). We use AssemblyFileVersion and
AssemblyInformationalVersion to keep track of different builds.
 
Back
Top