The internets agree: Visual Studio 2012 is a usability disaster

“Don’t put it out with your boots, Ted!”


Visual Studio is the fundamental tool used to create a good majority of the software for Microsoft’s operating systems, and has been for, well, a very long time. New releases tend to be inexorably linked to new language features or versions. Also typically, each new release has brought new features, and improvements to performance and usability.

With every new release of Visual Studio I have been party to, the upgrade was an improvement. .NET (aka 2003), 2005, 2008, 2010… I upgraded and never looked back (with the exception of the loss of VB6 perhaps… but it really did need to go).

Until Visual Studio 2012.

Maybe Microsoft thought forcing developers to develop in a low-fi tool would encourage good low-fi app design. Maybe they thought we needed a break from being productive. I don’t know.

They have removed WIDELY used features (setup projects anyone?), and dramatically uglified the interface. They have reduced the number of things that get code highlighting, and reduced the number of colors used to highlight. HOW COULD THAT POSSIBLY BE CONSIDERED A GOOD THING?

Go ahead, try searching Google for “Visual Studio 2012 looks”… here is what you will find:

(FYI: I’m pretty sure BING is filtering such suggestions – I just checked)

Top suggestions:
“Visual Studio 2012 looks horrible”
“Visual Studio 2012 looks like crap”

Top results?
“Visual Studio 2012 is ugly as hell” (Funny, because it’s a “deferred” Microsoft connect bug
Visual Studio 2012 is so ugly, I actually cried.


Does anybody know who is to blame for this? Given the pervasiveness of ugly in all of Microsoft 2012 products (seriously Microsoft, a touch-centric interface on a server operating system? What were you thinking?), you would think there must be somebody high up that deserves a flaming bad of poop…

Let’s just hope he (or she) takes it better than Sasquatch

Looking for Setup Projects in Visual Studio 2012?

There aren’t any. Microsoft quietly removed all Visual Studio Installer project types from Visual Studio 2012, instead pushing the use of InstallShield Limited Edition:

Windows Installer Deployment:

Visual Studio 2012 New Features: Compatibility:


There is surprisingly little information about this online. I got a chance to ask about it at TechEd 2012, and was told that WiX Toolset is the “future” of setup projects in Visual Studio, but they didn’t want to bake it in because WiX is so frequently updated.

Problem #1: None of the existing Project templates that included setup projects were updated to use either of the two options. (In fact the Shared Add-in project was removed altogether).

Problem #2: InstallShield LE is not a reasonable option (3rd party, requires registration and I hear projects expire), and WiX required learning yet another dialect.

Problem #3: A LOT of people have significant investments in Setup Projects.


Why did Microsoft remove them? Possibly for the same reason the word “legacy” is used when referring to desktop applications – Microsoft would love to take 30% of all your earnings through the Windows Marketplace, so they are certainly not going to help you deploy “traditional” apps if they can help it. It’s a really bad decision based on a painfully flawed strategic direction… and I doubt there is much we can do about it.

Unless somebody figures out how to put the functionality back in…

Handling Invalid Enum values in a DataContractSerializer

This all started when I was trying to serialize a CodeDom graph (actually a CodeNamespace object) using a DataContractSerializer. I hit the dreaded “Enum value ‘20482’ is invalid for type…”


(Note: this error was the showstopper after many other errors)

The problem: System.CodeDom.MemberAttributes should have the [Flags] attribute, but it does not. the value of 20482 is the bitwise OR of MemberAttributes.Final (2) and MemberAttributes.Private (20480). One solution was to go through all object in the CodeDom tree with attributes and force it to a single value – this is not really acceptable. Unfortunately, since we are dealing with a .NET Framework type, there is really no way to fix the type itself.

The solution: Fix the serializer… Read on for details.

Continue reading

Getting a poorly designed ClickOnce application to Run As Administrator

(Updated 5/10/2012 – I originally claimed that it was “trivial” to make a ClickOnce app require elevation – a commenter pointed out that ClickOnce does not support the requireAdministrator execution level at all. This does not let the vendor off the hook – they should not have used ClickOnce to deploy software that requires features ClickOnce does not support… FYI – there are workarounds from the deployment side)

One of our vendors distributes a couple tools as ClickOnce applications, but these applications perform privileged tasks that do not work with UAC enabled. A ClickOnce application cannot be elevated, nor can it be specified that it requires elevation, so the only way this application would have ever passed testing is if UAC was disabled on the developers’ machines, or Visual Studio is run as administrator)

Rant: UAC has been around since Windows Vista was released in 2006. As of this writing, that would be 6 years. Windows 7 has been out for 3 years. As much as some people might dislike the extra dialogs, UAC is a very good thing, and should not be disabled. There is no excuse for applications that do not handle UAC correctly. Adding the appropriate application manifest is not difficult, and when using ClickOnce it is practically trivial (5/10/2012: Errata: ClickOnce Doesn’t support UAC – I was thinking about Full Trust) and if an application requires elevation it should be distributed standalone or with an MSI setup project.

Don’t use ClickOnce for applications that require elevation; Add the Application Manifest with a setup project to require elevation; or better yet modify your app to not require elevation at all, but do not just pretend it doesn’t exist. 6 years… come on!

Ok, now that my rant is out of the way, if you are in a similar situation – a ClickOnce app that needs elevation to run, but doesn’t request it is a real pain in the butt.


“Run as Administrator” is conspicuously missing from the context menu:

Continue reading

Creating a Custom Tool (Single File Generator) for Visual Studio 2010

A Single File Generator or “Custom Tool” is a COM “extension” for Visual Studio that takes a project file as input, and spits out some code. (One example is the .settings files) Visual Studio automatically includes the code in your project, and updates it every time you save.

I developed a tool that reads an Office 2010 Ribbon XML file and produces an interface will all the callbacks in your file (because implementing callback signatures is a bear).

Unfortunately, Microsoft’s documentation on the subject is incomplete and obsolete. If you search the web, you will find contradictory information…
I didn’t want my assembly in the GAC, nor did want to have to register the COM object globally. I didn’t want to create a setup project, or use any fancy generated code… I just wanted it to work.

So here are some tips that should get you going.

  1. First of all, there is no need to use the Visual Studio extensibility project template for this. Just create a standard Class Library in the .NET language of your choice.
  2. Add a reference to Microsoft.VisualStudio.Shell.10.0 and Microsoft.VisualStudio.Shell.Interop to your project. (If you do not have these, you probably need to download the Visual Studio 2010 SP1 SDK)
  3. In the Project Properties, in the Application tab, click “Assembly Information…” and check the “Make Assembly COM Visible” box.
  4. Do NOT select “Register for COM interop” on the Build tab
  5. On the signing tab, check sign the assembly, and select or create a key
  6. Add the following using statements to your class file:
    using System.Runtime.InteropServices;
    using Microsoft.VisualStudio.Shell.Interop;
    using Microsoft.VisualStudio;
  7. Add the ComVisible attribute
  8. Add a Guid to the class (use the Tools Menu-> Create GUID and select Item 5 for c#, item 6 for, hit copy)
  9. Make your class implement the IVsSingleFileGenerator interface.
  10. It should look like this:
        public class Generator : IVsSingleFileGenerator
  12. Implement the IVsSingleFileGenerator interface’s two methods – Generate and DefaultExtension (see the documentation for more details)
  13. Build it!
  14. Now for the part where the documentation falls apart – registering and using this bad boy.

  15. The easiest way to register this is using the Visual Studio local registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0
    Note: on 32-bit systems, this may be at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0 – I am using the 64-bit
    There should be plenty of sub-keys under this key. If there are not, perhaps you need to look in a different version, or bit-ness
  16. First, you need to add the COM information like so
    Windows Registry Editor Version 5.00
    "Assembly"="DemoSFGen, Version=, Culture=neutral, PublicKeyToken=faketokenfffff88"
    "CodeBase"="file:///C:\\Users\\username\\Documents\\Visual Studio 2010\\Projects\\sfgen\\sfgen\\bin\\Debug\\sfgen.dll"

    Replace the GUID after CLSID with the GUID you generated earlier; replace the Class with your Namespace.ClassName; replace Assembly with the information from your dll (I used ILSpy – I’m sure there’s an easier way); replace CodeBase with the full path to your dll.

  17. Next, add the registry info to tell Visual Studio about the Generator:
    Windows Registry Editor Version 5.00
    @="Nice Name For your Generator"

    The GUID after \Generators\ corresponds to the languages in Visual Studio. See the docs for registering single file generators for a couple (or have a look in the registry).
    The Key name under the language guid (DemoSFGen in this case) is (I believe) how you will refer to the Custom Tool
    The value of CLSID needs to match your generated GUID

  18. Run Visual Studio, open a (different) project, and select an appropriate input file (text, xml, etc) In the properties for the file, add the name of the Custom Tool (“DemoSFGen”).
  19. Right click on the file, and select “Run Custom Tool”
  20. If everything worked, you will now be able to expand the file, and see your generated source underneath it. If there was a problem, Visual Studio may or may not display an error…

I know that Custom Tools aren’t the most often created things in the world, but hopefully these steps can at least get you up and running when you do try.