Acrolynx changes

Author: v-masebo

docs/vsto/microsoft-office-is-not-installed-on-this-computer.md

@@ -1,5 +1,5 @@
 ---
-title: "Microsoft Office is not installed on this computer | Microsoft Docs"
+title: "Microsoft Office is not installed on this computer"
 ms.custom: ""
 ms.date: "02/02/2017"
 ms.technology: 
@@ -17,7 +17,7 @@ ms.workload:
   - "office"
 ---
 # Microsoft Office is not installed on this computer
-  Visual Studio cannot find the Microsoft Office application that corresponds to the project type. If you are developing an VSTO Add-in project, this means that you cannot debug or run the project. If you are trying to create a document-level project, this means that you cannot create the project.  
+  Visual Studio cannot find the Microsoft Office application that corresponds to the project type. If you are developing a VSTO Add-in project, it means that you cannot debug or run the project. If you are trying to create a document-level project, this means that you cannot create the project.  
 
 ### To correct this error  
 

docs/vsto/one-or-more-properties-in-the-dot-ofs-file-are-not-valid-for-the-message-class-selected.md

@@ -1,5 +1,5 @@
 ---
-title: "One or more properties in the .ofs file are not valid for the message class selected | Microsoft Docs"
+title: "One or more properties in the .ofs file are not valid for the message class selected"
 ms.custom: ""
 ms.date: "02/02/2017"
 ms.technology: 
@@ -19,13 +19,13 @@ ms.workload:
 # One or more properties in the .ofs file are not valid for the message class selected
   This error appears when you import a form region that is designed in Outlook, but one or more fields on the form region are not compatible with the message classes that you select on the final page of the **New Form Region** wizard.  
 
- For example, you might select **Task (IPM.Task)** on the final page of the **New Form Region** wizard. If the form region contains a **Business Address** field, you will receive this error because a task does not have a business address. Therefore, the **Business Address** field is not compatible with the `IPM.Task` message class.  
+ For example, you might select **Task (IPM.Task)** on the final page of the **New Form Region** wizard. If the form region has a **Business Address** field, you'll receive an error. The error is because a task does not have a business address, and the **Business Address** field is not compatible with the `IPM.Task` message class.  
 
 ### To correct this error  
 
 -   On the final page of the **New Form Region** wizard, select a message class that is compatible with the fields on the form region.  
 
--   In the Forms Designer in Outlook, remove fields that are not compatible with the message classes that you plan to select on the final page of the **New Form Region** wizard.  
+-   In the Forms Designer in Outlook, remove fields that are not compatible with the message classes. Remove fields that you plan to select on the final page of the **New Form Region** wizard.  
 
 ## See also  
  [Walkthrough: Import a form region that is designed in Outlook](../vsto/walkthrough-importing-a-form-region-that-is-designed-in-outlook.md)  

docs/vsto/registry-entries-for-vsto-add-ins.md

@@ -25,7 +25,7 @@ ms.workload:
 
  [!INCLUDE[appliesto_allapp](../vsto/includes/appliesto-allapp-md.md)]  
 
- When you build your project, Visual Studio creates these registry entries on the development computer so that you can easily run and debug the VSTO Add-in. If you use ClickOnce to deploy your VSTO Add-in, the registry entries are automatically created on the end user computer. If you use Windows Installer to deploy your VSTO Add-in, you must configure the InstallShield Limited Edition project to create the registry entries on the end user computer.  
+ When you build your project, Visual Studio creates these registry entries on the development computer so that you can easily run and debug the VSTO Add-in. If you use ClickOnce to deploy your VSTO Add-in, the registry entries are automatically created on the end-user computer. If you use Windows Installer to deploy your VSTO Add-in, you must configure the InstallShield Limited Edition project to create the registry entries on the end-user computer.  
 
  For more information about how the registry entries are used during the load process for VSTO Add-ins, see [Architecture of VSTO Add-ins](../vsto/architecture-of-vsto-add-ins.md).  
 
@@ -35,9 +35,9 @@ ms.workload:
 ## Register VSTO Add-ins for the current user vs. all users  
  When a VSTO Add-in is installed, it can be registered in two ways:  
 
--   For the current user only (that is, it is available only to the user that is logged onto the computer when the VSTO Add-in is installed). In this case, the registry entries are created under the **HKEY_CURRENT_USER**.  
+-   For the current user only (that is, it is available only to the user that is logged on to the computer when the VSTO Add-in is installed). In this case, the registry entries are created under the **HKEY_CURRENT_USER**.  
 
--   For all users (that is, any user that logs onto the computer can use the VSTO Add-in). In this case, the registry entries are created under **HKEY_LOCAL_MACHINE**.  
+-   For all users (that is, any user that logs on to the computer can use the VSTO Add-in). In this case, the registry entries are created under **HKEY_LOCAL_MACHINE**.  
 
  All VSTO Add-ins that you create by using Visual Studio can be registered for the current user. However, VSTO Add-ins can be registered for all users only in certain scenarios. These scenarios depend on the version of Microsoft Office on the computer and how the VSTO Add-in was deployed.  
 
@@ -80,21 +80,21 @@ ms.workload:
 
  *Root*\Software\Microsoft\Office\Outlook\FormRegions\\*message class*  
 
- Like the other registry entries shared by all VSTO Add-ins, Visual Studio creates the form region registry entries on the development computer when you build your project. If you use ClickOnce to deploy your VSTO Add-in, the registry entries are automatically created on the end user computer. If you use Windows Installer to deploy your VSTO Add-in, you must configure the InstallShield Limited Edition project to create the registry entries on the end user computer.  
+ Like the other registry entries shared by all VSTO Add-ins, Visual Studio creates the form region registry entries on the development computer when you build your project. If you use ClickOnce to deploy your VSTO Add-in, the registry entries are automatically created on the end-user computer. If you use Windows Installer to deploy your VSTO Add-in, you must configure the InstallShield Limited Edition project to create the registry entries on the end-user computer.  
 
  For more information about the form region registry entries, see [Specify the location of a form region in a custom form](http://msdn.microsoft.com/library/office/ff868998.aspx). For more information about Outlook form regions, see [Create Outlook form regions](../vsto/creating-outlook-form-regions.md).  
 
 ##  <a name="LoadBehavior"></a> LoadBehavior values  
  The **LoadBehavior** entry under the *Root*\Software\Microsoft\Office\\*application name*\Addins\\*add-in ID* key contains a bitwise combination of values that specify the run time behavior of the VSTO Add-in. The lowest order bit (values 0 and 1) indicates whether the VSTO Add-in is currently unloaded or loaded. Other bits indicate when the application attempts to load the VSTO Add-in.  
 
- Typically, the **LoadBehavior** entry is intended to be set to 0, 3, or 16 (in decimal) when the VSTO Add-in is installed on end user computers. By default, Visual Studio sets the **LoadBehavior** entry of your VSTO Add-in to 3 when you build or publish it.  
+ Typically, the **LoadBehavior** entry is intended to be set to 0, 3, or 16 (in decimal) when the VSTO Add-in is installed on end-user computers. By default, Visual Studio sets the **LoadBehavior** entry of your VSTO Add-in to 3 when you build or publish it.  
 
  The following table lists all the possible values of the **LoadBehavior** entry. Some descriptions in this table refer to loading a VSTO Add-in manually or programmatically. To load a VSTO Add-in manually, select the check box next to the VSTO Add-in in the **COM Add-Ins** dialog box in the application. To load a VSTO Add-in programmatically, set the <xref:Microsoft.Office.Core.COMAddIn.Connect%2A> property of the <xref:Microsoft.Office.Core.COMAddIn> object that represents the VSTO Add-in to **true**.  
 
 |Value (in decimal)|VSTO Add-in status|VSTO Add-in load behavior|Description|  
 |--------------------------|-------------------------|--------------------------------|-----------------|  
 |0|Unloaded|Do not load automatically|The application never tries to load the VSTO Add-in automatically. The user can try to manually load the VSTO Add-in, or the VSTO Add-in can be loaded programmatically.<br /><br /> If the VSTO Add-in is successfully loaded, the **LoadBehavior** value remains 0, but the status of the VSTO Add-in in the **COM Add-ins** dialog box is updated to indicate that the VSTO Add-in is loaded.|  
-|1|Loaded|Do not load automatically|The application never tries to load the VSTO Add-in automatically. The user can try to manually load the VSTO Add-in, or the VSTO Add-in can be loaded programmatically.<br /><br /> Although the **COM Add-ins** dialog box indicates that the VSTO Add-in is loaded after the application starts, the VSTO Add-in isn't actually loaded until it is loaded manually or programmatically.<br /><br /> If the application successfully loads the VSTO Add-in, the **LoadBehavior** value changes to 0, and remains at 0 after the application closes.|  
+|1|Loaded|Do not load automatically|The application never tries to load the VSTO Add-in automatically. The user can try to manually load the VSTO Add-in, or the VSTO Add-in can be loaded programmatically.<br /><br /> Although the **COM Add-ins** dialog box indicates that the VSTO Add-in is loaded after the application starts, the VSTO Add-in isn't loaded until it is loaded manually or programmatically.<br /><br /> If the application successfully loads the VSTO Add-in, the **LoadBehavior** value changes to 0, and remains at 0 after the application closes.|  
 |2|Unloaded|Load at startup|The application does not try to load the VSTO Add-in automatically. The user can try to manually load the VSTO Add-in, or the VSTO Add-in can be loaded programmatically.<br /><br /> If the application successfully loads the VSTO Add-in, the **LoadBehavior** value changes to 3, and remains at 3 after the application closes.|  
 |3|Loaded|Load at startup|The application tries to load the VSTO Add-in when the application starts. This is the default value when you build or publish a VSTO Add-in in Visual Studio.<br /><br /> If the application successfully loads the VSTO Add-in, the **LoadBehavior** value remains 3. If an error occurs when loading the VSTO Add-in, the **LoadBehavior** value changes to 2, and remains at 2 after the application closes.|  
 |8|Unloaded|Load on demand|The application does not try to load the VSTO Add-in automatically. The user can try to manually load the VSTO Add-in, or the VSTO Add-in can be loaded programmatically.<br /><br /> If the application successfully loads the VSTO Add-in, the **LoadBehavior** value changes to 9.|  

docs/vsto/required-changes-to-run-office-projects-that-you-migrate-to-the-dotnet-framework-4-or-the-dotnet-framework-4-5.md

@@ -16,7 +16,7 @@ manager: douge
 ms.workload: 
   - "office"
 ---
-# Required Changes to Run Office Projects that You Migrate to the .NET Framework 4 or the .NET Framework 4.5
+# Required changes to run Office projects that you migrate to the .NET Framework 4 or the .NET Framework 4.5
   If the target framework of an Office project is changed to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or later from an earlier version of the .NET Framework, you must perform the following tasks to ensure that the solution can run on the development computer and on end user computers:  
 
 -   Remove the <xref:System.Security.SecurityTransparentAttribute> from the project if you upgraded it from Visual Studio 2008.  
@@ -29,10 +29,10 @@ ms.workload:
 
  For more information about each of these tasks, see the corresponding sections below.  
 
-## Removing the SecurityTransparent Attribute from Projects that You Upgrade from Visual Studio 2008  
+## Remove the SecurityTransparent attribute from projects that you upgrade from Visual Studio 2008  
  If you upgrade an Office project from Visual Studio 2008 and the target framework of the project subsequently changes to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or later, you must remove the <xref:System.Security.SecurityTransparentAttribute> from the project. Visual Studio does not automatically remove this attribute for you. If you do not remove this attribute, you receive an error message when you compile the project.  
 
- For more information about the conditions in which Visual Studio can change the target framework of an upgraded project to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or the [!INCLUDE[net_v45](../vsto/includes/net-v45-md.md)], see [Upgrading and Migrating Office Solutions](../vsto/upgrading-and-migrating-office-solutions.md).  
+ For more information about the conditions in which Visual Studio can change the target framework of an upgraded project to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or the [!INCLUDE[net_v45](../vsto/includes/net-v45-md.md)], see [Upgrade and migrate Office solutions](../vsto/upgrading-and-migrating-office-solutions.md).  
 
 #### To remove the SecurityTransparentAttribute  
 
@@ -53,20 +53,20 @@ ms.workload:
     [assembly: SecurityTransparent()]  
     ```  
 
-## Performing the Clean Command to Debug or Run a Project on the Development Computer  
+## Perform the clean command to debug or run a project on the development computer  
  If an Office project was built before the target framework of the project is changed to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or later, you must perform a **Clean** command and then rebuild the project after the target framework is changed. If do not perform a **Clean** command, you will receive a <xref:System.Runtime.InteropServices.COMException> when you try to debug or run the retargeted project.  
 
- For more information about the **Clean** command, see [Building Office Solutions](../vsto/building-office-solutions.md).  
+ For more information about the **Clean** command, see [Build Office solutions](../vsto/building-office-solutions.md).  
 
-## Updating the Prerequisites for Deployment  
+## Update the prerequisites for deployment  
  When you retarget an Office project to [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or later, you must also update the corresponding .NET Framework prerequisite in the **Prerequisites** dialog box. Otherwise, the ClickOnce deployment or InstallShield Limited Edition project checks for and installs a previous version of the .NET Framework.  
 
- For more information about updating the prerequisites for deployment to end user computers, see [How to: Install Prerequisites on End User Computers to Run Office Solutions](http://msdn.microsoft.com/en-us/74dd2c52-838f-4abf-b2b4-4d7b0c2a0a98).  
+ For more information about updating the prerequisites for deployment to end user computers, see [How to: Install prerequisites on end user computers to run Office solutions](http://msdn.microsoft.com/en-us/74dd2c52-838f-4abf-b2b4-4d7b0c2a0a98).  
 
-## Reinstalling Solutions on End User Computers  
+## Reinstall solutions on end user computers  
  If you use ClickOnce to deploy an Office solution that targets the .NET Framework 3.5 and then you retarget the project to the [!INCLUDE[net_v40_short](../sharepoint/includes/net-v40-short-md.md)] or later, end users must uninstall the solution and then reinstall the solution after you republish it. If you republish the retargeted solution and the solution is updated on end user computers, end users will receive a <xref:System.Runtime.InteropServices.COMException> when they run the updated solution.  
 
-## See Also  
- [Migrating Office Solutions to the .NET Framework 4 or later](../vsto/migrating-office-solutions-to-the-dotnet-framework-4-or-later.md)  
+## See also  
+ [Migrate Office solutions to the .NET Framework 4 or later](../vsto/migrating-office-solutions-to-the-dotnet-framework-4-or-later.md)