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.
While taking a look at the new Outlook Addin Ribbon Commands I came across these schema validation errors trying to deploy the addin once I added the VersionOverrides element. In particular I was getting this error message:
Failed to deploy the manifest file to the Exchange server. This app can’t be installed. The manifest file doesn’t conform to the schema definition. The element ‘Resources’ in namespace ‘http://schemas.microsoft.com/office/mailappversionoverrides’ has invalid child element ‘Images’ in namespace ‘http://schemas.microsoft.com/office/officeappbasictypes/1.0′. List of possible elements expected: ‘ShortStrings, LongStrings’ in namespace ‘http://schemas.microsoft.com/office/officeappbasictypes/1.0′... The element ‘Resources’ in namespace ‘http://schemas.microsoft.com/office/mailappversionoverrides’ has invalid child element ‘Images’ in namespace ‘http://schemas.microsoft.com/office/officeappbasictypes/1.0′. List of possible elements expected: ‘ShortStrings, LongStrings’ in namespace ‘http://schemas.microsoft.com/office/officeappbasictypes/1.0′.
After a bit of trial and error I discovered that the issue was to do with the order of child elements within the Resources element. It appears that there is a strict order that must be adhered to.
Here’s the code that was causing the error. Notice that I was defining Urls before Images.
I simply swapped this around to define Images first, then Urls and the xml then passed the validation check and I was on my way. Here’s the working code:
After experiencing some intermittent “path not valid” and very frustrating errors trying to open different types of files from my SharePoint server I’d had enough. I had to know what was going on.
Here’s the behaviour I was seeing. I had used a certain machine to edit SharePoint files in applications such as WordPad and Paint in the past so I just jumped on it and tried to open a file from SharePoint in MS Paint and it would just keep failing with “path not valid”. I tried the same file from another machine and it worked fine. So back the first machine with the error and I tried images from other directories on the same server, they all failed with “path not valid”. I then started trying to open different file types with different applications. What I found was quite surprising (to me anyway). I was able to successfully open a .txt file from SharePoint in WordPad and from that point on my original image files that failed to open in Paint started working fine.
Now I already knew that WebDav had a few dependencies and that the WebClient service had to be running, but I had initially dismissed this as a possible cause as I knew I’d been working fine with WebDav on this machine only a couple of days prior… it turned out this was a bad assumption to make.
What I wasn’t expecting was that there are some actions you can do that will start the WebClient service if it’s not already running. As I discovered, one of those actions it to use WordPad to try and open a file on a UNC path. A bit of digging around also revealed that putting a UNC path in Windows Explorer will cause the WebClient service to start as well.
Here’s the proof:
Now trying to open the original image file (that failed) in Paint works fine.
So I learned my lesson, even though it’s something I thought I already knew. If you are making use of WebDav MAKE SURE the WebClient service is set with a startup type of “Automatic”.