Visual Studio Professional 2015 and Windows 10 - All kinds of IDE errors

Question

I have recently done the following on my Macbook Pro

1. Installed VMWare 8 and updated to latest version

2. Installed Visual Studio 2015 from msdn (licensed via subscription)

3. Updated extensions/etc via the extensions/updates menu

4. Cloned my repository

5. Opened a solution originally created with VS.NET 2013 4a.) Allowed nuget to restore packages (which it did)

6. Attempted to get on and 'do work'

The problem here is, that it is regularly unusable for the following reasons:

• I regularly get 'object reference not set to an instance of an object' when trying to close the IDE! I have to kill devenv.exe from taskmgr.
• I regularly get 'Value cannot be null. Parameter name: compositionService' when trying to add references. I simply can't add references
• I see regular dialog prompts telling me that extensions have crashed and would I like to continue seeing this error message
• It is incredibly slow to react, by comparison with VS2013 which was relatively snappy.

I have a feeling that all are related to something and finding that something is my goal.

I have, so far: - Removed everything from the componentModelCache folder in the app data for the 14.0 folder, which prompted a load of reloading of MEF components (whatever they are!) when I reloaded the solution. This doesn't appear to have done a great deal, but it was stated as a potential solution for the 'cant load package x' problem.

It is random how long it is usable before these errors manifest themselves, but it's very frequent throughout the day that I'm killing the executable and re-opening.

I find it hard to believe that this software was shipped in this condition - so I assume that there's something that I need to do to remedy this situation with my local environment, solution, projects - or something else.

I am going to try and create a new solution and add the projects, one by one - but all I'm really doing is trial and error/clutching at straws.

Any advice on how to remedy my IDE? I have no hope of being remotely productive at present!

Answer 1

I think the VM issues were a red herring. I get these errors in Windows 10 running on the hardware (not in a VM). The most common error is the compositionService one. I also get "The TestWindowPackage did not load correctly."

It seems to happen after installing some updates, and get fixed by install some updates. It leaves the Solution Explorer unable to expand folders. Running as administrator does work around the issue, but other than that I would have to wait for an update in "Extensions and Updates" and then hopefully it would clear up.

After installing the UWP tools, I got the errors again and this time could not even close Visual Studio without killing the process.

Now I have found a scriptable solution in Oleg's answer to the TestWindowPackage issue.

Posted by Oleg [MSFT] on 1/29/2013 at 1:10 PM

This may be caused by a corruption in the metadata cache Visual Studio maintains for its various components. Could you run the following two steps from the Developer Command Prompt for VS2012 and let us know if this fixed the problem? Please run these commands "As Administrator" to avoid file access errors.

Use an administrator command prompt. Here I have updated the commands for Visual Studio 2015:

del %LocalAppData%\Microsoft\VisualStudio\14.0\ComponentModelCache
"c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" /setup

Answer 2

So,

This turned out to be appear to be related to the virtual machine and environment.

I had a bunch of failed Windows updates showing in the windows update screen in Windows 10. I shut down every app and restarted these, along with updating to the large November update to Windows 10.

I also upped the number of cores to the VM, from 2 to 4 and the same for memory. This had the desired effect on performance, also.

Once these two had been done, a reboot later and the environment was working fine.

This, therefore, is a complete niche occurrence I guess that was somehow related to a slightly dodgy Windows state and/or lack of 'grunt' Odd.