While developing the Visual T4 Code Generator edition my team and I are constantly having discussions on how the best code generation tool in earth should look like and also about more abstract code generation chores not necessarily related to the product were developing.

So it occurred to me (yes, Im that clever) that we should take our internal document drafts from our internal wiki and put all this stuff into a blog (of course we will remove the bad language first) to make our plans more public and gather community feedback while were at it.

In this new blog you will find posts by Adrian, Joaquin, Jose and me (and if I get lucky I may get other Clarius people to blog too)

Please subscribe and let us know what do you think, thanks!

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 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.

After a few weeks of lots of hard work we were finally able to release a pretty stable release of our T4 Editor out to the community at http://www.t4editor.net.

It currently support VS 2005 and VS 2008 beta 2 and has most (but not all yet) of the bells and whistles you would expect from a nice and integrated editor in Visual Studio (meaning IntelliSense, syntax coloring, region collapsing, etc).

If you're into anything like DSL, GAX or Software Factories then this is a must have for you.

And if you're using any of the code generation tools out there and you've haven't heard of T4 yet, then it's probably time you give it a look...

You can go directly to the download page and give it a try, I would love to hear your feedback if you do so!

Talking about obscure...

Take a quick look at the documentation for IVsTextManager.RegisterViewmethod.

The main description for the method reads: "Method information is not provided."

Ok... there isn't much I can guessabout the method from that solet'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.

If you're into extending Visual Studio then there are good news for you.

Grigori Melnik, Product Manager for GAX/GAT from Microsoft p&p, has announced there will be a compatible version that runs on Orcas pretty soon.

The announcement at TechEd 07 seems to have been received well by the blogsphere. For example Pablo is saying WOW... finally extending Visual Studio will be much easier.

Ive to admit, I dont find this near that exciting, sorry.

We have had Visual Studio PPE edition before. And we already had an idea of what can be done with the shell; basically if youve installed Team Explorer in a box without Visual Studio on it youve already experience the shell.

So, Victor, whats really new here? Thanks for asking!

In my opinion the most important thing to notice is that they have now removed the expensive part; it is nothing but great news to find out that you will be able to distribute royalty-free the shell with your custom extension.

But the obscure it still there. There is nothing new regarding helping you writing these extensions in order for you to have something at all that you could ship royalty free at the end of the day.

So, how many people will actually take immediate advantage of this? Those who are *already* experienced enough to write their own extensions and couldnt afford a non-royalty free license before. Take a pen and a very small piece of paper and that should be enough to write down all their names.

Overall, Im happy as this is still a good move, but there is much more work to be done (which can be read too as: Im not happy as I could be)

I would really kill to see news in the direction of putting some light into the obscure.

What is the hardcore way of extending Visual Studio: VSIP.

And what are the first things that come to mind when you think of VSIP: expensive and obscure. Expensive because it used to be 10k/year and obscure because its COM roots and its very poor (close to inexistent) documentation.

You tell me how do you build a huge community around expensive and obscure? You just simple cant. I believe the past years were more than enough to prove this.

So, someone at Microsoft realized about this fact and VSX was created. A new name is always a good thing; better yet if it is a TLA and begins or ends with X, you can hardly beat that J

What VSX is about (besides the cool name)? The official word wont tell much but this is what Im noticing: new useful samples in the VSSDK using managed code and improved documentation (or at least, part of it). The samples source code is still a good place where to find code comments that will give you much more information than what the docs will tell you.

Can you build a community around VSX? Although this is surely an improvement over expensive and obscure, IMO, this is still not enough.

Why?

Because all of the obscure its still there. Because you still need to mess with COM interfaces all the time and the versioning craziness like IVsComponentEnumeratorFactory3 and native structures and enumerations that were coded when naming like __VSMEPROPID2. VSMEPROPID_LAST2 made any sense. Let alone the VBisms you can find in todays DTE automation layer (like indexes starting at 1 instead of 0, etc). Also, I dont want 45 different and incompatible ways of doing the same thing.

It is 2007 now. I want a nice and clean OO framework that I could proudly look at without my eyes being hurt and that I can confidently build upon it.

Enough criticism now and lets add some constructiveness to this post.

What needs to be done?

1)

Home