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.
After lots and lots of hard work I'm very proud to announce that my team shipped v1.0 of the Clarius T4 Editor today.
We've been insanely struggling to get the bits finished during the last few months; you know, extending Visual Studio for simple stuff is far from trivial let alone extending it in some crazy ways like reusing the existing C# infrastructure. Nothing but lots of "fun"...
I've received lots of pings from people asking how the editor will be available, so this is the story:
We're offering a Community edition, featuring basic T4 IntelliSense and syntax coloring, for free as in beer. And we're offering a paid Professional edition too, including a few more extra features plus our King feature which is support for embedded C# code blocks. If you're interested into finding how these two editions compare you can find a summary here.
They say a picture is worth a thousand words so I'm trying to save some typing by using this picture:
Now imagine how much your productivity will improve and what are you going to do with all the time you will save thanks to using the T4 Editor. :)
If you are into extending the best IDE ever you already know that is not an easy task.
You will find challenges all day (some days just too many of them...) and you may spend an entire day (or a couple of them...) trying to accomplish even the most trivial things. Don't feel frustrated, you're not alone.
The good news is there is a dedicated team trying to change this and they've put up a 2-day conference filled with exclusive content on extending VS.
The admission price is an incredible low $100 so you really need a good excuse to not register.
At least four guys from Clarius (including me) will be attending it. If you're planning to do so too drop me a note so we can share our "extending VS" experiences, the good ones and the bad ones.
There are some very clear examples out there about what I mean when I talk about VS