Almost there... Stay on target...

Getting closer to getting the first general WiX task done.

I now have WiX creating my user, adding that user to the Administrators group (No comments from the peanut gallery, please!) and then creating a custom AppPool and creating a Web Application that is bound to that custom AppPool with a created VDir. Pretty nifty.

Here is what it looks like so far:

   1:  <Component Id="MySoftwareRequirements" Guid="{SOME-VALID-GUID}">

   2:    <CreateFolder/>

   3:    <util:User Id="MySoftwareUser" Name="MySoftwareUser" Password="supersekrit">

   4:      <util:GroupRef Id="Administrators"/>

   5:    </util:User>

   6:    <iis:WebSite Id          = "DefaultWebSite" 

   7:                 Description = "DefaultWebSite"

   8:                 Directory   = "MySoftwareSubDir">

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

  10:        <iis:WebDirProperties Id                    = "WebVirtualDirProperties"

  11:                              Execute               = "yes"

  12:                              Script                = "yes"

  13:                              Read                  = "yes"

  14:                              WindowsAuthentication = "no"

  15:                              AnonymousAccess       = "yes"

  16:                              AnonymousUser         = "MySoftwareUser"

  17:                              IIsControlledPassword = "no" />

  18:    </iis:WebSite>

  19:    <iis:WebAppPool Id="MySoftware" Identity="other" Name="MySoftware" User="MySoftwareUser"/> 

  20:    <iis:WebVirtualDir Id            = "MySoftwareVDir"

  21:                       Alias         = "MySoftwareVDir" 

  22:                       Directory     = "MySoftwareSubDir" 

  23:                       WebSite       = "DefaultWebSite"

  24:                       DirProperties = "WebVirtualDirProperties">

  25:      <iis:WebApplication Id         = "WebApplication"

  26:                          Name       = "MySoftware"

  27:                          WebAppPool = "MySoftware" />

  28:    </iis:WebVirtualDir>

  29:  </Component>

Of course, you can't see the reference to the Administrators group that is up at the top of the .wxs file under the Package element (see previous post). It is starting to come together.

More WiX stuff: Creating a user and adding them to a group.

Now that I am able to successfully create a new user I need to add that user to the Administrators group. Yeah, I hear you already, "That's a major security issue!" and I would tend to agree but this has been "mandated" by MercScum so there isn't much I can do about it.

Anyhoo. To do it I had do the following.

After the Product and Package element declarations I had to add a Group element, like this:

   1:  <Product Id="{F0C1692F-2D79-4D46-9BDF-DCBAD1DBCDDB}" Language="1033" Manufacturer="SomeManufacturer" Name="SomeProduct" UpgradeCode="{SOME-VALID-GUID}" Version="1.0.0.0">

   2:    <Package Compressed="yes" InstallerVersion="200" />

   3:      <util:Group Id="Administrators" Name="Administrators" />

It took some trial and error to find out where to put the util:Group element. The documentation says that it is a child of the Product element but I couldn't put it directly after. It had to go under the Package element. Good to know!

In my previously declared util:User element I had to nest a GroupRef element so the entire bit of XML reads like this:

   1:  <Component Id="RequiredUser" Guid="{SOME-VALID-GUID}">

   2:    <util:User Id="NewUser" Name="NewUserName" Password="supersekrit">

   3:      <util:GroupRef Id="Administrators"/>

   4:    </util:User>

   5:    <CreateFolder/>

   6:  </Component>

I was able to create the .msi and installed it on a VM and it worked like a charm. Luckily I only banged my head against the WiX brick wall for a few hours this time, unlike the create a new user head-banging. I suspect everything else will start to fall into place now that I am getting more comfortable with WiX and XML in general. Yes, I've managed to be in industry for almost 20 years without having to bow down to the great XML monster but now I am paying the price for being behind the curve. Back in my day we had CSVs and we liked 'em!

Can I has user created by WiX?

Ok. I'm starting to get this stuff figured out.

The User tag is part of WixUtilExtension.dll but it is not enough to simply reference WixUtilExtension on the command line.

You must also add an XML name space reference in the .wxs file. Also, another gotcha. The namespace spelling is different from the WixUtilExtension spelling. D'oh!

I had to add the following:

   1:  <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"

   2:       xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

Now, the User tag that I created has to have the "util" prefix to let the linker know that the User tag is being referenced for the WixUtilExtension:

   1:  <Component Id="RequiredUser" Guid="{SUPER-DUPER-GUID}">

   2:    <util:User Id="UserStuff" Name="UserStuff" Password="supersekrit" />

   3:    <CreateFolder/>

   4:  </Component>

Notice that I had to add the CreateFolder tag in my User tag to prevent error ICE18. Otherwise, it'll fail and make me cry.

I was able to link with candle with a "-ext WixUtilExtension.dll" reference and the wixobj was created and with the CreateFolder I avoided the dreaded ICE18 error. I was also able to create my .msi and I will test that tomorrow on my VM.

Wasn't that all intuitively obvious?

My thanks go out to the wix-users listserv that pointed out where I was banging my head against the brick wall of wix. Now with this information I should be able to go forward with the other tasks required and be a tad bit more efficient with WiX (Finally!).

My head hurts...

*bangs head against desk*

Search for creating users with WiX and you see the handy dandy User tag.

Go ahead and try that with WiX v3. Doesn't work?

Google the documentation. Aha! I need the sca.wixlib and associated sca*.dll files?

Search for files.

Not shipped with v3?

Hmmmm...

Download WiX v2.

Try using with WiX v3.

"The extension 'sca.wixlib' could not be loaded."

*continue to bang head against desk*

Now off to try this again with WiX v2. Can't use heat to harvest files? Guess I need to re-learn the process with tallow.

*continue to bang head against desk*

Do some more Googling. Hey, automated tasks are in the Wix*Extension.dlls. That's what I thought but couldn't get to load with -ext. Hmmmmm?

Some more Googling and reading of blogs. Oh, you can't just use the Wix*Extension.dll by name. Needs full path. Ok. That's not so bad.

Which Wix*Extension.dll has the task for using with the User tag? Dunno. I'll just copy all Wix*Extension.dll to my subdir and try 'em all.

Oops. WinDifxAppExtension.dll can't be loaded? Remove it from command line.

Oops. WixIsolatedAppExtension.dll can't be loaded. Remove it from command line.

Will by User tag be recognized now? *crosses fingers* Let's give it a try!

8<--------------------------------------------------
C:\SomeProduct\SP\Dist>candle -o SP.wixobj SP.wxs -ext WixDifxAppExtension.dll -ext WixDirectXExtension.dll -ext WixFirewallExtension.dl
l -ext WixGamingExtension.dll -ext WixIIsExtension.dll -ext WixMsmqExtension.dll -ext WixNetFxExtension.dll -ext WixPSExtension.dll
-ext WixSqlExtension.dll -ext WixUIExtension.dll -ext WixUtilExtension.dll -ext WixVSExtension.dll
Microsoft (R) Windows Installer Xml Compiler version 3.0.4318.0
Copyright (C) Microsoft Corporation. All rights reserved.

SP.wxs
C:\SomeProduct\SP\Dist\SP.wxs(461) : error CNDL0005 : The Component element contains an unexpected child element 'User'.
-------------------------------------------------->8

Fsck.

*sigh*

Hey. Wasn't I hired to be the performance SME? Hmmmm. What happened to that?

The pain of the WiX

Much like the use of candles in BDSM play, I am feeling the pain of the WiX wax motif windows installer. But like those candles, I think it'll pay off in the long run.

Once again, into the depths of XML fun! At least it's not XML scripting languages at this point but I am definitely feeling the pain of heat, candle and not seeing the light at the moment. WiX has a very steep learning curve.

So far I've learned how to harvest a bunch of files with heat, link with candle and assemble a .msi with light. With a simple and straightforward project it's actually pretty simple but unfortunately I am not on a simple project.

The first thing that I've found that has burned me is that we have a bunch of duplicated DLLs nested in different subdirs that I want to package as a product and apparently that is a no-no and can't be done. I've had to separate the subdirs generated by MSBuild into two seperate trees with parallel structures and create two .msi packages that when executed create the desired tree.

I banged my head up against that for long enough.

Now I'm trying to figure out how to create a user and that is pretty painful. There is a most excellent older tutorial located here but it doesn't document all the gotchas. I'm trying to find the extra DLL I have to reference via -ext on the command line for candle.exe that recognizes the user tag.

Unlike the nant to MSBuild conversion (which I don't think it was necessary) I figure that learning this WiX stuff will pay off. I mean, if WiX was good enough for MS to deploy SQL Server 2005 and Office 2007 it should do everything I ever want. It's just the learning curve that has to be climbed.

I can really see why deployment/build engineering can be a full time position on a team. I don't want to be a full time build/deployment engineer but I appreciate the knowledge and suspect that it'll pay off in the long run.

From MSBuild to WiX

Now that I've converted from NAnt to MSBuild scripts I am now learning the wonderful world of WiX to create .msi install packages. What does this have to do with my performance testing duties? Not a damn thing.

The hired mercenary scum that is running the project now is having do all sorts of things that are not part of our normal activities. I was hired to be a performanc SME and to build up a testing framework which is about 80% complete. My last work on that was over a month ago.

I suspect I shall not see another performance test on this project.

NAnt versus MSBuild

At work we are currently converting from NAnt to MSBuild scripts as we convert from CruiseControl.NET to TeamCity. Why are we changing from NAnt to MSBuild as we change CI servers? Nobody really knows for sure besides the guy that is running the project basically says, "I've mandated it." That's the only reason. Seems like a silly reason to be to go through all the trouble to rewrite all the scripts.

After working with NAnt and MSBuild I have come to one conclusion: I don't like XML based scripting languages. That's right, you heard it here. They are both a pain. Way too verbose and too much of a PITA. My personal belief is that we should just wrap all the functionality with a perl script and be done with it. :-) Just think about it: Simple if/then/else statements and simple loops without all the XML filler junque and all the dynamic data structures you want without a bunch more XML filler stuff. It's beautiful! Back in my day, you darn whipper snappers, we had .CSV files and liked 'em! And like Ant/NAnt, perl works under both Unix and Win32 (I've been using Win32 for a gazillion years but now that I run a 64-bit OS should I start saying Win32/64? That's a discussion for another time! Now back to my MSBuild and NAnt rant!) so you have multiple platform functionality.

MSBuild is taking me longer to wrap my head around. I don't like that I can create a property inside of a target, but that property is not available until the target where it was created as finished. Makes it a pain to attempt to modularize common calls for database work. And why doesn't MSBuild have a foreach construct? Sure, you can use the metabase accessing `%` to invoke multiple calls but how non-intuitive is that? Argh! I shouldn't have to write a helper function to make multiple calls with the % operator.

Yeah. I stand by my convictions on this one. Junque both of 'em and write a perl wrapper and be happy.