Visual Studio
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.
There are some very clear examples out there about what I mean when I talk about VS obscurity being a major pain for getting people extending the platform and trying to make my dream come true.
As a rule of thumb people should know that if demostrating incredibly basics things takes you more than a few words and a trivial code snippet then most probably something is wrong.
There is a post by Dr. Ex on how to detect when a toolwindow is closing, it's 52 paragraph and 509 words in length, pretty lengthly, ugh?
What this should have been instead?
mytoolwindow.Hide += new EventHander(hide_handler);
There is another post from Sara Ford that touches how to insert some text in the editor, it's 20 paragraphs and 300 words in length. If you have the estomatch to go throught it you will notice all sort of crazy stuff like you having to do your own memory managament (flashback to 1978!):
IntPtr pText = Marshal.StringToCoTaskMemAuto(text);
try
{
textLines.ReplaceLines(0, 0, endLine, endCol, pText, len, null);
}
finally
{
Marshal.FreeCoTaskMem(pText);
}
What this should have been instead?
myeditor.Text = "foo";
Luckily enough both, Dr. Ex and Sara, write their posts with a salt of humor which I don't think it's a coincidence but a technique for trying to eliminate the idea of suicide from their weblog readers while they're reading.
I'm fine with their approach as long as they understand that there isn't really anything funny about it and that this really, really, really begs for a change sooner than later.
I remember the time (3 years ago) when I was dogfooding latest ASP.Net bits and entering bugs like hell. I was also publicly posting most of my findings about what I did and didn't like and I always got nothing but a very good reaction from the ASP.Net team which was always open to feedback.
Now I'm spending most of my time inside Visual Studio so they are the target of my daily grins.
Ken Levy, PM on the VSX team, points from the official VSX weblog to my entry about VS being obscure.
While it doesn't mean they agree with me nor they will make the changes I am crying for, it doesn mean for one thing that they're listening. And that is always good thing.
Talking about obscure...
Take a quick look at the documentation for IVsTextManager.RegisterView method.
The main description for the method reads: "Method information is not provided."
Ok... there isn't much I can guess about the method from that so let's see what the arguments this method takes are about in order to help the guessing game. Its signature is:
int RegisterView (
[InAttribute] IVsTextView pView,
[InAttribute] IVsTextBuffer pBuffer
)
What are pView and pBuffer about? Let's check that doco again:
Parameters
pView
Do not use.
pBuffer
Do not use.
Does "do not use" really means "I've no idea what should go here"? Or is it more like "this is used internally by VS and maybe we should have said that at the method description where we originally said 'method information is not provided'"?
At this point you may be lead to believe whoever put this page online just doesn't care about your time. I mean, you took the time to search for this method, you were directed to MSDN, you open and read the help and you get zero information at all. I don't think this is the case. I'm guessing there is some automated tool that produces a million pages based on XML comments or something similar and that's the reason why some non-sense pages like this one end up online.
Based on this I can think of a way to automatically improve VSX developer's productivity out there: JUST remove pages like this one. You can save me a minute or two by doing so.
