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.
I previously wrote a blog post listing the silent install, repair and uninstall command line parameters for the .NET Framework 4. Since then, I’ve gotten questions from a few folks who are trying to deploy the .NET Framework 4 in ways that require them to run the MSIs directly instead of using the setup executable (for example, via Group Policy or WMI). Here are some steps you can use to extract the .NET Framework 4 setup package and create administrative install points for the MSIs that are a part of the .NET Framework 4:
Once you’ve created the administrative install points described above, you should be able to install the MSIs in the administrative install point folders directly or use steps like the ones previously published for the .NET Framework 2.0 to create Group Policy objects to deploy the .NET Framework 4. When doing this, you will need to apply an additional transform to each of the MSI files to prevent the installation from blocking you and telling you to run setup.exe instead. I have created an example transform that you can download from here for this scenario. This transform changes the condition for CA_BlockDirectInstall to False so it will not be run during the installation process.
Important note: when creating administrative install points and installing the .NET Framework 4 MSIs directly, it is your responsibility to install all of the prerequisites for these MSIs onto the target computer prior to attempting to install the MSIs. This includes the OS prerequisites listed here plus the OS update (.msu) files that are packaged with the .NET Framework 4 if you are running setup on Windows Vista or higher. If you do not install these prerequisites, then installing the MSIs will fail.
<update date="6/17/2010"> Added a link to a transform that can be used to bypass the custom actions in the .NET Framework 4 MSIs that prevent installing the MSI drectly and tell you to run setup.exe instead. </update>
<update date="9/18/2014"> Fixed broken link to the transform. </update>
Never mind. Once again I'm an idiot. I found your cleanup tool. Worked like a charm. Thanks for being a genius and putting this stuff online.
Sorry but I am little weak on this. I ran the commands in the instructions but I am unsure on which MSI I am suppose to use now. I have multiple MSI files in multiple locations.
I am wanting to put the MSI in a GPO
Hi Trev - I'd suggest referring to the .NET Framework Deployment Guide for Administrators for instructions about how to deploy the .NET Framework to a network of computers. You can find this deployment guide at msdn.microsoft.com/.../ee390831(v=VS.100).aspx.
I was hoping to avoid going that route. I have the MSI added to GPO correctly and I added the MST file you made, to the GPO but .Net still fails to install. I do use that same MST file for all of the MSI files? (core, extended,64 bit 32 bit etc..)I used Orca to run a validation test using the MSI and MST and received a ton of Mismatched component reference warning.
I followed your previous advise and removed the block from the MSI and its working great.
Thanks again. Your awesome!