The strange case of error "Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5"

November 11, 2012

In the past years, I have received some bug reports (less than 10 out of dozens of thousands of installations) reporting that the setup of MZ-Tools 3.0 for VBA / VB6 was failing with this error:

“Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”

I never discovered the cause (I just recommended to reinstall Office or VB6, depending on the case, or I sent the list of dependencies), but in the last weeks the problem has happened to two users of Microsoft Office 2013 using a clean installation. I already suspected that the problem was related to the file MSADDNDR.DLL (in the folder C:\Program Files (x86)\Common Files\designer), the reference used by add-ins for VB6 and for the VBA editor.

So I decided to investigate, and lo and behold, it happens that Office 2013 doesn’t install that file, it just installs the MSADDNDR.OLB object library file. I even used the orca.exe tool of the Microsoft Windows SDK to open the .msi files of the Office 2013 setup to verify. I guess that somehow some users of VB6 and old versions of Office had this file missing or damaged, what would explain the case completely.

To fix the problem, the new setups of MZ-Tools 3.0 released today install this file:

MZ-Tools 3.0.1206 for VBA with bug fix to support Microsoft Office 2013
http://www.mztools.com/blog/mz-tools-3-0-1206-for-vba-with-bug-fix-to-support-microsoft-office-2013/


The strange case of projects not being rebuilt

September 6, 2012

Yesterday while writing code for the next article about creating add-ins for the VBA editor of Office using Visual Studio .NET I noticed that when I used this approach to debug it, the add-in project was not being rebuilt when I changed some code and hit F5 to debug:

  • In the Solution Explorer of the Visual Studio project, right-click the solution
    node and click the “Add”, “Existing Project…” menu entry.
  • Select the path to Excel.exe, for example “C:\Program
    Files\Microsoft Office\Office14\EXCEL.EXE”.
  • Right-click the EXCEL.EXE node and click the “Set as Startup Project” menu
    entry.
  • Right-click the EXCEL.EXE node and click the Properties menu entry.
  • In the Debugger Type field, change its value from “Auto” to “Managed (v2.0)”.
  • Click the “Debug”, “Start Debugging” menu.
  • Excel will be launched.
  • Open the VBA editor and load the add-in. The breakpoint should be hit in the
    add-in project.

I remembered that the same happened to me some months ago with the solution of my add-in MZ-Tools 6.0, that contained the main add-in project and other projects for external operations of the MZ-Tools 6.0 SDK: the projects of the external operations were not rebuilt when I debugged the main add-in project.

The reason is that by default, the setting “Only build startup projects and dependencies on Run” that is in the “Tools, “Options…” window, “Projects and Solutions”, “Build and Run” section is checked. Once you uncheck it, the issue is solved.

I have updated the article that I wrote a couple of days ago to reflect this:

HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012014.aspx


The strange case of VB6 prompting to repair VS 2010 when MZ-Tools 3.0 is loaded

August 10, 2012

I have got a new laptop (an Apple MacBook Air 11″) and after installing BootCamp, Windows 7, VB6, VS 2005, 2008 and 2010, yesterday I noticed that when loading MZ-Tools 3.0 for VB6, it prompted to repair Visual Studio 2010. I had received the same or similar issue from 2 or 3 users these last years that I never knew how to solve, so I could only recommend to repair or reinstall Office, VB6 ,etc. Today I have investigated more and it seems that there are multiple causes but one of them documented by Heath Stewart was certainly my case:

How to work around the issue when opening Office applications repairs Visual Studio
http://blogs.msdn.com/b/heaths/archive/2009/05/29/how-to-workaround-the-issue-when-opening-office-applications-repairs-visual-studio.aspx

That is, if there was an external drive connected when you installed Visual Studio, you get the issue when you load some Office application, or some application using VB/VBA. Of course this issue doesn’t happen if you install from the DVD, because the drive (typically D:\) will be there always, but it happens if you have an external drive connected, specially if that is the drive where you are installing from!. It happened that other times I copied the setups to the internal hard drive before installing Visual Studio, but since the MacBook Air has only 128 GB of internal hard drive, I installed from an external drive.

That said, the workaround proposed in the post didn’t work for me. I guess that using the variable %ProgramFiles% on my Windows 7 64-bit rather than %ProgramFiles(x86)% didn’t help. Anyway, I got it so messed that finally I had to uninstall completely VS 2005, 2008 and 2010, which is a horrible experience because you have to uninstall lots and lots of separate setups (Visual Studio is by far the worst product regarding uninstallation). Then I started again the installations, but this time copying the media to the internal hard disk (it is a good thing to have USB 3.0 technology). And now I have 27 updates to install from Windows Update, but the issue is solved.

I hope this help others, and myself in the future ūüėČ


The strange case of "Error 1606: Could not access network location VS Developers" installing SP1 of Visual Studio .NET 2003

September 3, 2011

At the time of this writing there are three Visual Studio versions out there (VS 2005, 2008 and 2010) that support .NET Framework 2.0 and with an extensibility model that allows you to create a single binary add-in dll to target all of them (see HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET). So I wouldn’t support Visual Studio .NET 2003 in a new add-in created today, but my old MZ-Tools 6.0 add-in still supports Visual Studio .NET 2003. On the other hand, the current OS today is Windows 7 64-bit, and, alas, VS.NET 2003 is not supported by Microsoft in that Windows version. Not being supported doesn’t mean that it doesn’t work, specially if you want it only to test an add-in, not for actual development of projects, so I have it installed on Windows 7 64-bit despite all compatibility issues warnings during installation.

Yesterday I wanted to install SP1 of VS.NET 2003, that I noticed that I hadn’t installed, so executed the VS7.1sp1-KB918007-X86.exe setup just by double-clicking it. I got a warning about a security of files from Internet but I authorized its execution. At some point of the installation, I got this error:

“Error 1606: Could not access network location VS Developers (could not create group)”

This problem is caused if you have the User Account Control (UAC) feature of Windows Vista or Windows 7 activated. It happens that this setup was created before Windows Vista and therefore it is not UAC-compliant (it lacks a manifest). So, how does Windows Vista / 7 know if this executable requires admin rights? Windows Vista / 7 knows that most executables that are setups require admin rights, so when the UAC manisfest is missing, it applies some heuristic rules to guess if an executable is a setup or installer. In this case all rules failed, including the most usual one (the name includes the “setup” word) and UAC determined that VS7.1sp1-KB918007-X86.exe was not a setup and didn’t require admin rights, which caused the error above at some point.

Of course the solution is to install VS7.1sp1-KB918007-X86.exe by right-clicking it and selecting the “Run as administrator” menu entry.

Another solution is to rename the setup file name to include the “setup” word, for example VS7.1sp1-KB918007-X86Setup.exe, so that UAC guesses that it is a setup and it prompts for admin consent or admin credentials to elevate privileges.


The strange case of VisualStudio.DTE.9.0 registry key missing for Visual Studio 2008 Professional

February 26, 2011

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>.


The strange case of InvalidCastException in Microsoft.VisualStudio.PlatformUI.Automation.CommandBarCustomizer.Remove of VS 2010

February 26, 2011

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.


The strange case of VSLangProj80.ProjectProperties3.AbsoluteProjectDirectory

February 1, 2011

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 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.


The strange case of the registry key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Projects\{C8D11400-126E-41CD-887F-60BD40844F9E}

January 31, 2011

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.


The strange case of MZ-Tools taking 10 seconds to load

April 18, 2010

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…¬† ūüôā


The strange case of the files pidpropsca.dll in C:\ and pidca.dll in C:\Program Files

April 17, 2010

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.