Daniel Cazzulino's Blog

Note: this entry has moved.

 I started working on a sample app I want to build on top of CAB. I evaluated using RssBandit components to do the RSS parsing, NNTP reading and some other goodies it will have. Problem is that I don't like the GPL license at all, so first thing I did was to check RssBandit license as listed in SourceForge. It says it's BSD, cool. But looking at the dependencies the project has, I noticed it's using the #ZipLib, which is GPL-licensed and explicitly states that "Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.". Hence, RssBandit is also GPL, and I therefore cannot use any of its components in any project that is not GPL'ed.

Bottom-line: don't believe open source project admins that happily select any arbitrary licenses they like. *Always* check their dependencies, and the licenses of those, as it may be the case that the project is breaching some of them. This is IMO one of the reasons why leveraging OS projects is so risky and most companies don't do at all.

Update: ok, people complain that I didn't read the paragraphs following my quote. So I'll add my comments to it here. I did read them, but they hardly matter, if you're a conscious and careful developer. I do not want to get involved in hand-written exceptions invented by people that may or most probably may not have consulted a lawyer with expertise in OS licenses. The complex interation between a "core" or base license and its exceptions may very well turn out to be a breach of the original license altogether. Now, do I want to go over the fuss of figuring this out? Of course not. And the same goes for other companies that are scared at even looking at GPL'ed code. Specially if the exception to the license is expressed in terms as vague as "based on this library" or "under terms of your choice". Being a lawyer myself (although certainly not a practicing one), I can hardly believe that an exception that grants such a right (the later one) is not breaching the terms of the GPL. I certainly don't want to find out in court ;), and definitely I do not want to pay a good enough lawyer that I can trust for a forecast on the outcome of such an event.

Note: this entry has moved.

Probably you head about GAT, the Guidance Automation Toolkit. The reason p&p decided to create it was that packaging the guidance they ship (app. blocks, books, etc.) in a more interactive form, directly in VS was simply too costly. Creating and maintaining add-ins or VSIP packages is not only costly but also requires quite deep knowledge of VS intricacies. They needed a better way of doing VS integration. And GAT was born.

I had developed add-ins in the past, and I knew exactly the things that I hated (and you probably also do). As part of my job in realizing GAT, I wanted it to be very simple and straightforward for what we call guidance package authors. So, besides Wojtek designing a very simple conceptual model, I strove to make the programming model as easy as possible. You can judge the results for yourself, after going through the LAB that we created for TechEd.

Speaking of TechEd, here's Wojtek and myself getting ready for the presentation:

And here are we giving the actual presentation to a fairly big audience who asked very interesting questions and seemed to liked what we showed. GAT is a very cool technology that will play an increasingly important role under the Software Factory initiative.

Now, without getting into the buzzword-marketing stuff, what's GAT, after all? If you were evaluating writing an Add-in to automate some of the developer tasks that you repeatedly do in your company, what features in GAT would make you choose it instead? From my point of view, here are the main points that I consider critical in the decision:

1. Automatic generation of wizard UI on top of a robust Wizard Framework: creating a wizard "by hand", ensuring that the appropriate validation is performed, that no required fields are left incomplete before the next/finish button is enabled, building richer field-editing experiences, etc., is a tough job that almost everybody hates. And if you have an automatic wizard generation process, most people almost inmediately assume that it will look terrible or will not be suitable for complex scenarios. Guess what, GAT not only provides automatic wizard generation from an XML configuration file, but it also looks great, enables extensions that can make your wizards very user friendly, but at the same time encourages the development of reusable UI components/logic in the form of .NET TypeConverters and UITypeEditors. This means that over time, your wizards will look better and better, and they will be increasingly easier to build, as you create an increasingly big library of reusable components.
   Also, the wizard generation uses a brand-new wizard framework developed entirely from scratch for Whidbey, that is the core component that will unify all the wizard needs across teams in Microsoft developing VS integration packages. What this means to you is that you can rest assured that your packages will always be aligned with the best practices with regards to wizard UI layout and style, but also that it's a very robust and tested component that will take care of the complexities inherent to wizard UIs. And all that without taking away the ultimate flexibility point that allows you to simply develop a user control to use on a wizard page that is too complex to fit in the automatic UI generation features.
   
   
2. Abstraction from VS complexities: you will never again need to worry about QueryStatus, loading logic, command creation, etc. GAT takes care of all that for you. You just tell it where you want things to appear, and when. That's it. It will take care of hiding commands when they are not relevant, it will add tasks to the Task List, remove them when necessary, etc. Your core development task as the guidance package author is to create Actions that will be executed when the data (or argument) gathering phase is done (the Wizard). Just like the UI components mentioned above, GAT encourages a development style where actions (very simple classes with input/output properties and Execute/Undo methods) are small and reusable, and are chained to perform more complex tasks. These will also develop into libraries that you will start reusing more and more, further reducing the cost of creating integrated guidance in VS. Here at p&p we're already doing that, and the results are amazing.
   
   
3. Integration with VS or code templates the "right" way: one way of significatly increasing developer productivity is by providing templates or starting points for different development tasks, such as starting a new "my-company-standard-project-type", creating a new "business-entity" class, and so on. But with VS templates alone, you have several limitations:
   
   • Control over availability depending on context: you cannot control where the templates can be used. If your company uses the "Data Access Component" template for your data layer, you don't want your devs using that template on the WinForms/UI project.
   • Collection of argument for use by template: by default, you can only collect the item/project name from the user, via the Add New dialog. This is clearly insufficient for all but the most trivial cases (where a code snippet would perform almost as well, if not better). Consider a project that needs a database connection string, a project name, default namespace, and so on.
     
   • Creation of more complex code templates with dynamic code generation: VS templates only allow for very simple code templates that simply perform parameter replacement on the data passed by the Add New dialog. Even if you solved the problem and could get to pass more arguments/parameters to the template unfolding process, you still have just that, replacement of tokens in the files' content with the values of the arguments (such as public class $safeitemname$). But what happens when you need to generate more complex code depending on the values of the arguments, iterate them to generate repeated sections (i.e. one field for each received value in a list of database table columns)?

   GAT solves these problems with the following features:

   • Automatic filtering of templates according to the context. Templates will only appear where you say they apply to.
   • Integration of argument gathering (wizard) with the Templates, so that selecting a template can result in a full-blown wizard coming up and guiding the user though several steps to complete the "setup" for the template to unfold. But this integration goes further than just collecting arguments, it's a close integration that also allows execution of the full set of actions that your so-called Recipes defines. So unfolding a template can result in much more than just a bunch of files being copied from some place into your application. All kinds of complex things can also happen, only limited by your requirements and imagination (i.e. registering the project with a central SCC repository like Team System, start tracking of working time with a project management server, setup of test and staging server environments for the project, etc.). The full power of .NET is at your hands and you can do pretty much whatever you need at this point.
   • Dynamic templates through the Text Templating Tranformations Toolkit (T4), an engine designed along the lines of templating engines like NVelocity, CodeSmith or the defunct GenX, to aid in generating code (or other text-based outputs such as XML, HTML, SQL scripts, etc.)  from text templates that make use of the input arguments collected form the user or the environment (through so-called Value Providers).

Right now these are the ones that I consider the more important reasons to move to GAT. There are a lot of other features that I love, and probably as you get used to the above, you will find that some others turn out to be even better arguments for moving forward. But for now, I think you can get an idea of what you could have and you're probably missing ;)

Note: this entry has moved.

Longhorn in spanish, is "cuerno largo", which is what someone qualified as a "cornudo" has. "cornudo" is the guy cheated by his wife/girlfriend. I wonder if this was one of the reasons behind the recent renaming :).

Consolas in spanish is as close as it gets to the "masturbate" verb inflection (specially for women, where there's even the "consolador" device - a.k.a. dildo). Although according to some that would pretty much describe the sensation of using it, I doubt that was the idea behind the name :o)

I wish Peter didn't push me to write this post, hehe...

Note: this entry has moved.

Altova announced a royaltee-free distribution of AltovaXML engine complete with .NET interfaces. It supports XQuery 1.0 and XSLT 2.0 (with or without schema support). Excelent news for .NET developers!!!

Via TSS (thanks Paul!)

Note: this entry has moved.

We're having our first lab on CAB, with people from all over the country (US). It went incredible well. People seem to find CAB very useful and intuitive so far, and they certainly think we're solving a lot of the recurring problems they find when building rich smart client applications. We got lots of good feedback. Very engaging overall.
We got a very cool lab room at building 20 that contained a huge proyector screen and 93 seats with fancy LCDs with movable arms. Impressive.

There was also an entire fridge full of Haagen-Dazs ice cream, which is always a plus ;)

Note: this entry has moved.

Generating classes from XSDs, and being able to customize the process has been a favorite topic of mine for a while. Now there's a Guidance Package that Matias wrote for that very purpose, using the approach I proposed in my MSDN article. Read about the tool in his blog entry.

Note: this entry has moved.

A couple weeks ago, as we approached an important milestone for CAB, we had a session where we analyzed the job we did, not only technically but in every aspect. This introspection about how we work and interact as a team led to an interesting set of post-its on the wall:

After we grouped the notes according to the area (from technology/infrastructure to process/doc) and split the possitive and negative ones, we discussed them in turn. (tip: the picture is pretty high quality, so if you zoom enough, you may be able to read some ;)). It was very possitive to be able to express what we think about the project, the team and the environment. It made us think about it, reflect and find points for improvement. Edjez couldn't avoid going to the whiteboard, of course:

Process-wise, this is a very good practice that we'll surely be applying at ClariuS.

Note: this entry has moved.

For quite some time now, I've been lucky enough to be involved in various projects from Microsoft patterns & practices. I've already posted about the previous war room we had and also mentioned that we were improving it. Here's a picture of the setup process:



Finally, some pictures of the  CompositeUI application block team, and a couple EntLib guys too:





This time I didn't have time to add the bubbles showing the names of each, but I will, eventually :o)

Note: this entry has moved.

In the good old days of Everett (VS 2003), all project kinds, either web, win, class library, etc, shared the same command bar. You could put a command in all of them at once just by adding to that one. Nowadays, web projects (Venus) no longer use the C#/VB project systems. Hence, your commands in projects that were supposed to appear on web projects too, will certainly dissapear.

In GAT, you specify the command bar you want a command to appear, as follows:

<CommandBar Name="Project" />

The supported named command bars are just a subset, and nothing more than a facility to the guidance package author. In reallity, they are just shorcuts for the real GUIDs and IDs of the package and command bar respectively. And you can pass those two values instead of a name. For web projects, you specifically use:

 <CommandBar ID="1136" Guid="d309f791-903f-11d0-9efc-00a0c911004f"/>

That will make a recipe appear in the context menu of a web project.

Note: this entry has moved.

Peter is much more elocuent than me, so I'll let you read his post with the announcement. CAB is a very important step forward for developing rich client applications with good architectural design. Don't miss it if you're doing/planning to do any further WinForms development.