Category Archives: Other

Three things from Eclipse that would be nice to have in Visual Studio to develop extensions

While I have been working with Visual Studio .NET since the first version (2002), some years ago I started a start-up with a friend to develop crossword games for J2ME-enabled mobile phones. So I learned Java, downloaded the Eclipse IDE and the EclipseME plug-in (now Mobile Tools for Java) to develop J2ME MIDLets, and I had a lot of fun 🙂

There are three things from Eclipse that impressed me from the start that all these years developing add-ins for Visual Studio I miss a lot:

1) There is no setup.

You download a zip file, unzip it to some folder and that is all. Compare this with the installation of Visual Studio that even for service packs is increasingly longer. This is also true for other Microsoft products like Office, but at least Office will “fix” the problem when the Web-enabled version appears, so you will be able to create documents or spreadsheets like you can do it today with Google Docs. If you develop extensions for Visual Studio you need to have several versions and even service packs installed on your machine, and installing all them is painful, and you can’t have a version without service pack and other with service pack on separate folders, and you can’t install CTPs or betas because nobody could cleanup and restore everything when uninstalled, and the “solution” to all this is to use… virtual machines, which have their own dosis of problems (at least Virtual PC), they are increasingly heavier, require more memory on your computer and you need some more steps to deactivate CTP timebombs. Imagine that you could unzip Visual Studio versions, service packs or CTPs/betas on separate folders of your machine without touching the Windows registry…

2) You can have the source code for the IDE.

I can not emphasize enough how important is this when you develop some non-trivial extension for Visual Studio. But until recently even the source code of the .NET Framework was not available, so tools like .NET Reflector to decompile assemblies appeared, a tool that would have made rich its author if he would have charged just five dollars to each .NET developer that uses it rather than making it freeware (thanks, Lutz). Microsoft provided the source code of the .NET Framework with the release of Visual Studio 2008, and even the mechanism to debug it if you need to do so. But the source code of Visual Studio remains closed so you can’t understand how some internals of VS work, not to mention debug it, why your add-in or package doesn’t load or give you a cryptic COM error, etc. While it is understandable that some portions should remain closed (such as the .NET compilers or parsers), others could be perfectly provided with source code. All new additions to VS are now managed (not native), so you can decompile them to try to understand how they work. It would be nice to have the source code without decompilation and be able to debug your extension along with Visual Studio code.

3) It was thought with extensibility in mind from scratch

I have not used extensibility in Eclipse but from what I have read, it was fully extensible from scratch and everything was made with a minimal shell with lots of plug-ins for the features. Visual Studio, on the other hand, only provided extensibility through add-ins, macros and templates in the initial VS.NET 2002. The VSIP program to develop 3rd party packages didn’t appear until the VS.NET 2003 release. You didn’t have something named Visual Studio SDK until the VS 2005 release. Something like the Visual Studio Shell didn’t appear until the VS 2008 release. All that complicated by an IDE that was born as a native, COM (not .NET) application to develop mainly .NET applications but that required extensions to be COM. We are still suffering that…

The good news is that Microsoft is working a lot and really hard on point #3 to catch up. I wish they can think about points #1 and #2 too.

VB.NET 10.0 and C# 4.0 future directions: co-evolution and “compiler as service”

In the last days I have watched (among others) two videos of the PDC 2008 about subjects that are always of interest for developers of extensions for Visual Studio, specially if the extension deals with source code, which will be the usual thing in most cases:

Future Directions for Microsoft Visual Basic
http://channel9.msdn.com/pdc2008/TL12/

The Future of C#
http://channel9.msdn.com/pdc2008/TL16/

The matter of new syntax and language constructs is of most interest for many 3rd party tools. To put two examples, C# 4.0 will allow optional parameters and VB 10.0 will not require the line continuation character “_” to break lines in many cases.

There are two concerns regarding all this:

  1. Whether the automation model (EnvDTE*) will be updated to recognize it. It is not a secret that EnvDTE was not much enhanced since VS 2005 when EnvDTE80 brought new classes like EnvDTE.CodeClass2, EnvDTE80.CodeFunction2, etc.
  2. Four releases later, the automation model doesn’t support yet code inside methods, so you can’t get the method variables, constants and statements unless you parse the code on your own. While this is somewhat easier for VB.NET due to its verbose syntax (Dim, Const, End If, Next, etc.) it is painfull for C#.

In C# 3.0 and VB 9.0 parsing, type resolution and expression resolution got complicated with lambda expressions, extension methods, infering types from initializers, etc. but in the next versions of the languages with its “dynamic” approach this is going to be crazy. For example, VB 10.0 will support this syntax:

Sub Main()
...
   Dim thread As New Thread(Sub()
         For Each o In scores
            Console.WriteLine(o.ToString)
         Next
      End Sub
...
End Sub

That is, a Sub inside a Sub!. So, when you parse looking for variables, you will need also to take into account nested methods…  will the automation model provide something like EnvDTE100.CodeFunction3.CodeElements or EnvDTE100.CodeFunction3.CodeFunctions?

Not all are bad news; in fact, there are a couple of very good news:

  1. “Co-Evolution – there are no differences between the users of VB and C#. We are going to co-evolve the languages going forward. This means that if we introduce the features in one – then we will work hard to make that feature available in the other.”I wonder why MS took 6 years and four releases to realize this. When I heard some years ago that VB.NET developers where more concerned about productivity and C# developers were more concerned about “the code”, I thought it was a nonsense, as if C# developers wouldn’t like to be productive or VB.NET developers wouldn’t care about the elegance of code. The fact is that it is only a question of syntax: VB.NET is the natural option for people coming from a VB6/VBA background while C# is the natural choice for people coming from Java/C++ (let me say that I think that any good developer should know several languages). And from that point, both groups want the same features in the IDE and in the language(s). I have heard some people arguing that forcing both VB.NET / C# teams inside MS to provide the same features would hinder innovation, it takes time to catch on the other language, and that competition is good. For me, the question is why there are two whole huge separate teams to create two project subtypes that for the most part differ only in the syntax of the language (this is also true for the deceased Visual J#). I mean, they use similar project subtypes, with files or linked files, with imports/using, with compiled or source code references, with project property pages with similar properties, with configurations (Debug/Release) with similar properties, that compile to the same IL, etc. I guess this is for historical reasons, and maybe I am too naive, but it seems to me more natural to evolve towards a whole huge team that takes care of common things and allows extensions for VB.NET and C# (for example, the parsers), which would be developed by two small teams. My MZ-Tools add-in for Visual Studio supports VB.NET, C# and VJ #, it has tons of files and code, but it has a single file called MultiLanguageLibrary that handles the language differences. For example, imagine that Microsoft builds parsers that convert:C#
    int i = 5;
    f(i);
    

    or

    VB.NET

    Dim i As Integer = 5
    Call f(i)
    

    to something like this:

    <codeelement name = "i" kind="methodvariable" type="Int32" initialValue="5">
    <codeelement kind="methodcall" name="f">
       <arguments>
          <argument kind="methodvariable" name="i"></argument>
       </arguments>
    </codeelement>
    

    (just an idea)

    and then the remaining path is common for all languages. BTW, it would be nice to provide that parsing output to developers of extensions, and this is the second good news:

  2. Parsers/Compilers/Code Generators as services: Microsoft is going to “open up the box” so it is no longer a “black box” and will expose services to interact with its internal parsers, compilers, etc. so hopefully you don’t need to build your own parser and you don’t need to use the buggy and incomplete EnvDTE.Project.CodeModel / EnvDTE.ProjectItem.FileCodeModel. Don’t get too excited yet, since this will take years, though, and several Visual Studio releases.

Happy New Year 2009 and MVP again!

Hello all, and Happy New Year! I have just received today the e-mail from Microsoft awarding me the Microsoft Most Valuable Professional (MVP) title again (this is the sixth one since 2004!). I am very grateful and excited about this award and along with feedback that I receive from people it really encourages me to keep devoting quite of my spare time to the community of developers extending Visual Studio, mainly with add-ins.

Some weeks ago I took some days off and I got inspired those days with four (yes, 4) new initiatives or projects that I would accomplish in 2009 to help developers of add-ins for Visual Studio, apart from writing a new bunch of MZ-Tools Articles Series and answering questions in the MSDN forum about Visual Studio Extensibility. I will announce them in the next weeks or months as they move from a “proof of concept” state to something deliverable.

More on Visual Studio and .NET version numbering

Numbering is quite easy for any normal person (or even child) that you ask: 1, 2, 3, 4… For programmers it begins to get weird since many of them would say 0, 1, 2, 3… and when programmers need to version things, it goes absolutely crazy. It should be easy, though: a major number, a minor number (both quite visible to the end user) and some internal build number no so visible. So, you would have version 1.0. And the next major version would be 2.0. And some minor incremental version like 2.1. And something in between like 2.5. However early in the modern era of computing for the masses (that is, MS-DOS and Windows) we got something like Windows 3.11 for Workgroups (rather than 3.2) or Windows NT 3.51 (rather than Windows NT 3.6). And even in same cases letters like Windows NT 4.0 SP 6a. And we got four parts for versioning from Microsoft (major, minor, build, revision) and programmers from Oracle used even five parts. And then marketing people introduced a new scheme using years so you had Windows 95, Windows 98, and then something like Windows 98 SE, and then to something completely different without the year like Windows ME (Millenium Edition, don’t worry if you missed it) and then back to the year with Windows 2000 and then forward again without years like Windows XP or Vista and then back to square 1 (or 0?) with plain numbers again like Windows 7 (but not 7.0). OK, I am also guilty and I created MZ-Tools 4.0, then MZ-Tools 2005 and then back to MZ-Tools 6.0. I promise the next one will be 7.0 🙂

Now, to Visual Studio and .NET versioning. I wrote some time ago about some inconsistencies in the numbering used to version. I have created a more complete table. It would be nice that the table would be something like:

Visual Studio Commercial version 2002 2003 2005 2008 2010 (CTP)
Visual Studio ProgId VisualStudio.DTE.7.0 VisualStudio.DTE.7.1 VisualStudio.DTE.8.0 VisualStudio.DTE.9.0 VisualStudio.DTE.10.0
Visual Studio installation folder Microsoft Visual Studio 7.0 Microsoft Visual Studio 7.1 Microsoft Visual Studio 8.0 Microsoft Visual Studio 9.0 Microsoft Visual Studio 10.0
Visual Studio solution format 7.0 7.1 8.0 9.0 10.0
Visual Studio registry key 7.0 7.1 8.0 9.0 10.0
DTE version 7.0 7.1 8.0 9.0 10.0
.NET Framework folder v1.0 v1.1 v2.0 v3.0, v3.5 v4.0
SDK folder C:\Program Files\Microsoft Visual Studio 7.0\SDKv1.0 C:\Program Files\Microsoft Visual Studio 7.1\SDKv1.1 C:\Program Files\Microsoft Visual Studio 8.0\SDKv2.0 C:\Program Files\Microsoft Visual Studio 10.0\SDKv4.0
SDK registry key name (under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\Framework) sdkInstallRootv1.0 sdkInstallRootv1.1 sdkInstallRootv2.0 sdkInstallRootv4.0

But actually it is like this:

Visual Studio Commercial version 2002 2003 2005 2008 2010 (CTP)
Visual Studio ProgId VisualStudio.DTE.7 VisualStudio.DTE.7.1 VisualStudio.DTE.8.0 VisualStudio.DTE.9.0 VisualStudio.DTE.10.0
Visual Studio installation folder Microsoft Visual Studio .NET 2002 Microsoft Visual Studio .NET 2003 Microsoft Visual Studio 8 Microsoft Visual Studio 9.0 Microsoft Visual Studio 10.0
Visual Studio solution format 7.00 8.00 9.00 10.00 11.00
Visual Studio registry key 7.0 7.1 8.0 9.0 10.0
DTE version 7.00 7.10 8.0 9.0 10.0
.NET Framework folder v1.0.3705 v1.1.4322 v2.0.50727 v3.0, v3.5 v4.0.11001
SDK folder C:\Program Files\Microsoft Visual Studio .NET 2002\Framework\SDK C:\Program Files\Microsoft Visual Studio .NET 2003\SDKv1.1 C:\Program Files\Microsoft Visual Studio 8\SDKv2.0 C:\Windows\Microsoft.NET\Framework\v4.0.11001\sdk (*)
SDK registry key name (under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\Framework) sdkInstallRoot sdkInstallRootv1.1 sdkInstallRootv2.0 sdkInstallRootv4.0

(*) Notice that it uses the Microsoft .NET root folder and not the Visual Studio root folder.

It is left to the reader as an exercise to print this post, mark with a circle the differences between both tables and post a comment with your differences count 🙂

And why is this so important? For most users of Visual Studio, it really doesn’t matter. But for people developing extensions (add-ins, packages, etc.) for Visual Studio, it matters, because the extension needs to integrate within the Visual Studio host. It needs to place files in some folders (1). It needs to add/remove some entries to the registry (2). In needs to automate DTE for some tasks (3). It needs to get the paht to devenv.exe for others (4). It needs to get tools from the SDK to register (5). Its setup needs to use the Visual Studio ProgId registry key (6). Etc, etc.

(1) To register XML-based add-ins

(2) To register COM-based add-ins

(3) To remove add-in commands in VS.NET 2002/2003

(4) To remove add-in commands in VS 2005 and higher with devenv.exe /ResetAddIn

(5) To register COM-based add-ins with regasm.exe /codebase using a 3rd party installer such as InnoSetup.

(6) To detect if Visual Studio is installed or it is running.

And when your extension needs to target lots of Visual Studio versions for many years, you really need a table like the one above, because your brain won’t be able to recall all and if you did the proposed exercise you know by now that versioning patterns are unpredictable in Visual Studio and .NET (except for the “Visual Studio registry key” row, until now).

How to ask questions in a forum to increase your chances of an answer

Being developers I guess we all get the same feeling when some user of our application tell us that the app “doesn’t work”, or “it gives me an error” without further details. I am always tempted to reply “it works for me” to the first case and “which are the ‘first name’ and ‘last name’ of the error?” for the second case, to see if they get that more information is needed to do something about it. Yet after years in the forums I keep seeing lame posts written by developers that fail to give a meaningful subject, the version of the product that are using, the error that are experiencing, the code to reproduce it (or they provide the whole file of code with tons of lines), etc. I wonder how they expect to get a prompt and useful answer…

So today I decided to do something about it and I have written a sticky post in the MSDN forum about Visual Studio Extensibility:

How to ask questions to increase your chances of an answer
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/9307ca0b-d152-4c31-85f5-05b6166d7410

How many old Visual Studio versions does my add-in/package have to support?

I’m sure this is a question that every developer of extensions for Visual Studio, whether add-ins or packages, wonders from time to time. If you develop extensions for in-house use, you can drive, incentivate or even force your organization to migrate to the latest version of Visual Studio. But if you develop extensions commercially, things are quite different.

At the time of this writing we have the following Visual Studio versions:

  • Visual Studio .NET 2002, released in February 2002.
  • Visual Studio .NET 2003, released in April 2003.
  • Visual Studio 2005, released in October 2005.
  • Visual Studio 2008, released in November 2007.
  • Visual Studio 2010, to be released at the end of 2009 or in 2010.

Five releases start to be a lot of releases… even if you have managed to have a single code base for your extension (with some conditional compilation), or maybe even the same binary for several Visual Studio versions (with some dynamic adaptation to the Visual Studio version hosting the extension), and maybe the same setup, nothing can avoid you a lot of testing, to ensure that your extension works correctly on each Visual Studio version, because from time to time Microsoft introduces unintentionally new bugs. Furthermore, you would like to use new features of the .NET Framework like Generics of .NET 2.0, which you can’t use if your codebase is still to be build against .NET 1.0 or 1.1. You are also tired of having four whole releases of Visual Studio installed on your machine with identical shortcuts in the quick launch toolbar of your Windows (sort of Visual Studio 2008, which introduced the version number “9” in the icon). And some of the Visual Studio releases are not supported on your Windows Vista but since you want the latest OS, you don’t want to go back to Windows XP, so you install them anyway, and they work for the most part, but some very used features like Find hangs and you get frustrated…

So, you really wonder if you could drop support for VS.NET 2002. If your extension is a package, VS.NET 2002 didn’t provide support for 3rd party packages so there is no question. If your extension is an add-in, then you could probably drop support because VS.NET 2002 was the version 1.0 of the new IDE and it was somewhat incomplete and lacking some features that Microsoft took only one year to replace it instead of the usual two years cycle. And by the time people learned .NET and decided whether to use it for some serious project or not, VS.NET 2003 was out.

What about VS.NET 2003? This version introduced the Visual Studio Industry Program (VSIP) for packages, which in VS 2005 would evolve into the Visual Studio SDK. So, you really would like to get rid of VSIP and use only the new VS SDK, and dropping support for this version would mean that you can move your codebase to .NET 2.0, and your add-in can get rid of COM using toolwindows without a shim control, using XML-based registration rather than Registry-based registration, managed satellite DLLs instead of native C++ satellite DLLs, etc. And you wonder, how many people is still using VS.NET 2003? Hey, that’s stuff of five years ago! Could I get some usage statistics from somewhere, Microsoft perhaps? Do I send an e-mail to my customers? Do I drop support anyway?

Well, if you are a successful commercial vendor, you already know that all is about the customer, not about you, your technology, your preferences or your desires (if you are still a geek with disdain for marketing and sales there is good stuff to learn out there). So, let’s talk about the customer:

  • Customers hate when they have some software and hardware that at some point is not supported by the vendor, no matter how old. I remember that I had an HP CD recorder that when Microsoft shipped Windows XP was no longer supported. I found an article from Microsoft pointing to the HP web site, and indeed HP stated that they wouldn’t provide Windows XP drivers for that model. My CD recorder could be old and slow (4x, I think) but at that time it worked for my needs and if I needed to buy a new one to work with Windows XP, I may well purchase it from another vendor…. I haven’t purchased an HP product since then for that reason.
  • While you as a developer may have a MSDN subscription to get all the Microsoft software for development, many customers don’t. They buy some Visual Studio version and don’t upgrade unless they have the money and some compelling reason to do it (and maybe WPF, AJAX, etc, don’t qualify as a compelling reason). Think that the MSDN subscription is per-developer, not for a whole team. So only medium or big companies with special agreements (“Enterprise”, “Open”, “Select”) with Microsoft get new software as it is released. Students and hobbyists also get the latest versions in the form of Express editions, but these don’t support extensions, and you wouldn’t get much money from them anyway.
  • Even if a company has a software subscription with Microsoft and receives the new Visual Studio versions, they may have dozens or maybe more than a hundred .NET projects. And they have better (business) things to do than to migrate them just for technology purposes, forced by a vendor. Their company has already installed some .NET Framework version, and their projects and the Visual Studio version that they are using meet their needs. Or they use the latest Visual Studio version for new projects, but they don’t migrate the old ones because it takes time to do it.

So, despite your big desires of getting rid of old Visual Studio versions, as a developer of add-ons you need to support many previous versions of Visual Studio, and for many years. It’s the price you have to pay for developing extensions and not standalone applications. If I had doubts about dropping VS.NET 2003 support for my MZ-Tools add-in, the last two support e-mails that I have received about my MZ-Tools 6.0 for VS.NET add-in were from people still using VS.NET 2003… and you would be really surprised of how many people still download the version of my MZ-Tools 3.0 version of my add-in for Visual Basic 5.0 each month despite I would think that everybody had migrated to Visual Basic 6.0…

Fixed: Reading whole posts of this blog through a RSS reader

Today I have found the setting in the Community Server that hosts this blog that sets if the whole post or just a summary is published in the RSS feed. It was configured by default to publish only the summary so you got a “Read more…” at the end of an excerpt of each post when using a RSS reader. I tried to find the setting some months ago to no avail and today in a second try and after some searches on the web I have succeded 🙂

For other bloggers with the same problem, there are actually two settings, quite hidden (at least for me):

  • In the Control Panel, “Configure” tab, “Post Options” sub-tab, “Display” sub-sub-tab (no wonder I didn’t found it) there is a setting “Use post summaries in RSS” that by default was set to “Yes”. It needs to be changed to “No”. From this moment, the whole content of new posts is published, rather than a summary. Existing posts remain summarized, but you can change them with a second setting:
  • When you edit a post, go to the “Publication Settings” tab and there is a setting “Use post summaries in RSS”. By default it uses the general setting above but you can change it individually for each post. I have changed a few of past posts before getting tired…

So, you can now read whole posts with a RSS reader.

Modeless forms in add-ins

Basically you could use three kind of forms in your add-ins:

  • Modal forms: these are regular forms that are shown modally and block the UI until you dismiss them. For example, the Options window of Visual Studio.
  • Modeless forms: there are regular forms that are shown non-modally. For example, the Find dialog of the old VB6. AFAIK, VS.NET doesn’t use modeless forms at all.
  • Toolwindows: these are special windows that can be docked to edges of the IDE. For example, the Solution Explorer, etc.

It happens that modeless forms are tricky: they had some problems in VB6 (like not being minimized along with the IDE) and if I remember correctly they were unable to get the focus (or keyboard input, not sure) in Visual Studio .NET, so using toolwindows is almost mandatory in VS.NET. But my MZ-Tools add-in for VB6/VB5/VBA used modeless forms for some features, using a hack to be minimized with the IDE rather than staying on the screen. The hack involved some call to the SetParent Windows API and some change in the window style. It seemed to work OK, but this month I discovered by chance that when running on Windows Vista with Aero and transparency activated, the modeless windows appear without border at all! The problem seems to be the SetParent call but I have been unabled to fix it, so I have changed all modeless forms to toolwindows (the fix will be available next month). Curiously the only modeless form that I use in the version of MZ-Tools for VS.NET (a progress form for some operations) appears correctly with border using a similar hack. But the bottom line is that modeless forms should be avoided in add-ins: it is much better to use toolwindows.

CommandBarPopups with an image (not possible) and split dropdowns (not possible either).

Today I received in the e-mail a question about how to create a commandbar popup with an image in a Visual Studio add-in. The short answer is that commandbar popups can’t have images but I will ellaborate it here a bit more.

First, we need to define what a commandbar popup is. A commandbar popup is a special button (on a toolbar) or menu entry (on a menu) that when clicked, rather than performing an action like a regular button, it shows new buttons or menu entries. For that reason commandbar popups show an arrow to the right of its caption (>). Examples of commandbar popups in Visual Studio are:

  • The File, New menu item
  • The Tools, Macros menu item.
  • Etc.

None of those commandbar popups have (or can have) an image. You can create commandbar popups as explained in my articles:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in.

HOWTO: Add a popup command bar to the context menu of a code window of Visual Studio .NET.

Now, there are other kind of “popups” and “dropdowns” in Visual Studio:

  • The “dropdown combo”. For example, the Configuration Manager combobox in the Standard toolbar, which allows you to select the active configuration (“Debug”, “Release”). Although not very useful for most add-ins, the good news is that you can actually create them with an add-in as Craig Skibo (formerly in the MS VS extensibility team) explained long time ago here: Command Bar Types – Part 2
  • The “split dropdown” (I am not 100% sure about whether this is the correct name, but I think it is). This is a special button that appears on toolbars (not on menus) and has two (splitted) zones: a button with an image that when clicked performs some action, and an arrow than when clicked drops down new buttons. An example of this control is the New Project button on the Standard toolbar. If you click the button, you create a new project. If you click the arrow, it shows buttons to create a project, web site, team project, etc. Notice that the image of the button and its associated action reflects the last used button, so this is also a kind of MRU control which wouldn’t be desirable in some scenarios for add-ins (that is, it is not actually like a commandbar popup). AFAIK, you can’t create this kind of control using an add-in although apparently there was some intention from Microsoft to support it (see my comment in the Craig’s post).

Visual Studio 2010 PDC session: customizing and extending your developing environment

In my last post about the new Managed Extensibility Framework (MEF) I mentioned this PDC 2008 session about VS 2010 extensibility whose video is now available:

TL32 Microsoft Visual Studio: Customizing and Extending the Development Environment” by Tim Wagner

I have watched today the video and overall I have liked a lot what I have seen:

  • The IDE is moving slowly towards a managed .NET application (it will take several releases, but in this one the shell UI and the code editor is now .NET based using WPF).
  • There is a new Drop-In, Light-Up (DILU) deployment approach for extensions where you just drop a component in a special monitored folder so your extension just appears in the IDE. This is very cool.
  • 3rd party extensions can now contribute more easily to intellisense/auto completion/tooltips/smart tags stuff and can colorize (or any other WPF effect) the code.
  • There will be a new extensions manager to download extensions directly from the VS gallery, with auto-update / disable / uninstall capabilities.
  • Internally the extensions are built using the MEF approach.

All that said, it seems that the current CTP doesn’t offer any of that yet (at least mine). We will have to wait until Beta 1. Update: the current CTP offers some funcionality about the new editor (c:\Users\public\documents\CTPWalkthroughs\Visual Studio\Samples).

There are only a couple of things that scare me:

  • How well the internal changes in the IDE to handle all this new stuff are going to coexist with current technologies (add-ins, packages). I guess that there will be backwards compatibility, but, you know, changing internal things without breaking something is difficult. I mean, if you change the code editor technology (even if only the presentation layer, not the internal buffering stuff), there are add-ins and packages out there (not my case) that colorize, add smart tags, etc. The new code editor even allows you to use different font families and sizes for different parts of the code…
  • The other thing is the WPF stuff, or more precisely, when WPF designers rather than Windows developers start to create Windows applications (instead of, say, web sites where they can use their creativity to the max) because, simply put, I don’t think they know or care about Windows design guidelines. I am currenly learning Microsoft Expression Design 2, a WPF Windows application to create designs and it is a horrible Windows application:
    • It doesn’t honor the Windows look and feel (menu fonts, colors, etc). You can only choose between light or dark user interface. OK, Microsoft Office 2007 also started to violate Windows design principles using its own Segoe font rather than the Windows font (whatever the user has selected in the Control Panel), and many users have discovered in the forums that it is impossible to remove it.
    • It uses weird menu to change preferences: “Edit”, “Options” rather than the usual “Tools”, “Options” that every other Microsoft application uses. I guess there was some people influenced by Adobe applications which use “Edit”, “Preferences…”. I hope no people influenced by Apple starts switching the OK and Cancel buttons 😉
    • The toolbox is not the more user-friendly thing in the world. It uses multi-tool buttons and it changes their icons to the last used one. The toolbox of Visual Studio is much better (you can show all tools at the same time, with or without text)
    • The Layers panel doesn’t use a context menu to add or remove layers or other things, you have to use some weird artifact at the bottom of the panel to show a menu.
    • OK, this one is not arguable: the objects that you design in the canvas can’t be copied and pasted using a context menu! You have to use the ones under the “Edit” main menu. I can’t think about a Windows application that doesn’t offer a context menu to copy/paste selected objects…

So, while it is true that developers are not good designers, I think that it is also true that designers can’t create good applications (maybe web sites or video games, but not Windows applications).