MZ-Tools Articles Series: HOWTO Launch a process with admin rights from a Visual Studio 2008 add-in on Windows Vista

On Windows Vista with the User Account Control (UAC) feature enabled, processes that need to run with admin rights prompt the user for consent (either with a “OK” action if the user is already an admin running as standard user, or with an admin password request if the user is not an admin at all).

While Visual Studio .NET 2002, 2003 and 2005 need to run as admin (so you get the consent prompt when launching them on Windows Vista), VS 2008 was designed to run without admin rights (so you don’t get a consent prompt when running on Windows Vista). For that reason, you need to carefully design your add-in to work correctly on Windows Vista without requiring admin rights, as I explained in the article HOWTO: Design a Visual Studio add-in to install and run on Windows Vista.

But what happens if your add-in running inside VS 2008 on Windows Vista needs to launch a process that requires admin rights? For example, if it needs to launch regedit.exe? It will happen that the call to System.Diagnostics.Process.Start(…) will fail because the devenv.exe process of VS 2008 is running without admin rights. I recently found this situation for my MZ-Tools add-in and fortunately you can get easily the user’s consent with this code (VB.NET) using the “runas” verb:

HOWTO: Launch a process with admin rights from a Visual Studio 2008 add-in on Windows Vista
http://www.mztools.com/articles/2009/MZ2009007.aspx

The strange case of Microsoft.mshtml assembly missing

I received the following bug report from a customer:

System.IO.FileNotFoundException: File or assembly name Microsoft.mshtml, or one of its dependencies, was not found.

My MZ-Tools add-in references this component. Actually it doesn’t use it  (it was for future HTML/ASP.NET support) but that doesn’t matter. AFAIK, that component was installed by every installation of Visual Studio, because it is used for the ASP.NET/HTML designers (which until VS 2008 were IE-based). How could be that the customer didn’t have it?

It turned out that the customer was using Visual Studio .NET 2003 and that he installed only Visual C++, neither VB.NET nor C#. It seems that Visual C++ 2003 doesn’t use that component, and as soon as he installed VB.NET, the component was installed…

BTW, it seems that each time that I think about dropping support for VS.NET 2003 and concentrating only in VS 2005, 2008 and 2010 with .NET 2.0, I receive an e-mail from someone that happens to use VS.NET 2003… definitely developers of commercial add-ins need to support old versions of Visual Studio for many years….