Blog Archives

How to fix “The operation could not be completed” error adding references to Visual Studio 2017

The Issue

Using Visual Studio 2017 and attempting to add a reference to a project you receive an error stating “The operation could not be completed”.



The Solution

It seems that to bring up the Add Reference dialog in Visual Studio 2017 the Microsoft.VisualStudio.Shell.Interop.11.0.dll needs to be regsitered in the GAC. You can follow these steps to register this assembly in the GAC:

Open the Develop Command Prompt for VS2017 (ensure you run the as administrator otherwise the GAC registration may fail)


Change the current directory to the PublicAssemblies folder for your Visual Studio 2017 installation. Mine was:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies

Note: this path will be different for different versions of Visual Studio (e.g. you may find your path is C:\Program Files\Microsoft Visual Studio\2017\Community\Common7\IDE\PublicAssemblies)


Run the following command to register the assembly in the GAC:

gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll


Now restart VS2017 and try to add a reference to your project again and you should see the Add Reference dialog appear.



Beware the Office.js Dialog API falling silent under IE11

Issue Description

I’ve been leveraging the Office.js Dialog API recently and found a scenario where I just couldn’t get it to behave properly. At the moment this appears to be either a bug or limitation of the Dialog API. I found that the calling MessageParent() from the dialog fails to trigger the registered callback method in the host add-in when running in IE11 (on both Win 7 and Win 8.1)

Following are the steps to reproduce the issue with the Dialog API under IE11 where the messageParent() method fails to trigger the corresponding event back in the host add-in.


Steps to Reproduce

To reproduce the issue I’ve taken the Dialog API example from and hosted in Azure.

Then I updated the manifest to point to the location where I hosted it, and then tried to use it in the different environments (I made no code changes to the example).

For these repo steps I just opened Word Online in IE11 and side loaded the manifest. The issue also exists using Office Desktop on a machine with IE11 installed (but not Edge) as Office will then be trying to use IE11 and you get a similar issue.

On Windows 10 in Chrome or Edge (works as expected)



On IE11 on WIn 7 & Win 8.1 Fails to Communicate back to Parent Add-in

Now if I use the same manifest and try it from Win 8.1 IE11 the pop up dialog fails to send the message back to the parent add-in when you press a button.


If you close the dialog, the dialog close event method does get triggered back in the parent add-in (this is the same behaviour that we observed when developing our add-in).



I am aware of the documented issue of the Dialog API not working in mixed zones under IE (especially with difference in protected mode between the host page and the add-in/dialog URLs).

In the scenario above the host (Word Online) page is in the Internet Zone with Protected Mode off


And the add-in is also running in the Internet Zone with Protected Mode off


Beware SharePoint 2013 Search Results and the ListUrl Property

beware-caution-sharepointI was recently looking into the results returned by SharePoint 2013 under the scenario of alternate access mappings. Essentially this boils down to the same SharePoint content being available on different host URLs.

Here’s an example:

I can have a single site which I initially create on http://ourintranet, through the magic of alternate access mappings I can make the same SharePoint site also accessible on

SharePoint serves up exactly the same content irrespective of the URL host the user come in on. In the address bar of the users browser, the host portion of the URL remains constant as they navigate through the site e.g. if the user came in on they would not be switched over to the http://ourintranet host at any time.

These alternate access mappings carry across to search as well. The way this works is that the search processes will crawl the SharePoint site and index content based on one of the URLs (either http://ourintranet or, best practice is to use the access mapping of the default zone). When search results are requested the SharePoint server will find the matching results in it’s search index and then apply alternate access mappings to any of the URLs being returned so that even though the content was crawled and indexed with the URLs starting with http://ourintranet, if a user comes in on the URL and performs a search, then all search results will also use the access mapping.

Now to the issue with the ListUrl property being returned by search. This property simply misses the whole alternate access mapping transformation when the search results are returned and the value is read straight from the search index. Therefore the ListUrl property is fixed with the URL host that the search crawler is configured with. This means that when a user comes in on and performs a search, the ListUrl property will give back a result starting with http://ourintranet. Obviously this is not good and your users may not even have access to the content via the different access mapping.

Here’s an environment demonstrating the problem.

The initial site collection is created on http://vs-server38:83



The site collection is then extended (which creates the alternate access mapping) http://vs-server38:84



Through a browser we can now access the same site on http://vs-server38:83



or on http://vs-server38:84



The search content source is configured to crawl the content based on the default http://vs-server38:83 URL.


The screenshot below shows the results of performing a search query (via PowerShell) on the URL http://vs-server38:83. As you can see all URLs returned begin with http://vs-server38:83



This screenshot performs exactly the same search query only it uses the alternate access mapping of http://vs-server38:84. This time the issue is evident. The Path, OriginalPath and SiteName properties all return URLs that have been mapped to the alternate access URL I used. Note the ListUrl property still returns the http://vs-server38:83 based URL.



Delving further, each managed search property has a property called UseAAMMapping that seems to be the flag that tells SharePoint that the property contains a URL and need to apply alternate access mapping transformation when results are returned. Looking at the UseAAMMapping property through PowerShell we can see that the ListUrl property does not have this flag set while the other URL based properties (that work correctly) do have this flag set.


%d bloggers like this: