Category Archives: VS 2010

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 VS 2010 Macros stop working after February 2014 Windows Update

I have noticed today that VS 2010 macros stopped working.

Fortunately the cause is known (a security patch of Windows Update) and there is a workaround. See:

Visual Studio 2010 Macros Stop Working after February 2014 Windows Update
http://visualstudioextensions.vlasovstudio.com/2014/02/13/visual-studio-2010-macros-stop-working-after-february-2014-windows-update/

and:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/590abd1d-2faa-4a35-9b9c-fe404406d6cd/what-the-visual-studio-2010-macros-not-working-after-windows-update

MZ-Tools Articles Series: BUG: Setting CommandBarPopup.Visible to False doesn’t work when CommandBarPopup in context menu.

When I thought that I have fixed the bug that I explained in my last post, I found another subtle one: in VS 2010 and 2012, setting to False the Visible property of a CommandBarPopup was not honored if the CommandBarPopup was created on a context menu (for example, in the Code Window context menu), but it worked if created on a Toolbar (for example, the Standard toolbar).

This is another bug introduced in the WPF-based commandbars of VS 2010, since it works as expected in VS 2008 and before. Unfortunately I was unable to detect these two bugs back in 2009 during the VS 2010 beta since MZ-Tools 6.0 did not offer the more complete customization offered by the new MZ-Tools 7.0 version to show / hide buttons and dropdown menus. But fortunately, the workaround is as easy as adding the children CommandBarButtons before setting the Visible property to False.

I have written a small article to document it:

BUG: Setting CommandBarPopup.Visible to False doesn’t work when CommandBarPopup in context menu.
http://www.mztools.com/articles/2012/MZ2012008.aspx

And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):

https://connect.microsoft.com/VisualStudio/feedback/details/758545/commandbarpopup-visible-false-doesnt-work-when-commandbarpopup-in-context-menu#details

MZ-Tools Articles Series: BUG: CommandbarPopup.Caption changes CommandbarPopup.CommandBar.Name and viceversa.

A couple of days ago a customer of the new version MZ-Tools 7.0 for Visual Studio reported a bug regarding the dropdown menus visibility not preserved across Visual Studio sessions. I isolated the bug which happened to be a bug in the WPF-based commandbars of Visual Studio 2010 (and 2012), not happening in VS 2008 and before.

I have written a small article to document it:

BUG: CommandbarPopup.Caption changes CommandbarPopup.CommandBar.Name and viceversa.
http://www.mztools.com/articles/2012/MZ2012007.aspx

And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):

https://connect.microsoft.com/VisualStudio/feedback/details/758550/commandbarpopup-caption-changes-commandbarpopup-commandbar-name-and-viceversa#details

Bugs with the EnvDTE.DTE.ActiveSolutionProjects property with VS 2010 and VS 11 Beta

My MZ-Tools add-in was experiencing a random “System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.” when using the EnvDTE.DTE.ActiveSolutionProjects property that I knew that other developer reported in the MSDN VSX Forum in January. Today I tested a guess of Ryan Molden (from Microsoft) in his answer about a dependency on the visibility of the Solution Explorer and he was right.

But when I was writing the corresponding MZ-Tools Series article as I always do to document all the issues and bugs of the Visual Studio automation model (EnvDTE), I noticed that the problem didn’t happen in Visual Studio 2005 or 2008, only in VS 2010, so rather than considering it a “by design” issue, I opened a bug at Microsoft Connect:

BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown
https://connect.microsoft.com/VisualStudio/feedback/details/735830/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown#details

So, in VS 2010 the problem happens when one condition is met: The Solution Explorer is not shown.

Then, I tried in VS 11 Beta, which is more annoying because the Macros IDE is gone and you have to use an add-in to reproduce bugs, and I noticed that the problem doesn’t happen when a solution is loaded, but still happens when two conditions are met: The Solution Explorer is not shown and there is no solution loaded. So, I opened a separate bug against VS 11 Beta:

BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown and no solution loaded
https://connect.microsoft.com/VisualStudio/feedback/details/735835/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown-and-no-solution-loaded#details

Microsoft fixing VS 2010 SP1 breaks debugging add-in that targets .NET Framework 2.0

Service Pack 1 of Visual Studio 2010 introduced a bug when debugging add-ins in VS 2010 targeting .NET Framework 2.0 that I blogged about back in March. They were kind enough to contact me some months ago to try a private hotfix (which was successful) and yesterday they made it public.

The Microsoft Connect bug report that I opened was this:

http://connect.microsoft.com/VisualStudio/feedback/details/650694/vs-2010-sp1-breaks-add-in-debugging-targetting-net-framework-2-0-rather-than-net-framework-4-0

and the new Knowledge Base (KB) article with the hotfix is this:

FIX: Breakpoints are not hit when you debug a Visual Studio Add-in project that targets the .NET Framework 2.0 in Microsoft Visual Studio 2010 SP1
http://support.microsoft.com/kb/2591546

MZTools Articles Series: INFO: menuCommandBar.Controls[“Tools”] works in international versions of Visual Studio 2010

Retrieving a CommandbarPopup in Visual Studio to add buttons has always been tricky. There are incorrect ways to do it:

PRB: Performance problem of DTE.CommandBars[name] for CommandbarPopups in Visual Studio 2010
http://www.mztools.com/articles/2011/MZ2011005.aspx

BTW, I have updated this popular article to avoid that performance problem in VS 2010:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in
http://www.mztools.com/articles/2005/MZ2005003.aspx

and there are correct ones:

HOWTO: Locate commandbars in international versions of Visual Studio.
http://www.mztools.com/articles/2007/MZ2007002.aspx

HOWTO: Get a CommandBar by Guid and Id rather than by name from a Visual Studio add-in.
http://www.mztools.com/articles/2011/MZ2011004.aspx

And now Visual Studio 2010 introduces a new one, which is correct, but doesn’t work in international versions of Visual Studio 2005 and 2008:

INFO: menuCommandBar.Controls[“Tools”] works in international versions of Visual Studio 2010
http://www.mztools.com/articles/2011/MZ2011006.aspx

MSDN Community Content for “Automation and Extensibility for Visual Studio” updated for VS 2010

I mentioned in my last post that the MSDN documentation for Visual Studio uses a mechanism in the URL to reference several versions of Visual Studio. I noticed that the Community Content at the bottom of each documentation page doesn’t propagate from one documentation version to the next one, with good criteria I guess because maybe the content is not relevant in the next version. So, although long overdue too, I have entered today the community content for MSDN VS 2010 documentation that I entered in Sep 2008 for Visual Studio 2008 since all of it is relevant. It has been dozens of blocks with references to articles of the MZ-Tools Article Series.

Uninstalling Visual Studio 2010 SP1

Today finally I decided to uninstall SP1 of Visual Studio 2010. A sad decision, because I like to have the latest service packs and hotfixes, but my definition of service pack is something that fixes bugs, not introducing new ones, and SP1 introduces these two issues (a bug and a “by design” change actually) that I can’t stand anymore, and that are not going to be fixed:

VS 2010 SP1 breaks add-in debugging targetting .NET Framework 2.0 rather than .NET Framework
http://www.visualstudioextensibility.com/2011/03/15/vs-2010-sp1-breaks-add-in-debugging-targetting-net-framework-2-0-rather-than-net-framework

VS 2010 SP1 changing “ByVal” VB.NET code editor experience
http://www.visualstudioextensibility.com/2011/03/15/vs-2010-sp1-changing-quot-byval-quot-vb-net-code-editor-experience

I guessed that uninstalling SP1 from my laptop and my desktop computers was going to be long, and certainly it was so. Furthermore, it was annoying because the uninstaller asks for the original installation sources, even the installation source of Visual Studio 2010 Express Edition for one specific component (which I think never was installed on the computer that prompted for them, the other didn’t). Not only uninstalling SP1 is a long procedure (not unattended due to the source installation prompts) , but also you must reinstall or repair Visual Studio after uninstalling SP1. All of these are known issues described in the readme of Visual Studio 2010 SP1:

Visual Studio SP1 Readme:
http://go.microsoft.com/fwlink/?LinkId=210711

After a couple of (wasted) hours, I think that both Visual Studio 2010 installations are working again, without SP1.

More on VS 2010 SP1 breaks add-in debugging targetting .NET Framework 2.0

Sergey Vlasov, from Tabs Studio, has found a workaround to the problem of VS 2010 SP1 breaks add-in debugging targetting .NET Framework 2.0 that I posted yesterday:

Debugging add-ins for Tabs Studio in VS 2010 SP1
http://blog.tabsstudio.com/2011/03/16/debugging-add-ins-for-tabs-studio-in-vs-2010-sp1/

Thanks, Sergey.

On the other hand, apparently this problem debugging add-ins targeting something below .NET Framework 4.0 can also happen without SP1 according to this report in the MSDN VXS Forum (although the reports refers to a shared add-in for Office, not an add-in for Visual Studio 2010)