开发者

Is there a way to detect a setup version from a product?

开发者 https://www.devze.com 2023-01-15 14:28 出处:网络
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.

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 s开发者_如何学JAVAerver on a separate folder (ex. c:\Setups\Product 1.0\Setup.exe, c:\Setup\Product 1.5\Setup.exe, etc..)

Any suggestions ?


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消