I mentioned last time that any version of the .NET Framework beginning with ‘4’ is an in-place upgrade for any similar version with a lower minor version number. Applications that depend on .NET 4.0 as a minimum should run fine on any subsequent 4.x version. We need something to use as a prerequisite for such applications. Rather than force every computer in an organization to move up to the latest version, it would be more efficient to just use whatever version of .NET is included in the operating system. Note, though, that the .NET Framework feature can be turned off in some versions of Windows, so we do need an application package to ensure that it is turned on. With this in mind, let us build a new Configuration Manager Application.

Acquiring the Installation Files

We actually have everything we need already. All supported versions of Windows except for Windows 7 and Windows Server 2008 R2 have some 4.x version of .NET built in, and we can reuse our .NET 4.6.1 installer from last time to take care of the exceptions.

On your application staging file share (wherever you put application source files for Configuration Manager to find), create a folder for .NET 4.x. Mine will be \\fileserver\software$\Microsoft\.NET Framework 4.x. We don’t actually need any source files, and so as with .NET 3.5 on Windows 7 and .NET 4.6.1 on Windows 10 November Update, we will just provide Configuration Manager with a single file in that folder. I created a text file with Notepad in the folder containing the following text:

The following Microsoft .NET Framework 4.x versions are included as operating system compoments in the corresponding Windows versions, and so no content is required or available to install them on those versions.
-Windows 8/Windows Server 2012          .NET Framework 4.5
-Windows 8.1/Windows Server 2012 R2     .NET Framework 4.5.1
-Windows 10                             .NET Framework 4.6

Configuration Manager applications require a content folder, so this folder serves that role for the "Microsoft .NET Framework 4.x [Deploy as prerequisite only]" application's deployment types for these Windows versions.

That explains the presence of the otherwise empty folder to anyone reviewing this folder structure.

For Windows 7 and Windows Server 2008 R2, we will just install the latest version of .NET (4.6.1 at the time of this writing) in order to satisfy the requirement unless a lower 4.x version is detected.

Building the Configuration Manager Application

Windows 7 and Windows Server 2008 R2 (64-bit and 32-bit)

In the Configuration Manager Console, create a new Application. We are going to reuse the source folder and settings from our .NET 4.6.1 application package for our first deployment type. Here are the values I provided in mine:

I included the suffix “[Deploy as prerequisite only]” in the name of the package because it doesn’t make sense to show this package to users. If a user opens Software Center, he/she should see normal applications that can be installed, not supporting libraries with ambiguous names. Don’t deploy this Application on its own; just set it as a prerequisite for other Applications that need it. The bracketed text serves as a reminder of this principle.

Speaking of principles, I violated one of my own rules: There is no uninstallation program. This is acceptable because again, this is a prerequisite application, and also because this application package just ensures that an on-by-default feature is still turned on, on most systems. If you want users to be able to uninstall this application from Software Center in Windows 7, deploy the .NET 4.6.1 package we built last time as “available”, and it will be detected as already installed when this application is installed. Then the user can choose to uninstall it.

Finally, notice the detection logic. We don’t actually test for version 4.6.1; we merely test that some version of .NET 4.x has been installed. If the user has previously installed .NET 4.0, 4.5, 4.5.1, 4.5.2, 4.6, or 4.6.1, these will all signify that this application is already installed. Only if none of these is installed will .NET 4.6.1 be installed by Configuration Manager.

All Other Platforms

All of the other operating systems we are targeting can be satisfied by a single deployment type that merely turns on their built-in NetFx4 feature if it is turned off.

Here we use a Dism command to turn on the NetFx4 feature. This feature name refers to whichever 4.x version is built into the target platform, or, if it has already been upgraded, it turns on the upgraded replacement version. For example, Windows 8 includes .NET 4.5 as an OS feature, so turning on NetFx4 enables .NET 4.5 functionality. If .NET 4.5.2, for instance, has already been installed on Windows 8 and then disabled, turning on NetFx4 enables .NET 4.5.2 functionality.

Notice that we didn’t have to worry too much about Server Core in this application package. For the Windows 7/Server 2008 R2 deployment type, we just omit Server Core from the requirements as we did with the .NET 4.6.1 Application. For the other deployment type, since we are enabling an already-installed feature rather than running Microsoft’s buggy .NET 4.6.1 installer, there is nothing to worry about here regarding Server Core. The application package we just build will run fine on all supported platforms except a Server Core installation of Windows Server 2008 R2.

Coming Up

That wraps up our three-week focus on .NET Framework installation. Next time, we’ll build one more Global Condition to check a prerequisite, and then we’ll move on to the home stretch of building a robust Microsoft Office 2016 Application in Configuration Manager.