MSI Factory & Passing Command Line Arguments to a Custom Action

I created an installer using MSI Factory. Part of my setup logic is to launch an application at the end of the installation so that the user can complete the configuration process that requires them to deploy some customizations to their Team Foundation Server (TFS). I accomplish this by using Custom Actions and pass the executable as one of its parameters the installation folder or the value of INSTALLDIR, for example. The results, however, are not as expected.

In my installer I set the Command line arguments option in the Run Executable dialog of the Custom Actions editor to the following:

-p “[INSTALLDIR]”

One would expect that the property INSTALLDIR would be replaced by the actual value. At first I thought it did not since researching about it seemed to indicate that this was the case, as it was reported that way by many.

To test the case further I decided to “hard-code” the value of the expected path to pass as an argument in the installer Custom Action and things seem to work as expected.

So, I added logic in my executable code to write to the Event Log the possible causes of this issue (errors and the actual arguments passed). The following entry would happen when I execute my application as part of my installer through a Custom Action.

Event Type:    Warning
Event Source:    Process Template Item Deployer
Event Category:    None
Event ID:    0
Date:        4/12/2009
Time:        3:57:28 PM
User:        N/A
Computer:    TFSRTM
Description:
Timestamp: 4/12/2009 7:57:28 PM
Message: System.ArgumentException: Illegal characters in path.
   at System.IO.Path.CheckInvalidPathChars(String path)
   at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
   at System.IO.Path.NormalizePath(String path, Boolean fullCheck)
   at System.IO.Path.GetFullPathInternal(String path)
   at System.IO.DirectoryInfo.ctor(String path)
   at InCycle.Tools.Forms.ImportProcessTemplateItem.GetSupportedFilesFromPath(String path)
Category: General
Priority: -1
EventId: 0
Severity: Warning
Title:
Machine: TFSRTM
Application Domain: ProcessTemplateItemDeployer.exe
Process Id: 3956
Process Name: ProcessTemplateItemDeployer.exe
Win32 Thread Id: 3580
Thread Name: 
Extended Properties: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I then decided to inspect previous Event Log entries and found the following interesting entry.

Event Type:    Information
Event Source:    Process Template Item Deployer
Event Category:    None
Event ID:    0
Date:        4/12/2009
Time:        3:57:27 PM
User:        N/A
Computer:    LEOV-TFSRTM
Description:
Timestamp: 4/12/2009 7:57:27 PM
Message: Attempting to load files from "C:\Temp\InstallFolder""
Category: General
Priority: -1
EventId: 0
Severity: Verbose
Title:
Machine: LEOV-TFSRTM
Application Domain: ProcessTemplateItemDeployer.exe
Process Id: 3956
Process Name: C:\Program Files\InCycle Software\InCycle Add-ons\bin\ProcessTemplateItemDeployer.exe
Win32 Thread Id: 3580
Thread Name: 
Extended Properties: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

As you can see, for some reason “[INSTALLDIR]” is expanded correctly with one small problem, it seems to pass an extra quote at the end.

I then changed my code to add logic to fix the path that I expect as an argument before I use it elsewhere in my code. The following code snippet shows you the argument extraction with the added line that fixes the problem.

// Determine if a default path has been specified from which to load files.
if ("-P".Equals(args[0].ToUpperInvariant()))
{
    // Assign it for later use.
    loadFilesFromPath = args[1];
    // When launched from a MSI there may be invalid characters. Therefore,
    // make sure to remove all such characters before proceeding.
    loadFilesFromPath = loadFilesFromPath.Trim(Path.GetInvalidPathChars());
    // Display debugging details.
    Logger.WriteDebug(string.Format(CultureInfo.InstalledUICulture, "Attempting to load files from \"{0}\"", loadFilesFromPath));
}

Using string.Trim with Path.GetInvalidPathChars() allowed me to clean the errors from the given path.

I don’t know whether the problem lies in MSI Factory or in any underlying component, but this fixed it for me. Unfortunately, I don’t really have a way to fix this for executables for which I don’t have the code. Perhaps, writing a bootstrap application may help. But that’s another post.

Read full post...

Team Foundation Server (TFS) Customizations in x64 Environments

While testing one of the Visual Studio Team System (VSTS) extensions I wrote I came across a scenario where the assembly was failing to load under the 64-bit version of Windows 7. It turns out that by default when one creates a project in Visual Studio 2008 the target is set to Any CPU. This in turn sets the Processor Architecture of the resulting assembly to MSIL, which essentially lets the Operating System (OS) decide which .NET Framework version and flavor to use (for all intense and purposes). This causes a problem when writing extensions for VSTS such as Work Item Tracking Custom Controls and other applications that leverage the Team Foundation Server SDK.

When loading such an assembly (of type MSIL, the default created when using the target Any CPU) in a x64 environment it will use the corresponding .NET Framework assemblies, which are in this case also 64-bit. The problem is that since all Team Foundation assemblies are 32-bit (or specifically of type x86) the mix causes the application to fail loading, in my case with the following error (as displayed in the Windows Event Log).

Faulting application ProcessTemplateItemDeployer.exe, version 1.0.0.0, time stamp 0x49de2a19, faulting module KERNEL32.dll, version 6.0.6001.18000, time stamp 0x4791ada5, exception code 0xe0434f4d, fault offset 0x000000000002649d, process id 0x%9, application start time 0x%10.

As you can see this is not very helpful. More details can be retrieved, however, from the error dialog itself that shows up when the application falters. In my case, the following snippet is displayed (extras removed for brevity).

See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.InvalidProgramException: Common Language Runtime detected an invalid program.
   at InCycle.Tools.Forms.ImportProcessTemplateItem.ImportProcessTemplateItem_Load(Object sender, EventArgs e)
… (extra text removed …)
************** Loaded Assemblies **************
mscorlib    Assembly Version: 2.0.0.0    Win32 Version: 2.0.50727.3521 (NetFXspW7.050727-3500)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll

What is interesting here is the last line. Notice that the mscorlib.dll that my application is referencing comes from the Framework64 folder of the .NET 2.0 Framework.

The solution I found, after quite a bit of research and trial and error, is to force the extensions to specifically target x86. Doing so forces the OS to load the 32-bit framework assemblies at run time, even in a 64-bit OS.

Refer to the article How to: Optimize an Application for a Specific CPU Type on MSDN for specific details on how to change the Processor Architecture.

Read full post...

Sys is undefined when registering script via RegisterClientScriptBlock

Writing web applications using ASP.NET, most often than not, requires you to implement JavaScript code. If you are using AJAX and embed the script code as part of your page rendering you may run into the vague Sys is undefined error.

I have found that the error Sys is undefined is often caused when registering script using RegisterClientScriptBlock. The reason is that the AJAX Script Manager has yet to initialize. When using RegisterClientScriptBlock the script is placed immediately after the start of the form tag. In contrast, RegisterStartupScript places the script just before the closing form tag.

Therefore, the solution for this issue is to use RegisterStartupScript instead of RegisterClientScriptBlock.

Read full post...