What Alternative Can I Use to Detect the Presence of the VC++ Runtime When .NET Framework also a Requirement?
I’ve come up against a bump in the road involving C++ 2015 Update 3 detection. First we have an installation package that is not contained in a bootstrap .msi. We’ve also decided not to include the runtime via Merge Modules since they moved a portion out to Windows Update. So, up front we have to detect if the runtime(s) is in place.
So currently we have a C# MSI Custom Action that runs and queries the registry…
HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86 and 64 (on x64 systems) hives to ensure the required version is in place (14.0.242122.0). We grab the version via the registry values Major, Minor, Bld, Rbld, combine and compare to the required version value. If not there we set an MSI property which is hashed out by LaunchConditions action.
Here’s the problem, one of our other requirements is .NET 4.6.1. If the Framework is not in place (Custom Action is compiled to target 4.5.2) the action fails causing total blow up of the install. We don’t even get to LaunchConditions.
The sequence is…
AppSearch
VCDetectAction
LaunchConditions.
Anyway, I’m wondering if there is an easier way to detect the VC++ runtime. I guess I could try to write a MSI action that is not reliant on the Framework. This was a fairly large oversight on my part and was not caught by QA despite the fact I always tell them to start testing on a system devoid of any of the requirements.
I guess I could use System Search (registry) for the various version segments, but I would still need a widget to combine and compare.
What other language could I write this action/not reliant on the framework. My current action is C# based on the WiX toolkit format.
-
Placed in answers. - Superfreak3 7 years ago
Answers (5)
What I've done for now is to simply condition the VC++ detection custom action to run only if the .NET detection property, handled during AppSearch, contains the desired version value.
That's an easy and relatively clean approach for our purposes.
I've favorite the CA Type 19 link though.
you know the product code of the VC version you are looking for... so why not use the AppSearch (i.e. look for the ProductCode in the uninstall registry hive)? You don't need to jump through any hoops writing CA's.
This can be used to populate a cutom property and there is your answer...
If you need a specific update, then you know the key of this as well...
As for moving away from VBS, why? The MSI engine (AFAIK, please correct my VBScab if I'm wrong) contains it's own runtime so you never have any problems with s´pecific runtoime versions required before executing a CA, and it's not that hard to write one...
Just my tuppence...
Cheers
Phil
The VC++ version is really held in several values that would need some sort of script or widget to cobble together then compare to our requirement. I guess I could look into using just the Build version (#.#.Build.X) number, but not sure if that would ever conflict with another Major version moving from, let's say, 14 to 15. I could doubt there would ever be a conflict so I guess I could move in that direction.
As far as the vbscript custom actions and moving away from them, I simply did away with all of mine due to what I was reading years back - hard to troubleshoot, blocked by antivirus scripts, etc.
- objShell.RegRead to get reg value
- Session.Property("PROP_NAME")="Value" to set property value
- you can use Installer object to query Win32_Product class (similar to WMI call mentioned by SMal.tmcc) and parse an outpot
In a VBS custom action you can terimnate installation by calling a function which returns specific value; here is an example
Also you may consider to move your VCDetectAction (as it works fine if .NET is installed) after LaunchConditions and then create a new Error custom action with condiition in the InstallExecuteSequence based on a property from you C# code.
The sequence would be:
AppSearch
LaunchConditions
VCDetectAction
VCMissingError (with condition: C#_CODE_PROPERTY="Value")
Comments:
-
I've moved away from vbScript CAs a while back as I read many recommendation to move away from that type of action (difficult to troubleshoot, virus protection blocked, etc).
I am interested in the VCMissingError. What type of action would that be that would raise an error. How is that done? - Superfreak3 7 years ago-
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368078(v=vs.85).aspx
Using Orca or Insted you would need to create an entry in CustomAction table according to above link, and then schedule this action in the InstallExecuteSequence (for non silent installation you may need to add it to the InsatllUISequence too), right after your C# action.
Regarding VBS custom actions it is easy to write everything int MSI log (like it is described here:
http://resources.flexerasoftware.com/web/pdf/archive/msi_writing_to_the_log_file.pdf), and for me, debugging with MsgBox'es and some "cmd.exe /k" calls is not so scary :) - rad33k 7 years ago