<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” />

As I alluded to in my last wix blog entry if you want to provide any sort of location robust access to well known folders Type 50 CustomActions are not for you. I thought I could get away with this as we’re just using msi to deploy our bespoke app to the testing environments which we control. However my boss came to me this morning saying they had one machine on behaving in a pre-jited manor could I take a look; sure enough the windows folder on this machine was c:\winnt rather than c:\windows like I had assumed it would be. Lesson learn, I set off to alter my install scripts to produce Type 34 custom actions. Again much bashing of head against monitor (although slightly less than last time), so I thought I’d again share the results.

 /o:p

The only really change you have to make to yesterdays scripts is to the CustomAction tag itself. The syntax is shown below.

 /o:p

<CustomAction Id=“Test.exeFileNGen” ExeCommand=‘”[WindowsFolder]Microsoft.NET\Framework\v1.1.4322\ngen.exe” “[#DataPharm.PharmaNet.Logging.dllFile]“’ Directory=“InstallDir” />/o:p

 /o:p

The Directory property is the working of the command and it is a foreign to an entry into the directory table. I chose the install dir for this; it wasn’t a critical decision since everything is using a full path anyway. Probably the most important thing to note is the subtle difference between access a property and accessing a file path. A property has the syntax [Property] where Property is the name of the property (this is where I get the value for the windows folder). File paths, as discussed yesterday, use a similar syntax but with a hash (#) symbol.

 /o:p

The other slightly annoying thing is there is no well know of accessing the framework directory; you just specify the path you want to use starting from the windows folder. I guess this is because several versions of the framework installed all running side by side, but it does mean you end up hard coding you’re install against a specific version of the framework. This is definitely okay for me as I know were always going to be using framework v1.1.4322 during testing, well put it this way: we’ll having bigger problems than just ngening if we’re not.

 /o:p

Anyway the full wxs script is available here. Again it will compile but not link, unless you provide your own test.exe assembly./o:p

/o:p

Feedback:

Feedback was imported from my only blog engine, it’s no longer possible to post feedback here.

re: NGen Custom Actions using WiX – Part II: Type 34 actions - M. Scott Ford

You zipped up the wxsobj file not the wxs file.

Thanks for the post!

re: NGen Custom Actions using WiX – Part II: Type 34 actions - M. Scott Ford

I forgot to mention something. Reading that little bit about sequencing the actions after InstallFinalize was a life saver. I kept trying to sequence mine after InstallFiles, and was struggling to figure out why it was not working.

Thanks again!

re: NGen Custom Actions using WiX – Part II: Type 34 actions - Robert Pickering

A big d’oh re: file up load. This has now been corrected. Glad you found the info useful.

re: NGen Custom Actions using WiX – Part II: Type 34 actions - Graeme Foster

I know this post was a long time ago, but the zip I just downloaded contains the .wixobj file not the .wxs file - are you sure you fixed the download? :)

Good post, thanks!

re: NGen Custom Actions using WiX – Part II: Type 34 actions - Robert Pickering

I did fix it, but that change must have been undone in a redeployment or something. I seem to have miss placed the orginal, so I will have to redo the download sample. This will happen soon(ish).

However, some seems to have placed a pretty complete version of the sample <a href="http://graemef.com/?q=using_wix_to_run_ngen_2_0_against_your_application_during_installation_part_2&PHPSESSID=daf6ae6f5882866e2d7f03b0889e552d">here</a>.

Thanks!