October 2008 - Posts

Extending the Visual Studio 2010 Editor: not exactly a good first impression

I know this is the Visual Studio 2010 *CTP* meaning it's a very early release but still I feel quite a bit disappointed about the experience for developing extensions for the new editor.

While other features of Visual Studio 2010 are not mentioned nor supported at all in this CTP, the editor includes several walkthroughs on how to extend it and as I've found here, there is a custom VS SDK build custom made to support editor extensions scenarios. Also, the editor has its own forum for feedback.

With all this you would believe that there is a lot of interest from MS on gathering feedback and letting people trying out the new editor bits. And I do believe they sincerely meant this, but... the current experience is really UGLY.

The current CTP suffers from two major issues: 1) if you copy an extension while VS is running, VS will crash and 2) there is no such a thing as an "Experimental Hive" for the "Components" folder (this is where you copy extensions) meaning all files in there will get loaded up and thus locked by VS, so everytime you need to copy a new version (which is basically everytime you compile) you need to shutdown VS, overwrite the files and restart VS.

This is how the current development workflow for writing extensions looks like:

1) Write code, compile code
2) Shutdown VS
3) Copy DLLs to "Components" folder
4) Restart VS, try out the extension
5) Shutdown VS
6) Delete DLLs from "Components" folder
7) Change 1 line of code? Go back to 1) and repeat all over again...

As you can notice the above includes shutting down VS twice in order to try out even the very smallest changes...

Writing VS extensions (in VS 2008 and earlier) is already very-very hard so what one would expect in VS 2010 is nothing but stuff that simplifies this, and I'm betting the new managed editor APIs will help in this regard, so it's a real pity this "restart-VS-twice-for-every-compilation" wasn't fixed before the CTP went out...

I'm wishing this gets fixed in the next drop that is made available.

My Favorite Error Message from Visual Studio 2010 CTP

I swear I wasn't doing anything against the law when I got this nice error dialog:



Looks like the pBuffer variable is important enough inside VS as to get its own dialog! :-)

Entity Framework to adopt T4 for code generation in v2

Yesterday the Entity Framework team announced at PDC08 that they will based all their code generation on the Microsoft built-in T4 technology. This is great news as it will allow deeply customization of the generated code.

If you're new to T4 you should read Scott Hanselman's post on T4 as your starting point on what resources are out there.

And of course, if you're authoring T4 templates, you can't miss the Clarius T4 Editor!.

The New Visual Studio 2010 Code Editor

As you may have already heard Visual Studio 2010 will include a *new* code editor completely *rewritten* in fully managed code and based on *WPF*. Yaay!. Very, very promising stuff.

I just fired up the bits I received at the PDC08 and went Help->About Box, and looks like they haven't put much cycles into it yet -which is expected for a CTP release- and it's funny how are the calling it right now... "Text" (very humble!) with a somehow confusing description of "WPF Editor" and an ugly stock icon stolen from someplace.


I'll be playing with the new editor and extending Visual Studio 2010 for the next couple of days so stay tuned if you are into extensibility or just want to know about the latest news of Visual Studio 2010!

Wishing for dev10: Get rid of PLK, SLK, DLK and anything ?LK

Today one very annoying thing you've to do when you want to deploy your Visual Studio Package extension is to get a PLK or "Package Load Key" from Microsoft.

This is a painful process which can be divided into two equally painful parts:

Pain #1: Get yourself a PLK

For this you have to use a MS Website which used to be really bad at doing its job. For example, data you entered for your key was not available for reviewing later on and sometimes you never received the email with the requested key... we're talking very basic stuff, which was just not working properly.

The good news is they replaced the old website (delete C:\QuickAndDirtyWebAppCodedInFiveMinutes\*.*) with this single page which besides being much more friendlier than the original website it also... works!!

Pain #2: Debug your PLK

So after struggling (if you had to use the old website) to get yourself a PLK you still were left with the job of debugging it. Which wouldn't be that bad if it wasn't because the really poor support offered by Visual Studio logging then attempting to load your packages which basically was reduced to:

"Hey, I cannot load your package, sorry!".

A package load failure could be caused for a variety of reasons which Visual Studio can currently detect but just logs them in an unfortunately generic way. This requires of some obscure PLK troubleshooting time (some of it very hard to guess as "Is the crypto service running?") that translates to wasted hours.

And to add more to an already unfriendly process Visual Studio 2008 has three different kinds of Load Keys:

1) Package Load Key (PLK) to deploy your VS packages to end users
2) Developer Load Key (DLK) installed by the VS SDK so you can develop and run packages without a proper PLK in place
3) Shell Load Key (SLK) to deploy your VS-Shell based applications

My whishes for dev10 (or "Visual Studio 2010" if you like longer names) are the following:

1) Please don't invent a 4th ?LK to add to the previous three, there are more than enough already!
2) Please just kill the existing three key types and remove extensibility developers the need to go through this pain at all.

More Posts