Remotely Opening Office Files From SharePoint 2010

by Scosby Monday, August 22, 2011


Developing a client side application for SharePoint capable of opening files in their native Office application does not require very much code for a robust solution. This post will explore how to use the well documented SharePoint.OpenDocuments ActiveX control from managed code instead of from Javascript in a Web Browser. This approach will provide the end users with a familiar SharePoint experience in the application.


There are at least three obvious and important questions to ask regarding this topic:

·         Why not start a new process using the file’s URL?

·         Why not download the file to a temporary location?

·         Why not write a monolithic switch statement, using a handful of Office interop assemblies?

Start Process

The first question asks what is wrong with starting a new process for the file’s URL. This approach is indeed the most simple. However, undesired behavior can occur when attempting to open files from within folders of a document library.

Download File

The second question asks what is wrong with downloading the file. This approach seems more reasonable. However, there is no out-of-the-box integration with SharePoint given this approach. Additionally, this creates a burden on the application to clean up the downloaded file after it is no longer needed.

Interop Assemblies

The third question asks why not write a switch statement to determine which Office interop assembly should be used to open the file? This approach requires much more code. Additionally, it would be an edge case to need such a high level of complexity for opening Office files.


Fortunately, the three problems described in this post are easily solved using the existing Office tools provided by Microsoft. In particular, SharePoint developers are likely familiar with the SharePoint.OpenDocuments ActiveX control, used by Javascript in a Web Browser, to perform the task at hand.

The SharePoint.OpenDocuments control is defined in the OWSSUPP.dll file that is installed in the %ProgramFiles%\Microsoft Office\Office14 directory on the client computer during Microsoft Office Setup. This assembly is not well documented, but it is the one used by the SharePoint.OpenDocuments control.

Given this information, the reader can navigate through the OWSSUPP assembly with the Visual Studio Object Browser and discover the matching methods needed for the managed code solution. The next section will explain the SharePoint.OpenDocuments control, so the reader can gain a foundation to build upon in the code sample.

SharePoint.OpenDocuments Control

According to the documentation, the control is defined as “An ActiveX control that enables users of Microsoft SharePoint Foundation 2010 to create documents based on a specified template, or to edit documents using their associated applications.”

In other words, this control enables a developer to open a specific Office file from SharePoint in its native Office application on the client. When used in managed code, the control will display the familiar Open Document dialog for Office applications (see figure 1).


Figure 1 – The Open Document dialog is shown when opening a file from SharePoint

This post will focus on the OpenDocuments.ViewDocument method. As stated in the documentation, this method “opens the document for reading instead of editing, so that the document is not locked on the server.” This behavior is best for a majority of scenarios. By using this method, the developer allows the end user to decide when to edit or lock the document on the SharePoint server.

Code Sample

This code sample uses a hardcoded URL to open a file. However, real world applications will be working with URLs from many different sources, such as search results or views. The developer needs the following version of Office to complete this code sample:

·         Microsoft Office 2010 (2007 should work but not 2003)

o    32-Bit

The code sample will use a console application to open a hardcoded URL for an Office file by using the COWSNewDocument interface and the IOWSNewDocument2 interface.

1.       Create a new console application in Visual Studio.

2.       Right click the project’s References and select Add Reference.

3.       The developer will not find the OWSSUPP components in the COM tab. Thus, select the Browse tab and navigate to %ProgramFiles%\Microsoft Office\Office14\OWSSUPP.DLL to add the reference to the project.

4.       Double click the newly added OWSSUPP assembly in the console application’s References list to open the Object Browser.

5.       Using the Object Browser, navigate into the Interop.OWSSUPP assembly. Expand the OWSSUPP namespace and explore its members. Be sure to look at the COWSNewDocument interface and the IOWSNewDocument2 interface, since these are the building blocks for the code sample.

6.       Modify the Main method in the Program class to look like the following code snippet, be sure the fileUri variable represents a file that is accessible.

        static void Main(string[] args)


            Uri fileUri = new Uri("http://scvm1/Shared Documents/Document 1.docx");


            string fileUrl = fileUri.GetComponents(UriComponents.AbsoluteUri, UriFormat.UriEscaped);


            OWSSUPP.IOWSNewDocument2 control = new OWSSUPP.COWSNewDocument() as OWSSUPP.IOWSNewDocument2;




7.  Start debugging and watch the Open Documents dialog pop up.


The code sample is very short. Note how the COWSNewDocument interface is instantiated and cast to the IOWSNewDocument2 control interface. This interface is the earliest implementation of the ViewDocument method. Thus, the reader should use the IOWSNewDocument2 interface, unless additional functionality in the newer versions is needed.


For additional functions in the OWSSUPP interfaces, such as EditDocument or CreateNewDocument, it is wise to compare the documentation for the SharePoint.OpenDocuments control with the OWSSUPP members in the Object Browser. Since Microsoft doesn’t document OWSSUPP on MSDN, it is extremely beneficial to refer back to the SharePoint documentation. Most of the times, it is OK to omit the varProgId parameter, in which case that tells the control to default to the currently installed application for that file.


This post showed how easy it is to translate the SharePoint.OpenDocuments ActiveX control into a managed code solution for opening SharePoint Office files in their native application. The reader has learned how to compare the existing documentation for the SharePoint.OpenDocuments control against the OWSSUPP members in the Object Browser. The end users will appreciate a familiar experience in the reader’s application, as the Open Document dialog is the same experience provided by SharePoint from the browser.

Tags: ,

IT | Programming