Add .NET Framework-specific callouts

.openpublishing.redirection.framework.json

@@ -952,6 +952,10 @@
             "source_path_from_root": "/docs/framework/docker/index.md",
             "redirect_url": "/dotnet/framework"
         },
+        {
+            "source_path_from_root": "/docs/framework/get-started/the-net-framework-and-out-of-band-releases.md",
+            "redirect_url": "/dotnet/framework/get-started/out-of-band-releases"
+        },
         {
             "source_path_from_root": "/docs/framework/get-started/net-core-and-open-source.md",
             "redirect_url": "/dotnet/core/introduction"

docs/framework/64-bit-apps.md

@@ -8,13 +8,13 @@ helpviewer_keywords:
   - "64-bit programming [C++]"
 ms.assetid: fd4026bc-2c3d-4b27-86dc-ec5e96018181
 ---
-# 64-bit Applications
+# 64-bit applications
 
 When you compile an application, you can specify that it should run on a Windows 64-bit operating system either as a native application or under WOW64 (Windows 32-bit on Windows 64-bit). WOW64 is a compatibility environment that enables a 32-bit application to run on a 64-bit system. WOW64 is included in all 64-bit versions of the Windows operating system.
 
-## Running 32-bit vs. 64-bit Applications on Windows
+## Running 32-bit vs. 64-bit applications on Windows
 
- All applications that are built on the .NET Framework 1.0 or 1.1 are treated as 32-bit applications on a 64-bit operating system and are always executed under WOW64 and the 32-bit common language runtime (CLR). 32-bit applications that are built on the .NET Framework 4 or later versions also run under WOW64 on 64-bit systems.
+32-bit applications that are built on .NET Framework 4 or later versions run under WOW64 on 64-bit systems.
 
  Visual Studio installs the 32-bit version of the CLR on an x86 computer, and both the 32-bit version and the appropriate 64-bit version of the CLR on a 64-bit Windows computer. (Because Visual Studio is a 32-bit application, when it is installed on a 64-bit system, it runs under WOW64.)
 
@@ -26,11 +26,8 @@ When you compile an application, you can specify that it should run on a Windows
  Many assemblies run identically on both the 32-bit CLR and the 64-bit CLR. However, some programs may behave differently, depending on the CLR, if they contain one or more of the following:
 
 - Structures that contain members that change size depending on the platform (for example, any pointer type).
-
 - Pointer arithmetic that includes constant sizes.
-
 - Incorrect platform invoke or COM declarations that use `Int32` for handles instead of `IntPtr`.
-
 - Code that casts `IntPtr` to `Int32`.
 
  For more information about how to port a 32-bit application to run on the 64-bit CLR, see [Migrating 32-bit Managed Code to 64-bit](/previous-versions/dotnet/articles/ms973190(v=msdn.10)).

docs/framework/additional-apis/index.md

@@ -112,4 +112,4 @@ These APIs support the product infrastructure and are not intended or supported
 
 ## See also
 
-* [.NET Framework and Out-of-Band Releases](../get-started/the-net-framework-and-out-of-band-releases.md)
+* [.NET Framework and Out-of-Band Releases](../get-started/out-of-band-releases.md)

docs/framework/app-domains/assembly-placement.md

@@ -2,7 +2,7 @@
 title: "Assembly Placement"
 description: Review guidelines for .NET assembly placement within directories (for example, in the global assembly cache or in the application's directory or subdirectory).
 ms.date: "03/30/2017"
-helpviewer_keywords: 
+helpviewer_keywords:
   - "<codeBase> element"
   - "locating assemblies"
   - "assemblies [.NET Framework], placement"
@@ -11,10 +11,12 @@ ms.assetid: ff8d48bc-f606-484f-9fe1-d0af264269fb
 ---
 # Assembly Placement
 
-For most .NET Framework applications, you locate assemblies that make up an application in the application's directory, in a subdirectory of the application's directory, or in the global assembly cache (if the assembly is shared). You can override where the common language runtime looks for an assembly by using the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) in a configuration file. If the assembly does not have a strong name, the location specified using the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) is restricted to the application directory or a subdirectory. If the assembly has a strong name, the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) can specify any location on the computer or on a network.  
-
- Similar rules apply to locating assemblies when working with unmanaged code or COM interop applications: if the assembly will be shared by multiple applications, it should be installed into the global assembly cache. Assemblies used with unmanaged code must be exported as a type library and registered. Assemblies used by COM interop must be registered in the catalog, although in some cases this registration occurs automatically.  
-
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
+For most .NET Framework applications, you locate assemblies that make up an application in the application's directory, in a subdirectory of the application's directory, or in the global assembly cache (if the assembly is shared). You can override where the common language runtime looks for an assembly by using the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) in a configuration file. If the assembly does not have a strong name, the location specified using the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) is restricted to the application directory or a subdirectory. If the assembly has a strong name, the [\<codeBase> Element](../configure-apps/file-schema/runtime/codebase-element.md) can specify any location on the computer or on a network.
+
+ Similar rules apply to locating assemblies when working with unmanaged code or COM interop applications: if the assembly will be shared by multiple applications, it should be installed into the global assembly cache. Assemblies used with unmanaged code must be exported as a type library and registered. Assemblies used by COM interop must be registered in the catalog, although in some cases this registration occurs automatically.
+
 ## See also
 
 - [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md)

docs/framework/app-domains/build-multifile-assembly.md

@@ -22,6 +22,8 @@ ms.assetid: 261c5583-8a76-412d-bda7-9b8ee3b131e5
 ---
 # How to: Build a multifile assembly
 
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
 This article explains how to create a multifile assembly and provides code that illustrates each step in the procedure.
 
 > [!NOTE]

docs/framework/app-domains/build-single-file-assembly.md

@@ -18,6 +18,8 @@ ms.assetid: a6063221-43a5-4d3e-814c-288a4ec69aec
 ---
 # How to: Build a .NET Framework single-file assembly
 
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
 A single-file assembly, which is the simplest type of assembly, contains type information and implementation, as well as the [assembly manifest](../../standard/assembly/manifest.md). You can use command-line compilers or Visual Studio to create a single-file assembly that targets the .NET Framework. By default, the compiler creates an assembly file with an *.exe* extension.
 
 > [!NOTE]

docs/framework/app-domains/gac.md

@@ -2,7 +2,7 @@
 title: "Global Assembly Cache"
 description: Understand the global assembly cache, which is a computer-wide code cache where the common language runtime for .NET is installed.
 ms.date: "03/30/2017"
-helpviewer_keywords: 
+helpviewer_keywords:
   - "assemblies [.NET Framework], global assembly cache"
   - "GAC (global assembly cache)"
   - "ACLs [.NET Framework]"
@@ -14,28 +14,30 @@ ms.assetid: cf5eacd0-d3ec-4879-b6da-5fd5e4372202
 ---
 # Global Assembly Cache
 
-Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer.  
-
- You should share assemblies by installing them into the Global Assembly Cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the Global Assembly Cache to make them accessible to COM interop or unmanaged code.  
-
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
+Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer.
+
+ You should share assemblies by installing them into the Global Assembly Cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the Global Assembly Cache to make them accessible to COM interop or unmanaged code.
+
 > [!NOTE]
-> There are scenarios where you explicitly do not want to install an assembly into the Global Assembly Cache. If you place one of the assemblies that make up an application in the Global Assembly Cache, you can no longer replicate or install the application by using the **xcopy** command to copy the application directory. You must move the assembly in the Global Assembly Cache as well.  
-  
- There are two ways to deploy an assembly into the Global Assembly Cache:  
-  
-- Use an installer designed to work with the Global Assembly Cache. This is the preferred option for installing assemblies into the Global Assembly Cache.  
-  
-- Use a developer tool called the [Global Assembly Cache tool (Gacutil.exe)](../tools/gacutil-exe-gac-tool.md), provided by the Windows SDK.  
-  
+> There are scenarios where you explicitly do not want to install an assembly into the Global Assembly Cache. If you place one of the assemblies that make up an application in the Global Assembly Cache, you can no longer replicate or install the application by using the **xcopy** command to copy the application directory. You must move the assembly in the Global Assembly Cache as well.
+
+ There are two ways to deploy an assembly into the Global Assembly Cache:
+
+- Use an installer designed to work with the Global Assembly Cache. This is the preferred option for installing assemblies into the Global Assembly Cache.
+
+- Use a developer tool called the [Global Assembly Cache tool (Gacutil.exe)](../tools/gacutil-exe-gac-tool.md), provided by the Windows SDK.
+
     > [!NOTE]
-    > In deployment scenarios, use Windows Installer to install assemblies into the Global Assembly Cache. Use the Global Assembly Cache tool only in development scenarios, because it does not provide assembly reference counting and other features provided when using the Windows Installer.  
-  
- Starting with the .NET Framework 4, the default location for the Global Assembly Cache is **%windir%\Microsoft.NET\assembly**. In earlier versions of the .NET Framework, the default location is **%windir%\assembly**.  
-  
- Administrators often protect the systemroot directory using an access control list (ACL) to control write and execute access. Because the Global Assembly Cache is installed in a subdirectory of the systemroot directory, it inherits that directory's ACL. It is recommended that only users with Administrator privileges be allowed to delete files from the Global Assembly Cache.  
-  
- Assemblies deployed in the Global Assembly Cache must have a strong name. When an assembly is added to the Global Assembly Cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change.  
-  
+    > In deployment scenarios, use Windows Installer to install assemblies into the Global Assembly Cache. Use the Global Assembly Cache tool only in development scenarios, because it does not provide assembly reference counting and other features provided when using the Windows Installer.
+
+ Starting with the .NET Framework 4, the default location for the Global Assembly Cache is **%windir%\Microsoft.NET\assembly**. In earlier versions of the .NET Framework, the default location is **%windir%\assembly**.
+
+ Administrators often protect the systemroot directory using an access control list (ACL) to control write and execute access. Because the Global Assembly Cache is installed in a subdirectory of the systemroot directory, it inherits that directory's ACL. It is recommended that only users with Administrator privileges be allowed to delete files from the Global Assembly Cache.
+
+ Assemblies deployed in the Global Assembly Cache must have a strong name. When an assembly is added to the Global Assembly Cache, integrity checks are performed on all files that make up the assembly. The cache performs these integrity checks to ensure that an assembly has not been tampered with, for example, when a file has changed but the manifest does not reflect the change.
+
 ## See also
 
 - [Assemblies in .NET](../../standard/assembly/index.md)

docs/framework/app-domains/how-to-configure-an-application-domain.md

@@ -13,6 +13,8 @@ ms.assetid: 07ea8438-7a34-49f0-a7e8-3d6ff7e4a482
 ---
 # How to: Configure an Application Domain
 
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
 You can provide the common language runtime with configuration information for a new application domain using the <xref:System.AppDomainSetup> class. When creating your own application domains, the most important property is <xref:System.AppDomainSetup.ApplicationBase%2A>. The other **AppDomainSetup** properties are used mainly by runtime hosts to configure a particular application domain.
 
  The **ApplicationBase** property defines the root directory of the application. When the runtime needs to satisfy a type request, it probes for the assembly containing the type in the directory specified by the **ApplicationBase** property.

docs/framework/app-domains/how-to-create-an-application-domain.md

@@ -2,28 +2,30 @@
 title: "How to: Create an Application Domain"
 description: Review how to create an application domain in .NET. You can create an application domain to load assemblies to manage personally, or create one to execute code.
 ms.date: "03/30/2017"
-dev_langs: 
+dev_langs:
   - "csharp"
   - "vb"
   - "cpp"
-helpviewer_keywords: 
+helpviewer_keywords:
   - "application domains, creating"
 ms.assetid: ba1fa43e-49f5-47d9-bd7f-3024af16f4ba
 ---
 # How to: Create an Application Domain
 
-A common language runtime host creates application domains automatically when they are needed. However, you can create your own application domains and load into them those assemblies that you want to manage personally. You can also create application domains from which you execute code.  
-
- You create a new application domain using one of the overloaded **CreateDomain** methods in the <xref:System.AppDomain?displayProperty=nameWithType> class. You can give the application domain a name and reference it by that name.  
-
- The following example creates a new application domain, assigns it the name `MyDomain`, and then prints the name of the host domain and the newly created child application domain to the console.  
-
-## Example  
+[!INCLUDE [net-framework-specific](../includes/net-framework-specific.md)]
+
+A common language runtime host creates application domains automatically when they are needed. However, you can create your own application domains and load into them those assemblies that you want to manage personally. You can also create application domains from which you execute code.
+
+ You create a new application domain using one of the overloaded **CreateDomain** methods in the <xref:System.AppDomain?displayProperty=nameWithType> class. You can give the application domain a name and reference it by that name.
+
+ The following example creates a new application domain, assigns it the name `MyDomain`, and then prints the name of the host domain and the newly created child application domain to the console.
+
+## Example
 
  [!code-cpp[ADCreateDomain#2](../../../samples/snippets/cpp/VS_Snippets_CLR/ADCreateDomain/CPP/source2.cpp#2)]
  [!code-csharp[ADCreateDomain#2](../../../samples/snippets/csharp/VS_Snippets_CLR/ADCreateDomain/CS/source2.cs#2)]
- [!code-vb[ADCreateDomain#2](../../../samples/snippets/visualbasic/VS_Snippets_CLR/ADCreateDomain/VB/source2.vb#2)]  
-  
+ [!code-vb[ADCreateDomain#2](../../../samples/snippets/visualbasic/VS_Snippets_CLR/ADCreateDomain/VB/source2.vb#2)]
+
 ## See also
 
 - [Programming with Application Domains](application-domains.md#programming-with-application-domains)