Daniel Cazzulino's Blog

Of course you already knew that the PDC 2005 sessions are available online, right? (although not for much longer, I heard). But you just don't have the time to browse the list to find the interesting ones and download them one by one... Well, now you can point your favorite site copier software to the starting point Full PDC05 Sessions (grouped by DVD ;)), and download the full set. Note that the links point to the zipped presentations only.

This is the magic of XML :)... you just need a list of sessions they expose, plus a rather simple XSLT transformation (except for the muenchian grouping ;)), and off you go!

Enjoy... I suspect when they get huge download numbers for all sessions, this will end pretty soon ;)

These are roughly the things that you need to change in your current package:

1. Search replace "50505" with "51206" in the entire solution. This is the changed assembly version number that appears in all your .vstemplates.
2. Delete all references from all projects to Microsoft.Practices.* and re-add them pointing to the new version of the binaries.
3. Search replace "igt" with "gax" (for XML and .vstemplate files)
4. All T3 templates need to be updated to the T4 syntax shared with the DSL tools
5. Search & replace: Microsoft.Practices.RecipeFramework.Library.Actions.T3Action, Microsoft.Practices.RecipeFramework.Library with Microsoft.Practices.RecipeFramework.VisualStudio.Library.Templates.TextTemplateAction, Microsoft.Practices.RecipeFramework.VisualStudio.Library
6. DteHelper class now lives in the Microsoft.Practices.RecipeFramework.Library namespace and assembly.
7. In .vstemplate files, you could previously specify initial state for your recipes with the following syntax:

    <TemplateReference Name="Projects\ServiceAgent\ServiceAgent.vstemplate" Target="\ServiceAgents">
      <XmlSerializableHashtable xmlns="http://schemas.microsoft.com/pag/igt-xmlhashtable" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">
       <Entries>
        <Entry>
         <Key xsi:type="xs:string">Key1</Key>
         <Value xsi:type="xs:string">Value1</Value>
        </Entry>
       </Entries>
      </XmlSerializableHashtable>
     </InitialState>-->
    </TemplateReference>

    <TemplateReference Name="Items\SerializableClass.vstemplate" Target="/" >
     <InitialState xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <Entry>
       <Key>SerializableField</Key>
       <Value>Name</Value>
      </Entry>
     </InitialState>
    </TemplateReference> 

I think that's all, but let me know if you find anything that's missing or not working!

 Note: this entry has moved.

The Guidance Automation Extensions (GAX) and Toolkit (GAT) have been updated for Visual Studio 2005 RTM. As Tom describes it:

At long last, the Guidance Automation Toolkit (GAT) and Guidance Automation Extensions (GAX) have been updated for the final version of Visual Studio 2005. For those that came in late, GAT allows developers and architects to integrate guidance deliverables such as blocks, frameworks and patterns into the Visual Studio environment, using mechanisms such as templates, wizards and code generation. GAT is targeted at people authoring these "guidance packages", while GAX is the runtime component required by anyone consuming guidance packages. You'll be seeing quite a few p&p deliverables built using GAT (and hence requiring GAX) over the next year, so this would be a great time to get up to speed on this exciting technology.

Just as a quick list of things that GAX/GAT enables you to do, *very* easily:

1. Create reusable actions that automate VS using either the DTE or the VSIP interfaces.
2. Create rich argument collection strategies for use in wizards using .NET standard TypeConverter and UITypeEditor base classes. This also means that you get the built-in ones supported in your wizards for free!!
3. Create automatic argument calculation strategies, that can determine (default) argument values from the environment (such as the opened solution, currently selected project properties, VS state, etc.)
4. Declaratively design wizards using XML, by specifying the arguments that need to be collected, their .NET type and converters/editors to use to assist the user and validate the input, and even custom pages (a special kind of user control) for advanced input scenarios!
5. Group the arguments used by the actions, the automatic argument collection strategies, the wizard to manually them from the user, and the set of actions to perform on the environment in so-called recipes.
6. Easily associate recipes to item, project or solution templates, so that additional arguments can be collected for the VS template expansion and parameter replacement, as well as to execute actions after the unfold operation finishes.
7. Easily expose those recipes as commands in main or context menus. Assign icons to them simply by pointing to an image file! (no more unmanaged VC++ resources for icons or those ugly .CTC files defining commands in VSIP!!!)
8. Create code generation templates using a text templating language code-named T4 that is shared with the DSL Tools (similar in spirit to classic ASP, CodeSmith, NVelocity, etc.)
9. Easily contextualize the recipes and templates so that they appear only for:
   • A particular element in the solution (i.e. a specific project, item, solution folder, etc.)
   • Elements that satisfy a given condition, coded easily in any .NET language (i.e. all XML files, XML files whose root element belongs to a given namespace, all C# projects that are class libraries and have a reference to Indigo, etc.) 
10. Easily create and package code snippets with your guidance
11. Automatically create an MSI setup file to include all the above!

If the above list grabbed your interest, go and download GAX and GAT and start playing with it! Don't forget to ask your questions either on the MSDN forum or the GuidanceAutomation.net community site.

Read the following entry on how to upgrade from Beta2-based GAT packages and the new version.

It turns out that according to some algorithm that someone posted, I'm number 15 in weblogs.asp.net according to my blog's worth :o). Very cool. I will try to keep posting useful information here...

Thank you for reading me ;-)

About a year ago (feb-22-2005) I reported a bug in the implementation of most built-in TypeConverters, which is that even if the value you pass to IsValid is invalid for the target type, it will return true. To better understand the issue (which is fairly trivial anyway), say you have code like the following that performs validation on a property value before setting it:

object theObject;        // Received somehow
object theValue;         // Received somehow
PropertyInfo property;   // Get the property info using reflection for the property we're about to set.

TypeConverter converter = TypeDescriptor.GetConverter(property.PropertyType);
if (!converter.IsValid(theValue))
{
    throw new ArgumentException();
}
else
{
    property.SetValue(theObject, theValue, null);
}

Now, because of the bug I mentioned, the if will never enter as the built-in converters will always report a valid value even if you pass an "asdf" for an integer property, for example. So, obviously my code has a bug that I still didn't realize (assuming I didn't do any TDD, of course, as otherwise I'd already know there's no way that code would work as expected).

Someone on the .NET team decided that it was going to be a breaking change to fix it. In their words, two months after I reported the bug, they said:

"Since TypeConverters are used so widely, changing the Int32Converter (and the other TypeConverters mentioned) to override IsValid will likely break applications, ..."

Now, how can an application be broken if a piece of functionality is not usable because it never behaves as expected? Clearly the application is already broken (if it uses code like the one I showed above) and probably the developers didn't realize yet.

After I reopened the bug so that it gets considered for post-Whidbey, I got the following answer:

"We do not have the luxury of making that risky assumption that people will not be affected by the potential change."

And closed as won't fix. I think this is a clear case where the back-compat issue is taken too far and clearly hinders the usability and quality of the platform.

If you agree, go vote the bug. The .NET platform CAN be better.