The other day I received a bug report from a customer of my MZ-Tools 6.0 add-in because the setup was not detecting any installation of Visual Studio while he claimed that he had Visual Studio 2008 Professional. The setup of that version of MZ-Tools detects the installation of Visual Studio versions checking the existence of the registry entries HKEY_CLASSES_ROOT\VisualStudio.DTE.<version>, where <version> can be 8.0 for VS 2005, 9.0 for VS 2008, etc. It does so because those entries are not created for Express editions of Visual Studio, which in turn don’t support add-ins.

So, I asked the customer to check the existence of HKEY_CLASSES_ROOT\VisualStudio.DTE.9.0 and he informed me that the registry key didn’t exist, while it should because Visual Studio 2008 Professional creates it. In the next e-mail he mentioned the “educational” version of Visual Studio 2008 Professional. I was not aware of this edition, but I found that there is a Microsoft Education Product Center that offers licenses for “academic” institutions. I don’t know for sure if the “Professional” edition of Visual Studio is different for academic institutions and for companies, but there is another registry key that can be used to detect if Visual Studio is installed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>

My customer confirmed me that that registry key did exist. My only doubt was if Express editions create those too so I searched the web and I found my own article (I always love when this happen) HOWTO: Detect installed Visual Studio editions, packages or service packs that states that Express editions don’t create:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>

but:

• For VB Express: HKEY_LOCAL_MACHINE\Software\Microsoft\VBExpress
• For VC Express: HKEY_LOCAL_MACHINE\Software\Microsoft\VCExpress
• For C# Express: HKEY_LOCAL_MACHINE\Software\Microsoft\VCSExpress
• For J# Express: HKEY_LOCAL_MACHINE\Software\Microsoft\VJSExpress
• For Web Developer Express: HKEY_LOCAL_MACHINE\Software\Microsoft\VWDExpress

So, future versions of my setup will use HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>.

At the time of this writing, this is still an unsolved case, but I am posting it anyway with the hope that some day someone can solve it.

Since I included support for Visual Studio 2010 in my add-in MZ-Tools 6.0, I have received bug reports from three customers with this exception:

System.InvalidCastException: Specified cast is not valid.
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at Microsoft.VisualStudio.PlatformUI.Automation.CommandBarCustomizer.Remove(ControlCustomizer control)
at Microsoft.VisualStudio.PlatformUI.Automation.CommandBarControl.Delete(Object Temporary)
at Microsoft.VisualStudio.PlatformUI.Automation.CommandBarControl._Marshaler.<>c__DisplayClass10.<Delete>b__f()
at Microsoft.VisualStudio.Shell.ThreadHelper.Invoke(Action action)
at Microsoft.VisualStudio.PlatformUI.Automation.CommandBarControl._Marshaler.Delete(Object Temporary)
at EnvDTE.Command.Delete()

The exception happens when I delete an EnvDTE.Command of the add-in, which in turn deletes the CommandBarButtons created from it, a technique that I described in the article:

HOWTO: Prevent dead CommandBarButtons when Visual Studio or an add-in crashes.
http://www.mztools.com/articles/2009/MZ2009002.aspx

The problem is not reproducible and it has only happened to three customers, always in Visual Studio 2010, not in Visual Studio 2005 or 2008, so it is related to the new WPF-based commandbars of Visual Studio 2010. So, I used Reflector for .NET (freeware, soon to be paid version) to see what could cause the InvalidCastException in the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarCustomizer.Remove(ControlCustomizer control) method. The Microsoft.VisualStudio.PlatformUI.Automation.CommandBarCustomizer class resides in the Microsoft.VisualStudio.Shell.UI.Internal.dll assembly of the folder C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE and the Remove method is like this:

public void Remove(ControlCustomizer control)
{
   ErrorHandler.ThrowOnFailure(base.Wrapped.Remove(control.Wrapped));
}

The ControlCustomizer class is like this:

public class ControlCustomizer : InterfaceWrapper<IVsControlCustomizerPrivate>, IDisposable

And the InterfaceWrapper<T> interface is like this:

public abstract class InterfaceWrapper<T>
{
   // Fields
   private readonly T _wrapped;

   // Methods
   protected InterfaceWrapper(T wrapped);

   // Properties
   public T Wrapped { get; }
}

So, on the one hand, control.Wrapped returns something of the IVsControlCustomizerPrivate type.

On the other hand, the base of the CommandBarCustomizer is of InterfaceWrapper<IVsCommandBarCustomizerPrivate> type, the Wrapped property returns something of IVsCommandBarCustomizerPrivate type and its Remove method is like this:

IVsCommandBarCustomizerPrivate[PreserveSig]
int Remove([In, MarshalAs(UnmanagedType.Interface)] IVsControlCustomizerPrivate pControl);

which expects a parameter of the IVsControlCustomizerPrivate type, the same type that we are passing!. So, how is that an InvalidCastException can happen? The only scenario where I have seen that two types with the same names (name, full name, assembly names) can’t be cast is because they belong to an assembly that is loaded twice from different locations. I am not sure if somehow this is happening here.

When you have a System.Type that is a component, the best way to get its public properties is to use System.ComponentModel.TypeDescriptor.GetProperties(type), rather than System.Type.GetProperties(). This is so because a component type can have a designer which is able to add new properties to the type, and to remove or change existing properties. For example, controls have a Locked property that is added by the designer of controls (ControlDesigner class), it is not a property that belongs to the System.Windows.Forms.Control type.

If the type is not a component, I guess that System.ComponentModel.TypeDescriptor.GetProperties returns the same public properties than System.Type.GetProperties. System.ComponentModel.TypeDescriptor.GetProperties returns a collection of PropertyDescriptor, which has an IsBrowsable property that tells you if a property is browsable or not.

So, the other day I got an strange issue: I was calling System.ComponentModel.TypeDescriptor.GetProperties on the VSLangProj80.ProjectProperties3 type (which is not a component type but my code was called other times with types that are components), to get the properties that are likely to exist in the EnvDTE.Project.Properties collection. And I got in the results the “AbsoluteProjectDirectory” property, that I noticed that didn’t appear in the Object Browser of Visual Studio, despite its IsBrowsable property returning True. How come?

I was aware that VSLangProj80 stuff is not pure .NET but an imported typelib or something like that, but it was not until I used .NET Reflector that I discovered that the get accessor method of the AbsoluteProjectDirectory property has the System.Runtime.InteropServices.TypeLibFuncFlags attribute with the &H40 value:

<DispId(&H2732)> _
ReadOnly Property AbsoluteProjectDirectory As <MarshalAs(UnmanagedType.BStr)> String
   <MethodImpl(MethodImplOptions.InternalCall, MethodCodeType:=MethodCodeType.Runtime), DispId(&H2732), TypeLibFunc(CShort(&H40))> _
   Get
      ...
   End Get
End Property

which matches the FHidden value:

<Serializable, Flags, ComVisible(True)> _
Public Enum TypeLibFuncFlags
   ' Fields
   FBindable = 4
   FDefaultBind = &H20
   FDefaultCollelem = &H100
   FDisplayBind = &H10
   FHidden = &H40
   FImmediateBind = &H1000
   FNonBrowsable = &H400
   FReplaceable = &H800
   FRequestEdit = 8
   FRestricted = 1
   FSource = 2
   FUiDefault = &H200
   FUsesGetLastError = &H80
End Enum

That explained the issue and I was able to tweak my code to deal with that case. BTW, notice that there is also a TypeLibFuncFlags.FNonBrowsable flag.

Yesterday I returned from some days of vacations at Israel (Jerusalem and Tel-Aviv) and since the flight was being incredibly annoying and boring (after some hours in the airport and then a long delay before taking off) I decided to grab my laptop to work on a feature of the next version of my MZ-Tools add-in. This feature needs to know the guids of the project types supported by the Visual Studio IDE where MZ-Tools is loaded. I already wrote articles in the MZTools Articles Series about:

HOWTO: Get the project flavor (subtype) of a Visual Studio project from an add-in
http://www.mztools.com/articles/2007/MZ2007016.aspx

and

INFO: List of known project type Guids
http://www.mztools.com/Articles/2008/MZ2008017.aspx

Visual Studio 2005 and 2008 used to store project type Guids in the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\<version>\Projects and I thought that the same applied to Visual Studio 2010. However, I noticed two strange issues:

1) The project type guid {C8D11400-126E-41CD-887F-60BD40844F9E} (that belongs to Database projects of Visual Studio 2010) was not in the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Projects if you are using a 64-bit Windows OS). Searching the registry I found that it was stored only in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key.

2) Somehow, this code of my add-in was returning that project type guid even when it is not in the registry key (LocalMachine) that the code is querying:

Dim registryKey As RegistryKey

registryKey  = Microsoft.Win32.Registry.LocalMachine.OpenSubKey("Software\Microsoft\VisualStudio\10.0\Projects", False)

registryKey.GetSubKeyNames()

...

registryKey.Close()

Needless to say, without Internet access and Google I depleted the battery of the laptop without finding the answers.

Today I found two posts of Aaron Marten about the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config registry key introduced by Visual Studio 2010. So, that registry key is built merging the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0 registry key with Pkgdef files on disk. Since the {C8D11400-126E-41CD-887F-60BD40844F9E} value doesn’t appear in the HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key, it could only come from a Pkgdef file, and certainly I found it: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Data\vspackage.pkgdef, which contains this fragment:

[$RootKey\$Projects\{C8D11400-126E-41CD-887F-60BD40844F9E}]
@=”Database”
“DisplayName”=”Database”
“DisplayProjectFileExtensions”=”#210”
“Package”=”{068E2583-0872-403B-AF4C-6C2A8F2D8C3E}”
“DefaultProjectExtension”=”dbproj”
“PossibleProjectExtensions”=”dbproj;dbp”
“ProjectTemplatesDir”=”$RootFolder$VSTSDB\ProjectTemplates\Database”
“Language(VsTemplate)”=”Database”

So, that explained issue #1, but what about the #2? How is that querying the subkeys of HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects returns the value {C8D11400-126E-41CD-887F-60BD40844F9E} that is only present in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key? Notice that this was a good thing for my purposes, but I didn’t have an explanation. So I used the Process Monitor utility to trace registry activity and I found that the code above was actually querying the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects registry key!!! That could only mean that somehow Visual Studio performs a registry redirection (not mentioned in the posts of Aaron), so that any query from the devenv.exe process (or its extensions!) to HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0 is redirected to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config. To confirm this, I executed that code from a Windows Forms application and not from a Visual Studio add-in, and certainly the {C8D11400-126E-41CD-887F-60BD40844F9E} value is not returned, because in this case no registry redirection is performed and the true HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Projects registry key is queried.

Almost two weeks ago something strange started to happen on my laptop: the next version of MZ-Tools that I am working on was taking almost 10 seconds to load, while usually loads in 1 or 2 seconds. Since I was working on some other complex tasks (unit testing of add-ins, satellite DLL for custom pictures in international versions of Visual Studio, etc.), I didn’t devote time to troubleshoot this but as days passed finally three days ago I started to investigate.

At first I thought it was caused by some changes in the source code, such as handling the AppDomain.AssemblyResolve event to return the satellite DLL assembly, a required technique in international versions of Visual Studio (as I will blog about in a few days). But this was not the problem.

An intriguing thing was that the problem didn’t reproduce on another two computers of mine, nor on another partition of the same laptop with Windows 7 64-bit instead of Windows 7 32-bit. I created another user account on the partition where the problem reproduced and it happened too. So, it was not something user-specific but something machine-specific to the main partition and OS of my laptop (I was glad that this was the case and not a problem of the add-in).

I isolated the problem to the point where I measured that a single DTE.CommandBars.Add call to add a toolbar was taking 2 seconds (no surprise then that the whole add-in was taking 10 seconds). So I thought it could be some problem with the multiple products that install .NET / Visual Studio components, such as the own Visual Studio versions, their service packs, their security updates, but also Microsoft SQL Server (which installs .NET stuff) and Microsoft Office (which installs Visual Studio Tools for Applications). All that complicated with the fact that to do tests with international versions of Visual Studio I had both the English and Spanish versions installed.

So, I started to uninstall products, testing the load time after each uninstallation: the security packs, the service packs, SQL Server, Office, etc. etc. I even uninstalled the whole Visual Studio versions and reinstalled just one, to no avail: the add-in took still 2 seconds just to create a toolbar.

When I was resigned to format the partition and start from scratch hoping that that would solve the problem and maybe reinstalling products I could find the culprit, I did one last thing: to use Process Monitor to diagnose the problem. And I noticed a lot of disk access to the C:\Users\Carlos\AppData\Local\Microsoft\Windows\Temporary Internet Files location such as:

?FusionBindError!Category=NativeImage!exe=devenv.exe!name=EnvDTE80, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

And when I saw the “FusionBind” term I remembered: a couple of weeks ago I needed to use the Assembly Bind Log Viewer (fuslogvw.exe) to diagnose the problems locating the satellite dll assembly in international versions of Visual Studio. I opened that tool and bingo! the trace was activated. As soon as I deactivated (note: you need to launch it with admin rights) the problem was solved. Somehow I forgot some day to turn it off.

Now I have a lot of products to reinstall, but I am happy that I didn’t have to reformat…  🙂

I have been noticing for years the presence of two strange files in the file system of my computers:

• pidpropsca.dll in C:
• pidca.dll in C:\Program Files

Finally I decided today to investigate what they are, where they came from and more importantly, if I can delete them.

I thought it would be easy searching on the web. But both Google and Bing returned an incredible small list of results, and none of them was useful. The Pidpropsca.dll doesn’t have copyright but the other one, pidca.dll, belongs to Microsoft, and they were created in 2005 and 2006. No many clues here.

Then I used the Dependency Walker (depends.exe) utility to inspect the functions exported by those dlls. I found something more interesting:

• pidca.dll exports the functions ValidateProductID and DllMain
• pidpropsca.dll exports the functions SetAcademicProps and SetPidProps

It was the latter the one that gave me the clue, because “Academic” is something that Microsoft Visual Studio uses as one of the SKUs for editions. Also, I learned some days ago that to go from the Visual Studio 2010 Trial Edition that I got from Microsoft some days ago to the RTM release that was published on MSDN Subscriber Downloads some days later you need a “pid”,  which I guess it means “Product ID”. So, the dlls came from some Visual Studio version. I started searching the setups of all Visual Studio versions and I was lucky enough to find them at the fist version that I tried: the Visual Studio 2005 Team Edition for Database Professionals. This team edition came as a separate product after Visual Studio 2005, which originally only offered Team Edition for Developers, for Architects or for Testers, and the unified Team Suite. The setup folders of Visual Studio 2005 Team Edition for Database Professionals contain those two dlls.

I found later from this post of Quan To that “ca” stands for Crypto API and that during the installation of Visual Studio some data needs to be encrypted. Somehow the Visual Studio 2005 Team Suite and the Visual Studio 2008 Team Suite (which includes the Team Edition for Database Professionals) do all that stuff without using or leaving those two dlls in the file system. But Visual Studio 2005 Team Edition for Database Professionals uses and leaves them and since it was a separate product that I guess not many developers installed (I did because my MZ-Tools add-in supports it for some features), it is no surprise that there aren’t many search results on the web about those dlls.

The next version of my MZ-Tools add-in will target Visual Studio 2005, 2008 and 2010 so I can finally get rid of COM registration and native satellite DLLs and I can use a managed satellite DLL for custom pictures. I was using the “en-US” culture for the satellite DLL assembly and the same “en-US” name for the folder that contains it, and this was working fine for months using Visual Studio 2005/2008 in English on two computers, one with Spanish Windows XP and other with English Windows 7.

However, the other day, on the Spanish Windows XP computer loading the add-in in VS 2005 caused an FileNotFoundException saying that the satellite DLL with culture ‘es-ES’ (Spanish) was not found. In VS 2008 it worked fine. What the heck? That worked for months and anyway I thought that if some culture is not found, Windows, Visual Studio and whatever defaults to the English culture, but nope, using the Assembly Binding (Fushion) Log Viewer revealed that only the Spanish version was being searched for. What caused this problem?

It took me a while to discover the cause from the following facts:

• The Windows OS was in Spanish
• Visual Studio 2005 / 2008 were both in English
• Visual Studio uses the default value “Same as Microsoft Windows” in the Tools, Options window, Environment, International Settings section, Language combobox.
• If Visual Studio is not installed in the language of Windows, as it was the case, that setting is not honored and Visual Studio uses the language of the version that was installed, which was English.
• In the VS 2005 that caused the problem, changing that setting to use “English” rather than “Same as Microsoft Windows” solved the problem. So, somehow, VS 2005 got the Spanish version too, although I didn’t install it.
• When the “English” value was selected all project templates were fine, but when the “Same as Microsoft Windows” value was selected, most of the project templates disappeared, remaining only a few ones that gave me the clue that the product that brought the Spanish language to Visual Studio 2005 was a 3rd party product and Microsoft InfoPath 2007 and its Visual Studio Tools for Applications (VSTA) that I installed in Spanish some time ago. Since I was using VS 2008 most of the time, I didn’t notice this break until months later.

It happens that VSTA uses the Visual Studio 2005 Shell in integrated mode, so it affects the Visual Studio 2005 installation. However, it doesn’t seem to install all the resources in Spanish because the Visual Studio menus were in English, but the “Same as Microsoft Windows” setting was honored (using Spanish and causing the add-in to fail) and the project templates were filtered too.

The way for an add-in to know the language used by Visual Studio when the “Same as Microsoft Windows” setting is used is checking the EnvDTE.DTE.LocaleID property. I could have saved myself a few hours if I had included that piece of information in the exception report…

I am still trying to solve the problem of localized managed satellite DLLs (another ridiculous nightmare just to provide custom pictures) and when I find the solution I will update this article that currently fails in non-English Visual Studio versions:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands,
buttons and toolwindows.
http://www.mztools.com/articles/2005/MZ2005007.aspx

I have posted too how to test add-ins in international versions of Visual Studio:

MZ-Tools Articles Series: HOWTO: Testing add-ins in localized versions of Visual Studio
https://www.visualstudioextensibility.com/2010/04/01/mz-tools-articles-series-howto-testing-add-ins-in-localized-versions-of-visual-studio

One of the customers of my MZ-Tools 6.0 for Visual Studio .NET add-in reported some days ago that the setup was showing the following error when installing MZ-Tools for Visual Studio 2010 (RC) (it worked fine for other IDE versions):

“The assembly ‘VSLangProj80, version 8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ should be present in the Global Assembly Cache (GAC) but it has not been found there, maybe the uninstallation of some other product remove it”

It happens that it is not clear for some people (even within Microsoft) that EnvDTE.dll, VSLangProj,dll, etc. should not be included in the setup of Visual Studio add-ins, so some people were including those dlls in their add-in setups, with the undesired consequence that somehow those dlls were being removed from the GAC when uninstalling some add-ins. When I got tired of bug reports related to this, I made the setup of my add-in to check the existence of some required Visual Studio assemblies such as EnvDTE.dll, etc. and to provide the customer with a procedure to restore them (omitted for brevity in the message above) copying them from the Visual Studio folders to the GAC.

So, I got my customer to check the VSLangProj80.dll in the GAC and… it was there. Then I noticed that VSLangProj80.dll has a dependency on VSLangProj2.dll that the setup was not checking. But that dll was also in the GAC. Then I noticed that to check the existence of a DLL in the GAC my setup was trying to load the dll using System.Reflection.Assembly.Load(assemblyName) and if the load failed with any exception, then it assumed that the assembly was not in the GAC. So I guessed correctly that the error message was misleading, I changed the setup to show the message above only if the exception was a System.IO.FileNotFoundException, and to show the actual exception otherwise. Then we got this other error:

“System.IO.FileLoadException: Mixed mode assembly is built against version ‘v1.0.3705’ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information”

Then I learned what a “mixed mode assembly” is and the useLegacyV2RuntimeActivationPolicy attribute that needs to be used in a .config file to fix that issue in CLR 4.0, but I will let Mark Miller (Marklio) to explain it in full detail and to the MSDN documentation the short version.

There is something that I haven’t solved yet and it is why I was unable to reproduce the problem on my computer when the .config file didn’t have yet that attribute, but anyway the problem was solved for my customer.

Today I installed the latest 3.0 version of the Windows Installer XML (WiX) toolset (3.0.5419.0), which integrates with both Visual Studio 2005 and 2008 and provides a new project type and project template to create WiX setups. When I clicked the File, New Project menu, WiX project type, it worked fine in VS 2005. However, it caused the following error in VS 2008:

“.wixproj cannot be opened because its project type is not supported by this version of the application. To open it, please use a version that supports this type of project.”

After searching the web for a while to no avail, I finally noticed that this problem was caused because my shortcut to VS 2008 included /SafeMode after devenv.exe. When the shortcut didn’t include that command-line switch, it worked fine. That switch disables the Add-In Manager and prevents add-ins and 3rd party packages (such the WiX one) being loaded. I had it because I have my MZ-Tools add-in marked to load on startup (to avoid loading it by hand through the Add-In Manager each time I debug it), but I don’t want it to be loaded the very first time that I open VS to load its project, to avoid the problem PRB: ‘Could not copy temporary files to the output directory’ error building Visual Studio .NET add-in. Another way to prevent it is to press the left Shift key while VS is started, but that approach doesn’t work well on Windows 7 and VS 2010 will not support it, as explained in the article, so using /SafeMode will be the only approach.

Now, it would be nice if VS showed a more helpful message such as:

“.wixproj cannot be opened because its project type belongs to a 3rd party package that is not allowed to load when the Visual Studio process (devenv.exe) is launched with the /SafeMode switch.”