The strange case of MZ-Tools keeping disabled

I have received a couple of issues in the last days from users of my MZ-Tools package, reporting that it keeps disabled, they have to enable it, and when restarting Visual Studio 2015 it happens again.

I haven’t seen that issue, so I could not investigate on my computer, but searching the web I found this post of MVP fellow David Gardiner that explains that the issue can happen to any extension and he provides a solution:

Web Essentials 2015 extension keeps being disabled

So far my users have confirmed the solution. Thanks David!

The new VS “15” installation design

I am these weeks pushing all my dev teams (near 40 people) of my daily job to upgrade from old versions of Visual Studio (2003-2013) to Visual Studio 2015, and all I hear from the first people taking the task are horror stories about the VS 2015 taking “hours” to install or “the whole day”. Their laptops are not more than 3 years old (my company renews them after that period) but I know they have 4 GB of memory, and most importantly, HDD disks instead of SSDs. I will try to convince management to pay the hardware upgrades to 8 GB of memory and SSD disks, but the VS 2015 setup experience couldn’t be worse for them. I will also take a look at why it takes so long on their computers, because they were instructed to install only the required components (desktop and web development with VB.NET/C#) and in my experience that should not take more than 1 hour on a computer with a HDD disk. I bought myself a Microsoft Surface 4 Pro for work some months ago and I think that VS 2015 installed in “only” 30 minutes, which surprised me a lot.

Microsoft is well aware of the painful setup experience for Visual Studio since long time ago, and they have decided to improve it a lot in the new VS “15” (not to be confused with VS 2015) with a new minimal install, optional “Stacks” or “Workloads” (name still to be decided), and isolated, low-impact, MSI-free, GAC-free, registry-free components:

New-Visual-Studio-Installer

This was a first post on the Visual Studio blog: Faster, Leaner, Focused on Your Development Needs: The New Visual Studio Installer. And today there is a new post: On the Road to Release: Redesigning Visual Studio Installation that provides a couple of interesting things:

The strange case of .vsct file being used by another process when migrating the version of a Visual Studio package

There is another very strange issue that I saw long time ago but until this week I hadn’t seen it again. It happens when you try to convert a Visual Studio 2010 package project to Visual Studio 2015. The steps to reproduce it are the following:

  1. Create a VS package with VS 2010, with at least one command, so a .vsct file (Visual Studio Command Table) is created.
  2. Open the VS package solution with Visual Studio 2015. You get this dialog with the one-way upgrade warning:

    VSPackageOneWayUpgrade

  3. When you click OK, you get this strange error: “The process cannot access the file ‘VSPackage1.vsct’ because it is being used by another process”.

    VSPackageVsctInUse

  4. When you click OK, the VS package project is marked as unavailable:

    VSPackageProjectUnavailable

Interestingly, the problem doesn’t happen if you migrate first the VS Package project from VS 2010 to VS 2012, and then from VS 2012 to VS 2015 (I cannot test with VS 2013 because I cannot install the VS 2013 SDK on Windows 10). It doesn’t happen either if you create the package with VS 2012 and you migrate it to VS 2015.

As I said, I saw this problem for the first time long time ago (I think last year), migrating my own MZ-Tools package. I don’t remember how I solved it, but likely I created a new package with VS 2012 or VS 2013.

This week I received an email about converting the DAX editor for SQL Server, which is VS 2010-based, and whose code is available on CodePlex, to support SQL Server 2016. My first suggestion was to convert the VS package project to VS 2015. When I tried it, I got the error about .vsct file in use by another project. And this time I was decided to investigate the cause.

First, I tried to guess which was the other process that was preventing the Visual Studio process (devenv.exe) to migrate the project. Using Process Monitor or Process Explorer didn’t show any suspect. Being involved the .vsct file, my main suspect was the VS Command Table compiler (vsct.exe) but I couldn’t verify, and I was not sure if that VSCT compiler was involved in the migration phase (definitely it’s involved in the build phase).

Second, I compared patiently each line of the .csproj of the migrated package project with the .csproj of my own MZ-Tools package, removing or changing lines until both were virtually identical. Still the error.

Third, while the error was still shown, I tried to edit the .vsct file with a text editor and save it (successfully) and even rename the file (also successfully), so apparently the .vsct file was not in use at all.

Now what? Suddenly I had the magic idea of replacing the .vsct file of the migrated project by the one of my MZ-Tools package, and this time the project loaded, no longer “unavailable”. So the problem was inside the .vsct file. Again patiently I started to comment/remove sections of the .vsct file, and again and again, and the problem persisted. Eventually, the .vsct file had only 6 lines (the “extern href” lines) and the problem persisted!:

<?xml version="1.0" encoding="utf-8"?>
<CommandTable xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <Extern href="stdidcmd.h"/>
 <Extern href="vsshlids.h"/>
 <Extern href="msobtnid.h"/>
</CommandTable>

And finally, as soon as I removed the msobtnid.h extern declaration, the problem was solved. That file contains the “Definition of some VSCT specific constants. In this sample we use it for the IDs inside the guidOfficeIcon group”. The VS 2012 package wizard (and higher) no longer includes it in the .vsct file, which explains that migrating a package from VS 2012 to VS 2015 doesn’t suffer this issue. One thing remains: the migration to VS 2015 doesn’t remove that “extern href” (so the problem happens), but does the migration to VS 2012 remove it? The answer is yes, that line is commented after the migration from VS 2010 to VS 2012:

 <!--Definition of some VSCT specific constants. In this sample we use it for the IDs inside the guidOfficeIcon group. -->
 <!--<Extern href="msobtnid.h" xmlns="http://schemas.microsoft.com/VisualStudio/2005-10-18/CommandTable" />-->

So, Microsoft knew about that problem in VS 2012, likely VS 2013 doesn’t suffer the problem either because the package wizard is the same, but somehow they forgot in VS 2015, which uses a different package wizard.

It remains to be explained why the error message is so misleading but my patience with this issue is depleted and now that I know the solution and it’s documented here for other VSX developers I am more than satisfied.

The strange case of Visual Studio 2013 SDK setup blocked on Windows 10

I think I never reported this problem, neither on Microsoft Connect nor on this blog (it seems that I have been very busy last months…), but I have reproduced it on my two Windows 10 machines. When I try to install the VS 2013 SDK on Windows 10, I get the following error:

Setup Blocked
“Windows Program Compatibility mode is on. Turn it off and then try Setup again.”

And here it is the screenshot:

VS2013SDKBlocked

The Compatibility Mode is not activated:

VS2013SDKCompatibility

When I activate it,  running the vssdk2013_full.exe setup with the “Troubleshoot compatibility” context menu, the setup is run with Windows 8 compatibility but still I get the same error.

I don’t know if I am the only VSX developer in the world with this problem (I haven’t seen it reported) but anyway today I have opened a bug report on Microsoft Connect, which includes the screenshot and the log file. If this problem happens to you, now you know you are not alone. I don’t have a solution or workaround, though.

UPDATE (Jun 16): Thanks to Mister Magoo for pointing in the comments that the problem is that I renamed the setup file from vssdk_full.exe to vssdk2013_full.exe.