Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
Many installers and applications require that one or more versions of the .NET Framework be installed on the system in order to be able to install and function correctly. This article provides sample C++ code that can be used in a setup program or in an application's code to detect the install state and service pack level of various versions of the .NET Framework.
Note - when used in a setup program, this sample code is intended to be used in a setup EXE bootstrapper. It is not intended for use within an MSI. If your setup program is a single MSI, you can use Windows Installer AppSearch and RegLocator tables to detect the install state. If you use WiX to create your MSI, you can use the information provided in the WixNetFxExtension instead of implementing this logic yourself. Refer to How To: Check for .NET Framework Versions in the WiX documentation for more details.
.NET Framework versions that can be detected by the sample code
The sample code available via this article supports detecting the install state and service pack level for the following versions of the .NET Framework:
Registry-based detection code
The simple version of the sample code queries the officially documented registry values that are intended to be used to detect the presence of each version of the .NET Framework.
This sample code can be downloaded from the following location:
Registry-based detection code and more in-depth checking that loads mscoree.dll
The more thorough version of the sample code queries the officially documented registry values like in the previous sample. In addition, it performs an additional check that loads mscoree.dll and uses some of its APIs to query for the presence of specific versions of the .NET Framework. The algorithm to perform the additional check was originally introduced in this blog post.
Creating a Visual Studio project to compile the sample code
The sample code available for download via the links above is in the form of a single C++ source (.cpp) file. If you are having trouble getting this code to compile on your system, you can refer to the instructions in this blog post to create a Visual C++ project that can be used to compile the sample code into a sample executable file.
Hi Alex - This error is caused by the Visual C++ runtime files not being available on the target computer. I took a look at my steps at blogs.msdn.com/.../9387659.aspx and there is a step that I use when I build the code myself that I forgot to list there. I use the Visual C++ /MT compiler option to statically link to the VC++ runtime files to avoid this type of problem. This is described more at msdn.microsoft.com/.../2kzt1wy3.aspx.
You can add this switch in the Visual Studio IDE by right-clicking on your project in the VS solution explorer, choosing Properties, then going to Configuration Properties | C/C++ | Command Line and putting /MT in the additional options text box.
I did exactly what you told me before reading your post. Just couldn't afford waiting for your reply and searched on the Web :) Too bad the file's size increased almost twice as much. But I can live with that.
Hi Alex - Yeah, file size is one of the trade offs you have to make if you decide to statically link the VC runtime files. Depending on where this code ends up being used, you may not need to do that - for example, if you're going to run this .NET Framework detection code within an application that already depends on the VC runtime files and that has logic to make sure it is present on the user's computer or something like that.
Hey Aaron - thanks for the great code, it works great! One thing I'm having an issue with (i'm not well versed in C++ so forgive me if this is a stupid question) is that I can only build this in VS2010 if it is set to be a windows app, not a console app. I get the following error when set to console:
error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
Hi Jeff - The sample code I have posted is for a Win32 application, not a console application. If you want to use a console application instead, you'll need to replace the _tWinMain function signature in the sample code with something like the following:
int _tmain(int argc, _TCHAR* argv)
Thank you for your awesome work! I created NSIS plugin based on detectfx_new.cpp. Short description is available here: nsis.sourceforge.net/DotNetChecker_plug-in. Source code is on GitHub: github.com/.../NsisDotNetChecker.
Hope you do not mind (I found no license for your code).
Hi Alexey Sitnikov - Thanks for sharing this link. I don't mind at all that you used this sample code like this. There is not any license associated with this code - I created it for sample purposes only, and anyone is free to re-use it as they see fit.
The links are broken... can you please fix them?
Hi SkyDriver - The links appear to be working fine for me. You might need to go to http://skydrive.live.com and log in before they'll work for you, so I'd suggest trying that.
I cannot install .net framework v4
everytime it rolls back after a specific time and the installation says that it is insuccessfull due to fatal error.
i have tried by enabiling the .net framework 3.5 options at Turn windows feature on or off..
i am running a windows 7 32 bit..plz help..
Hi Soham - My first suggestion is to try installing the latest version of the .NET Framework 4 family, which is the .NET Framework 4.5.2. You can download it from www.microsoft.com/.../details.aspx.
If that doesn't install either, then can you please use the tool described at blogs.msdn.com/.../6458047.aspx to collect all of your setup log files, upload the file named %temp%\vslogs.cab that this tool will create to a file server (such as http://onedrive.live.com), and then reply back here and provide a link that I can use to download your log files and take a closer look?
On my windows 7x64 OS, 4.5.2 shows version 378758, not 378675 as your code comment says is required by Win8.1.
Hi Dougal - I'm assuming you meant 4.5.1, not 4.5.2 in your comment - correct? If so, the version information you're seeing is what is expected here. Windows 8.1 comes with the .NET Framework 4.5.1 installed as an OS component, and the version number for the OS component version of 4.5.1 is different than the version number for the redistributable version of 4.5.1 (which is what you have installed on your Windows 7 PC).