CodeGen

Visualizing SOA’s Return on Investment

EltonStoneman — Thu, 26 Mar 2009 18:36:18 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

This is the rather grand title of a WebCast I've recorded recently which tries to illustrate where the return on investment comes after moving to a SOA strategy. The video is on Digital Forum: Visualizing SOA ROI , and the Open Source proof of concept it references is on CodePlex: ESBSimpleSamples.

In the WebCast I start with a blank Visual Studio solution and create a new Web app which consumes an existing service. All in it takes 3 lines of code and around 3 minutes of development (most of it spent correcting typos), and it doesn't require me to have any understanding of the underlying SOA infrastructure – in this case, Microsoft's ESB Guidance package sitting on BizTalk Server 2006 R2. Equally important, assuming the service we consume is in production, the testing and deployment effort needed for the new project is minimal.

This is a rework of a presentation I did with a client where I wanted to show how quick and easy it is to use their SOA implementation. I had reservations of showing a code demonstration to an audience which included IT heads (IT Director and Solution Architects) and project management, but it was surprisingly well received, so I've reproduced it using services and components which are publicly available.

Direct links to the references in the WebCast are here:

ESB Guidance: http://www.codeplex.com/esb
UK SOA/BPM User Group presentation: http://sbug.org.uk/media/p/129.aspx
Blog posts on ESB Guidance: http://geekswithblogs.net/EltonStoneman/category/7947.aspx

Sixeyed.Guidance.CodeGeneration: Technical Walkthrough

EltonStoneman — Mon, 09 Mar 2009 23:05:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The Code Generation Guidance Package on CodePlex was designed to be extensible and reusable. There are three main C# projects, which isolate logic for code generation, and the UI and GAX components.

Sixeyed.CodeGeneration

This is the core project, defining how metadata is represented and retrieved, and defining configuration for code generation runs. Metadata is defined in terms of:

A metadata source, which contains the logic for connecting to the source
A metadata provider, which uses the source to provide a list of available items, and to populate requested items
Metadata items, which are a representation of the metadata, typically using an appropriate .NET framework class

Code generation and UI logic always works on the interfaces which define these components, and the relationships between them:

In the Add Generated Items recipe, the available source types, sources and providers are populated from the collection of IMetadataSource objects held in the static SourceContainer class (additional sources can be added to the container at runtime using the SourceAssemblyConfiguration recipe argument – described in Sixeyed.Guidance.CodeGeneration Sample Package). When a provider is selected, GetItemNames is called to populate the list of available metadata items. When the selected items are iterated over in a code generation run, GetItem is called and the populated IMetadataItem is loaded as a property for the T4 template. The metadata item exposes the provider, and the provider exposes the source so the template can connect directly to the metadata if it needs to.

Each metadata interface has an abstract base class which implements it and contains core logic. For a given source, there may be an additional base class which abstracts logic common to that type of source. In Sixeyed.CodeGeneration.Metadata.Database.Source, DatabaseSource contains logic for accessing ADO.NET data sources in terms of IDbConnection and IDbCommand objects; SqlServerSource contains overriding logic to specify SqlConnection and SqlCommand usage – any additional database sources would do the same. Similarly for the SOAP metadata source, the logic for accessing WSDL is abstracted into a base class which may be used by other sources (e.g. a WCF specific source):

IMetadataProvider contains logic for accessing the source and retrieving a list of available items, and for populating a named item. The majority of logic is in the generic base class, so provider classes are quite simple. Simpler still are metadata item classes, which inherit the generic ItemBase class, specifying the underlying type of the item (XmlSchema in this case), without requiring any additional code.

Logic for populating template properties and executing T4 templates is located in the Guidance project rather than the code generation project, as it is dependent on the specific T4 engine being used.

Sixeyed.CodeGeneration.UI

The UI project contains generic user controls which represent metadata selections, and expose various events to notify of selection changes. The Guidance package Wizard uses these components rather than defining its own UI – the controls from this assembly allow code generation to be configured and invoked from a different UI host.

Sixeyed.Guidance.CodeGeneration

This project defines the GAX package and links together the code generation and UI components. The Guidance package is quite straightforward – it contains a single class AddGeneratedItems for the action of generating items from metadata and adding them to the selected project. The action expects SourceConfiguration, SelectedItems and TemplateConfiguration arguments; it connects to the source, iterates over the selected items and executes the template for each item.

To collect the argument values, there are custom wizard pages and value providers for each, allowing a recipe to provide ready-configured settings, or build a UI to gather them from the user:

Sixeyed.Guidance.CodeGeneration.CustomWizardPages. The custom Wizard pages use the static Metadata class to share state for the configured metadata source and provider. They override IsDataValid to determine if the page has collected enough information for the Wizard to proceed and the base class provides EnableNextStep which will advance the Wizard by enabling the Next or Finish button as appropriate. The base class will read the SourceAssemblyConfiguration recipe argument if provided, and use it to add any extra metadata assemblies at runtime.
Sixeyed.Guidance.CodeGeneration.ValueProviders. The value provider classes are straightforward, reading optional arguments from the recipe and populating the relevant metadata settings. Custom recipes can specify value providers to load settings instead of Wizard pages, so the Wizard UI can be restricted.

TODOs

There are a couple of minor changes I'd like to make to the current codebase:

Sixeyed.Guidance.CodeGeneration.CustomWizardPages.SelectTemplate defines its own UI, which should be moved to a user control in the UI project;
Sixeyed.CodeGeneration.Generation.MemberName contains methods for providing valid field and property names, but the Pascal and camel-case conversion is very basic;
Sixeyed.CodeGeneration.UI.SourceUri has some ugly hard-coding to decide which UI dialog it should show for different types of URI. It should be configurable, but I'm not happy moving it to an attribute of IMetadataSource, as that brings the UI into the core project.

And some additional metadata sources which I'll add at a future point – a Clipboard source providing access to clipboard data through text or XML providers, and a BizTalk source which will use the ExplorerOM for providers supplying application, group and instance information as metadata.

Sixeyed.Guidance.CodeGeneration Sample Package

EltonStoneman — Sun, 08 Mar 2009 22:46:00 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The basic Code Generation Guidance Package on CodePlex comes with an additional sample Guidance package. This sample is intended to demonstrate how the functionality of the base package can be customised to create a project-specific Guidance package, where you can easily add tailored code generation recipes to your package. In the basic package are the Wizard steps necessary to configure ad-hoc code generation, but there are also ValueProviders which can read configuration from recipes without requiring the whole user interface.

Installation

You'll need to modify the hard-coded paths and URIs in the sample package, so it doesn't come with an installed release. If you open the Sixeyed.Guidance.CodeGenerationSample solution you'll see that it references the base Sixeyed.Guidance.CodeGeneration and Sixeyed.CodeGeneration assemblies. The sample contains a set of T4 templates in the \Templates\Text directory, the XML configuration for the package and the XML includes for individual recipes. There's no additional code in the sample project, all the required functionality is in the referenced base package.

Together with the GAX project, there's a database project which you can use to create a SQL Server database suitable for the data-bound recipes to run against. To install, run the CreateDatabase script and then execute the SSIS package to populate data from the included Excel workbook (this is only necessary if you want to run the recipes as-is, otherwise you can modify the XML to use your own database).

Sample T4 Templates

There are T4 templates for each of the metadata providers in the base package. The scripts named _Simple.tt are straightforward and begin with the name of the expected provider; to run them, you can use Add Generated Items from the base package, select the relevant metadata and point to the template. To demonstrate more useful code generation, there are two more substantial templates:

ConfigurationSection.cs.tt – use the File source and the Text provider on this template. If you select Configuration.txt (from the database project) as the source, the recipe will generate a typed configuration class, which has a static property to access the current config settings. The template can be easily extended to add a Default value for optional settings, and the same text file can be used to drive a different T4 template to generate the actual configuration settings;
StoredProcedure.cs.tt – use the SQL Server database source and the Stored Procedure provider. Select a procedure and the recipe will generate a DAL class to execute the stored procedure. This class won't compile, as it inherits from a base class which isn't provided, but it demonstrates one approach for DAL generation.

Sample Recipes

The included recipes demonstrate configuring one or more settings for code generation so that the Wizard can be tailored or avoided altogether. Generate Stored Procedure shows this best, configuring the metadata provider using the SourceConfigurationValueProvider:

<ValueProvider Type="SourceConfigurationValueProvider"

SourceTypeName="Database"

SourceName="SqlServer Database"

SourceUri="Data Source=x\y;Integrated Security=True;Initial Catalog=Scratchpad;"

ProviderName="Stored Procedure Provider">

</ValueProvider>

</Argument>

These settings are the equivalent of the first Wizard page, selecting the metadata source. It specifies the source type and source name, the URI for the source (in this case, the Scratchpad database included with the sample), and the metadata provider name. Having the SourceConfiguration argument pre-populated means the first Wizard page will be skipped. The recipe also specifies the T4 template to use with the TemplateConfigurationValueProvider:

<ValueProvider Type="TemplateConfigurationValueProvider"

TemplatePath="x:\y\z\Templates\Text\StoredProcedure.cs.tt">

</ValueProvider>

</Argument>

Only the template path is specified here, but other settings (target namespace, class name etc.) can also be provided. Having the TemplateConfiguration argument populated means the third Wizard page will not be shown. Running this recipe gives you a Wizard form which only contains the second page, for selecting metadata items, pre-populated with the list which has already been loaded from the configured database:

- note that the other pages are not available, so the user is constrained to using the configured source and T4 template.

Other recipes demonstrate configuring all or part of the settings needed for code generation. Generate Simple runs a template which requires no metadata, so it connects to the metadata source, runs the template and adds the project output with no user intervention. Additional Source demonstrates how you can extend the base code generation guidance package with additional metadata sources and providers of your own, without rebuilding the base package. Specify the SourceAssemblyConfiguration argument:

<ValueProvider Type="SourceAssemblyConfigurationValueProvider"

AssemblyList="Sixeyed.CodeGeneration.Tests">

</ValueProvider>

</Argument>

- and the .NET assemblies named in AssemblyList (semi-colon separated) will be interrogated at run-time to identify IMetadataSource and IMetadataProvider implementations (there'll be more detail on those interfaces in a coming post). Any available classes will be added to the list of sources and providers shown in Add Generated Items, and can also be used in SourceConfiguration argument values.

Usage

By providing custom recipes, you can tailor your own Guidance packages which contain recipes for generating classes or other artifacts based on established patterns. This gives the project team an easy way of ensuring consistency for common coding problems in the domain – configuration sections and stored procedure wrappers are simple examples. Note that the URIs and paths are hard-coded. The code generation guidance package will attempt to find a T4 template if the path is not fully stated, but it won't always succeed (there's an issue with returning the running GuidancePackage instance that I haven't tracked down). In a typical project though, templates would be in SCM and source URIs would be consistent among developers, so fully-qualified hard-coded text shouldn't be a problem.

I'll be extending the sample package to include other templates that may be useful starting points for common code generation tasks – enums to represent reference data, unit tests for .NET and BizTalk artifacts, MSBuild scripts and anything else that occurs. If you have any templates of your own which would fit in a standard library, let me know and I'll add you as a CodePlex contributor.

Code Generation Guidance Package

EltonStoneman — Sun, 08 Mar 2009 01:51:14 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

I've been working on a Guidance package which lets you use Visual Studio as a front end to generate items from T4 templates. Using a recipe wizard you choose your metadata from a Web service, database or file system source, and the template is rendered against each of the metadata objects you select. It's on CodePlex here: Code Generation Guidance Package, and comes in two flavours. The basic Guidance package has a single recipe "Add generated items" – when you run it, you specify a metadata provider, select the items to use for metadata and the T4 template to render against the items.

The second package is a sample which extends the functionality of the main Guidance package with custom recipes. This demonstrates how you can define recipes for pre-configured generation types, so the user does not need to complete all the wizard pages – one example specifies a database connection string and a T4 template for generating stored procedure wrappers; to add a new DAL class, the user runs the recipe and just selects which stored procedure(s) they want generated.

Neither package comes with any Visual Studio solution or project templates, and they do not need to be used to create the original solution. Any existing project can make use of the code generation features by enabling the package(s) through Tools…Guidance Package Manager.

In this post I'll give an overview of using the basic Sixeyed.Guidance.CodeGeneration package, and in future posts I'll add some technical detail and give a walkthrough of the sample project.

Add Generated Items

Run the Add generated items recipe from the Guidance Package Manager, or from the context menu of any project in Solution Explorer. The wizard loads to collect settings - in the first page you select the metadata source type, configure the source and select the metadata provider:

During generation, the provider will load each of the selected metadata items and provide them as a property which can be accessed in the T4 template. For instance if you use the SQL Server Stored Procedure provider, your T4 script will have a populated SqlCommand object available to use.

Provided with the basic Guidance package are the following Sources and Providers:

File System
- File source – for using one or more files as metadata
  - XML File provider – for using XML file contents, exposed to the template as an XmlDocument instance
  - Text File provider – for using text file contents, exposed as a string
  - Assembly File provider – for using a .NET assembly, exposed as an Assembly instance
- Directory source – for using a list of directory contents as metadata
  - File List provider – for using a list of file names, exposed as a List<string> instance
  - Directory provider – for using a directory, exposed as a DirectoryInfo instance
Database
- SQL Server Database
  - Query Result provider – for executing a SQL query and exposing the results in a populated DataSet
  - Table provider – for using a table as metadata, exposed as an empty DataTable with the correct structure
  - Stored Procedure provider – for using stored procedures, exposed as a populated SqlCommand object
WSDL
- SOAP source
  - Web Method provider – for using a Web service method, exposed as a MethodInfo object
  - Schema provider – for using the WSDL of the service, exposed as an XmlSchema object

When you select a provider, it will load a list of all available metadata items, and you select which items you want to run the T4 template against:

The item selection is always a simple list displaying the item name – this will be the name of the file, table, Web method etc (an exception is the QueryResult provider which uses this page to capture the SQL query to be executed).

In the final screen, select the T4 template to use:

The file dialog will default to the "Templates" folder of the Guidance package, but you can navigate to any T4 file. If you want to override the output settings from the T4 file, specifying a different target filename, namespace extension or class name you can do it in the additional properties in this step:

Finish the wizard and the recipe will iterate over each of the selected items, populating a representation of the metadata and passing it to the T4 template property.

T4 Template Properties

In order to access metadata item information and create the output, your T4 script needs to specify two properties which will be populated using the Guidance PropertyProcessor engine:

<#@ property processor="PropertyProcessor" name="MetadataItem" #>

<#@ property processor="PropertyProcessor" name="TemplateConfiguration" #>

The MetadataItem property is an object implementing Sixeyed.CodeGeneration.Metadata.Interfaces.IMetadataItem:

The underlying Item property gives you access to the populated metadata item – the object type will depend on the provider, and will be specified in the ItemType property. The Key for the item (the name shown in the Select Items wizard page) is available, as is the metadata Provider which can be used to navigate up to the source.

The TemplateConfiguration property allows you to control the output of the template, setting default values for the target file name etc. (which can be overridden in the Select Template wizard page). It's an object of type Sixeyed.CodeGeneration.Generation.TemplateConfiguration:

Sample Templates

The CodeGeneration.Sample Guidance package contains a sample template for each of the metadata providers, demonstrating the type of object they expose and how it can be used. The scripts don't do much other than demonstrate usage, but there are fully-fledged scripts for generating wrappers for SQL Server stored procedures, and configuration sections from text files. The full script for the Table provider sample makes straightforward use of the underlying DataTable object:

<#@ template language="C#" #>

<#@ property processor="PropertyProcessor" name="MetadataItem" #>

<#@ property processor="PropertyProcessor" name="TemplateConfiguration" #>

<#@ assembly name="System.dll" #>

<#@ assembly name="System.Data.dll" #>

<#@ assembly name="System.Xml.dll" #>

<#@ assembly name="Sixeyed.CodeGeneration.dll" #>

<#@ import namespace="System.Data" #>

<#@ import namespace="Sixeyed.CodeGeneration.Generation" #>

<# PrepareOutput(); #>

Table name (from metadata): <#= MetadataItem.Key #>

Table name (from table): <#= dataTable.TableName #>

Columns:

<# foreach (DataColumn column in dataTable.Columns)

{

#>Column Name: <#= column.ColumnName #>

Data Type: <#= column.DataType #>

<#} #>

<#+

private DataTable dataTable

{

get{ return MetadataItem.Item as DataTable; }

}

private void PrepareOutput()

{

TemplateConfiguration.ClassName = string.Format("Table_{0}", MemberName.ToPascalCase(MetadataItem.Key, true));

TemplateConfiguration.FileExtension = "cs";

}

(If you don't already have it, the T4 Editor Community Edition from Clarius makes editing templates much easier).

The directives specify the expected properties, and import the relevant reference assemblies and namespaces. The script provides the dataTable property to easily access the metadata item as a typed DataTable object. In the PrepareOutput method (called at the start of the template), the script sets up the target class name and file extension. In this case a target filename is not specified, so the engine will use the class name and file extension for the filename. Note there are some helper methods in Sixeyed.CodeGeneration.Generation.MemberName for preparing valid member names.

Selecting a single table called Manufacturers for this script generates and adds a file called Table_Manufacturers.cs to the selected project, containing the following output:

Table name (from metadata): Manufacturers

Table name (from table): Manufacturers

Columns:

Column Name: ManufacturerId

Data Type: System.Int16

Column Name: ManufacturerName

Data Type: System.String

Column Name: AvailableFromDate

Data Type: System.DateTime

Column Name: AvailableToDate

Data Type: System.DateTime

Usage

For ad-hoc code generation, this basic Guidance package lets you specify metadata to execute against a T4 template. For commonly used scripts and standard patterns you can build a custom Guidance package which contains your solution structure, and specific recipes for generating known types of item – for DAL classes, entities, configuration sections, proxies or anything else that is based on external metadata.

ExecuteT4Template MSBuild task: Updated

EltonStoneman — Sat, 04 Oct 2008 14:14:31 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

As Cory pointed out, my original task to execute T4 templates under MSBuild (replacing property markers in the T4 script with evaluated values from the build, see: An MSBuild task to execute T4 templates), fails under MSBuild 3.5. This is down to a change in the object model in the framework. All the useful classes are internal and all the useful properties are private, so they have to be reflected over - which makes my code brittle.

I've updated the task as part of a set here: Sixeyed MSBuild tasks, and it now works with either MSBuild 2.0 or 3.5.

Another update will be coming soon, to allow you to use named item group values, as well as property values and whole item groups in the script. A script can be marked with %(Collection.Identity) and when the task is called iteratively over a collection, the script will be populated with the current collection value each time. I'm also planning to change it to use the T4 engine directly rather than invoking the TextTransform console app, to hopefully speed up the execution time.

I'm using this task increasingly in builds now. It's a lot neater than having multiple XML or Regex file updates, and the template can be used to isolate logic so the builds stay clean. Currently it's used to dynamically generate Wix scripts, generate BizTalk bindings file for a set of environments, generate documentation projects for Sandcastle Help File Builder and produce config files for running DevPartner code coverage. Some of those templates may be generically useful, so I'll add them to MSDN when I get to the next update.

T4 template to generate Wix scripts to generate WCF MSIs in MSBuild

EltonStoneman — Thu, 04 Sep 2008 19:55:11 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Snappy title. We have a project which contains lots of WCF Service projects, and we want to generate MSIs so we can deploy them to IIS. The gaps between the projects are minimal as they all use the same structure, so instead of having separate Setup or Wix files in each of the solutions, generating the WXS files on the fly was an option.

The installer steps we wanted were reasonably simple:

install WCF artifacts to the chosen directory (.svc and web.config files)
install WCF binaries to the chosen directory\bin
install dependencies to the GAC
create a virtual directory in IIS pointing to the install directory

The only UI we particularly needed was the choice of install directory, so the Wix for this fits into a fairly straightforward T4 template:

<#@ template language="C#" #>

<#@ output extension=".xml" #>

<#@ assembly name="System.dll" #>

<#@ import namespace="System.IO" #>

<#@ import namespace="System.Security.Cryptography" #>

<#@ import namespace="System.Text" #>

<?xml version="1.0" encoding="UTF-8"?>

<Product Id="<#= this.GetProductId() #>"

Name="<#= ServiceName #>"

Language="1033"

Version="<#= VersionNumber #>"

Manufacturer="Company"

UpgradeCode="<#= this.GetUpgradeCode() #>">

<Media Id="1" Cabinet="<#= ServiceName #>.Install.cab" EmbedCab="yes" />

<# foreach (string filePath in this.WcfArtifacts.Split(';'))

{

this.AddFile(filePath);

}#>

</Component>

<# int index = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<Component Id="GACComponent_<#= index++ #>" Guid="<#= this.GetNewGuid() #>" SharedDllRefCount="yes">

<# this.AddAssemblyToGAC(assemblyPath); #>

</Component>

<#}#>

<# this.AddAssembly(this.WcfAssembly); #>

</Component>

</Directory>

<iis:WebVirtualDir Id="WcfVirtualDir" Alias="<#= ServiceName.TrimEnd(".Wcf".ToCharArray()) #>" Directory="INSTALLLOCATION" WebSite="DefaultWebSite">

<iis:WebApplication Id="WcfApplication" Name="<#= ServiceName #>" />

</iis:WebVirtualDir>

</Component>

</Directory>

<iis:WebSite Id="DefaultWebSite" Description="Default Web Site">

<iis:WebAddress Id="AllUnassigned" Port="80" />

</iis:WebSite>

<Feature Id="ProductFeature" Title="<#= ServiceName #>" Level="1">

<# int i = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<# } #>

</Feature>

</Product>

</Wix>

<#+

private string ServiceName

{ get{ return "$(ProjectName).$(ProjectFilter)"; }}

private string VersionNumber

{ get{ return "$(Version)"; }}

private string WcfArtifacts

{ get{ return @"@(WcfArtifacts)"; }}

private string WcfAssembly

{ get{ return @"@(WcfAssembly)"; }}

private string WcfDependencies

{ get{ return @"@(WcfDependencies)"; }}

…

- the full template is here: WCF Service Wix template.

A couple of interesting things here – the Guids are generated from the name of the elements (see Generating Deterministic Guids), so multiple versions will have the same Guid and will operate as updates, provided the name of the service doesn't change; the tags for MSBuild properties in the template get resolved using the ExecuteT4Template MSBuild task; the GACd assemblies flag themselves as SharedDllRefCount so if you uninstall this package, the files will be left in the GAC if any other packages use them, but removed if this is the only package that uses them.

Another custom task is needed to resolve the dependencies of the WCF assembly (sample version here: MSBuild ResolveDependencies task), and the MSBuild snippet to run it together with the Wix commands looks like this:

<ResolveDependencies AssemblyList="@(WcfAssembly)"

Filter="$(CompanyName).$(ProductName)">

</ResolveDependencies>

</Target>

<ExecuteT4Template ToolPath="$(MSBuildProjectDirectory)\$(BuildBinDir)"

TemplatePath="$(TemplateRoot)\Services.Wcf.wxs.tt"

OutputPath="$(ArtefactWixDir)\$(ProductName).$(ProjectName).Wcf.wxs">

</ExecuteT4Template>

</Target>

- we store all the intermediate files (the T4 template with resolved property values, WXS and WIXOBJ files) to help with debugging.

Flattening WSDL from WCF Services

EltonStoneman — Wed, 30 Jul 2008 17:23:15 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

If you're hosting WCF services in IIS and try accessing the WSDL using ServiceDescriptionImporter.Import, you'll get an error saying Unable to import binding BasicHttpBinding_IXyzService…

WCF separates out its schemas into logical components, which ServiceDescriptionImporter and other clients (including the ESBSimpleSamples ServiceClient generator) can't work with, as they're expecting a single flat WSDL.

Christian Weyer from Thinktecture has a solution here: Improving WCF Interoperability: Flattening your WSDL. If you download and build his sample project, copy Thinktecture.ServiceModel.Extensions.Description.dll to your service bin folder and amend your .svc description to use the Thinktecture factory:

<% @ServiceHost Language=C# Service="Xyz.XyzService" Factory="Thinktecture.ServiceModel.Extensions.Description.FlatWsdlServiceHostFactory " %>

- this will return a flattened WSDL, so tools expecting one file will work correctly.

An MSBuild task to execute T4 templates

EltonStoneman — Fri, 25 Jul 2008 18:54:23 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

I was looking for an MSBuild task which could execute a T4 template, replacing tags in the template with the value of properties or item groups from the build - giving your T4 templates access to all the runtime values used in the build scripts. So you start with a T4 template like this:

<#@ template language="C#" #>

<#@ output extension=".txt" #>

<#@ assembly name="System.dll" #>

***START

Property value: StartDir= $(StartDir)

Item Group value: TextFiles = @(TextFiles)

***END

- execute it through a call to ExecuteT4Template in your build target:

</PropertyGroup>

</ItemGroup>

</Target>

- and it produces the following output:

***START

Property value: StartDir= C:

Item Group value: TextFiles = \zeros.txt

***END

There wasn't one that I could find so I put a simple one together. A couple of fiddly things worth noting if you do something similar:

the project's property values are not exposed to the executing task in an accessible way, so you have to reflect around BuildEngine to get hold of the executing project;
if you don't want to write an ITextTemplatingEngineHost or rely on a GAX or other host, you'll end up shelling out to TextTransform.exe (as I have).

Full source for the task is here: ExecuteT4Template.cs (note this uses version 1.1 of the TextTransform tool).

A couple of things to note: this task will update all instances of property and item tags in the template - $(propertyName) or @(itemGroupName) (it's not clever enough to deal with %(itemGroupName.ValueName))- with the value from MSBuild, if the named property/item group exists in the project. Potentially you may want to leave certain tags in place in the template, in which case you'll need to ensure there are no matching properties in the build, or extend the task to take a list of names to ignore.

Also, if you're using a value in your script which is the output from another task, then the task which produces the output must be in a separate target which completes before the call to ExecuteT4Template. MSBuild seems only to store properties/item groups from task outputs when targets are completed, so if the output is created in the same target as the T4 task, the property won't be registered and the tag in the template won't be replaced.

I have a couple of other tasks which all relate to deploying BizTalk and ESB Service Providers, so I'll add them to the ESBSimpleSamples CodePlex project along with this one.

SSO Config Tool

EltonStoneman — Mon, 30 Jun 2008 00:41:30 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The Enterprise Single Sign On database can function as a centralized configuration store, as well as an identity store, which is available to all BizTalk instances in a group, and also to custom .Net apps. For a clear explanation of the benefits and drawbacks of the EntSSO approach (and the alternative options), see Michael Stephenson's post Where do I store my custom configuration for a BizTalk solution.

Here I'll look at overcoming some of the practical issues in developing, deploying and maintaining config in an EntSSO store using another tool I've been using for a while and have recently put onto CodePlex: SSO Config Tool.

The original purpose was to codegen a strongly-typed configuration model that abstracted away the EntSSO store, and made read-only config values available from a static class for expressions:

- or .Net code:

//extract the UDDI config settings:

string uddiUrl = ConsolidatedGyroscope_App1Config.UDDIServerUrl;

uint uddiTimeout = ConsolidatedGyroscope_App1Config.UDDICacheTimeout;

So it does that (if you're looking for an app which just lets you manage SSO stores, have a look at Richard Seroter's Config Application Manager), and it also gives you:

a console app to generate the config, and to import/export between EntSSO and an XML config file
MSBuild task versions of the console functionality
a UI version of the console functionality, which also lets you maintain config settings:

There are a couple of things worth noting here.

Application Settings

These are all mandatory. The Groups specify who has access to read and update the config store settings. Groups must exist at the time you try and save the app to EntSSO, and they cannot be built-in groups or the "Everyone" group (not that you would…). The BizTalk groups are sensible options, so they're the default for the UI.

Fields

Field types are limited (by EntSSO) to one of the following built-in types:

String
Int32
UInt32
Boolean

The type you select will be emitted as the type of the property in the generated config model. Values are validated against the given type. The Masked option is a little misleading – all entries in EntSSO are encrypted, but if the field is defined as Masked in the config store then you can only retrieve it if you access EntSSO with a specific flag. The generated config model gives itself this permission, so the Masked value has no effect if you only use the config model.

XML

A custom schema is used so I can capture the expected field data type (rather than inferring it) – so it's similar but not compatible with the structure used by ssomanage.

Generated Code

The config model produced by SSOConfigTool uses a couple of helper classes in the SSOConfig namespace. When you generate the model, you can either generate the source code (so you'll have to add the SSOConfig assembly to your app as well as adding the C# class), or a compiled assembly (which contains the configuration model in your selected namespace, and the helper classes in SSOConfig, so you can use it on its own). The API (Microsoft.BizTalk.Interop.SSOClient) should be in the GAC.

Structure is quite basic – there's an SSOApplication class that represents the config store for an application, and the business of wrapping the EntSSO API is done in SSOHelper. The config class uses SSOApplication behind the scenes to get field values, and exposes them as the correct type. The class also exposes a CacheSSOAccess property which determines whether values are fetched from EntSSO on each call, or lazy loaded – it defaults to being lazy loaded (this is a static class so be aware of the thread implications if you're changing this value).

Some quirks with the EntSSO API are documented here:

For the config tool, the implication is that it creates a dummy field in the config app, but you won't see it unless you look in SSODB.

Usage

I've mainly used the UI to create the app in the EntSSO store, then used the MSBuild tasks to extract the app as XML and generate code from it. Alternatively you can use the build tasks to create the SSO store and/or generate code from a saved config file. The sample MSBuild files in the project show these uses.

Work Outstanding

Only a couple of things – firstly the SSO Config Tool (in its various guises) expects the EntSSO store to be available locally, so currently it doesn't allow you to run it from one machine to update SSO on another. The other one is more of an annoying niggle – if you try to open an SSO app from the UI, you'll probably find the dropdown list of available apps empty. This is down to ISSOMapper.GetApplications always returning an empty list, so until I work out why it thinks the user isn't entitled to view them, you'll need to type in the name of the app. Think of it as a security measure.

Contract-First CodeGen

EltonStoneman — Fri, 06 Jun 2008 02:45:00 GMT

I've added some codegen scripts to the ESBSimpleSamples project, and a simple UI which runs the scripts against metadata it retrieves from a WSDL endpoint. The codegen templates were built for a custom tool which we use (not public I'm afraid), and then stripped down for the "ServiceClient.Generator" tool, so the structure might look a bit odd, but they do the following jobs:

Extract the schema from the WSDL location to XSD (ready for loading into BizTalk)
Build a (very) clean request DTO for the selected method
Build a (similarly) clean response DTO for the selected method
Build a typed ServiceRequest object for use with the ESBSimplseSamples.ServiceClient library, giving access to the service via ESB

The classes are just displayed in the form at the moment (using ScintillaNET for readability):

(if anyone has a burning desire to increase the functionality of the UI, let me know and I'll add you to the CodePlex project).

I'm intending to add further codegen scripts to generate:

a unit test stub for calling the ServiceRequest
a sample XML message containing the necessary itinerary steps in the header, and some dummy values in the body
settings for adding the service to a UDDI repository.

This all works splendidly for the straightforward services I've tried so far, though I'm expecting some rework to deal with services that use types across a variety of schemas.

Rummaging around in the System.Web.Services.Description namespace to get the WSDL metadata really isn't much fun. I'll write a post moaning about it in more detail later, but for now I'll point to a couple of helpful resources: Web Service Studio Express (the basis for the DynamicProxy code) and C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\DefaultWsdlHelpGenerator.aspx (the page that ASP.Net runs when you enter a WSDL location in IE).