Carlos Quintero blog

Debugging .NET Framework working only "sometimes"

carlosq — Wed, 10 Apr 2013 17:35:00 GMT

I am these days (well, nights) debugging an extremely difficult issue with the ImageList control and I had that idea that debugging the .NET Framework (source step) would help a lot. That feature was introduced in VS 2008 and my feeling these years when I tested it from time to time was that sometimes it worked, sometimes it didn't. Yesterday that I needed it badly I searched the web and I discovered that I was not alone. There are tons of issues and workarounds about it. I tried all them to no avail.

Finally someone from Microsoft posted here (only a few weeks ago after all these years!) that the root cause is out-of-date PDBs, and that it is going to happen each time that Microsoft releases a new build of an assembly, which is not only in service packs but also any security patch. Since there is cadence between the release of the assembly and the release of the PDB (that has been up to 1 year in the past!), this feature is basically broken, bad designed.

The alternative, suggested strongly by that guy, is to use .NET Reflector, a paid tool which for developers of Visual Studio extensions is even more useful to debug Visual Studio assemblies (not just .NET Framework assemblies) as I explained in this guest post on their blog.

Msaddndr.dll file officially not installed by Microsoft Office 2013

carlosq — Sat, 06 Apr 2013 08:30:00 GMT

As I posted back in November, the setup of an add-in for the VBA editor of Office 2013 written with VB6 could fail with the following error:

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

I mentioned that the cause was that the file Msaddndr.dll is no longer installed by Office 2013 and today I have found that Microsoft wrote an official Knowledge Base (KB) article stating it a month later:

A custom add-in that uses interfaces in the Msaddndr.dll file does not work in Office 2013
http://support.microsoft.com/kb/2792179

The workaround is, of course, that your setup installs that file. BTW, I got yesterday a bug report from a user of my MZ-Tools 3.0 for VBA with that same error but using a MZTools3VBASetup.exe that already (supposedly) installed the file. It happened that the system already had that file installed, but an old version, and the setup only installed it if not present, so it was not replaced by the newest version. So, when applying this workaround, ensure that your setup installs the file if not present, or if it is an older version, because it seems that there are at least two versions of Msaddndr.dll out there.

Windows PowerShell scripts to register a .NET-based add-in for a COM-based host application

carlosq — Wed, 27 Mar 2013 22:03:00 GMT

Before Visual Studio 2005 introduced XML-based registration for add-ins with an .AddIn file (which enabled X-Copy deployment), add-ins for Microsoft applications required two steps to be registered:

To register the add-in dll as ActiveX (COM) component
To register the add-in dll as add-in for the host application through some registry entries

This is still true for COM-based add-ins for Visual Studio (any version) and for other hosts such as Microsoft Office or its VBA editor which only support COM-based add-ins.

Some months ago I wrote how to create a COM add-in for the VBA editor of Office using .NET, which is almost the only way to create an add-in for the VBA editor of Office 64-bit, since it doesn't support 32-bit COM add-ins.

I am working since some months ago on a .NET-based version of my MZ-Tools add-in for the VBA editor of Office 32/64-bit and I always wanted a single script to perform the two steps above. This was a nice excuse to learn Windows PowerShell, so I bought a book and after reading some chapters to get the concepts today I decided to create the scripts that call regasm.exe to register the .Net assembly for COM-Interop and create the registry entries for the add-in to be recognized by the VBA editor:

1) This is the content of a file named Functions.ps1 which contains reusable functions:

# To run .ps1 scripts you need to execute first: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$Regasm32 = 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\regasm.exe'
$Regasm64 = 'C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm.exe'

function Register-Assembly32([string]$Assembly, [string]$RegistryKey, [string]$FriendlyName)
{
   Execute-Command -RegAsm $Regasm32 -Arguments '/codebase' -Assembly $Assembly
   Register-AddIn -RegistryKey $RegistryKey -FriendlyName $FriendlyName
}

function Register-Assembly64([string]$Assembly, [string]$RegistryKey, [string]$FriendlyName)
{
   Execute-Command -RegAsm $Regasm64 -Arguments '/codebase' -Assembly $Assembly
   Register-AddIn -RegistryKey $RegistryKey -FriendlyName $FriendlyName
}

function Unregister-Assembly32([string]$Assembly, [string]$RegistryKey)
{
   Execute-Command -RegAsm $Regasm32 -Arguments '/unregister' -Assembly $Assembly
   Unregister-AddIn -RegistryKey $RegistryKey
}

function Unregister-Assembly64([string]$Assembly, [string]$RegistryKey)
{
   Execute-Command -RegAsm $RegAsm64 -Arguments '/unregister' -Assembly $Assembly
   Unregister-AddIn -RegistryKey $RegistryKey
}

function Register-AddIn([string]$RegistryKey, [string]$FriendlyName)
{
    New-Item         -Path $RegistryKey -Force
    New-ItemProperty -Path $RegistryKey -Name Description -PropertyType String -Value $FriendlyName
    New-ItemProperty -Path $RegistryKey -Name FriendlyName -PropertyType String -Value $FriendlyName
    New-ItemProperty -Path $RegistryKey -Name LoadBehavior -PropertyType DWord -Value 3
}

function Unregister-AddIn([string]$RegistryKey)
{
    if (Test-Path -Path $RegistryKey)
    {
        Remove-Item -Path $RegistryKey
    }
}

function Execute-Command([string]$RegAsm, [string]$Arguments, [string]$Assembly)
{
    $psi = New-Object System.Diagnostics.ProcessStartInfo
    $psi.CreateNoWindow = $true
    $psi.UseShellExecute = $false
    $psi.RedirectStandardOutput = $true
    $psi.RedirectStandardError = $true
    $psi.FileName = $RegAsm
    $psi.Arguments = $Arguments + ' ' + $Assembly
    $process = New-Object System.Diagnostics.Process
    $process.StartInfo = $psi
    [void]$process.Start()
    $StandardOutput = $process.StandardOutput.ReadToEnd()
    $StandardError = $process.StandardError.ReadToEnd()
    $process.WaitForExit()
    [system.windows.forms.messagebox]::show($StandardOutput + $StandardError)
}

2) Then I have other scripts that include that script:

MyAddInVBA32Registration.ps1:

$ScriptDirectory = Split-Path $MyInvocation.MyCommand.Path
. (Join-Path $ScriptDirectory Functions.ps1)

$Assembly = (get-item Env:\USERPROFILE).Value + '\Documents\MyAddIn\Exe\Debug\MyAddIn.dll'

Register-Assembly32 -Assembly $Assembly -RegistryKey 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MyAddIn.Connect' -FriendlyName 'My Add-In'

MyAddInVBA64Registration.ps1:

$ScriptDirectory = Split-Path $MyInvocation.MyCommand.Path
. (Join-Path $ScriptDirectory Functions.ps1)

$Assembly = (get-item Env:\USERPROFILE).Value + '\Documents\MyAddIn\Exe\Debug\MyAddIn.dll'

Register-Assembly64 -Assembly $Assembly -RegistryKey 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\MyAddIn.Connect' -FriendlyName 'My Add-In'

MyAddInVBA32Unregistration.ps1:

$ScriptDirectory = Split-Path $MyInvocation.MyCommand.Path
. (Join-Path $ScriptDirectory Functions.ps1)

$Assembly = (get-item Env:\USERPROFILE).Value + '\Documents\MyAddIn\Exe\Debug\MyAddIn.dll'

Unregister-Assembly32 -Assembly $Assembly -RegistryKey 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MyAddIn.Connect'

MyAddInVBA64Unregistration.ps1:

$ScriptDirectory = Split-Path $MyInvocation.MyCommand.Path
. (Join-Path $ScriptDirectory Functions.ps1)

$Assembly = (get-item Env:\USERPROFILE).Value + '\Documents\MyAddIn\Exe\Debug\MyAddIn.dll'

Unregister-Assembly64 -Assembly $Assembly -RegistryKey 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\MyAddIn.Connect'

To run the scripts you need to enable PowerShell execution first and they need to be run with admin rights.

I am finding PowerShell with a learning curve harder than expected and with some "by-design" issues that makes it "tricky" in my opinion, but I hope to learn it in depth.

MZ-Tools Articles Series updated

carlosq — Tue, 26 Mar 2013 13:45:00 GMT

Many of the MZ-Tools Articles that I have written in the last years seemed a bit outdated because each one has a header like this:

Author:	Carlos J. Quintero (Microsoft MVP)	Applies to:	Microsoft Visual Studio .NET 2002
Date:	March 2010		Microsoft Visual Studio .NET 2003
			Microsoft Visual Studio 2005

Where the date and the list of Visual Studio versions would reflect the moment in time when I wrote them.

I have reviewed all them (200+) and many are now updated to reflect that they apply until the last Visual Studio 2012 version when that is the case:

Author:	Carlos J. Quintero (Microsoft MVP)	Applies to:	Microsoft Visual Studio .NET 2002
Date:	March 2010		Microsoft Visual Studio .NET 2003
Updated:	March 2013		Microsoft Visual Studio 2005
			Microsoft Visual Studio 2008
			Microsoft Visual Studio 2010
			Microsoft Visual Studio 2012

So, most HOWTO articles are now current. The exceptions are those articles which are BUG or PRB (issue), that I haven't bothered to check if they are still present.

MZ-Tools Articles Series: BUG: DTE.ActiveDocument.ActiveWindow does not return the active document window if toolwindow active

carlosq — Sun, 17 Mar 2013 16:18:00 GMT

My first small article this year is to document this bug of Visual Studio 2005, 2008, 2010 and 2012:

BUG: DTE.ActiveDocument.ActiveWindow does not return the active document window if toolwindow active
http://www.mztools.com/articles/2013/MZ2013001.aspx

Which I have just reported to Microsoft Connect:

Document.ActiveWindow does not return always the active window
https://connect.microsoft.com/VisualStudio/feedback/details/781522/document-activewindow-does-not-return-always-the-active-window

and that is a variation of a bug that I reported for VS.NET 2002/2003 and that I thought it was definitely fixed in VS 2005 (the relevant factor is that it still fails if a toolwindow is active):

BUG: Document.ActiveWindow does not return always the active window in Visual Studio .NET 2002/2003
http://www.mztools.com/articles/2004/MZ2004013.aspx

The strange case of "LoaderLock was detected" with a COM add-in written in .NET

carlosq — Sun, 17 Mar 2013 00:07:00 GMT

Since some days ago, I was getting the following error when closing Visual Basic 6.0 from the Visual Studio debugger (I am developing a .NET-based version of MZ-Tools for the 64-bit VBA editor of Office, and VB6 will get it too):

LoaderLock was detected
Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This is a warning of the Managed Debugging Assistants (MDA) of Visual Studio.

Today I decided to investigate. Soon it was clear that it was caused by the test-runner add-in that I created to run integration tests within VB 6.0. Since the error was caused during shutdown, I removed initializations (and the corresponding cleanups) to isolate the problem and I discovered that the problem was in this method:

      internal List<string> GetAddinProgIds()
      {
         List<string> colAddinProgIds;

         colAddinProgIds = new List<string>();

         foreach (AddIn objAddIn in m_objVBE.Addins)
         {
            colAddinProgIds.Add(objAddIn.ProgId);
         }
         return colAddinProgIds;
      }

That method gets the registered add-ins of the VBE object (to load them in a combobox and select an add-in to run its test suites).

I soon realized that maybe I should release propertly some COM object and certainly the problem was fixed:

      internal List<string> GetAddinProgIds()
      {
         List<string> colAddinProgIds;
         Addins colAddins;

         colAddinProgIds = new List<string>();

         colAddins = m_objVBE.Addins;
         foreach (AddIn objAddIn in colAddins)
         {
            colAddinProgIds.Add(objAddIn.ProgId);
         }

         // The following statement is to prevent the following error:
         // LoaderLock was detected
         // Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain
         // or image initialization function since doing so can cause the application to hang.
         System.Runtime.InteropServices.Marshal.ReleaseComObject(colAddins);

         colAddins = null;

         return colAddinProgIds;
      }

The strange case of "Set property 'System.Windows.ResourceDictionary.DeferrableContent' threw an exception."

carlosq — Sat, 09 Mar 2013 21:43:00 GMT

In the recent days, each time that I clicked the New Project button of the Visual Studio 2012 IDE, I got this exception:

"Set property 'System.Windows.ResourceDictionary.DeferrableContent' threw an exception."

I have been clueless about this problem until today. When a problem happens in Visual Studio, the recommended approach is to launch it in "Safe mode", because maybe an extension (add-in, package, etc.) is causing it. As a previous step, what I did today is to take a look at the Add-In Manager and I noticed that I had an add-in (a test runner that I created to perform integration tests of my MZ-Tools add-in) marked to load on startup. I unmarked it and then the problem disappeared. Why was this add-in causing this problem?

After some isolation, it happened that this add-in was setting an event handler for the AppDomain.AssemblyResolve event (to locate required assemblies) and a silenced NullReferenceException was happening in the event handler. The following minimal add-in reproduces the issue:

    public class Connect : IDTExtensibility2
    {
      private DTE2 _applicationObject;
      private AddIn _addInInstance;
      private AppDomain _appDomain;

      public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
        {
            _applicationObject = (DTE2)application;
            _addInInstance = (AddIn)addInInst;

         switch (connectMode)
         {
            case ext_ConnectMode.ext_cm_Startup:
               // OnStartupComplete will be called
               break;

            case ext_ConnectMode.ext_cm_AfterStartup:
               InitializeAddIn();
               break;
         }
    }

      public void OnStartupComplete(ref Array custom)
      {
         InitializeAddIn();
      }

      private void InitializeAddIn()
      {
         _appDomain = AppDomain.CurrentDomain;
         _appDomain.AssemblyResolve += AppDomain_AssemblyResolve;
      }

      public void OnDisconnection(ext_DisconnectMode disconnectMode, ref Array custom)
        {
         _appDomain.AssemblyResolve -= AppDomain_AssemblyResolve;
      }

        public void OnAddInsUpdate(ref Array custom)
        {
        }

        public void OnBeginShutdown(ref Array custom)
        {
        }

      private Assembly AppDomain_AssemblyResolve(object sender, ResolveEventArgs args)
      {
         Assembly objAssembly = null;
         AssemblyName objAssemblyName = null;

         // Force a NullReferenceException
         if (objAssemblyName.Name == "")
         {
         }

         return objAssembly;
      }
    }

The strange case of the add-in initialized twice

carlosq — Thu, 14 Feb 2013 19:54:00 GMT

As I commented in my last post, I have developed my own integration test infrastructure to test my MZ-Tools add-in. As part of it, there is an add-in that is the test runner, that when loaded loads in turn the MZ-Tools add-in if not loaded, locates its friend assembly that contains the integration tests, loads it, gets the test suites, gets the test methods, shows them in a treeview and executes the ones that I select.

This worked fine if the test runner add-in was not marked to load on startup and I had to load it with the Add-in Manager. But when the test runner add-in was marked to load on startup, the MZ-Tools add-in was initialized twice, giving an exception because some code didn't expect to run twice (duplicated key).

The code of the MZ-Tools initialization is similar to the one that I wrote in my article HOWTO: Use correctly the OnConnection method of a Visual Studio add-in and that I constantly recommend in the MSDN VSX Forums:

   AddIn _objAddIn;
   EnvDTE.DTE _objDTE;

   void IDTExtensibility2.OnConnection(object objApplication, ext_ConnectMode eConnectMode, object objAddInInst, ref System.Array r_objCustom)
   {
      _objDTE = (EnvDTE.DTE)objApplication;
      _objAddIn = (AddIn)objAddInInst;

      switch (eConnectMode)
      {
         case ext_ConnectMode.ext_cm_Startup:

            // IDTExtensibility2.OnStartupComplete will be called
            break;

         case ext_ConnectMode.ext_cm_AfterStartup:

            Initialize();
            break;
         }
      }
   }

   void IDTExtensibility2.OnStartupComplete(ref System.Array r_objCustom)
   {
      Initialize();
   }

   private void Initialize()
   {
   ...
   }

This pattern assumes that:

1) If an add-in is loaded on startup:

The OnConnection method will be called with the ext_ConnectMode.ext_cm_Startup flag.
The OnStartupComplete method will be called later TOO, when the Visual Studio IDE has completed its initialization.

2) If an add-in is loaded through the Add-In Manager:

The OnConnection method will be called with the ext_ConnectMode.ext_cm_AfterStartup flag.
The OnStartupComplete method will NOT be called (because the Visual Studio IDE was already initialized when you used the Add-In Manager to load the add-in).

But in my case, the Initialize method was being called twice. How was that?

It happens that there is a subtle behavior here: when an add-in marked to load on startup loads in turn another add-in (using EnvDTE.AddIn.Connect = true), in the second add-in the OnConnection method is called with the ext_ConnectMode.ext_cm_AfterStartup flag, AND the OnStartupComplete is called too!!! (because the Visual Studio IDE was not initialized when the first add-in was loaded on startup). So, the Initialize method is called twice.

I was about to report this as a bug, but I have thought that maybe the behavior is correct after all, that is, when VS has finished its initialization it calls OnStartupComplete for all add-ins that are loaded in that moment, independently of whether they were marked to load on startup or they were loaded by another add-in marked to load on startup. And what is really misleading is the MSDN documentation about the OnStartupComplete method:

(OnStartupComplete) "Occurs whenever an add-in, which is set to load when Visual Studio starts, loads."

That implies that if add-in is not set to load on startup, its OnStartupComplete method will not be called.

The Remarks section is correct, though, since it does not relate the OnStartupComplete call to whether the add-in was set to load on startup or not:

"On occasion, OnConnection does not occur correctly, such as when an add-in is loaded, but a component required by an add-in has not yet loaded. This is unusually due to the fact that Visual Studio has not yet started completely. Using OnStartupComplete guarantees that the Visual Studio integrated development environment (IDE) has completed the startup process."

As you realize, this is a subtlety that your add-in won't experience unless is loaded by another add-in when Visual Studio is started.

Long time without blogging

carlosq — Thu, 14 Feb 2013 19:03:00 GMT

I have been long time without blogging, and the reason is that I have been quite busy doing the following:

- I have migrated the whole code of my MZ-Tools 7.0 add-in from VB.NET to C#. After 10 years programming in VB.NET, I decided to switch to C# and the best way is to use it everyday, so I had to migrate the product. The migration was successful and build 7.0.0.103 released on December 1 was C#-based. Only a couple of bugs were introduced that were not detected by the automated integration tests. FWIW, I used Instant C# from Tangible Software Solutions.

- I have enforced the Code Analysis feature of Visual Studio on the MZ-Tools code base with All Microsoft Rules, and after lots of fixes I was able to pass all with some custom suppressions and four of them disabled: CA1031 Do not catch general exception types, CA1502 Avoid excessive complexity, CA1506 Avoid excessive class coupling and CA5122 P/Invoke declarations should not be safe-critical. If you have tried to enforce them on a large code base you know how time-consuming is that.

- I have done massive architectural changes in the code base of MZ-Tools for Visual Studio to prepare a new unified version 8.0, .NET-based, that will support Visual Studio (VB.NET, C#), Visual Basic 6.0 ("Classic"), VBA editor of Office 32-bit and VBA editor of Office 64-bit. That means to encapsulate the automation models of VS and VB "classic". I already have the user interface, options, setup and unit-test/integration-test subsystems. It "only" remains the features, but it will take me months yet :-). I will blog about this in the next months when I am closer to the release.

- I have created an integration test runner that runs in the IDE where MZ-Tools is loaded, rather than in the IDE where the MZ-Tools source code project is loaded. While the Visual Studio SDK provides a remote MS-Test-based host adapter for this purpose, I tried it two years ago with disappointing results, so I created my own integration testing infrastructure in MZ-Tools. But the MZ-Tools add-in, its integration tests and the test-runner were in the same assembly (using a special configuration). Now I have isolated them so I have the add-in, the integration tests and the test-runner in three separate assemblies. I hope to release the test runner in CodePlex or similar some day.

- I migrated to Visual Studio 2012 (I am almost used to the new UI style) and I am planning to adopt TFS (I am finishing the simultaneous reading of Professional Team Foundation Server 2012 and Testing for Continuous Delivery with Visual Studio 2012). In the past I used Perforce, but after a failed restore after a crash (likely my fault) I didn't use source control for some time and I want to adopt TFS now.

And I was almost three weeks on vacation during Christmas, resting and watching lots of TV series :-)

The 10-years MVP custom disk from Microsoft

carlosq — Thu, 14 Feb 2013 18:51:00 GMT

I have just received the 10-years MVP custom disk from Microsoft :-)

"Congratulations! In recognition of your longstanding community contributions as a Microsoft MVP, Microsoft is honoring your achievement with a custom award disk to add to your MVP Crystal Wedge Award."

10 years as Microsoft Most Valuable Professional (MVP)

carlosq — Tue, 01 Jan 2013 17:25:00 GMT

Happy New Year!

I have received a new Most Valuable Professional (MVP) award from Microsoft just a couple of hours ago. This is a very special one for me because it is my 10th MVP award and, as always, I am very grateful to Microsoft for this recognition:

"Dear Carlos Quintero,

Congratulations! We are pleased to present you with the 2013 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Visual Basic technical communities during the past year."

A wrong way of checking the Visual Studio version where an add-in is loaded

carlosq — Mon, 10 Dec 2012 22:26:00 GMT

Take a look at this code of an add-in that checks that it is loaded only in Visual Studio 2012 and try to figure out what's wrong:

      private DTE2 _applicationObject;
      private AddIn _addInInstance;

      public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
      {
         const string REGISTRY_KEY_VS_11_0 = "SOFTWARE\\MICROSOFT\\VISUALSTUDIO\\11.0";

         string addInRegistryRoot = null;

         _applicationObject = (DTE2)application;
         _addInInstance = (AddIn)addInInst;

         switch (connectMode)
         {
            case ext_ConnectMode.ext_cm_AfterStartup:
            case ext_ConnectMode.ext_cm_Startup:

               addInRegistryRoot = _applicationObject.RegistryRoot.ToUpper();

               if (!addInRegistryRoot.StartsWith(REGISTRY_KEY_VS_11_0))
               {
                  System.Windows.Forms.MessageBox.Show("This add-in only works with Visual Studio 2012");
               }
               break;
         }
      }

If you have discovered it, either you are quite expert on globalization issues or you are a Turkish developer. My MZ-Tools add-in had similar code that has worked correctly for years until a few weeks ago, when a developer reported that using the Turkish culture (user interface, language input keyboard, etc.) MZ-Tools refused to load. You can simulate that effect inserting the following line at the start the OnConnection method that sets the Turkish culture for the current thread:

System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo("tr-TR");

The reason is that in Turkish, the upper case of the character i is not I but İ (with a dot), as explained here. So _applicationObject.RegistryRoot.ToUpper() returns the following string:

"SOFTWARE\\MİCROSOFT\\VİSUALSTUDİO\\11.0"

which is different from:

"SOFTWARE\\MICROSOFT\\VISUALSTUDIO\\11.0"

Of course, the solution is to use _applicationObject.RegistryRoot.ToUpperInvariant() or an overloaded version of StartsWith() that uses the ordinal or invariant culture comparison ignoring the case.

So, if you make software for international markets, ensure that you run the Code Analysis feature of Visual Studio with the Microsoft Globalization Rules, because two rules are violated with the code above:

- CA1304: Specify CultureInfo (in _applicationObject.RegistryRoot.ToUpper())
- CA1307: Specify StringComparison (in sAddInRegistryRoot.StartsWith(REGISTRY_KEY_VS_11_0))

The Visual Studio (2012) Image Library

carlosq — Tue, 04 Dec 2012 09:07:00 GMT

Microsoft published some days ago the Visual Studio Image Library:

The Visual Studio Image Library contains application images that appear in Microsoft Visual Studio, Microsoft Windows, the Office system and other Microsoft software. The library of over 5,000 images can be used to create applications that look visually consistent with Microsoft software.

http://www.microsoft.com/en-us/download/details.aspx?id=35825

LearnVSXNow! (about Visual Studio packages), by Istvan Novak (DiveDeeper's blog)

carlosq — Sat, 01 Dec 2012 23:03:00 GMT

MVP fellow Istvan Novak wrote long time ago a long series of small articles about Visual Studio Extensibility (VSX) with packages on his DiveDeeper's blog.

I have added a new section to my Resources about Visual Studio .NET extensibility page with sorted links to all of them:

LearnVSXNow!, by Istvan Novak (DiveDeeper's blog)
http://www.mztools.com/resources_vsnet_addins.aspx#LearnVSXNow

Back from Microsoft Tech / Community Day 2012 Madrid

carlosq — Sat, 24 Nov 2012 10:26:00 GMT

I'm back from the Microsoft Tech Day / Community Day 2012 at Madrid, which have been great. The aspect that I like most is networking with people, either old MVPs that I already know, new MVPs or other people.

In this event I was introduced to Jesús Salas, the author of VS Anywhere , also available on the Visual Studio Gallery, an extension for Visual Studio that provides team collaboration in real time with a very innovative approach.

I also met my friend Pep Lluis Baños, Visual Basic MVP like me, who brought to the event an intriguing kind of electronic mini motherboard that happened to be the mainboards used in .NET Micro Framework, a technology that I only knew the name. Since I returned, I have been so excited about this technology that I have watched the Gadgeteering and the .NET Micro Framework video, I have read documentation, I have bought the Getting Started with .NET Gadgeteer book that I am reading and I do plan to buy some .NET Gadgeteer Starter Kit for Christmas to start playing. It's great also to see how powerful and flexible Visual Studio and the .NET Framework have become to accommodate all kind of extensions with project types, visual designers for electronic layouts, debuggers with external devices, etc.

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

carlosq — Sun, 11 Nov 2012 22:46:00 GMT

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/

Red Gate Blog Guest post: Using .NET Reflector to understand and debug Visual Studio assemblies

carlosq — Tue, 30 Oct 2012 22:36:00 GMT

After I wrote this post about using .NET Reflector to debug Visual Studio assemblies, Red Gate asked me to write a guest post on their blog to tell more about it:

Guest post: Using .NET Reflector to understand and debug Visual Studio assemblies
http://www.reflector.net/2012/10/guerst-post-using-net-reflector-to-understand-and-debug-visual-studio-assemblies/

Adopting Visual Studio 2012

carlosq — Sat, 20 Oct 2012 15:39:00 GMT

Finally today, after much reluctance in the past weeks, I have decided to adopt Visual Studio 2012 as the development environment for all my Visual Studio solutions, and I have just migrated them. I still find the default Light theme unpalatable but the Visual Studio 2012 Color Theme Editor extension provides much more pleasant themes and you can even switch themes with a couple of clicks.

What prompted me to the move was that Packt Publishing gave me a copy of the book Visual Studio 2012 Cookbook of fellow MVP Richard Banks to write a review and after reading the first chapter about the new IDE enhancements in the Solution Explorer and Tab Well I realized they were too good to miss the opportunity to use them on a daily basis.

MZ-Tools Articles Series: HOWTO: Get an inverted bitmap to use with the Dark theme of Visual Studio 2012 from an add-in.

carlosq — Sun, 14 Oct 2012 17:19:00 GMT

There is a feature in my MZ-Tools add-in that requires to show the pictures of its commands in a treeview, to select which ones to be visible or not. When using Visual Studio 2012 and the Dark theme, the background of the form and the treeview are darked, and the bitmaps should have inverted colors, as shown in this picture:

I wanted to reuse the command pictures and use a function that inverts their colors as VS 2012 does. I knew the ThemeDIBits method of the IVsUIShell5 interface, but it took me a while to discover a Visual Studio assembly that used it. Finally I found it and here is the approach:

HOWTO: Get an inverted bitmap to use with the Dark theme of Visual Studio 2012 from an add-in.
http://www.mztools.com/articles/2012/MZ2012030.aspx

The sample also shows how to get the background color of toolwindows, using also the IVSUIShell5 interface.

Note: my command pictures use the almost green (RGB=0,254,0) to denote the transparent color, and the sample provided uses that color, but you can use any color.

MZ-Tools Articles Series: HOWTO: Detect Visual Studio requirements for MSI-based extensions setups.

carlosq — Sat, 13 Oct 2012 09:28:00 GMT

My new article in the MZ-Tools Articles Series is about Visual Studio extension setups (a digression from the "theming extensions" subject of my last articles). I learn something new very often from questions in the MSDN Visual Studio Extensibility (VSX) Forum, when I have to investigate something before providing an answer.

A few days ago a question led me to learn something new that I have documented here:

HOWTO: Detect Visual Studio requirements for MSI-based extensions setups.
http://www.mztools.com/Articles/2012/MZ2012029.aspx

While writing that article I noticed that I had to update a bit these old ones:

HOWTO: Detect installed Visual Studio editions, packages or service packs
http://www.mztools.com/Articles/2008/MZ2008003.aspx

HOWTO: Detect if Visual Studio .NET is installed in a Visual Studio Setup package for an add-in
http://www.mztools.com/Articles/2006/MZ2006001.aspx