Using Visual Studio 2017 and attempting to add a reference to a project you receive an error stating “The operation could not be completed”.
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.
I 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 http://extranet.mycompany.com
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 http://extranet.mycompany.com 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 http://extranet.mycompany.com, 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 http://extranet.mycompany.com URL and performs a search, then all search results will also use the http://extranet.mycompany.com 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 http://extranet.mycompany.com 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.
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.