Update Excel and Word projects that You migrate to the .NET Framework 4.5
Applies to: Visual Studio Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
If you have an Excel or Word project that uses any of the following features, you must modify your code if the target framework is changed to the .NET Framework 4 or later:
Collections that derive from CollectionBase
You must also remove the
Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute
and references to theMicrosoft.Office.Tools.Excel.ExcelLocale1033Proxy
class from Excel projects that are retargeted to the .NET Framework 4 or later. Visual Studio doesn't remove this attribute or the class reference for you.
Remove the ExcelLocale1033 attribute from Excel projects
The Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute
has been removed from the portion of the Visual Studio 2010 Tools for Office runtime that is used for solutions that target the .NET Framework 4 or later. The common language runtime (CLR) in the .NET Framework 4 and later always passes locale ID 1033 to the Excel object model, and you can no longer use this attribute to disable this behavior. For more information, see Globalization and localization of Excel solutions.
To remove the ExcelLocale1033Attribute
With the project open in Visual Studio, open Solution Explorer.
Under the Properties node (for C#) or the My Project node (for Visual Basic), double-click the AssemblyInfo code file to open it in the code editor.
Note
In Visual Basic projects, you must click the Show All Files button in Solution Explorer to see the AssemblyInfo code file.
Locate the
Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute
and either remove it from the file or comment it out.<Assembly: ExcelLocale1033Proxy(True)>
[assembly: ExcelLocale1033Proxy(true)]
Remove a reference to the ExcelLocal1033Proxy class
Projects that were created by using Microsoft Visual Studio 2005 Tools for the Microsoft Office System instantiate the Excel Application object by using the Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy
class. This class has been removed from the portion of the Visual Studio 2010 Tools for Office runtime that's used for solutions that target the .NET Framework 4 or later. Therefore, you must remove or comment out the line of code that references this class.
To remove the reference to the ExcelLocal1033Proxy class
Open the project in Visual Studio, and then open Solution Explorer.
In Solution Explorer, open the shortcut menu for ThisAddin.cs (for C#) or ThisAddin.vb (for Visual Basic), and then choose View Code.
In the Code Editor, in the
VSTO generated code
region, remove or comment out the following line of code.Me.Application = CType(Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Wrap(GetType(Excel.Application), Me.Application), Excel.Application)
this.Application = (Excel.Application)Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Wrap(typeof(Excel.Application), this.Application);
Update code that uses the GetVstoObject and HasVstoObject methods
In projects that target the .NET Framework 3.5, the GetVstoObject
or HasVstoObject
methods are available as extension methods on one of the following native objects in your project: Document, Workbook, Worksheet, or ListObject. When you call these methods, you do not need to pass a parameter. The following code example demonstrates how to use the GetVstoObject method in a Word VSTO Add-in that targets the .NET Framework 3.5.
Dim vstoDocument as Microsoft.Office.Tools.Word.Document = _
Globals.ThisAddIn.Application.ActiveDocument.GetVstoObject()
Microsoft.Office.Tools.Word.Document vstoDocument =
Globals.ThisAddIn.Application.ActiveDocument.GetVstoObject();
In projects that target the .NET Framework 4 or later, you must modify your code to access these methods in one of the following ways:
You can still access these methods as extension methods on Document, Workbook, Worksheet, or ListObject objects. However, you must now pass the object returned by the
Globals.Factory
property to these methods.Dim vstoDocument as Microsoft.Office.Tools.Word.Document = _ Globals.ThisAddIn.Application.ActiveDocument.GetVstoObject(Globals.Factory)
Microsoft.Office.Tools.Word.Document vstoDocument = Globals.ThisAddIn.Application.ActiveDocument.GetVstoObject(Globals.Factory);
You can alternatively access these methods on the object that is returned by the
Globals.Factory
property. When you access these methods in this way, you must pass the native object that you want to extend to the method.Dim vstoDocument as Microsoft.Office.Tools.Word.Document = _ Globals.Factory.GetVstoObject(Globals.ThisAddIn.Application.ActiveDocument)
Microsoft.Office.Tools.Word.Document vstoDocument = Globals.Factory.GetVstoObject(Globals.ThisAddIn.Application.ActiveDocument);
For more information, see Extend Word documents and Excel workbooks in VSTO Add-ins at run time.
Update code that uses instances of the generated classes in document-level projects
In document-level projects that target the .NET Framework 3.5, the generated classes in the projects derive from the following classes in the Visual Studio Tools for Office runtime:
ThisDocument
: DocumentThisWorkbook
: WorkbookSheet
n: WorksheetChart
n: ChartSheetIn projects that target the .NET Framework 4 or later, the types in the Visual Studio Tools for Office runtime listed above are interfaces, instead of classes. The generated classes in projects that target the .NET Framework 4 or later derive from the following new classes in the Visual Studio Tools for Office runtime:
ThisDocument
: DocumentBaseThisWorkbook
: WorkbookBaseSheet
n: WorksheetBaseChart
n: ChartSheetBaseIf code in your project refers to an instance of one of the generated classes as the base class that it derives from, you must modify the code.
For example, in an Excel Workbook project that targets the .NET Framework 3.5, you might have a helper method that performs some work on instances of the generated
Sheet
n classes in your project.
Private Sub DoSomethingToSheet(ByVal worksheet As Microsoft.Office.Tools.Excel.Worksheet)
' Do something to the worksheet object.
End Sub
private void DoSomethingToSheet(Microsoft.Office.Tools.Excel.Worksheet worksheet)
{
// Do something to the worksheet object.
}
If you retarget the project to the .NET Framework 4 or later, you must make one of the following changes to your code:
Modify any code that calls the
DoSomethingToSheet
method to pass the Base property of a WorksheetBase object in your project. This property returns a Worksheet object.DoSomethingToSheet(Globals.Sheet1.Base)
DoSomethingToSheet(Globals.Sheet1.Base);
Modify the
DoSomethingToSheet
method parameter to expect a WorksheetBase object instead.Private Sub DoSomethingToSheet(ByVal worksheet As Microsoft.Office.Tools.Excel.WorksheetBase) ' Do something to the worksheet object. End Sub
private void DoSomethingToSheet (Microsoft.Office.Tools.Excel.WorksheetBase worksheet) { // Do something to the worksheet object. }
Update code that uses Windows Forms controls on documents
You must add a using (C#) or Imports (Visual Basic) statement for the Microsoft.Office.Tools.Excel or Microsoft.Office.Tools.Word namespace to the top of any code file that uses the Controls property to add Windows Forms controls to the document or worksheet programmatically.
In projects that target the .NET Framework 3.5, the methods that add Windows Forms controls (such as the AddButton
method) are defined in the ControlCollection and ControlCollection classes.
In projects that target the .NET Framework 4 or later, these methods are extension methods that are available on the Controls property. To use these extension methods, the code file in which you use the methods must have a using or Imports statement for the Microsoft.Office.Tools.Excel or Microsoft.Office.Tools.Word namespace. This statement is generated automatically in new projects that target the .NET Framework 4 or later. However, this statement is not added automatically in projects that target the .NET Framework 3.5, so you must add it when you retarget the project.
For more information, see Add controls to Office documents at run time.
Update code that handles Word content control events
In projects that target the .NET Framework 3.5, events of Word content controls are handled by the generic EventHandler<TEventArgs> delegate. In projects that target the .NET Framework 4 or later, these events are handled by other delegates.
The following table lists the Word content control events and the delegates that are associated with them in projects that target the .NET Framework 4 or later.
Event | Delegate to use in .NET Framework 4 and later projects |
---|---|
Added | ContentControlAddedEventHandler |
ContentUpdating | ContentControlContentUpdatingEventHandler |
Deleting | ContentControlDeletingEventHandler |
Entering | ContentControlEnteringEventHandler |
Exiting | ContentControlExitingEventHandler |
StoreUpdating | ContentControlStoreUpdatingEventHandler |
Update code that uses the OLEObject and OLEControl classes
In projects that target the .NET Framework 3.5, you can add custom controls (such as Windows Forms user controls) to a document or worksheet by using the Microsoft.Office.Tools.Excel.OLEObject
and Microsoft.Office.Tools.Word.OLEControl
classes.
In projects that target the .NET Framework 4 or later, these classes have been replaced by the ControlSite and ControlSite interfaces. You must modify code that refers to Microsoft.Office.Tools.Excel.OLEObject
and Microsoft.Office.Tools.Word.OLEControl
to instead refer to ControlSite and ControlSite. Other than the new names, these controls behave the same way that they do in projects that target the .NET Framework 3.5.
For more information, see Add controls to Office documents at run time.
Update code that uses the Controls.Item(Object) property
In projects that target the .NET Framework 3.5, you can use the Item(Object) property of the Microsoft.Office.Tools.Word.Document.Controls or Microsoft.Office.Tools.Excel.Worksheet.Controls
collection to determine whether a document or worksheet has a specified control.
In projects that target the .NET Framework 4 or later, the Item(Object) property has been removed from these collections. To determine whether a document or worksheet contains a specified control, use the Contains(System.Object) method of the Controls or Controls collection instead.
For more information about the Controls collection of documents and worksheets, see Add controls to Office documents at run time.
Update code that uses collections that derive from CollectionBase
In projects that target the .NET Framework 3.5, several collection types in the Visual Studio Tools for Office runtime derive from the CollectionBase class, such as Microsoft.Office.Tools.SmartTagCollection
, Microsoft.Office.Tools.Excel.ControlCollection
, and Microsoft.Office.Tools.Word.ControlCollection
.
In projects that target the .NET Framework 4 or later, these collection types are now interfaces that do not derive from CollectionBase. Some members are no longer available on these collection types, such as Capacity, List, and InnerList.