Macros Have Been Dropped from Visual Studio 11
As of version 11, macros will no longer be available in Visual Studio. This marks the first version in nearly a decade to not allow for crating ad-hock extensions to the IDE. Fully compiled extensions can still be created and new project templates are included to make that process much easier.
According to Microsoft’s usage tracking data, macros in Visual Studio are currently being used by less than 1% of all developers. This alone isn’t enough to cause Microsoft to drop the feature, the macro feature in Visual Studio has also a disproportionately high maintenance cost. Unlike most other features, the macro support has to be updated and exhaustively tested for each new version of Visual Studio. In theory one should be able to record and replay any feature via the macro IDE, which places a huge maintenance burden on Microsoft.
According to Matt Kaufman, the macro IDE hasn’t been updated for several versions. Firing it up, one will quickly notice that it looks like an old version of Visual Studio. More troubling is the fact that it still only supports Visual Basic. One cannot use C# or any of the newer .NET languages to create macros.
As mentioned before, the support for extensibility now includes several new project templates. The current list, which is offered under both VB and C# follows:
- Visual Studio Package: This is used for the older VSPackage style pugin-ins.
- Editor Classifier: Used for creating your own syntax highlighting
- Editor Margin: Used to adorn the margins in an editor window
- Editor Text Adornment: Used to adorn text within an editor window
- Editor Viewport Adornment: Used to place editor visuals relative to the editor’s visual surface
- [VB/C#] Item Template
- [VB/C#] Project Template
- VSIX Project: This is the newer plug-in model that is most commonly seen in the Visual Studio Gallery
- Windows Forms Toolbox Control
- WPF Toolbox Control
In addition to the language specific templates there is a generic extensibility folder containing:
- Visual Studio Add-In: This is a wizard that lets you create add-ins using C#, VB, C++ ATL, or C++ CLR.
- Visual Studio Package: This is another wizard that lets you choose between C#, VB, and C++.
- Visual Studio Shell Isolated: This lets one create applications based on the Visual Studio IDE itself. An early example of this is the AddOn Studio for World of Warcraft.
Developers are just users, they don't customize
We know that average users don't customize settings either. Yet a lot of developers tell them "there's a setting for that, if you wanted it, why didn't you set it at the first place?"
Also, for dynamic languages, the IDE support in recent years was terrible. Once another php architect came to me and told me, I can't be an architect like him, as I use vim, and a real architect should use an IDE. I asked him: what features do you use of that IDE? Do you build custom modules? No, we use what came with it. Do you use refactoring features? No, it doesn't work in PHP in our IDE. Then what on Earth are you talking about? I'm full of vim refacroring macros, custom editor shortcuts and I regularly kill of antipatterns in the code using automated refactoring. Still he wasn't convincible...
(When I'm doing java, I prefer IntelliJ as it rocks, especially in refactoring which I love there; I don't have too many realistic options when I'm doing c#, of course...)
Also, developers tend not to build editors for their own domain-specific languages, or some even can't configure a custom deployment system, which surprises me especially in xml and cloud settings (the ability to build a visual editor to our yaml-based form and entitity descriptors, and one-click deployment w/ jira handling were the sole reason I started to standardize on netbeans, despite having terrible php/js support, and questionable java support)
So, today's developers are just users: they don't think into it that the tools they use are simply code as well, and they don't try to recognize their own use cases and improve their own situation, which is really sad and provokes further questions on the role and future of our profession as well.
Putting this into context
Besides being woefully outdated, Microsoft has hired Erich Gamma of Eclipse fame to work on various sprints to improve Visual Studio. Macros don't save nearly as much time as features like Eclipse's Mylyn project, and other timesaving features that better integrate a developer's workflow. If a developer wants "macros" for Visual Studio, then they have tons of third party tools that do the job better, such as CodeRush. Incidentally, CodeRush just announced it is ready for Visual Studio 2011.
It is not like you can't do keybindings in Visual Studio, either. There are even Emacs Emulation Mode plug-ins for VS 2010. It would be funny if people, voting with their feet, used Emacs Emulation Mode, or a VIM plug-in, or CodeRush instead of the Microsoft-supported product. The phrase "too clever by half" comes to mind for the macro IDE.
Still need record/playback of plain keystrokes
But the Macros IDE aside, can anyone tell me where I can now go to simply record and playback keystrokes in VS-11? Since this (legacy) feature uses the Macros IDE transparently in the background, it too is now gone. I have used this feature most every day in Microsoft compiler products dating back 20+ years . . . and now they've decided to take it away?!?
Really -- what is the replacement for this? If MS can supply us with a record/playback keystrokes extension, I'm fine with that; I just don't know if that's even possible.
Re: Still need record/playback of plain keystrokes
I just installed VS 2012 and was appalled that recording basic keystrokes was not available.
Does this mean that we are a part of the 1%? (I can see the protesters circling already).
But seriously, when working on legacy code, repeated edits always happen (like changing a ubiquitous function call so that it looses a parameter). But creating an extension for something that is going to be used for all of an hour and then thrown away!!!
My carpal tunnel is going to suffer because of this.
Tom Gilb & Kai Gilb Jan 26, 2015