Category Archives: The strange case of…

The strange case of..., VS 2010, VS 2015

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

6 Comments

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 2013

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

5 Comments

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.

The strange case of...

The strange case of System.InvalidOperationException: “Loading of the ImageList did not succeed”

2 Comments

In the last months, I have had two or three reports of the users of my MZ-Tools extension about this exception:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: Loading of the ImageList did not succeed.
 at System.Windows.Forms.ImageListStreamer..ctor(SerializationInfo info, StreamingContext context)
 --- End of inner exception stack trace ---

With a full trace that is included in this StackOverflow question with the same problem.

Incidentally, I had seen that exception very sporadically in the last tests of a session of integration tests of MZ-Tools.

For Visual Studio, MZ-Tools has more than 3,000 integration tests (most of them reproduce user actions such as setting options, executing commands and getting results in code or in treeviews, etc.). It is my experience that no version of Visual Studio has been able to run all the tests without crashing due to out of memory errors, etc. so I tend to run them in sets of 500-800 tests, restarting Visual Studio after each session. In this scenario, I have never seen the exception above.

For VB6 and VBA, on the other hand, there are “only” 1,500+ integration tests, and both IDEs are very capable of running all of them in a single session (and much faster than Visual Studio). In this case, I have seen the exception in the last tests but very rarely. So, I finally decided to investigate this issue.

There is little information on the web about this exception with the ImageList. Some old MSDN KB articles mention problems with the ImageList and leaks:

FIX: ImageList Class Leaks GDI objects (for .NET Framework 1.0)

Memory usage increases for a .NET Framework 2.0-based application when you use the ImageList.ImageCollection.Item property to obtain an image or when you call the ImageList.ImageCollection.GetEnumerator method.

I am using .NET Framework 2.0 but it is fully patched. Since the problem could be related to GDI objects leaks, I used theTask Manager to check it:

TaskManager

To add the GDI Objects column you need to right-click on the column header and then select it on the list:

TaskManagerColumns

Then I ran the 1,500+ integration tests in Excel while watching the GDI Objects counter and, to my surprise, the counter increased and increased, never releasing objects. So, there is a GDI object leak somewhere that I will investigate in the next days. I don’t know yet if this is the same cause for the users of my extension (it could be that they use the IDEs for very long periods of time without restarting) but certainly I have now a a GDI object leak to find.

The strange case of...

The strange case of localized resources not being loaded

For many years I have used a custom localization approach for my MZ-Tools add-in: instead of using .resx files, I used a single embedded .xml document which had nodes for each term, and in turn each one had children nodes for each language (I currently provide six languages). Then I had some functions to retrieve the required term in the desired language. This approach has some advantages, such a centralized source of resources for localization, less size at run-time, and a simplified setup with no resource dlls to deploy (I am aware that *.resources.dll files can be embedded too, but the approach is tricky).

Recently I wanted to use a web-based platform for localization, and to use .resx files which are the “standard” approach for localization. There are also 3rd party extensions such as ResXManager that allows you to manage localized resources in a centralized way using a grid. For the web platform I decided to use OneSky (it’s great and it allows up to 5 users for free). On this platform you can use tons of formats to upload/download the resources to localize, including of course .resx files. So, finally I had all changes made and a new setup that deploys all the *.resources.dll files:

Resources

The localization worked during development, however it failed when installing the extension with the setup. The MZ-Tools add-in failed for VBA/VB6/VB5, it also failed for VS 2005-2010, and the MZ-Tools package also failed for VS 2012-2015. The strings were always shown in English, the default language. Why? I suspected it was somehow related to obfuscation, which I use in the “Release” configuration (used by the setup) but not in the “Debug” configuration (used during development). Using .NET Reflector I didn’t notice anything wrong with the deployed *.resources.dll files. So, I thought about replacing the installed obfuscated main dll by the original one before obfuscation, but before I had to disable strong name verification because at “Release” configuration you need to use delay signing to use obfuscation, and re-sign after obfuscation. To disable strong name verification you have to execute:

sn.exe –Vr *,<public key token>

Suddenly, before replacing the main dll, all worked. So, the problem was that the *.resources.dll files were using delay signing and .NET was refusing silently to load them. I guess that using the Assembly Binding Log Viewer (fuslogvw.exe) would have revealed this. By the way, you can know if a .NET assembly is using delay signing or not (even if it is set to skip strong name verification) using:

sn.exe –vf <assembly>

So, when a Visual Studio project is set to use delay signing, not only its main output assembly but also its *.resources.dll files lack the strong name, and the build process that you use to sign again the main assembly must re-sign also its *.resources.dll files.

The strange case of..., VS 2015, VS Extensibility, VS Packages

The strange case of CreatePkgDef failing because of strong name validation

After several days fixing bugs of my new MZ-Tools 8.0 version, today I have tried to run the build process that I have to generate the “Production” version and it has failed with this chain of errors:

Error 1 CreatePkgDef : error : ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. MZTools8VSPackage

Error 2 at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) MZTools8VSPackage

Error 3 at System.Reflection.RuntimeModule.GetTypes() MZTools8VSPackage

Error 4 at System.Reflection.Assembly.GetTypes() MZTools8VSPackage

Error 5 at Microsoft.VisualStudio.Tools.CreatePkgDef.ProcessAssembly(String fileName, Hive hive, PkgDefContext context, Boolean register, RegistrationMode mode) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 260 MZTools8VSPackage

Error 6 at Microsoft.VisualStudio.Tools.CreatePkgDef.DoCreatePkgDef(InputArguments inputArguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 164 MZTools8VSPackage

Error 7 at Microsoft.VisualStudio.Tools.CreatePkgDef.Main(String[] arguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 85 MZTools8VSPackage

Error 8 Could not load file or assembly 'MZTools8PlugIn, Version=8.0.0.0, Culture=neutral, PublicKeyToken=a756ad4bac8a0579' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) MZTools8VSPackage

The first thing I noticed is that the errors show a location “f:\dd\VSSDK\VSIntegration\Tools\src” that is not on my hard disk. This is because the VS SDK tools (at C:\Program Files (x86)\Microsoft Visual Studio 12.0\VSSDK\VisualStudioIntegration\Tools\Bin) are shipped with the .pdb files for debugging.

The second thing that I noticed is that the CreatePkgDef.exe utility was failing because of a strong name validation that happened in the System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) method of the .NET Framework. However, this had been working until a few days ago. My MZ-Tools package (MZTools8VSPackage.dll) uses .NET Framework 4.5 and it is not obfuscated, but it uses a core MZTools8PlugIn.dll that uses .NET Framework 2.0 and it is obfuscated. So, the things are arranged as follows:

  • In “Debug” configuration, the MZTools8PlugIn.dll assembly is generated with a strong name because no obfuscation is performed.
  • In “Release” configuration, the MZTools8PlugIn.dll assembly is delay-signed, because it requires obfuscation, and you can’t alter an assembly signed with a strong name. So, obfuscation is done in a post-build step and then the obfuscated assembly is finally signed. The details are documented here.

So, in “Release” configuration, CreatePkgDef.exe is failing because the package assembly is loading a required assembly that doesn’t have a strong name yet (delay-sign). I was well aware that normally you need to instruct the .NET Framework to skip strong name validation using sn.exe -Vr (which for sn.exe 32-bit adds a special registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification) but somehow the CreatePkgDef step of the package assembly compilation of my build process has been working for ages until a few days ago without that strong name validation skipping step.

What has changed in the last days? My only suspect was Visual Studio 2015 and .NET Framework 4.6, that I installed on my main dev machine once they got RTM status. Since .NET Framework 4.5, 4.5.1, 4.5.2 and 4.6 are “highly compatible” with .NET Framework 4.0, they are not installed “side by side” but “on top” of the previous version. But it could be that one version introduces a breaking change to existing apps. To verify this hypothesis, first on my main dev machine where the issue was happening I created a package with Visual Studio 2008 (which uses .NET Framework 3.5 and CLR 2.0) and it compiled even setting the following delay sign in the AssemblyInfo.cs file:

[assembly: AssemblyDelaySign(true)]

The same was not true if I used Visual Studio 2010 or higher (which use .NET Framework 4.0 / CLR 4.0 or higher), but it was true in the past. So the suspicion increases.

Then, I setup a new virtual machine with only Visual Studio 2013 (.NET Framework 4.5.2) and lo and behold, a package compiles even if you use delay sign:

VSPackageBuildWithNet45

As soon as I downloaded and installed  only .NET Framework 4.6 (no need to install Visual  Studio 2015), the same package compilation gets this error:

CreatePkgDef : error : FileLoadException: Could not load file or assembly 'VSPackage1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=69b8a83eb37e3459' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

VSPackageBuildWithNet46

So, .NET Framework 4.6 introduces a breaking change that I have not seen documented.

Now, there is at least a couple of solutions:

  • You can build the package assembly with a strong name even in “Release” configuration, so CreakePkgDef doesn’t fail, and remove the strong name before obfuscating. Since the sn.exe utility doesn’t allow to remove strong names, you must search some other utility on the web (they exist).
  • You can instruct the .NET Framework to skip strong name validation using sn.exe -Vr before the package assembly is built, not after the package is built and before the assembly is obfuscated. The utility sn.exe is so handy that it allows you to skip strong name validation for assemblies that don’t exist yet, specifying just the public key token that will be used to sign them:
sn.exe -Vr *,public_key_token
The strange case of..., VS 2010

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

The strange case of...

The strange case of VBA editor prompting to repair Visual Studio (again)

On one of my computers I have started to suffer again the strange case of a prompt to repair Visual Studio 2010 when launching the VBA editor of any Office application. I already posted about this back in 2012 when I learned that a cause for that issue was having an external hard drive connected to the computer while you installed Visual Studio. When the drive was disconnected, the issue appeared. Since I did use an external hard drive as source for the setups of Visual Studio, that was certainly the case. Since then, I never have an external hard drive connected while I install Visual Studio, I copy the setups to the desktop, disconnect the drive and proceed to install.

So, what is causing the issue now, out of the blue? I am reading again the post How to work around the issue when opening Office applications repairs Visual Studio where Heath Stewart explains the issue and the workaround, and again, the cause is the presence of a drive unit that was present while Visual Studio was installed and sometime later that drive letter is no longer available. In my new cause these days, it was caused because the computer is an office laptop, and my company partitions the hard drive in two units, “C:” for apps and “D:” for data. Since that is plainly useless (the hard drive is the same so if broken you lose both partitions and most data goes anyway to the “Desktop” or “My Documents” locations, which are on “C:”), a couple of days ago I removed the empty “D:” partition and joined the space to the “C:” partition (which was almost full). Alas, since the “D:” unit was removed the issue with the VS 2010 prompt to repair appeared.

The post of Heath Stewart explains how to find the offending component filtering by “Warning” kind, “MsiInstaller” source and “1001” event id. But it you filter instead by “1004” event id, you will get the offending missing unit (“D:” in my case).

I have been unable to fix the issue yet with the instructions of the post, so I have had to uninstall VS 2010. I am now gettting a prompt to repair Visual Studio 2013…oh my…, you see, the installers of Visual Studio are so crappy that if you are a developer of extensions for Visual Studio and get a new computer you know you have to spend a lot of hours installing VS 2005, SP1, VS 2008, SP1, VS 2010, SP1, VS 2012, VS 2013, tons of patches and updates, etc. and when you think it’s done, some day you discover that you need to uninstall all of them (or to format the hard drive to start again) as I did in 2012 and it seems that I will have to do this next week again…

The strange case of...

The strange case of error 8013101b loading a Visual Studio add-in

Another error that can happen loading an add-in that I have found today is the following (with an unhelpful error message as usual):

Error Message: <Unknown error>
Error number: 8013101b

This error happens if you have compiled the add-in with a CLR version higher than the one supported by the Visual Studio IDE where you are trying to load it. For example, if you compile the add-in using Visual Studio 2010, 2012 or 2013 using CLR 4.0 and you try to load it in Visual Studio 2005 or 2008, which only support CLR 2.0.

Remember that the CLR is not the same than the .NET Framework. The correspondence is as follows:

  • .NET Framework 1.0 use CLR 1.0
  • .NET Framework 1.1 use CLR 1.1
  • .NET Framework 2.0, 3.0 and 3.5 use CLR 2.0
  • .NET Framework 4.0, 4.5 and 4.5.1 use CLR 4.0

And there is no such thing as CLR 3.0, CLR 3.5, CLR 4.5 or CLR 4.5.1. While .NET Framework 3.0 and 3.5 just installed new libraries without touching the CLR 2.0, .NET Framework 4.5 and 4.5.1 do touch the CLR 4.0 (a kind of in-place replacement) but keeping it backwards compatible and maintaining the version 4.0.

This means that for example, the problem doesn’t happen if you compile the add-in with VS 2013 using .NET Framework 4.5.1 (uses CLR 4.0) and you try to load it in VS 2010 (supports CLR 4.0). A problem can happen if you use some assembly of .NET Framework 4.5 or 4.5.1 because it would be missing on a machine with only VS 2010 and .NET Framework 4.0 but that would be a different issue, not a 8013101b error.

I have updated my article about troubleshooting add-ins with this new error number:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/mz2007009.aspx

The strange case of...

The strange case of InvalidComObjectException exiting Visual Studio 2013 after debugging extension

I found a couple of days ago a bug that I hadn’t seen before: when you create an add-in with Visual Studio 2013 (you need to install the VS 2013 SDK), hit F5 to debug it, which launches a second VS 2013 instance and close this instance (even without loading the add-in), you get:

An unhandled exception of type ‘System.Runtime.InteropServices.InvalidComObjectException’ occurred in mscorlib.dll
Additional information: COM object that has been separated from its underlying RCW cannot be used.

InvalidComObjectException

This exception happens in System.Threading.Tasks.AsyncCausalityTracer.TraceSynchronousWorkCompletion(System.Threading.Tasks.CausalityTraceLevel, System.Threading.Tasks.CausalitySynchronousWork)

Searching the web I have found that it happens also with packages and DSL designers of the VS 2013 SDK, that is, with any kind of extension. It was reported on Microsoft Connect:

Visual Studio 2013 Domain Specific Language Designer crash on exit.
https://connect.microsoft.com/VisualStudio/feedback/details/813425/visual-studio-2013-domain-specific-language-designer-crash-on-exit

and Ryan Molden (MSFT) acknowledged the bug in this thread of the MSDN VSX forum about packages:

Default VSPackage template in VS2013 SDK Throws Exception when exiting
http://social.msdn.microsoft.com/Forums/vstudio/en-US/06c0c8f3-e616-4c8c-9a62-aa87a6a63edb/default-vspackage-template-in-vs2013-sdk-throws-exception-when-exiting?forum=vsx

It is a bug of the async causality tracing stuff of the CLR 4 modified by the .NET Framework 4.5.1 (and used by VS 2013), because it didn’t happen with the CLR 4 of the .NET Framework 4.5 (used by VS 2012). Notice that it doesn’t depend on the .NET Framework used by your extension (.NET 2.0 in my case).

We will need to live with this bug until the Windows team (which owns the CLR, not the VS team) fixes it. An interesting thing is that I hadn’t seen this problem until I reformatted my laptop with Windows 8.1 a couple of days ago. Previously I was using Windows 7 and in fact I haven’t been able to reproduce the problem today on another laptop with Windows 7.

The strange case of...

The strange case of error “Windows Program Compatibility mode is on.” when installing Visual Studio 2012 language packs

Another problem apart from this other one that can happen installing Visual Studio 2012 language packs to try your extension with other languages is the following:

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

WindowsCompatibilityProgramOn

The error message is misleading: I have found that it happens if you rename the setup file from the original name “vs_langpack.exe” to something else, such as “vs_langpack_english.exe”, etc. (for example, to have all the language packs in the same folder).

Notes:

  • The problem doesn’t happen with Visual Studio 2013 language packs, though.
  • I am using Windows 8.1 RTM. It could be that the problem doesn’t happen on other Windows versions.
  • Apparently the same happens to VS 2012 (not a language pack) if not named correctly, according to this bug report on Microsoft Connect. Microsoft says it’s a bug of Windows 8.1 RTM.