Question

so, here is the situation here.

I have 2 asp.net websites + some winform applications that are installed with a setup. They are all represented as merge modules into the setup project.

Currently when we want to update the global version of the application we must update all versions into asp.net websites and stuff. I know it is possible to detect the version into the assembly info of an asp.net application, which is quite easy. The difficulty here is to detect the “global” setup version. (say here the website is version 1.5 but the global setup itself is version 3.4).

At some point I guess that if I locate the setup.exe/setup.msi file I could browse it with reflexion, but it is not exactly the best solution. We store each setup per version on the server on a separate folder (ex. c:\Setups\Product 1.0\Setup.exe, c:\Setup\Product 1.5\Setup.exe, etc..)

Any suggestions ?

Answer 1

Define “global” setup version. Are you saying that each patch updates some but not all assemblies, and thus the version of any one assembly, or even any of the assemblies at all, may not reflect the last patch installed?

3 options:

• Keep the global version info in each config file and push out updates to every config of every installed component every time (not recommended).
• Provide a shared config file, or references from other configs to a “main” config, that can be referenced from any of the executable projects, and make sure that config gets updated every time.
• Maintain a registry key containing the global version for the software package.

Of the three, I would pick the last, since the installation and patching is spread over several areas of the system, but every area SHOULD be able to read a software registry key (if not update it). The process is not difficult; you can reference the static System.Win32.Registry object to get base keys for LocalMachine, CurrentUser, etc. and from there you can traverse the tree by navigating through RegistryKey objects (or creating one from scratch with the key path). You can specify the key path with an AppSetting in the various web and app.config files; this shouldn’t change nearly as often as the value of the key itself.