views:

31

answers:

2

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 ?

+1  A: 

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.

KeithS
When I speak about "global" setup, I mean there is one setup project that installs various applications (say for instance, a website for the frontend v.1.0, a website for backend v1.4, a communication client v3.2 and the hole package [setup project] is v4.3)
Erick
All of the different applications are in fact different solutions but included in the setup package as merge modules
Erick
Gotcha. I would go for the registry option. You're running an installer, which requires admin privileges anyway. Set up some custom behavior in the Install and Uninstall handlers that creates a Registry key under HKLM/Software/<your app>/Version, and make sure that all other apps know how to get there (an AppSetting is probably best). Your apps will require read access to the Registry; read up on usage of RegistryPermission and RegistryPermissionAttribute to ensure that your code has this permission before trying to access the registry, to avoid unhandled exceptions.
KeithS
+1  A: 

If you are installing multiple packages from one MSI, then it is best to let the MSI be listed in ARP and then the version of this "global setup" will be readily available to future MSI's. Without knowing which technology you are using to create your setup it is hard to give more solid advice, but in WiX (windows installer XML) you simply have to include an upgrade element that will take care of this for you automatically. Most technologies should have some way for you to check the current install version.

Adkins