Net Framework 4.6 1 Targeting Pack Download

[Aleshia Ducharme]

InVisual 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.

It filters items in the Add New Item dialog box, the Add New Reference dialog box, and the Add Service Reference dialog box to omit choices that aren't available in the targeted version.

It filters custom controls in the Toolbox to remove those that aren't available in the targeted version and to show only the most up-to-date controls when multiple controls are available.

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 the .NET Framework 3.5 or later, a reference to System.Core and a project-level import for System.Linq (in Visual Basic only) are added automatically. If you want to use LINQ features, you must also turn Option Infer on (in Visual Basic only). The reference and import are removed automatically if you change the target to an earlier .NET Framework version. For more information, see Work with LINQ.

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.

I don't really understand what I'm selecting when I change the "Target Framework" in Visual Studio. Does that mean "will be compatible with this version and up"? Or "will be compatible with only this version"? It seems like it's the latter so far; my tests in virtual machines show .NET 4 targeted assemblies failing without .NET 4, and .NET 3.5 targeted assemblies failing without .NET 3.5. Is there no way to set this so I can achieve maximum compatibility?

UPDATE: To clarify, I have a program that targets .NET 2. The posters here seem to indicate that it should load with .NET 4. But in an environment with only .NET 4 and nothing before it, it fails to load.

UPDATE2: Okay, figured it out, but it's far more complex than the posters here seem to think. I'm opening a different question to discuss the intricacies, but the short version is, you need an app.config with in it if you want to run non-.NET 4 assemblies on .NET 4. They won't load without it.

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.

I have then installed .NET Framework 4.0.1 Targeting Pack and .NET Framework 4.0.2 Targeting Pack as I can't install 4.0.3, restarted the machine over an over, but Visual Studio continues not to show the framework on the dropdown menu.

I had this same thing after uninstalling VS2015 community, my VS2010 projects all started blowing up with this. My issue was I was missing FrameworkList.xml from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\RedistList. I copied from another machine and the problem went away.

In fact if you have a client Windows machine with .NET 4.0 installed and install 4.5 it will update both the client and extended profiles to 4.5 (and in 4.5 there is no client and extended profiles anymore, comes in full).

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).

An app or library can target a version of .NET Standard. .NET Standard versions represent standardized sets of APIs across all .NET implementations. For example, a library can target .NET Standard 1.6 and gain access to APIs that function across .NET Core and .NET Framework using the same codebase.

An app or library can also target a specific .NET implementation to gain access to implementation-specific APIs. For example, an app that targets Xamarin.iOS (for example, Xamarin.iOS10) has access to Xamarin-provided iOS API wrappers for iOS 10, or an app that targets Universal Windows Platform (UWP, uap10.0) has access to APIs that compile for devices that run Windows 10.

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.

The net5.0, net6.0, net7.0, and net8.0 TFMs include technologies that work across different platforms. Specifying an OS-specific TFM makes APIs that are specific to an operating system available to your app, for example, Windows Forms or iOS bindings. OS-specific TFMs also inherit every API available to their base TFM, for example, the net6.0 TFM.

.NET 5 introduced the net5.0-windows OS-specific TFM, which includes Windows-specific bindings for WinForms, WPF, and UWP APIs. .NET 6 and later versions have additional OS-specific TFMs, for example, net6.0-ios.

To make your app portable across different platforms but still have access to OS-specific APIs, you can target multiple OS-specific TFMs and add platform guards around OS-specific API calls using #if preprocessor directives. For a list of the available symbols, see Preprocessor symbols.

Cross-platform application models (Xamarin Forms, ASP.NET Core) and bridge packs (Xamarin Essentials) should at least target the base TFM, for example, net8.0, but might also target additional platform-specific flavors to light-up more APIs or features.

You can also specify an optional OS version at the end of an OS-specific TFM, for example, net6.0-ios15.0. The version indicates which APIs are available to your app or library. It doesn't control the OS version that your app or library supports at run time. It's used to select the reference assemblies that your project compiles against, and to select assets from NuGet packages. Think of this version as the "platform version" or "OS API version" to disambiguate it from the run-time OS version.

3a8082e126