Visual Studio is celebrating its 20th anniversary these days! Twenty years ago Visual Studio 97 was launched and on March 7 Visual Studio 2017 RTM has been released in a livestreamed two-day launch event at https://launch.visualstudio.com. You can share your story with Visual Studio with the hashtag #MyVSStory.

My story with Microsoft tools started some years earlier, in 1994. During college I learned Modula-2 (similar to Pascal), C and some C++. In my first job, my boss gave me a book and told me to learn Visual Basic 3.0 in two weeks, and I fell in love with the language and IDE in a couple of days, as soon as I saw a VBX control to show maps. VB3 lacked classes, intellisense and a lot of things, but it was very productive compared to C/C++. In 1996, VB4 was released, which came in two flavors, 16-bit and 32-bit, used OCXs and introduced classes, but no extensibility yet. In 1997 Visual Studio 97 was launched, which was a suite of separate IDEs, one for Visual C++, one for Visual Basic 5.0, etc. and for the first time, extensibility in the form of add-ins:

Only one year later, Visual Studio 6.0 was released with VB 6.0, that offered a very similar extensibility model. Next year, my company hired a contractor to develop an add-in to review the quality of the source code of our applications. These days of Visual Studio Code Analysis (FxCop), Roslyn analyzers, SonarLint, and tons of similar extensions we take this for granted, but in 1998 there was nothing. The contractor did a good job, but after he left I felt that I could improve the add-in, so I learned the extensibility model of VB6 and I fell in love again :-). I ended developing my own add-in with new features that I released as freeware on the web.

During almost three years, from 1998 to 2001, Microsoft didn’t release a new Visual Studio, and for a good reason. The .NET Framework initiative was announced in 2001, and finally in February 2002 a brand new Visual Studio .NET was released, a unified IDE for VB.NET, Visual C++, a new language C#, etc. I learned .NET during 2002 (I fell in love again…) and the new automation model (EnvDTE) provided by the new IDE, that was completely different to the one of VB6 but inherited some strange details such as collections starting at 1 and not at 0. Visual Studio .NET 2002 provided add-ins, templates, wizards, and a new extensibility mechanism named Macros that allowed to record or to code by hand procedures to execute repetitive actions. But it didn’t provide support to create packages, nor a SDK. From the extensibility point of view, it had some oversights, such as requiring add-ins to be COM components (and therefore using COM Interop if written in a managed language instead of C++) and requiring a COM Shim (an ActiveX control developed in C++) to host managed toolwindows (and the provided COM shim had lots of problems with the tab key navigation, etc.).

Only 14 months later, in April 2003, Microsoft released Visual Studio .NET 2003, which introduced for the first time VSIP (Visual Studio Integration Program), a kind of SDK (not named as such yet) to develop native packages in C++. Later a VSIP Extras was released to use manage languages (C# at least).

Two years later Visual Studio 2005 was released, which was a great release. It introduced .NET Framework 2.0, MSBuild, and important novelties in the extensibility area: it provided a proper VS 2005 SDK for the first time, it allowed to develop packages in managed languages using the Managed Package Framework (MPF), it allowed XML-based add-ins (using an .AddIn file instead of COM-registration), it didn’t require COM shims for toolwindows, and it was gorgeous with its 24-bit color toolbars.

(In November 2006 I started to blog about Visual Studio Extensibility (VSX) with add-ins).

Visual Studio 2008 was the next release, which didn’t introduce anything remarkable in the extensibility area, but Microsoft introduced in February 2008 the Visual Studio Gallery:

And then Visual Studio 2010 was released, which, for me, has been the best and more beautiful Visual Studio ever released, despite the insane amount of problems that caused to developers of add-ins during the betas because new Windows Presentation Foundation (WPF)-based commandbars were introduced. From the extensibility point of view, add-ins didn’t require a satellite dll for custom pictures any more, the Managed Extensibility Framework (MEF) was introduced to extend the new code editor (which was WPF-based too), changed the .ctc format to define commands and commandbars to the .vsct file that is used still today and introduced the VSIX packaging format to deploy extensions (except add-ins). It also introduced the Extension Manager:

Two years later Visual Studio 2012 was introduced, which arguably has been the most unfortunate Visual Studio version ever released. It removed colors from the user interface (and even separation lines during the betas), it used upper-case top menus (all of this despite tons of complains) and from the extensibility point of view, it removed macros, a very controversial decision that reached 6,000 votes to bring them back on UserVoice (something that happened some years later in the form of an extension for VS 2013/2015).

I think that even Microsoft realized that Visual Studio 2012 was quite disappointing, because it released Visual Studio 2013 very fast, only a year later instead of the usual 2 or 3-year cycle. Some color was brought again with themes (not too enough color for me, though), but, alas, for developers of add-in there was bad news: add-ins were still present, but officially deprecated. Packages were the primary form of extensibility for Visual Studio and finally Microsoft decided it was time to get rid of add-ins. Retrospectively I am glad of that decision because it forced me to learn packages, but it was a huge amount of work that required some thought and strategies. Visual Studio 2013 introduced big news for all developers: a free Community Edition that supported extensions, on the contrary to the former Visual Studio Express editions, a common request on UserVoice.

Visual Studio 2015 was released two years later, effectively removing add-ins. The venerable Add-In Manager of Visual Studio since the year 2002:

was removed and the Extensions and Updates dialog became the central window for extensions:

Visual Studio 2015 also brought us async packages, new ruled-based UI contexts, the Image Service and Catalog to eliminate major pain points related to asset maintenance, high DPI scaling, and theming and a huge Visual Studio Image Library. It also provided “Roslyn”, that is, the C# and VB.NET compilers as platform, and open source, so you can leverage them to build Roslyn analyzers (live code analysis without building) and code fixes.

The Visual Studio 2017 version that was released on March 7 provides the Roaming Extension Manager, something that was available originally for Visual Studio 2015 as an extension. It also provides also a very light setup, very isolated and resilient, that requires some changes in extensions. A handy feature for VSX developers is that now the Community, Professional and Enterprise editions can coexist on the same computer, which allows you to test your extensions on all those editions without requiring additional computers or virtual machines.

Finally, the Visual Studio Gallery is in the process to be transformed into the Visual Studio Marketplace. For Visual Studio currently it only allows to download extensions, while the publishing is still done on the Visual Studio Gallery, something that will be migrated in the next months.

For many years VSX was hard due to difficult APIs and lack of documentation and support, but now you have much better documentation, tons on samples on GitHub, including real extensions, tons of VSX developers, and several forums such as the veteran MSDN Visual Studio Integrate forum (still my favorite that I visit daily), StackOverflow or the more recent and very active Gitter (Microsoft/extendvs) chat room.

So, it has been a long journey for Visual Studio extensibility until today and likely I have forgotten some milestones. But one thing is sure: this is the best moment to be a VSX developer. Happy Birthday, Visual Studio!

I already blogged about Visual Studio extensions and DPI-awareness, where I detailed my experience converting my MZ-Tools extension to DPI-awareness for the most part (I haven’t updated the toolbar buttons yet because the required API only works on VS 2015 and higher).

I also mentioned how to run Visual Studio or setups with DPI virtualization (DPI-unaware) on high DPI displays, to overcome some display problems that can happen designing Windows Forms or running some old SDK setups.

My problems didn’t end there, though. One of my customers reported me a bug that happened when using a laptop with a retina display connected to a non-retina external display. I was familiar with the problem because I have suffered it too, since I own a Surface Pro 4 with a dock station that uses a non-retina display. With some combination of undocking / restart / docking, I could end with this problem using MZ-Tools 8.0 for VBA in the VBA editor of Office (click to enlarge):

I thought that I was the only person with that problem but after the bug report I knew it affected other users. Also, I noticed that when the problem happened, Notepad++ was also affected in the document tabs, and it was already reported here, here and here:

My add-in uses Windows Forms, but Notepad++ uses GDI, so it is not a problem of Windows Forms but of GDI.

Aa a workaround, I had to change all the forms and usercontrols of my add-in to detect if the font was “too big” and in such case adjust its size. Technically, the System.Drawing.SystemFonts.DefaultFont is returned huge. It happens that internally it calls GetStockObject(DEFAULT_GUI_FONT), which according to MSDN is not recommended. So, if the add-in detects that the font of the form/usercontrol is much bigger (say, two points) than the size of System.Drawing.SystemFonts.MessageBoxFont (which is not affected by the problem), then it changes the size. The problem is convoluted by the fact that I cannot reproduce it at will.

It seems that the DPI-awareness problem is so pervasive that Microsoft has invested a lot of work to fix or alleviate it on the Windows 10 Anniversary Update introducing the concept of “Mixed-Mode” DPI scaling, also known as sub-process DPI scaling, via the concept of the DPI-awareness context (MSDN documentation here) and I am glad to see that the investment will continue heavily on the new Windows  10 Creators Update, due later this year, that will introduce new enhancements, including a new DPI-awareness context (“Per-Monitor V2”), automatic DPI scaling for GDI-based apps, new Windows Forms DPI scaling improvements (for people like me still using Windows Forms) and other improvements for Internet Explorer and Windows desktop icons (that I suffer too). You can watch the following video by James Clarke and Peter Felts explaining the improvements and showing cool demos (new post and sample to follow soon):

This is another cross-post from my other web site, Visual Studio Resources, that may be of your interest as a VSX developer if your extension uses Windows Forms or .NET 2.0/3.0/3.5 tooling (included in WinSDK 7.1, but not in WinSDK 8.0 or higher):

The high-DPI (retina) displays pose some problems to us developers, so that we need to modify our applications to make them DPI-aware. In the post Visual Studio extensions and DPI-awareness I explained how I became DPI-aware and the painful experience to make my application (an extension for Visual Studio) DPI-aware. If you don’t know about DPI-awareness, start with that post.

In this post, I am going to explain how to do the opposite: to make an application that claims to be DPI-aware run as DPI-unaware. Technically this is called DPI virtualization mode, where the application thinks that it is running at 96 dpi and the Windows OS scales its window as a bitmap to the proper size. The result is that the application appears blurred but it’s usable, while in DPI-aware mode it has problems (by the way, if your problem is the opposite, see the Knowledge Base article Some desktop applications may appear blurred on high-DPI displays).

I have found a couple of scenarios where I have wanted some applications to become DPI-unaware even at the cost of appearing blurred on my retina display:

The first case is designing Windows Forms with Visual Studio. Modern versions of Visual Studio (2015, 2017) are truly DPI-aware but they alter the designer files of Windows Forms, so you need to either use a non-retina display, or to use a virtual machine with retina display disabled or to set the retina display scaling to 100% instead of 200% or 250%, which makes everything tiny and unreadable. But there is a better solution: you can make Visual Studio (or any process) DPI-unaware adding the following registry entry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
"dpiAwareness"=dword:00000000

(Thanks to Tanya Solyanik, from Microsoft, that provided me this trick).

The other case is an application that claims that it is DPI-aware, but it is not really. For example, the setup of the Windows SDK 7.1 (you may download it as winsdk_web.exe, but once executed the process is really sdksetup.exe). You can see here in Process Explorer that it claims that its DPI-awareness is “System Aware”:

But when executed on a retina display, it becomes tiny and truncated:

When creating the registry entry above for SDKSetup.exe:

then it displays with the correct size and without truncations, that is, usable (although blurred):

I hope this post helps if you are in one of those two scenarios.