4

Microsoft is promoting .Net for over 8 years now.

.Net assemblies are versioned using 4# versioning like major.minor[.build[.revision]]. Ref here

While, Windows Installer still suggests 3# versioning like major.minor.build. Ref here

With the difference in versioning in two systems. It is not straight to map .Net assemblies version to an installer. It is quite complicated to use Windows Installer for installing .Net applications, particularly when someone wants to implement Upgrading Product for any change in Revision.

How to overcome this situation? We want to Upgrade our product even if there is smallest change in Revision.

NileshChauhan
  • 5,469
  • 2
  • 29
  • 43
  • To be fair the Windows Installer has existed for over 10 years now. But, in any case, I think their decision to support only 3 parts of the typical 4 part version annoying. – Rob Mensching May 07 '09 at 04:53

3 Answers3

4

This isn't something to overcome. It is a design limitation to accept and design around. Annoying yes but not something that is likely to change in the foreseeable future. Windows Installer ProductVersions are based on 3 parts. Also, remember the first two parts can't be more than 255 but the 3rd part can be up to 65,535.

Rob Mensching
  • 33,834
  • 5
  • 90
  • 130
2

Why would you map .NET assembly versions straight to your product version? Do you really have only one assembly in your product?

Most product configuration management processes I've seen usually tracks product versions with manifests (aka bills of materials) listing what versions of binaries, configuration files and documentation goes in that product version. This decouples your development process from your release process, which is a Good Thing, not least for commercial products.

Pontus Gagge
  • 17,166
  • 1
  • 38
  • 51
  • We do have multiple assemblies, but we want our clients to upgrade to latest version for slightest changes we do in our code base. Hence, we include SVN revision number as last part of assembly version. some how we want to keep out product numbers same with our assemblies' version. Is it wrong to do? – NileshChauhan May 11 '09 at 10:50
  • Identification schemas should be stable and predictable. Your upgrade policy may shift in the future. Including a revision with your assembly version ID is fine -- but your *product* is more than just the sum of your assemblies. Your product is what you decide to ship to customers. The shipping decision is separate from your build decision. Always plan for change. My advice: provide separate product version identities, make them visible to customers (installers, Help>About), and provide BoM's linking product version to assembly version (as well as document revisions &c). – Pontus Gagge May 11 '09 at 14:17
1

The versions used by .NET and the Windows installer address different concerns. In .NET, the assembly version is used by the loader to determine which version of the assembly to load. Remember, you can deploy the multiple versions of the same assembly to GAC and have them available side-by-side. You can even have policies that specify the exact version of an assembly to load. I can have different versions of assembly A in GAC and have application 1 using version 1 and application 2 using version 2. While I don't know that much about the Windows installer, I think it is using the version and the product guid to keep track of what version of an application installed so that it can determine if the application you're installing is newer than what's already installed and warn the user or uninstall it first or let the user choose.

Mehmet Aras
  • 5,284
  • 1
  • 25
  • 32