vagmi's personal blog - Setup

Multi Platform versus Cross Platform

nospam@example.com (Vagmi) — Fri, 07 Oct 2005 16:34:27 +0200

I have lately been pondering over methods to deploy cross platform products. I investigated certain options like InstallShield's Universal Project and ZeroG's InstallAnywhere. But to tell the truth, it goes against the philosophy of installation. They rely on the presence of the right version of JRE. Some installations also package the native versions of JRE along with the installation package. This is quite an overhead. Other products use their custom homegrown installers. As most of the setup developers and administrators know, homegrown installers are a disaster waiting to happen. A good installation technology should do the following.

Continue reading "Multi Platform versus Cross Platform"

Anders Helsberg + Whiteboard + C# = really cool

nospam@example.com (Vagmi) — Wed, 27 Apr 2005 11:36:00 +0200

While I was browsing the MSDN, I came across this very interesting video which features Anders Helsberg and his skills with the whiteboard. I really wish that he teach me programming. A must see for every C# programmer.

Unit Testing MSI Packages... Maybe

nospam@example.com (Vagmi) — Thu, 17 Mar 2005 09:54:00 +0100

I was recently reading the article by Marting Fowler on Continuous Integration. Our team has set process to have daily builds of the MSI package along with the binary builds. It would have been an easier task with the WIX Toolset but most of our code still is in InstallShield DevStudio. We have used the InstallShield Standalone Build environment to build our MSI package as a batch job. We have various build machines to build different parts of the software and the Standalone Build environment helps us achieve this process without bleeding for separate licenses. As Marting Fowler had suggested, a successful build is just not a build without errors, it should be a workable output which clears some basic tests. I wondered if we could implement the Test First approach suggested by XP as a part of the MSI Build Process. The test first approach requires you to write self testing code which does some basic smoke tests. These are called unit tests or Build Verification Tests. I am sure that most developers include such code in their applications but I have not heard of such tests for Installation programs especially MSI packages.

I had blogged earlier on how the WIX Toolset can be used for distributed development. It is really cool that the WIX Toolset can avoid building merge modules, when they are not really required. But as we currently do not have much choice regarding this, we do build different projects as merge modules and later integrated them into the main project. Thus, technically our unit tests are integration tests.

A successful installation is not just an installation without errors. A successful installation should install the desired set of features and components. So, their states should be checked. This would involve parsing the verbose log file generated. The .NET Regular Expressions helps very well here <grin/>. We can check for the action return values and the feature and component installation states from the log file. Additionally, after installation, the files and registry entries on the target machine can be compared to the files and registry entries in the MSI package for the components that are marked installed. This can be done by comparing an uncompressed build or an administrative image with the files on the target machine. These criteria have a greater impact during upgrade than the first time installation.

I am just toying around with this idea and not really sure if it would be feasible for complex upgrade scenarios. I will post followups if I get anywhere with this. <smile/>

ATL RGS Woes

nospam@example.com (Vagmi) — Wed, 09 Mar 2005 20:25:00 +0100

I had been off the blogging world for quite some time now. I was so swamped with work that I really could not collect my mind to write anything worthwhile. I recently bumped into a really sticky issue (and continue to remain stuck with that). We have a VSIP enabled COM DLL that uses a lot of ATL RGS code. Some of these values in this RGS file were dependent on some environment variables. Also the path to the satillite DLL and some project items were authored in the RGS file. I tried harvesting registry entries out of the RGS file but there were far too many parameters to handle. And hence, I had to do the unthinkable ---- SELF REGISTRATION --- . But despite our attempts, surprise..surprise..But that did not work either.

I then remembered that the environment variables were also a part of my package. And ofcourse, the environment variables will not be effected until the installation finishes and hence the registration failed. Developers did not have the time to fix it so we had to do a really nasty workaround. We needed to have chained setup; one to setup the environment variables and other to actually install the package. This is okay at the current stage as the package is used by our internal customers who are all developers and have predictable machine configurations. However, this will be a catastrophe on an actual production environment.

I had posted in the MS Visual Studio extensibility newsgroups about other alternatives but was informed by Bob Arson that RGS file was the only way to go. However, some of Microsoft's VSIP deployment presentations demostrated authoring these registry entries using the registry view in the Visual Studio Installer project. A little bit of googling also revealed that we could use VsipRegPkg.exe to extract these registry entries for managed plugins. But ours is an unmanaged plugin :-(. Our developers claim that they have done the right thing as per Microsoft's recommendation and that they would not require the environment variables after they acquire the PLK. But even then, there is the dependency on the satillite DLL to be present in a particular location. I wish that the other Microsoft teams run their suggestions via the deployment groups. This would greatly benifit the overall quality of the product. I guess our developers need to watch MSDN TV. They almost say "Use Managed Code" on every show.

Breeds of Setup Engineers

nospam@example.com (Vagmi) — Thu, 06 Jan 2005 13:12:00 +0100

A little earlier, Chris had put this comment on my blog about Using The WIX Toolset for Distributed Development.

Firstly, I believe that Chris and I belong to different breeds of setup engineers. Chris uses tools like AdminStudio, DevStudio and Repackager to repackage setups and distribute them via SMS, Active Directory or other Change and Configuration management applications. This breed is often known as a packaging engineer. They have to often deal with hideous packages which move all sort of cryptic resources and perform changes on the system. Oh.. dont you hate repacking a setup while on a tight deadline when a custom configuration is performed on the target machine by the setup "script" which depends on the machine state/user input/configuration/location and data being moved?

I belong to a breed of setup engineers who are fortunate enough to design such hideous logic. We don't have to deal with black boxes of setup and try to figure out what is being installed. But we have a challenge of a different sort. We need to ensure that the setup runs without a problem on all configurations supported by the application itself. We are called Setup Developers. The setup developers have to take care of several criteria like the media size, privileges, future upgrades and design a fool proof system that is probably going to get upgraded and maintained for 3-4 years. And believe me, we do not have such a busy release schedule as InstallShield's. By the time we release a support package (which is usually a big patch), we forget what we put in the previous package. Hence we stay away from configuration specific tasks as far as possible. Maintaining such application/configuration data during the entire lifecycle of the product is quite a challenge.

Setup Developers are often found in packs. :-) Usually, more than one developer works on a setup package. My blog entry about using the WIX toolset for Distributed development is a real life scenario. So our efforts are that we create setups which can easily be deployed over a diaspora of machine configurations. If the setup fails then customer does not get a chance to find out the amazing bugs which the application developers put in to the product.

Configuration Data is such a Pain

nospam@example.com (Vagmi) — Wed, 29 Dec 2004 18:16:00 +0100

I have finally got my computer to my new house in Bangalore. I dont have access to the internet, so I will essentially by offline. I am yet to install SharpDevelop and .NET Framework SDK v1.1. Hopefully, I should be able to get it done today. I had some time today morning but I was too busy playing NFS Hot Pursuit 2 and Quake 3. (No real souls to frag. Only bots. )

Currently one of our installation packages does something that it should not be doing. It is handling configuration data for several applications. Clearly this created several issues during upgrades. Now, for the next schedule major release, we (the packaging team) decided that we would let the applications handle the configuration information. This was duly presented as a proposal to other "application development" teams in a meeting. The people were a little hot under the collar during the meeting. Other development groups suspected that we were doing this to brush off our responsibility. I am sure that other setup developers would also have faced such similar predicament.

I was recently browsing through the InstallShield Community forums and found that mosth setup developers were invariably including configuration data as a part of their installation. I even saw one post where a setup developer had used a VBScript custom action with the FileSystemObject and tried to replace certain place holder texts in the installed configuration file. I am sure that many of us, who have burnt their fingers with VBScript and FSO, would agree with me. Logically speaking, there is nothing wrong with this approach. But we have to realize that we are introducing a element that can go wrong. Having deferred VBScript custom actions with FSO is a lot of fun while debugging.

My recommended approach would be to have a small configurator utility, which would accept command line parameters and perform the same tasks. This serves two purposes.

The configuration data is effectively taken out of the MSI. You can avoid slicing and dicing the CustomActionData property to get the desired values. There is one element less in the project that can go wrong.
The user need not run the installation, if he has specified incorrect configuration. He has the option of configuring the software after installing it. While installing on locked down environments, the setup author has to ensure that the permissions table is authored such that the current user has no problems writing on the the specified resources. This should'nt be a problem for registry keys or folders as their permission tokens can always be altered by the installer.

Finally, Riko is back. It seems that he is going to submit his tallow source to the community. I can't wait to get my hands on it.

My 2 cents

nospam@example.com (Vagmi) — Thu, 23 Dec 2004 17:18:00 +0100

If people were following the the WIX-Users Mailing list, they would find that it has been a little hot recently. The first instance (as far as my knowledge goes) was with Michael creating a validation tool for the WIX Toolset called 'smoke'. I personally found it very useful as it could easily be included as a part of the build process. The output is in a structured XML format that makes it easier for us to crunch and build reports. But, some of the members in the group did not share the same level of enthusiasm. Michael seemed to be put off by that and included a disturbing update to his blog entry. Rob immediately acknowledged it and posted a blog entry about being thick skinned.

Recently, history repeated with Marc Bogers starting to ask about the ICE 33 warnings as Tallow populates the Registry table instead of the Registry Tables group. Firstly, Tallow is only a helper utility and is anything but perfect. It is useful but does not exactly produce usable WIX code. Heck, it doesn't even write to a file. Rob had said that ICE33 warnings can be ignored as it created some "strange behavior". More precisely, the resiliency associated with advertisement would prompt the end user for the media when Windows Installer detects some inconsistencies with the CLSID registration. Michael dismissed the argument that it arose from sloppy authoring and had nothing to do with MSI itself. Follow Michael's blog entry on COM registration for more information.

As we all know, Rob does not agree on a lot of things like inserting GUIDs while generating output with Tallow, using the Registry Tables Group and so on. I am sure that he has good reasons behind them. I am also sure that many people (including me), have modified Tallow to suit their requirements. Some people are using Riko's Tallow that does write to the Regsitry table's group using the Class and TypeLib elements. (On a totally different note, Riko, when are you going to release that code of yours?) I have a version of Tallow that creates components with GUIDs and names them appropriately. I am pretty sure that I am aware of the consequences and I have written code to persist the component information for future reference.

This freedom is the inherent beauty of open-source software. People can use their own ingenious imagination to tailor the tool to best suit their requirements. Of course, some of our opinions differ and we need a healthy debate to analyze these opinions and make the best of it. We should refrain from flaming and should try to embrace new ideas. Rob may be the BDFL for the WIX Toolset but I am sure that he would like the WIX Toolset to be successful and that helps developers create better installers without breaking much sweat. I tried hard not to write about this topic but after reading Michael's blog and comments with certain conspiracy theories, I wanted to voice my opinion too. I am sorry if I have hurt anybody's feelings.

Using an InstallScript application as the setup launcher

nospam@example.com (Vagmi) — Mon, 13 Dec 2004 18:16:00 +0100

This, I guess, is my first InstallShield specific post. MSI is good in a lot of things but not when dealing with more than one package in a single transaction. MSI engine is designed to be run as a single instance and cannot be used effectively to install more than one package. Nested installations are possible but often lead to undesired consequences. Having a setup chainer is good but it involves writing code and handling reboots. So, for all who are using InstallShield DevStudio and up can benefit by using the InstallScript project as their setup launcher and monitor. We can effectively "script" a launcher application and have complete control over the installation process using the available libraries.

Why InstallScript....? I would not usually recommend InstallScript for any of the custom actions in the project, as the MSI-Scripting bridge is a little weak and has certain limitations. However, InstallScript libraries would cut down most of the code that you would have to write with a brand new C++ application. Also the scripting engine supports the silent mode. So you do not have to code separately for that either. But on the flip side, you would have an overhead of 1 Meg for the InstallScript engine. But this is okay considering the fresh set of bugs that you would introduce with the first version of the launcher application. For those not concerned about silent mode, you can check out the free open source setup launcher (dotNetInstaller).

The trick here is to use the InstallScript's program....endprogram syntax instead of the event based model. This makes sure that you do not register the application and does not call unknown events in between. Good old block scripting. <smile/> This also means that you need to take care of exceptions. If you are a setup developer from the good old InstallShield Professional 5.x days, you would immediately be at home with this kind of approach. So a simple script to just display a message box would be as below.

#include "ifx.h" //The standard header
//Our program block starts here
program
MessageBox("Hello World!",INFORMATION);
endprogram

InstallScript engine just executes the statments present between the program and endprogram statements. As you can see, this approach gives you the flexibility of a complete scripting language with libraries custom made for creating installations. InstallScript projects are known for their flexibility but miss on the other aspects of MSI such as Elevated Privileges, Install on Demand, Source Resiliency and Self-healing.

Spying on Registry Entries

nospam@example.com (Vagmi) — Wed, 01 Dec 2004 21:21:00 +0100

I am probably letting out the best kept secret of installation industry. I always used to wonder and have now discovered how most of the installation tools spy on registry entries that are created during COM registration or similar processes without actually affecting the build system. The spying program creates temporary registry keys for each of the registry hives HKCR, HKLM, HKCU, HKU and it maps the registry hives to these temporary registry keys. It then triggers the registration function which creates registry entries withing the registry keys specified instead of including it in the hives. I came across this revelation while I was wading through the source code for Tallow in the WIX toolset.

The core of this spying exercise relies on functions exposed by the advapi32.dll. The actual hive to key mapping is performed by the RegOverridePredefKey() function. The handle to the registry key is passed by using the RegCreateKeyEx() or the RegOpenKeyEx() function. After the mapping is done, you can invoke the DllRegisterServer() function after loading the library using the LoadLibrary() function. This mapping would be active for all the registry entries created by that particular process. So out of process registration for exe files may not directly work with this method. For the sake of simplicity, I am going to extract COM Interop settings from a given assembly. So let us write a simple console app in C# to do this. This app would perform the mapping and write the registry entries to a REG file and wipe out the key after the file is written.

Extracting registration information from a DLL file is similar but involve the importing other functions from Kernel32.dll. So I am giving that a raincheck now. You can download the Wix toolset's source package if you are interested. To start off with, let us write a class with static members to import the functions from advapi32.dll and create wrappers for them. Ensure that you have System.Runtime.InteropServices namespace included.

    class OverRideRegistry
    {
        //We first declare some stuff required. The are defined in winreg.h and windows.h        publicstaticreadonly UIntPtr HkeyClassesRoot = (UIntPtr)0x80000000;
        publicstaticreadonly UIntPtr HkeyCurrentUser = (UIntPtr)0x80000001;
        publicstaticreadonly UIntPtr HkeyLocalMachine = (UIntPtr)0x80000002;
        publicstaticreadonly UIntPtr HkeyUsers = (UIntPtr)0x80000003;

        publicconstuint Delete = 0x00010000;
        publicconstuint ReadOnly = 0x00020000;
        publicconstuint WriteDac = 0x00040000;
        publicconstuint WriteOwner = 0x00080000;
        publicconstuint Synchronize = 0x00100000;
        publicconstuint StandardRightsRequired = 0x000F0000;
        publicconstuint StandardRightsAll = 0x001F0000;

        publicconstuint GenericRead = 0x80000000;
        publicconstuint GenericWrite = 0x40000000;
        publicconstuint GenericExecute = 0x20000000;
        publicconstuint GenericAll = 0x10000000;

        #region The Interop Import Stuff
        //we now import the functions exposed by advapi32.dll        //Use RegCreateKeyEx to get handle to the openedKey        [DllImport("advapi32.dll", EntryPoint="RegCreateKeyExW", CharSet=CharSet.Unicode, ExactSpelling=true, SetLastError=true)]
        internalstaticexternint RegCreateKey(UIntPtr key, string subkey, uint reserved, string className, uint options, uint desiredSam, uint securityAttributes, out IntPtr openedKey, outuint disposition);

        //This does the actual hive to key mapping        [DllImport("advapi32.dll", EntryPoint="RegOverridePredefKey", CharSet=CharSet.Unicode, ExactSpelling=true, SetLastError=true)]
        internalstaticexternint RegOverridePredefKey(UIntPtr key, IntPtr newKey);

        //Like good programmers, we release our handles.        [DllImport("advapi32.dll", EntryPoint="RegCloseKey", CharSet=CharSet.Unicode, ExactSpelling=true, SetLastError=true)]
        internalstaticexternint RegCloseKey(IntPtr key);
        //Our interops are done :-)        #endregion
        //Now we actually write wrapper functions to use the imported functions        //Wrapper for creating Registry Keys        internalstatic IntPtr OpenRegistryKey(UIntPtr key, string path)
        {
            IntPtr newKey = IntPtr.Zero;
            uint disposition = 0;
            uint security = StandardRightsAll | GenericRead | GenericWrite | GenericExecute | GenericAll;
            int error = RegCreateKey(key, path, 0, null, 0, security, 0, out newKey, out disposition);
            return newKey;
        }
        //Wrapper for the mapping        internalstaticvoid OverrideRegistryKey(UIntPtr key, IntPtr newKey)
        {
            int error = RegOverridePredefKey(key, newKey);
        }
        //Wrapper for freeing the handle        internalstaticvoid CloseRegistryKey(IntPtr key)
        {
            int error = RegCloseKey(key);
        }
    }

Now that we have the helper class with the static methods, we can define our main Console App class, which would use the functions in the helper class to register the assembly and steal the registry entries. Let us define the functions that Map and Map the registry hives. I had initialized the RegLocation to a string "Software\\Vagmi\\RegInterop\\". So the extracted registry entries would be put in the HKLM hive within the specified path. Also not that I have mapped HKLM as the final mapping. Else all keys that are subsequently created would be created within our registry key.

        void MapRegHives()
        {
            MapRegHive(OverRideRegistry.HkeyClassesRoot,this.RegLocation+"HKCR");
            MapRegHive(OverRideRegistry.HkeyCurrentUser,this.RegLocation+"HKCU");
            MapRegHive(OverRideRegistry.HkeyUsers,this.RegLocation+"HKU");
            MapRegHive(OverRideRegistry.HkeyLocalMachine,this.RegLocation+"HKLM");
        }
        void MapRegHive(UIntPtr key, string location)
        {
            Console.WriteLine("Mapping " + key + " to " + location);
            IntPtr createdKey=IntPtr.Zero;
            try            {
                createdKey=OverRideRegistry.OpenRegistryKey(OverRideRegistry.HkeyLocalMachine,location);
                OverRideRegistry.OverrideRegistryKey(key,createdKey);
            }
            catch(Exception e)
            {
                Console.WriteLine("Caught exception: " + e.Message);
            }
            finally            {
                //close key like responsible programmers                OverRideRegistry.CloseRegistryKey(createdKey);
            }
        }
        //Functions to unmap registry hives.        void UnMapRegHives()
        {
            OverRideRegistry.OverrideRegistryKey(OverRideRegistry.HkeyClassesRoot,IntPtr.Zero);
            OverRideRegistry.OverrideRegistryKey(OverRideRegistry.HkeyCurrentUser,IntPtr.Zero);
            OverRideRegistry.OverrideRegistryKey(OverRideRegistry.HkeyLocalMachine,IntPtr.Zero);
            OverRideRegistry.OverrideRegistryKey(OverRideRegistry.HkeyUsers,IntPtr.Zero);
        }

I then parse two command line arguments one for the DLL and another for the REG file to export. I then pass these as constructors to my class, which calls these functions.

        public RegSpyCOMInterop(string AssemblyPath, string RegFile)
        {
            try            {
                Assembly a=Assembly.LoadFrom(AssemblyPath);
                RegistrationServices regServices=new RegistrationServices();
                //map hives to registry keys                    MapRegHives();
                    //Register assembly for COM interop                    regServices.RegisterAssembly(a,AssemblyRegistrationFlags.SetCodeBase);
                    //Unmap hives                    UnMapRegHives();
                WriteToRegFile(RegFile);
            }
            catch(Exception e)
            {
                Console.WriteLine("Caught Exception : " + e.Message);
            }
        }

The WriteToRegFile() function launches regedit and exports the hive that contains our keys. It then uses simple text replacement to change the values of the exported file to make the REG file functional.

        publicvoid WriteToRegFile(string regfile)
        {
            RegistryKey r=Registry.LocalMachine.OpenSubKey(RegLocation,false);
            PathToDelete=r.Name + "\\";
            Process pr=new Process();
            pr.StartInfo.FileName="regedit";
            pr.StartInfo.Arguments=" /e " + regfile + " " + r.Name;
            pr.Start();
            pr.WaitForExit();
            string line;
            StreamReader reader=new StreamReader(regfile);
            StreamWriter writer=new StreamWriter("TempFile.txt");
            while((line=reader.ReadLine())!=null)
            {
                writer.WriteLine(processRegistryName(line));
            }
            reader.Close();
            writer.Close();
            File.Copy("TempFile.txt",regfile,true);
            File.Delete("TempFile.txt");
            r.Flush();
            r.Close();
        }

        public String processRegistryName(string regname)
        {
            string newRegName="";
            newRegName=regname.Replace(PathToDelete,"");
            newRegName=newRegName.Replace("[" + PathToDelete.Substring(0,PathToDelete.Length-1) + "]","");
            newRegName=newRegName.Replace("HKCR","HKEY_CLASS_ROOT");
            newRegName=newRegName.Replace("HKCU","HKEY_CURRENT_USER");
            newRegName=newRegName.Replace("HKLM","HKEY_LOCAL_MACHINE");
            newRegName=newRegName.Replace("HKU","HKEY_USERS");
            return newRegName;
        }

There you have it. A command line utility to extract COM Interop Registry entries. Hope this answered some of your queries regarding registration without affecting the target system. You can find the entire source code at http://www.geekswithblogs.net/vagmi.mudumbai/articles/16581.aspx.

Microsoft's Whitepaper on Patch Sequencing

nospam@example.com (Vagmi) — Wed, 24 Nov 2004 11:54:00 +0100

While browsing, I came across this excellent whitepaper on MSI 3.0 Patch Sequencing.

http://www.microsoft.com/downloads/details.aspx?FamilyId=AD7AC91E-2493-4549-AE6F-BF5E007C12A3&displaylang=en