I had a similar situation as well. I used Microsoft's Bootstrap generator app to create bootstrapper from my installer. But it changed the case to all lower-case, even though the HomeSite URL still had the mixed case format. When this was installed to a *nix-based web server (not sure what the client was using specifically) where case is significant, it kept responding with File Not Found.
Very annoying :) A. -----Original Message----- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: November-18-09 5:34 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Private Assemblies? This sounds like what I guessed in my previous emails, that you were in the weeds trying to figure out what was "wrong" with the install when the real problem is found by debugging and profiling the application. I run a team of several install guys that support around 200 developers and I've learned to have a very disbelieving attitude when people come in and say the install is broken. For example, InstallShield has an annoyance where if you drag a folder into the files and folder view it'll jack with the case of the folder. It's usually harmless but one day a developer came to me and said the install was broken because the case of a directory being deployed was incorrect and that it was causing the application to not work. I just simply told the developer that windows is case sensitive but not case aware and that he should thank me for finding a bug in HIS code. He never did come back again to ask for me to fix the case of the directory. So I'd fix the application not the shortcut in the install. Then again, I also wonder why there is a command line argument for a config file when .NET already has a well established App.Config pattern. --- On Tue, 11/17/09, JKLists <jkli...@ifm-services.com> wrote: > From: JKLists <jkli...@ifm-services.com> > Subject: Re: [WiX-users] Private Assemblies? > To: "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> > Date: Tuesday, November 17, 2009, 6:48 PM > > > Would you mind to share that? Don't want to mock you > (if it was your fault), but it might be helpful for the > archives and the next one that searches for similar terms.. > > > > Oh, no, I don't mind. As I said before, I never thought WiX > was broken, > and I fully admit my ignorance since I'm new to WiX and > MSI. Just > because I'm a seasoned software engineer doesn't imply that > a new tool > set won't cause me to publicly humiliate myself from time > to time. *grin* > > > The Short Answer: > > I learned as a MSI/WiX noob is the power of disassembling > the MSI files > when trying to replicate and improve an existing installer > produced with > InstallShield. It's useful to see what MSI is being told to > do. That may > have saved a lot of heartburn had I done that earlier in > the process. > > The problem ultimately was an obscure bug in the > application (surprise, > surprise). It was the way I was using WiX (adhering to > standard good > software engineering practices) that revealed the bug. > > > The Long Answer: > > For the record, here are the gory details of the process I > went through, > in case somebody in the future has similar troubles. > > This is a very complicated piece of software with scores of > assemblies > (including a number of wrappers around unmanaged plain and > COM DLLs), so > the likelihood of messing something up shouldn't be > discounted. Heat did > it a great job doing the heavy lifting, getting me 80% of > the way there. > I ended up having to retouch the XML on each of the > entries, and I broke > the massive output into manageable fragments. > > The initial symptoms were: > 1) The application was crashing very, very early in the > initialization > stage. > 2) Installing debug-enabled binaries produced only one > diagnostic > message, essentially "I'm starting". > > "Obvious" Conclusion: > > Something different between the two MSIs was triggering the > crash. > > > > I've seen goofy stuff like that before when Windows found > something > basic but critical out of place. Based on that past > experience, I > started going through a process of elimination to determine > what was out > of place and was causing the crash. > > There were some great hints for how to diagnose the > problem, many of > which I had already done. For example, Christopher > suggested maybe .NET > wasn't installed. Andreas suggested to check that all of > the files were > actually installed, and in the correct locations. Those > were the first > things I checked. > > After diffing the directories and files, I diffed the > registry changes. > The main thing that stood out was the private assemblies > section that > InstallShield produced, but not WiX. This was my wrong > turn. I wrestled > with what those registries meant for a while, and when > stumped posted my > question yesterday. > > What got me back on track this morning was when I saw that > I could just > copy the installed directories to a clean machine. I > decided that the > registry hunt was the wrong path. Bob's suggestion to use > dark to > decompile the two MSIs was timely. > > Dark's output of the two MSIs allowed me to see the > intimate details of > the InstallShield advertised shortcuts. In the Arguments > attribute, I > used the [foo] syntax to build an absolute path to a > configuration file, > while InstallShield provided a hard-coded relative path. > > Specifically, in one fragment I declare the directory > structure, which > includes a subdirectory with an Id of the form > dirFooConfigs. In another > fragment I declare shortcuts. In the <Shortcut> tag I > included arguments > of the form > > Arguments=""[dirFooConfigs]$(var.fooConfigFile)"" > > to produce a full path to the file surrounded by quotes due > to the > spaces in directory names. > > The application, it turns out, has a fatal bug that barfs > horribly on > the absolute path that I told WiX to build. It is well > formed and > correct. However, in the thousands of man-hours developing > the software, > nobody ever tried feeding the application a reference to > the config file > in that exact way... that never happens, right? > > So, I was right that /WiX itself was never the problem/. I > did run down > the wrong path based on diffing the registry, combined with > my ignorance > of what I was seeing in the registry produced by > InstallShield. > > Again, in summary, the main lesson I learned as a MSI/WiX > noob is the > power of disassembling the MSI files to look at things as > MSI sees them. > > I hope that somebody finds that useful in the future. > > > > ---------------------------------------------------------------------------- -- > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
