versioning assemblies

[IT4EVR]

For some reason this concept has mystified me. Let's say I create an application on C:\MyApp\MyApp.exe. This represents version 1.0.0.0.

Now I want to create version 1.0.1.0. What's the best strategy for creating multiple versions of the same application but retaining all versions? Does this amount to side by side versioning?

I read that I should create a subfolder under the main application folder for the various versions. So then I might have something like C:\MyApp\MyApp1.0.1.0 ? Am I just adding a new project to the existing solution pointing to this new directory, or a separate project outside this solution? And then once I create this new version, I assume I need to create a separate setup project for each version?

I understand I have to assign these assemblies strong names or versioning doesn't apply.

Anyone who can demystify this for me gets a nice little star...

 

[GeertVerhoeven]

Hi,

There is no problem in adding those projects to the same solution.

You can add multiple project outputs to one setup project. When doing this, you need to make sure that the name of the dll/exe is different for each version otherwise it will give a warning like this:
WARNING: Two or more objects have the same target location ('[targetdir]\windowscontrollibrary1.dll')
WARNING: Two or more objects have the same target location ('[targetdir]\windowscontrollibrary1.dll'

So the best way according to me is to add a setup project for each version. Otherwise you are not really creating a new version but a new application.

To deploy your application, it is indeed best to assign it a strong name (via sn.exe or project properties) and install it in the GAC (Global Assembly Cache).

Greetz,

Geert

Geert Verhoeven
Consultant @ Ausy Belgium

My Personal Blog

 

[chiph]

This is a good reason to have a source control system other than Visual Source Safe (it handles this situation about as well as it does anything else -- badly). SCM systems are specifically designed to let you do this. Plus their other advantage is that they're an infinite undo system.

If you were using something like Subversion (which is good and free, by the way), you'd create a new branch for the new version, and do the work there. Since this is a branch, you'd have everything in there that was current as of when you created the branch, so all you'd have to do is modify the files you need for the new version, change the AssemblyInfo.cs files to reflect the new version number, compile & ship.

A highly recommended book on the subject (which is SCM system agnostic) is:

Software Configuration Management Patterns: Effective Teamwork, Practical Integration
ISBN: 0201741172

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[IT4EVR]

Thanks for the info...i'll need to check this out.

It would seem to get a bit unwieldy to create a separate project for each build. From what I understand Microsoft creates a new build each day.

Then comes the issue of files shared by the different assemblies. Different assemblies could have different versions of components they reference etc. Best approach load them into the GAC and reference them from there?

As it stands we're not using any Version Control. I'm not a big fan of VSS but version control is an absolute must these days.