Visual Studio Office Development (VSOD) Support Team

Office VBA: Reference downgrade problem

Ajay Bandooni — Mon, 23 Jan 2017 18:33:15 GMT

In the world of Office VBA programming, many a times there is a need to automate other Office applications from an Office application's VBA code. For example - You have Office 2016 installed on your machine and you would like to automate Excel from Word VBA. One of the ways to achieve this would be to go to the Word VBA project and add a reference to "Microsoft Excel 16.0 Object Library". This way of binding is called early binding. Also, there is another flavor of binding called "late binding". A detailed explanation of the Early binding/Late binding is mentioned in the below article: https://support.microsoft.com/en-us/kb/245115 You may face a problem related to the early binding in an environment where users use different versions of Office. Let's understand this with the help of an example. Suppose you have Office 2013 installed on your machine and you want to automate Excel from Word VBA code. To achieve this, you would add a reference of "Microsoft Excel 15.0 Object Library" in Word VBA project. Now if you use this VBA code on any machine where you have Office 2013 installed this will work fine. Also, if you try to run it on a machine with Office 2016, it will still run as the Office upgrades the references in your project to greater version. In this case if you check the references in the Word VBA project, you will find that the reference "Microsoft Excel 15.0 Object Library" has been upgraded to "Microsoft Excel 16.0 Object Library". If you save the Word file on a such a machine(with Office 2016) and then try to run the same file on a machine with lower version of Office (i.e. Office 2013, Office 2010 etc.), the code will fail to run due to missing reference since the VBA project cannot find the reference. This is by design. VBA references are upgraded but are not downgraded. So if your VBA code is being used in such an environment where users have different versions of Office, then late binding is the way to go. Since late binding doesn't involve working with references, this problem does not occur. Below is the example of code written using early and late binding: Early binding ========================================= Dim exApp As Excel.Application Dim exBooks As Excel.Workbooks Dim exBook As Excel.Workbook Set exApp = New Excel.Application exApp.Visible = True Set exBooks = exApp.Workbooks Set exBook = exBooks.Add() Late binding ========================================= Dim exApp As Object Dim exBooks As Object Dim exBook As Object Set exApp = CreateObject("Excel.Application") exApp.Visible = True Set exBooks = exApp.Workbooks Set exBook = exBooks.Add()

Considerations while reading/writing registry keys under HKLM from Office Addin in Office Click-to-Run

Jeeva Mahendran — Fri, 09 Dec 2016 01:09:50 GMT

An add-in running on Click-to-Run (C2R) version of Office (Office 365), which creates custom registry entries under HKLM hive, will have the registry entries created in the C2R portion of the registry . For example, if your add-in tries to create a registry entry HKLM\Software\MyCustomKey then it gets created as HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\MyCustomKey (Wow6432Node assuming 32-bit Office). This is by design as C2R version uses registry redirection to achieve Application Virtualization. If your add-in is the only one writing and reading these custom registry entries, there will be no problems as the registry redirection will happen in both the cases (writing/reading). However, you may see problems when you install Office updates. Since the C2R portion of the registry is owned by Office, the custom entries made might get deleted with Office update. This is also expected and is a by design behavior. So, the question is how can we create custom registry entries from our Office add-ins and get away with the threat that the C2R Office update brings. Well there isn’t an ideal solution/workaround for this but below are couple of workarounds that can be used : Workaround 1 You can create a logon script or something similar which periodically executes on the machine to do the following:

Check if C2R location contains your custom registry keys.
If yes, read those keys and store their state.
If not, create your registry key there using the state you had saved.

Pros of this strategy: Takes less development time, no code change in your existing product is needed Cons of this strategy: Not tightly integrated with your product, needs to run every login. Workaround 2 Have an external process which will be used to write/read custom registry. If your Office add-in which is loaded inside the Office address space creates a custom entry in registry, it will be redirected to C2R hive. To avoid this, create an external process outside Office . Whenever you need to read or write to registry, communicate with this process using something like windows messages or named pipes or .NET Remoting etc. This external process reads or writes the registry and communicate the results back to you. Pros of this strategy:

Tightly integrated with your product. You don’t need to run this every login.

Cons of this strategy:

Will involve some amount of development and code changes to your add-in.

After installing Office 2016 Version 1609 Office files containing VBA Form may hang the Office application [Update: Fixed in Office 2016, 1610 build]

Sangeeth Krishna — Tue, 25 Oct 2016 18:45:35 GMT

Issue If an Office file has a UserForm which has Cycle Property set to “2 – fmCycleCurrentForm” (or any other control which has this property set) then the Office application may hang while trying to show this UserForm in Office 2016 Version 1609. Cause This is a bug which is being worked by Product group. Workarounds a. Move to Version 1608 following the article below https://support.microsoft.com/en-us/kb/2770432 b. If there is a machine where you can open the file (older build of Office 2016 or older Office versions):

Open the file
Go to VBA IDE (by pressing alt + F11)
Go through each forms in design mode and see if any of them has ‘Cycle’ property as ‘2’(fmCycleCurrentForm).
If any form/frame has such value, make it ‘0’ (fmCycleAllForms).

Note: Issue can also occur if any ‘Frame’ control is set with cycle property ‘2’ as well Resolution This is fixed in Latest Version of Office 2016 Build : 1610.

VSTO Add-in may fail to load if signed by some SHA256 certificates [Update : Fixed with latest VSTO runtime]

Sangeeth Krishna — Thu, 28 Jan 2016 14:56:00 GMT

Symptom VSTO add-in may fail to load if all of the following conditions are true:-

The SHA256 certificate used to sign the add-in is based on SHA256 algorithm (http://www.w3.org/2000/09/xmldsig#rsa-sha256)
“Require Add-ins to be signed by Trusted publisher” setting is checked in Office Trust Center.
The deployment manifest is not accessible (For e.g. you installed the VSTO add-in from a network location or USB drive that is no longer accessible.)

If you have VSTO_SUPPRESSDISPLAYALERTS environment variable set to 0, you will receive an error "SignatureDescription could not be created for the signature algorithm supplied." Cause VSTO Click-Once infrastructure reads the deployment manifest to know the signature algorithm (in this case SHA256 algorithm “http://www.w3.org/2000/09/xmldsig#rsa-sha256).In a case where it cannot find the deployment manifest, it goes with default values which don’t have support for SHA256 algorithm, and thus the error. Work Around Any of the following workarounds will avoid the issue: 1. Use SHA256 certificates to sign manifest which uses http://www.w3.org/2000/09/xmldsig#rsa-sha1 algorithm 2. Make sure the install location is always accessible 3. Uncheck “Require Add-ins to be signed by Trusted publisher” Resolution This issue is resolved in the updated VSTO Runtime which can be installed from the link https:\\aka.ms\vstoruntime

Considerations for common performance issues with Office Add-ins and Macros in Office 2013

cts-praghav@outlook.com — Mon, 28 Sep 2015 10:58:00 GMT

The intent of this blog post is to address frequent questions that we see comparing performance difference between Office 2010 and 2013, especially by developers who use Office as a development platform via macros using VBA, add-ins, COM add-ins and interop using C++ / a .Net languages such as C#, VB.Net. Before we compare the performance between versions, it is very important to note that the hardware plays a critical role. So, it is important to try and match the hardware (CPU, RAM, disk type etc...) to make sure the performance issue that is affecting is not due to these changes. Firstly, let’s take a look at the changes that have been done to Microsoft Office 2013. Secondly, let’s look at frequent issues an Office developer would experience and subsequently with a possible tip / workaround to reduce the performance impact.

There are a lot of features that have been added to Microsoft Office 2013 as a whole, which might contribute to the general slowness in some development scenarios. For e.g. invoking a method from Object Model. While every effort has been done to make sure that the performance does not deteriorate drastically, but as one can understand new feature needs more code to be executed which implies slower operation / execution.
Microsoft Office 2013 introduced a design change in rendering of UI. Office applications have moved from traditional GDI+ rendering, to DirectX based rendering.
Excel 2013 has moved from Multiple Document Interface (MDI) to Single Document Interface (SDI).

Programming for the Single Document Interface in Excel

The following are few tips / workaround that might help you.

Make sure you have updated Office to the latest and greatest as the issue may have been addressed in latest patches.

The below article talks about best practices that could be considered for performance issues with Excel VBA.

Excel VBA Performance Coding Best Practices

The below article talks about performance issues arising out of incompatible third party video drivers.

Performance and display issues in Office 2013 client applications

Check “Disable hardware graphics acceleration” check box under File-> Options -> Advanced -> Display section. (See screenshot below).

Uncheck “Animate controls and elements inside windows” check box under System -> Advanced System Settings -> Advanced -> Performance Options -> Settings. (See screenshot below).

Using “ScreenUpdating” property appropriately would help to speed up your macro code execution.

Application.ScreenUpdating Property

Using “DoEvents” function appropriately would help in yielding execution so that the operating system can process pending messages/actions.

DoEvents Function

In a scenario where your macro executes many individual copy and paste operation and it takes longer than expected to complete the copy and paste operations, consider setting “AcbControl” registry as explained in the below KB article. This is applicable to Excel 2010 and Excel 2013. Remember to use the appropriate registry key location (14.0 for Excel 2010 and 15.0 for Excel 2013).

Description of the Office 2010 hotfix package (Mso-x-none.msp): August 13, 2013

There is slowness in certain Object Model calls, like Protect and Unprotect of a document.

Excel macros that protect and unprotect worksheets may run slowly

While comparing performance between Office versions, it is advisable to use similar configuration machines. Adding logs to the application might help in identifying which call(s) take long time for execution. Hope this information is helpful. I will try to keep this post up-to-date. Update : Note that these tips/points are also applicable to Office 2016.

After installing MS15-022 update you may not be able to run HTML script under Office context

Sangeeth Krishna — Wed, 13 May 2015 17:17:00 GMT

Symptom

After installing MS15-022 update you may not be able to run HTML script under Office context

Cause

This security update opts Microsoft Word, Excel, or PowerPoint into local computer lockdown, a feature control for Internet Explorer, to prevent scripts in Office documents from running with elevated user rights.

Here are documentations which explains this security change:

Microsoft Security Bulletin MS15-022 - Critical

https://technet.microsoft.com/en-us/security/ms15-022

MS15-022: Description of the security update for Microsoft Excel 2010: March 10, 2015 [known Issues Section]

https://support.microsoft.com/en-us/kb/2956142/

Work Around

The workaround is to make the html run in lesser user rights/zone than Local Computer Zone. The Mark of the Web (MOTW) is a feature of Windows Internet Explorer that enhances security. MOTW enables Internet Explorer to force webpages to run in the security zone of the location the age was saved from—as long as that security zone is more restrictive than the Local Machine zone—instead of the Local Machine zone. When you are developing webpages, the MOTW enables you to test your HTML documents in the security zone where you intend the pages to run. Adding the MOTW to your webpages also enables you to fully test their compatibility with users' security settings.

Read more about Mark of the Web from the link below:

https://msdn.microsoft.com/en-us/library/ms537628(v=vs.85).aspx

Mark Of the Web - Example 1 :

Mark Of the Web - Example 2 [Localhost] :

Note: Based on the end users security for Internet zone/Intranet Zone you may have to add the "Saved From url" into security zone

==========================================================================================

Microsoft Security Bulletin MS15-022 - Critical

https://technet.microsoft.com/en-us/security/ms15-022

MS15-022: Description of the security update for Microsoft Excel 2010: March 10, 2015 [known Issues Section]

https://support.microsoft.com/en-us/kb/2956142/

Mark of the Web

https://msdn.microsoft.com/en-us/library/ms537628(v=vs.85).aspx

Using MSBUILD through command line or from TFS Server to compile VSTO projects may fail with error 'The "SignFile" task could not be initialized with its input parameters'

Sangeeth Krishna — Tue, 10 Feb 2015 10:27:00 GMT

Symptom

You may get the following errors if you try to compile VSTO Projects through MSBUILD through command line or from TFS Server Post Visual Studio Update 3

C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\v12.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (268): The "TargetFrameworkVersion" parameter is not supported by the "SignFile" task. Verify the parameter exists on the task, and it is a settable public instance property.

C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\v12.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (264): The "SignFile" task could not be initialized with its input parameters.

Cause

Visual Studio 2013 Update 3 also brings some changes in VSTO Targets file. These changes are known only by MSBUILD 12.0 components.

Work Around

1) If you are using TFS make sure Build Process Profile to be version 12.0 (like, “TfvsTemplate.12.xaml” )

Steps:

Edit build Definition from Team Explorer
Click Process tab
Pick “TfvsTemplate.12.xaml” from the Build Process Template selection instead of “Default Template”

2) If you are building locally make sure the MSBUILD used is version 12.0:

On 32-bit machines they can be found in: C:\Program Files\MSBuild\12.0\bin
On 64-bit machines the 32-bit tools will be under: C:\Program Files (x86)\MSBuild\12.0\bin
and the 64-bit tools under: C:\Program Files (x86)\MSBuild\12.0\bin\amd64

Additional Information

Customize your build process template

http://msdn.microsoft.com/en-us/library/dd647551.aspx

MSBuild is now part of Visual Studio!

http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx

ActiveProject.CustomDocumentProperties may return ‘null’ for Applications Compiled using Visual Studio 2010 C# express edition

Sangeeth Krishna — Thu, 15 May 2014 13:05:00 GMT

Few days back I worked on an issue where an application compiled using Visual Studio 2010 C# Express edition was getting ‘null’ at “Application.ActiveProject.CustomDocumentProperties” when trying to follow below article :

How to Use Automation to Get and to Set Office Document Properties with Visual C# .NET
http://support.microsoft.com/kb/303296/en-us

Cause

The issue was found to be due to a bug in the NOPIA code generated by Visual Studio 2010 C# express edition. This issue is fixed in the latest versions of Visual Studio Express editions (VS 2012 Express Edition for C# or VS 2013 Express Edition for C#)

Work Around

Set the “Embed Interop Types” property to “False” for the MSProject PIA references added to project

Office automation through VC++ using MFC Class from TypeLib results into large number of compilation errors

abhitri — Tue, 04 Jun 2013 16:18:00 GMT

When trying to Automate Excel, Word, etc using VC++ (MFC based application) in Visual Studio 2010 we generally perform the following steps –

1-Go to Visual Studio

2-Click New Project

3-Expand Visual C++ tree node

4-Choose MFC

5-Select MFC Application

6-Enter project name, click OK

7-Choose a dialog based project

8-Click Finish

9-The bare bone project is created

In order to add an MFC Class from Typelib, we do the following –

10-Right click project -> Add -> Class

11-Select “MFC Class from TypeLib” , say Add

12-In the list of available type libraries, choose Microsoft Excel 14.0 Object Library

13-Then choose the list of classes you are planning to use in
the project, eg, _Application, _Workbook etc

Once you are done, you will see the relevant header files
being added – eg- CApplication.h, CWorkbook.h etc

Now in order to automate, you will be required to include
the appropriate header file in your projects cpp file, eg, TestDlg.cpp

Eg, #include "CApplication.h"

#include "CWorkbook.h"

Now begins the trouble -

As soon as you include the respective header files, you will
be presented with a huge number of errors (300+ errors) being thrown during
compilation.

Some errors may appear like –

error C2011: 'Picture' : 'struct' type redefinition

syntax error : identifier 'MsoRGBType'

syntax error : ''

etc, etc, etc

In order to resolve these mean errors, you need to do a small step –

Go to the top of each header file and locate the following
line

#import "C:\\Program Files(x86)\\Microsoft Office\\Office14\\EXCEL.EXE" no_namespace

Comment this line for each Excel(Office) related header files individually in order to get rid of the compilation errors.

Customizing Office 2013 backstage

Ajay Bandooni — Fri, 05 Apr 2013 06:54:00 GMT

Office 2013 introduced many changes to the backstage. In this blog post we will see how Office 2013 backstage can be customized using the backstage XML. The list of idMso’s for Office 2013 can be downloaded from: http://www.microsoft.com/en-us/download/details.aspx?id=36798.

We’ll modify the blog post based on your feedbacks.

Let’s get started with the idMso(s) of the common commands in Office 2013:

Now, let’s have a look at some of the common backstage customization scenarios and the XML used:

Adding a custom task in the “Open” tab

To achieve the above, following XML can be used: