Download .net Framework 4.6.1 Targeting Pack
Yanira Gauntner
This has confused me ever since I first started coding in C#. My goal is to create an assembly that will run on the most recent .NET framework the user has, whatever that may be. I don't want to require .NET 4 to be installed, but I want to use it if the user has it, and more importantly, I want it to still work if the user has only .NET 4 and nothing below. I'm beginning to suspect this is not even possible.
The frameworks are designed to be backwards-compatible; if you have a program written in .NET 2.0, you can run it in the 4.0 runtime, because none of the frameworks ever remove functionality that a prior version had (which is why we still have the non-generic collections like ArrayList, even though they're deprecated in favor of generic collections). However, the reverse is not necessarily true; a 4.0 app is not guaranteed to run in 2.0, because it MAY take advantage of new features of the new runtime that are not available in prior versions. In any case, if you want your app to attempt to run on runtime versions it does not specifically target, you must specify that in the app.config using SupportedRuntime elements.
Develop your app to target the EARLIEST framework version that you want to support. This will disable access to newer features of newer runtimes (like Linq in 3.5, and dynamic typing in 4.0) ensuring your app will not require any feature that cannot be provided by any of the supported runtimes.
Specify the frameworks that are acceptable to your application by using the SupportedRuntime element in your app.config file. This will tell the native code that initializes the runtime in which your app will run that if it can't find the targeted version, any of the others are acceptable. I believe the behavior is to look for the targeted framework first, and if not available it should use the newest supported runtime.
.NET is backward-compatible, this means if you select .NET Framework 2.0 as target framework, it will run on installed version 2.0, 3.0, 3.5 and 4.0. But if you select e.g version 4.0 as target framework, it will only run if you have version 4.0 installed.
You are also selecting language features when you pick this, so I know of no way that you would be able to use 4.0 framework features using an application targeting 2.0 framework. Even dynamically loading assemblies doesn't work, try loading a dll compiled to 4.0 from a 2.0 application, it won't let you.
In Visual Studio, you can specify the version of .NET that you want your project to target. Framework targeting helps guarantee that the application uses only functionality that is available in the specified framework version. For .NET Framework apps to run on another computer, the framework version that the application targets must be compatible with the framework version that's installed on the computer.
A Visual Studio solution can contain projects that target different versions of .NET. However, note that you can only build against a single version of .NET either using reference conditionals for a single build or recursively build different binaries for each version. For more information about target frameworks, see Target frameworks.
In an existing Visual Basic, C#, or F# project, you change the target .NET version in the project properties dialog box. For information about how to change the target version for C++ projects, see How to modify the target framework and platform toolset instead.
If your code contains references to a different version of the .NET than the one that you targeted, error messages may appear when you compile or run the code. To resolve these errors, modify the references. See Troubleshoot .NET targeting errors.
When you create a .NET Framework project, you can select the target .NET Framework version after you select a project template. The list of available frameworks includes the installed framework versions that are applicable to the selected template type. For non-.NET Framework project templates, for example .NET Core templates, the Framework drop-down list doesn't appear.
For .NET Framework projects, the Add Reference dialog box disables system assemblies that don't pertain to the target .NET Framework version so that they can't be inadvertently added to a project. (System assemblies are .dll files that are included in a .NET Framework version.) References that belong to a framework version that's higher than the targeted version won't resolve, and controls that depend on such a reference can't be added. If you want to enable such a reference, reset the .NET Framework target of the project to one that includes the reference.
When you target a framework in an app or library, you're specifying the set of APIs that you'd like to make available to the app or library. You specify the target framework in your project file using a target framework moniker (TFM).
The following table defines the most common target frameworks, how they're referenced, and which version of .NET Standard they implement. These target framework versions are the latest stable versions. Prerelease versions aren't shown. A target framework moniker (TFM) is a standardized token format for specifying the target framework of a .NET app or library.
A target framework is typically referenced by a TFM. The following table shows the target frameworks supported by the .NET SDK and the NuGet client. Equivalents are shown within brackets. For example, win81 is an equivalent TFM to netcore451.
Target frameworks are specified in a project file. When a single target framework is specified, use the TargetFramework element. The following console app project file demonstrates how to target .NET 8:
When you specify multiple target frameworks, you may conditionally reference assemblies for each target framework. In your code, you can conditionally compile against those assemblies by using preprocessor symbols with if-then-else logic.
The following library project targets APIs of .NET Standard (netstandard1.4) and .NET Framework (net40 and net45). Use the plural TargetFrameworks element with multiple target frameworks. The Condition attributes include implementation-specific packages when the library is compiled for the two .NET Framework TFMs:
The build system is aware of preprocessor symbols representing the target frameworks shown in the Supported target framework versions table when you're using SDK-style projects. To convert a .NET Standard, .NET Core, or .NET 5+ TFM to a preprocessor symbol, replace dots and hyphens with an underscore, and change lowercase letters to uppercase (for example, the symbol for netstandard1.4 is NETSTANDARD1_4).
Install a developer targeting pack to develop against the most recentversion of the .NET Framework in Visual Studio or another developmentenvironment, or download the .NET Framework redistributable fordistribution with your app or control.
The developer pack for .NET Framework 4.5.1 or 4.5.2, the targeting pack for .NET Framework 4.6, and the developer pack for .NET Framework 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, or 4.8 provides a particular .NET Framework's version of the reference assemblies, language packs, and IntelliSense files for use in an integrated development environment such as Visual Studio. If you are using Visual Studio, the developer pack or targeting pack also adds the installed version of the .NET Framework to the target choices when you create a new project.
I have just run into this problem: the solution would not build locally, because project A targeting .NET 4.5 was referencing project B targeting 4.6.1. The reference was ignored with a warning, and all attempts to use classes from project B led to compiler errors. Amazingly, the same commit compiled perfectly well on our build server.
Project A:
warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
warning MSB3274: The primary reference ProjectB.dll could not be resolved because it was built against the ".NETFramework,Version=v4.6.1" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.5".
I solved a problem with failing .dotnet Windows Updates by uninstalling all installed versions and reinstalling the latest version of .net on several computers without any problems. YMMV. You could make an image backup and try this. If some program fails to work, you could the restore your image.
I solved a problem with failing .dotnet Windows Updates by uninstalling all installed versions and reinstalling the latest version of .net on several computers without any problems. YMMV. You could make an image backup and try this. If some program fails to work, you could the restore your image. Jerry
Can I develop apps with different versions with Visual Studio 11 Beta? Sure, you can multi-target all these versions and even plugin more targeting packs. I'll do a blog post later this week on Portable Libraries, a new version in .NET 4.5 that makes creating libraries for any CLR (including Xbox, Phone, Mono and others).
Now I'll change the properties of my project from .NET 4.5 to .NET 4. I won't change anything else. I'll build. Note that the type isn't there, I get a build error and I can't reference the namespace. You will know if you're using new .NET 4.5 functionality. The multi-targeting build system was designed for this and existed as far back as .NET 3.5. Those reference assemblies are there to catch this kind of thing.
In a previous post, I made a recommendation of additionally targeting net461 in addition to netstandard2.0 in certain scenarios, however one of the nice things about targeting netstandard2.x is that on macOS you can install the .NET Core SDK, build it, and "it just works".
760c119bf3