Problems Unzipping and Re-zipping an XAP file during installation to Modify a Config File


  •  I have an interesting dilemma to which, I hope, someone may have an answer. My company has a very complex web application which we deliver to our clients via an InstallShield multi-instance installer package. The application is Written in ASP.NET MVC3 (using the Web Forms View Engine), C# 4.0, and Silverlight. It is the Silverlight component of the app with which we are having problems during installation.

    Many of our clients wish to install our web app in what we refer to as “mixed-binding mode”. This may not be the correct terminology. What I mean to say is that the client will install the web app on a web server that is internal to the client’s firewalls and expose it to the web via a proxy server in the DMZ. In this way, everything internal to the firewall will resolve as HTTP, while every external request will resolve as HTTPS.

    This does not pose a problem to most of the web application during installation because it will be running inside the firewall and will ALWAYS be HTTP when the app is installed in “mixed-binding mode”. This is not the case with the Silverlight component. Because it runs in the end-user’s browser process space, it is external to the proxy and firewall and must resolve via HTTPS.

    The Silverlight files are in the XAP file. Within the XAP file, we have a configuration file (in XML format) that must be modified based on the binding mode of the web application (HTTP, HTTPS, or MIXED). As we all know, XAP files are simply Zip files, so theoretically all that is needed to edit a file contained in the XAP is to rename it from “*.xap” to “*.zip” and use any zip compatible utility or library component to extract the configuration file, edit it by some manual or automatic means, and then use the same zip component to re-archive the modified file back into the XAP file.

    “Therein lies the rub!” This must take place automatically within the InstallShield Basic MSI process. At first we tried using an Install Managed Code Custom Action using the DotNetZip library; however, DotNetZip seems to have an incompatibility with InstallShield. Every time InstallShield launched the Custom action, the installed would throw a InstallShield 1603 error the moment the custom action tried to execute the first DotNetZip command. (Yes we did rename the XAP file from “*.xap” to “*.zip” prior to trying to unzip the file.) We encountered the same problem with SharpZipLib.

    Next, we dropped down to a lower level algorithm using the Shell32 library. We knew there would be timing considerations to take into account using this method since Shell32 processes run in a separate thread so we built wait states into the process, as shown below:

    //Extract the config file from the .zip archive
    Shell32.Shell shell = new Shell32.Shell();
    string extractedFolderPath = tempZipFileName.Substring(0, 
        tempZipFileName.Length - 4) + "\\";
    if (Directory.Exists(extractedFolderPath))
        Directory.Delete(extractedFolderPath, true);
    //Folder name will have the file extension removed.
    Shell32.Folder output = 
    Shell32.Folder input = shell.NameSpace(tempZipFileName);
    foreach (FolderItem F in input.Items())
        string name = F.Name;
        //We only extract the config file
        if (name.Equals(CFG_FILE)) 
            output.MoveHere(F, 4);
    //You have to sleep some time here, 
    //  because the shell32 runs in a separate thread. 

    This seemed to work the “majority” of the time.

    NOTE: the use of the word “majority” above. The process works inconsistently on a fast server, whereas it works consistently on a slower machine. Don’t ask me why, my math professors always taught me that a second is a second (in this Universe at least).

    We have even tried this with a PowerShell script. In this case, we are able to extract the configuration file and rename it in the target folder to which it was extracted; however, everything we have tried to do copy the renamed file back to the ZIP archive has failed. This is very unusual since we added a second call to push the target folder and all its children into the Zip archive and that works just fine (See the code reference below)!

    $shell=new-object -com shell.application
    #Establish Current Location as Current Location
    #Determine the path of the $CurrentLocation
    #Create a namespace using the $CurrentPath
    #Rename the XAP File to a ZIP file for extraction
    #  will work.
    Get-ChildItem *.xap|Rename-Item -NewName {
        $_.Name -replace "xap","zip"
    #Create a ChildItem object using the ZIP file.
    $ZipFile = get-childitem
    #Insure the ZIP File is not readonly
    (dir $ZipFile).IsReadOnly = $false
    #Create a shell namespace for the ZIP Folder within the ZIP File.
    $ZipFolder = $shell.namespace($ZipFile.fullname)
    #Iterate through the ZIP Items in the ZIP Folder
    foreach ($CurFile in $ZipFolder.items())
        if ($ -eq "ServiceReferences.ClientConfig")
            #Current item's name matches the file we want to extract,
            #  so copy it from the ZIP Folder to the Current $Location.
            #Wait briefly to insure process stays in sync
            Start-sleep -milliseconds 1000
            #Change the extention to the extracted file,
            #  so we can tell it from the original when we
            #  insert it back to the ZIP Folder.
            Get-ChildItem *.ClientConfig|Rename-Item -NewName {
                $_.Name -replace "ClientConfig","ClientConfig_Test"
            #Create an object containing the extracted file.
            $ClientConfigFile = get-childitem ServiceReferences.ClientConfig_Test
            #Wait briefly to insure process stays in sync
            Start-sleep -milliseconds 2000
            #No need to search further
    #For some reason this WILL not copy the renamed file back 
    #  into the ZipFolder, even though it should (see below)!
    #For some reason copying the entire current directory 
    #  works just fine! Go figure!
    #I hoped this would work, but it doesn't????
    write-output "renaming to the original extension"
    #Rename ZIP file back to a XAP file,
    #  so Silverlight can use it.
    Get-ChildItem *.zip|Rename-Item -NewName {
        $_.Name -replace "zip","xap"

    This shouldn’t be this hard to do. Somebody has to have done something like this before! I mean any complex web installation is going to need an automated install process and is going to have to be eventually installed using proxies and DMZ’s.

    Any assistance would be appreciated. Here are the specifications we must follow:

    1. Use InstallShield Basic MSI as the installer.
    2. Any InstallShield Custom Action must be written in C#.
    3. The XAP file must be modified after the file has been copied to the server by the installer.
    4. Management wants me to stay away from BSD and GNU "free-ware" like Info-Zip, 7Zip, et. al.

    Ken Jinks

    Senior Web Developer

    Sungard Omni Wealth Services

    Birmingham AL

    • تم التحرير بواسطة jinkskgpt 18/رجب/1433 02:24 م Severe Error
    • تم النقل بواسطة Bob Wu-MT 21/رجب/1433 09:39 ص (From:ClickOnce and Setup & Deployment Projects)
    18/رجب/1433 02:13 م

جميع الردود

  • Hi Ken,

    I'm sorry that InstallShield is a third party product which is not supported by the MSDN forums. If you have any question about InstallShield, you can get help in the official InstallShield Forums.

    Sorry for any inconvenience this may cause.

    Best Regards,

    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us

    • تم التحرير بواسطة Bob Wu-MT 21/رجب/1433 09:39 ص
    • تم الاقتراح كإجابة بواسطة Mr. WhartyModerator 22/رجب/1433 12:46 ص
    • تم إلغاء اقتراح كإجابة بواسطة jinkskgpt 22/رجب/1433 05:24 ص
    21/رجب/1433 09:38 ص
  • The incompatibility is between MSI and DotNetZip. I only mentioned InstallShield because I use it as a MSI editor. Please read the post next time rather than jumping to conclusion just because you see a non-ms product mentioned. I asked the question looking for a work around the problem in the Windows Installer MSI WHICH IS A MICROSOFT PRODUCT!

    Ken Jinks Senior Software Development Consultant Software Engineering Enterprises Decatur AL

    22/رجب/1433 05:31 ص
  • Hi Ken,

    The error 1603 is a general Windows Installer engine error. I'm sorry that I said this is a InstallShield issue.

    However, it can be caused by InstallShield or DotNetZip. The flexerasoftware mentioned that some suggestions on this error, see

    Besides, the ClickOnce and Setup & Deployment Projects support Setup Project which builds an installer for a Windows-based application, so I think the ClickOnce and Setup & Deployment Projects forum is not the appropriate forum as your are writing a ASP.NET web application.

    Best Regards,

    Bob Wu [MSFT]
    MSDN Community Support | Feedback to us

    24/رجب/1433 09:41 ص