Showing posts with label XML/XSL. Show all posts
Showing posts with label XML/XSL. Show all posts

Friday, October 27, 2006

Generate WiX 2.0 Web Folder Fragment

This little utility grew out of need. I'm offering it up for free because it's so rough around the edges - no documentation, brute force approach, hardcoding, assumptions, etc. - you get what you paid for! It consists of a command script, a VBScript and an Xsl file - you can download it here. To use it, you also need another little utility I built which will generate a nested Xml directory listing that you can find here.

It will take an Xml directory file (from this previous utility) and generate a WiX 2.0 compatible fragment with the following features:

  1. DirectoryRef element so it can easily be referenced back to a Directory in a "controlling" WiX file.
  2. Component element for the web virtual directory with WebVirtualDir and WebApplication child elements.
  3. Component element representing the root of the web folder with a child elements for all Files found there, including both long and short names as needed.
  4. Nested Directory elements representing each of the sub folders under the root web folder (recursive) with all files.
  5. Ignores Visual SourceSafe (*.scc) files. ;)
  6. ComponentGroup element to pull together all the pieces of the web site so it can be easily referenced from a Feature (via ComponentGroupRef) in a "controlling" WiX file.

Of course, there's been limited testing (very limited, ok...I've only tested it on one project) so you may find some bugs. There's also some hardcoding and assumptions. Pay special attention near the top of the Xsl file where it's building the web virtual stuff (e.g. AllowSessions, DefaultWebSite, etc.). I didn't bother to get fancy and code for parameters.

Because of lack of time it carries a big assumption about the various artifact names - it uses the root folder name that you're building from. For example, if your web folder source is located at [C:\Inetpub\wwwroot\mywebsite] then it'll pick up "mywebsite" as the internal WiX name for the vdir, webapp, alias, etc. Finally, it picks up the auto generated GUIDs from the directory Xml ("ah, that's why he stuck them in there" ;) ) to use for component IDs and GUIDs. Therefore, this probably only has limited use as a first time tool since changing the GUIDs on each release of an MSI is generally frowned upon.

To use it simply drop the three files into your WiX build directory and invoke it from a command line: bldWebWxs "path_to_root_of_webFolder_source" wxsFilename

Hopefully, this will save you some time and get you most of the way there.

Enjoy!

Original post

Build XML Directory Structure

I've hacked together a little VBScript utility that will generate an Xml representation of a directory structure which you can download here. I looked around for something that already did this and came across Pat Coleman's DIR2XML utility. It provided a basis for what I needed but there were a couple of things I had to tweak - it generated a "flat" listing of all files and it produced an XHTML document via an XSL transform. Pat did a lot of the heavy lifting with the recursive directory scanning and getting file version information.

My bldDirXml.vbs does the following:

  1. Generates a nested Xml containing <folder> and <file> tags.
  2. Supports a "flattened" mode [-f] which pulls the information up into attributes of the folder or file tag instead of child elements.
  3. Generates a unique id for each folder and file.

To run it, use the following command: cscript bldDirXml.vbs "folderPath" [outputFilename] [-f]

All the usual disclaimers apply - it's a pretty brute force approach, not heavily tested, your mileage may vary, hold your nose if you look at the code, etc.

Enjoy!

Original post

Monday, October 3, 2005

Detecting end of a list in XSLT using position()

Apparently Mohammad Azam has recently discovered using XSLT for code generation. One of the issues he's learned is that when using XSLT to generate code you have to be aware of where you are in the list of nodes that's currently being traversed. The particular problem he's got is that looping through a list of fields and tacking on a comma afterwards leaves one stray comma on the end of the list.

The way I solved this problem was a combination of a “switch” statement and using the built-in position() and last() functions to know where you are:

<xsl:choose>
<xsl:when test=”position() = 1”>emit code here for first node in list</xsl:when>
<xsl:when test=”position() = last()>emit code here for last node in list</xsl:when>
<xsl:otherwise>emit code here for all other nodes in list</xsl:otherwise>
</xsl:choose>

I have been successful in building various templates for code generation over the years using XSLT. However, as the complexity of the generated code increases (think multi-tiered, layered application) then it becomes harder to manage (you can go crazy from staring at XSL for many hours!). Kathleen Dollard does a good job of pulling together various technologies (XSL, Code Dom, Db Info Schema, XSD) in her book Code Generation in Microsoft .NET. Unfortunately, it came out a few months too late for me! Why? Because I had already hit my head many times and worked through most all the issues she does in her book by the time it was published.

Instead, I had already decided to give CodeSmith a try and haven't looked back since. Not only is the familiar ASP/ASP.NET style more “natural“ for developers, but the built-in support for database schemas as well as Xml-based schemas/input and copious samples makes getting off the ground much, much easier.

Original post