It was easy to check if VSTO 2005 SE was installed by just calling MsiGetProductInfo() with the product code {388E4B09-3E71-4649-8921-F44A3A2954A7}, as listed in MSDN.
What is the product code for the VSTO 2010/4.0 runtime? Or is there a better way to determine if it's already installed? This is for our installation process.
Also, I am trying to figure out the same for Windows Imaging Component.
Unfortunately the answers here so far do not quite cover all the bases.
Product Code
This does not appear to be reliable - we're looking for a minimum version, not a specific version. Though the product code is in theory only supposed to change for major version increments, the version of VSTO on my machine - 10.0.40303 - has a product code of {A0FE0292-D3BE-3447-80F2-72E032A54875}. This suggests that Microsoft isn't necessarily keeping them stable, so I'd suggest this is not a good option.
File version
Another option may be to check for the presence / version of the VSTO assemblies themselves, which may typically be in %PROGRAM FILES%\Common Files\Microsoft Shared\VSTO\10.0. However I'd say this directory is not guaranteed - the actual directory appears to be specified in the registry, but obviously this solution is now no better than just getting the version from the registry directly...
Registry
So going by the registry is probably the only option left.
Unfortunately, the VSTO runtime version can appear in any one of 4 registry locations:
HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v4 (32-bit, VSTO installed from Office 2010 installation)
HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup\v4R (32-bit, VSTO installed from redistributable)
HKLM\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4 (64-bit, VSTO installed from Office 2010 installation)
HKLM\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4R (64-bit, VSTO installed from redistributable)
Note: I don't have a definitive source for this - I'm cobbling together bits of information from, for example, this blog post by Wouter van Vugt and this SO answer. There may be even more to it than that.
In addition, there may be minimum version requirements, though I suspect that in practice this is only going to affect people running pre-release versions of Office 2010:
The Visual Studio 2010 Tools for Office runtime also ships with
Microsoft Office 2010. However at the time of Office 2010 RTM, the
runtime with Office only supports Office solutions that target the
.NET Framework 3.5. If your solution targets the .NET Framework 3.5,
it can run either if Office 2010 is installed or if the Visual Studio
2010 Tools for Office Runtime redistributable is installed. If your
Office solutions target the .NET Framework 4, you must redistribute
the Visual Studio 2010 Tools for Office runtime (citation).
The easiest way is to check the registry.
HKLM\Microsoft\vsto runtime setup\v4\Install
HKLM\Microsoft\vsto runtime setup\v4R\VSTORFeature_CLR40 (this is for the 4.0 Office extensions)
The safest and cleanest method is still checking the product codes, here they are:
For VSTO 2010 x86, version 10.0.31124: {41A01180-D9FD-3428-9FD6-749F4C637CBF}
For VSTO 2010 x64, version 10.0.31124: {C3600AE6-93A0-3DB7-B7AA-45BD58F133B5}
I got them by extraction the contents of the following packages with 7-Zip and analyzing the MSIs with Orca:
http://download.microsoft.com/download/F/3/9/F395E3C2-28A0-4F0D-9E20-FF4D1ADB08D8/vstor40_x86.exe
http://download.microsoft.com/download/F/3/9/F395E3C2-28A0-4F0D-9E20-FF4D1ADB08D8/vstor40_x64.exe
They keys vary by the OS you are installing to. I painstakingly installed the standalone vsto and office 2010 and 2013 .exe's in x86 and x64.
In order to use the registry to check if vsto is installed, you need to verify the existence of the following keys:
for x64:
HKLM\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4 -> Install
HKLM\SOFTWARE\Wow6432Node\Microsoft\VSTO Runtime Setup\v4 -> ProductCode
for x86:
HKLM\SOFTWARE\Microsoft\VSTO Runtime Setup -> InstallerPath
Edit: What I actually ended up doing, was verify that the v4 folder exists.
I needed a way of detecting this when deploying Vstor as an application in SCCM 2012. I used the following PowerShell script to retrieve the info from WMI.
If the version is 10.0.50908, output is generated. SCCM considers detection to be successful if the detection script returns any value.
$VstorVersion = Get-WmiObject -Query "select ProductVersion from SMS_InstalledSoftware where ARPDisplayName = 'Microsoft Visual Studio 2010 Tools for Office Runtime (x64)'" -NameSpace "root\cimv2\sms"
if ($VstorVersion.ProductVersion -ge '10.0.50908') {Write-Host "Found"}
Here code.
In public method we determine is VSTO installed from Office or VSTO runtime package.
In private method, check if version is equals or bigger than version VSTO2010
public static bool CheckVSTO2010 ( ) {
string regFragment = IntPtr.Size == 8 ? "\\Wow6432Node\\" : "\\";
string regVSTO = string.Format( #"SOFTWARE{0}Microsoft\VSTO Runtime Setup\", regFragment );
return CheckVSTOVersion( regVSTO + "v4\\" ) || CheckVSTOVersion( regVSTO + "v4R\\" );
}
private static bool CheckVSTOVersion ( string keyPath ) {
using (var key = Registry.LocalMachine.OpenSubKey( keyPath )) {
//Not installed
if (key == null) {
return false;
}
var releaseKey = key.GetValue( "Version" );
if (releaseKey != null && !string.IsNullOrEmpty( releaseKey.ToString() )) {
var version = new Version( releaseKey.ToString() );
return version.Major >= 10 && version.Build >= 40820;
}
}
return false;
}
Related
When deploying software with the Visual Studio redistributable 2015, if a more recent redistributable is found, the user is presented with a confusing dialog box that implies that something is wrong with the software.
To avoid this, when deploying software with the 2015 runtime, the developer must first check for the existence of more recent versions of the Visual Studio runtime, by polling the registry, and avoid the install attempt if a newer version is found.
For example, here are some checks on a 64 bit system for Visual Studio 2015/2017:
//Check for VS2015 on x86 architecture
if(installer.value("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\
VisualStudio\\14.0\\VC\\Runtimes\\x86\\Installed") == 1)
{
doInstall = false;
}
//Check for VS2017 on x86 architecture
if(installer.value("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\
VisualStudio\\15.0\\VC\\Runtimes\\x86\\Installed") == 1)
{
doInstall = false;
}
if(doInstall===true)
{ //Install }
(Written in Qt for installscript.qs)
You can see the check differs only by the version number, and this currently holds true for all the existing Visual Studio runtimes. I can poll any existing version of Visual Studio and confirm if that install is present by simply changing the version number.
So for now, it's a simple case of checking if 2015 or 2017 exist, and react accordingly.
The problem: After I have released my software, there will certainly be later versions of Visual Studio that I am not currently testing for. I need to future proof my release so that my installer does not attempt to install the Visual Studio 2015 redistributable if there is a hypothetical Visual Studio 2020 already present.
At the moment I feel the only solution is to add in a whole bunch of tests for these hypothetical Visual Studio versions, following the naming convention and going up to some large number that will cover the intended life of the program.
This looks like a Y2kbug type mistake. It feels like there should be a better way. I can't seem to find any posters even considered this problem, let alone solutions for it, so I'm guessing there must be some commonly known, obvious solution, that I'm just missing.
My best guess is that there might be a common registry key that simply indicates if 'any' Visual Studio product is installed, but I have yet to find one.
I would personally regexp parse the version from the path VisualStudio\\**15.0**\\ and then test if myRequiredVersion>ParsedVersion. There is always a possibility that MS (or any company) goes haywire with naming conventions and change the whole path in the future, but that is the risk with everything really. You should maybe ask the user anyways whether he knows there is (newer) runtime/redistributable and allow installing even if you cannot find a proper match.
I am facing problem with huge amount of errors in visual studio, that is caused by unknown problem.
I don't know, how and where I could but the embed interopt type to false.
Last time I resolved this problem with uninstalling my Visual Studio and all related programs, but this time it doesn't work.
You have your project setup wrong, not a problem you can fix by re-installing Visual Studio. Never use that crutch btw. You added more than one reference for PowerPoint, incompatible versions as well. You picked Microsoft.Office.Interop.PowerPoint, a PIA, which got you the reference to the Office 2010 version, and you picked "Microsoft PowerPoint 15.0 Object Library" from the COM tab, the Office 2013 version.
You can't have it both ways, you can only target one specific version of Office.
One possible reason you got into trouble is because Microsoft no longer publishes the PIAs for new Office versions, starting with Office 2013. PIAs are obsolete, elegantly and efficiently replaced by the "Embed Interop Types" option available since .NET 4.0 and VS2010. Also known as the "No PIA" feature.
You have to pick one or the other, both cannot work. If you intentionally want to target an old Office version then using the PIA is the right way. But strongly favor the COM tab reference, it ensures that you'll test your program with the Office version you have on your machine and avoids the need to have the PIA installed on the user's machine.
Let us take VS 2010 as example. I have an app and that needs to be deployed on the end user's system. I have the following algorithm:
1) If the code is built using Visual Studio 2010 (without SP1) then
the installer needs to check/install atleast VC++ 2010 runtime
10.0.30319.
2) If the code is built using Visual Studio 2010 SP1 then the
installer needs to check/install at-least VC++ 2010 runtime
10.0.40219.
I know that the latest Service Pack(SP) of VC++ 2010 runtime would support the apps developed using non-SP/old SP Visual Studio 2010.
Thus, is it not the best practice to install the latest version of VC++ Runtime on the end user machine, irrespective of the Service-Pack-status of Visual Studio? I feel this will be the safer option when it comes to security etc..
Please enlighten me.
Consider the VC runtime as yet another module in the system, not different from a regular application for the aspect that interests you. Just like for an application, in general you should always have the latest version since it should (at least in theory) be more stable, has more features and less bugs. That said, if you know that a specific version contains a critical bug or a change that interferes with your usage model (e.g., it was freeware and became shareware), you should skip it or adopt your software accordingly.
So i've been searching this for quite a while now, to no avail! Has anyone figured out how to change the $(WindowsSdkDir) macro in visual studio 2010, to make it point to whatever version of the windows sdk they would like?
Hopefully this can be a reference to all those who will search for this after me. :)
To tailor an individual Visual Studio 2010 project to use a specific version of the Windows SDK go to Project | Properties, select the General tab (under Configuration properties) and then set the "Platform Toolset" drop down to point at the SDK you want to use. The WindowsSdkDir macro will change appropriately.
Remember to make this change for all Configurations and all Platforms.
I ran into a similar problem when trying to setup a fresh system using VS2010 and the Windows 7 / .NET 4 SDK (v7.1). The solution turns out to be similar to the one for Visual Studio 2008, but in a different registry location. You want to apply the same edits, but the location is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
for 32b Windows and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows
for 64b Windows.
Also, depending on your installation (for both 32b and 64b versions of Windows), you may also need to change the corresponding key in the HKEY_CURRENT_USER tree.
You want to edit the following keys to point to the SDK version you want to use:
CurrentInstallFolder
CurrentVersion
ProductVersion
After making the changes, I restarted Visual Studio and it used the appropriate SDK version. I don't know if this is a bug in the SDK installer (one was logged for the WindowsSDK v6.1, but none for v7.1) or if it is by design, but everything seems to compile correctly after my changes.
Tested for 32b and 64b Windows 7.
[HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows]
"CurrentInstallFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\"
Note that, in contrast to the other registry locations, here actually no sub-key for 7.1 might exist. Don't be confused Visual Studio 2008 is searching here anyways.
I have searched for a list of VB6 files that are redistributable, but did not find one. Can anyone point me to such a list? I specifically need to verify that tabctl32.ocx is redistributable. Thanks!
There is a file on the Visual Studio 6.0 setup disk that contains a list of redistributable components - \Disk1\common\redist\redist.txt
In short, it confirms that you can redistribute tabctl32.ocx.
From the VB6 EULA:
4.1.2 Redistributable Code-Extended Use. Visual Basic, Visual C++, Visual J++, and Visual Studio. If this EULA accompanies any of the Microsoft products listed in the heading of this subsection, you may permit your end users to reproduce and distribute the object code form of certain portions of the SOFTWARE PRODUCT (as listed in REDIST.TXT as "Extended Use Redistributable Code") only in conjunction with and part of a Licensed Product and/or Web page that adds significant and primary functionality to the Extended Use Redistributable Code.
The "Extended Use" section of REDIST.TXT includes tabctl32.ocx.
Here's Microsoft's list of the controls that are supported on Vista and Windows 7. Some are distributed with Windows, and some you have to distribute yourself - listed under Supported Runtime Files to Distribute with Your Application.
tabctl32.ocx is supported, but you have to distribute it yourself. I think that's confirmation that you are legally allowed to distribute it.
(Edit: See also Controls shipped in Visual Basic 6.0)