I don't know where to reply to this thread so I thought I'd just start here.
Personally, in the list of all the technologies to blame, I blame Fusion. <smile/> Fusion is the technology under the GAC (Fusion is actually a code name for a few things but the GAC is very much Fusion's fault) and due to some (IMHO) really brain dead design decisions they created a system that doesn't interact really well with existing installation technologies. Then the C++ team did another brain dead thing (IMHO) and took a dependency on Fusion and made the C Run Time (CRT) Win32 SxS DLLs. Now we have deep, low-level, core functionality that pretty much everyone on the planet (that writes C++) needs dependent on a high level, poorly designed, data store (aka: GAC). The easiest way out of the mess and the one that I always recommend is to statically link the CRT. There are downsides (your executable is bigger for example) but your install gets so amazingly more simple that I personally can't imagine making the trade off the other way. For example, you'll notice all of the WiX custom actions statically link to the CRT so your install has no dependencies on the GAC (which are actually impossible to satisfy in the middle of an install). PS: Has anyone ever noticed how many custom actions the CRT merge modules pull in? Terrifying amounts of code to do something that should have remained simple, copy the CRT with your application. And to think, people use to argue that the GAC was going to make installation easier. <smile/> Adam Majer wrote: > Richard wrote: > >> The problem isn't anything to do with Vista, its because your service >> has a dependency on something in the GAC and the files don't really >> appear in the GAC until after the Commit phase of the install. >> >> Just mark your service as starting automaticly and you shouldn't have >> any problem. Then Windows will start the service when its needed. >> Why do you think that you must start your service before the install >> finishes? >> > > First a general comment - thanks for all the replies! > > Regarding the service now, I think the problem has a lot to do with the > installation of stuff into the GAC (the recommended way of doing things > after all). All that the service needs is the C runtime, nothing special > here. But that is not available. > > Now, wix has > > <ServiceControl .... start="install"/> > > so, why have that? Coincidently, it works on *every* release of windows, > but not Vista because of Vista's new way of handing assemblies. > Therefore the bug is either in WiX, Windows Installer or Vista. By my > understanding of how things work, GAC > refresh/update/install/committing/whatever you want to call it, should > just be an API call within Windows Installer so the installation > sequence can be, > > > .. install stuff (including to GAC) > .. refresh GAC -- maybe this could be a custom step that doesn't run > unless needed, like when starting services before installation is done. > .. start services. > > Then if start services fails, you roll back by uninstalling the stuff > from the GAC, (refreshing it again, if you have done it before) and > rolling back the rest of the installation. > > > Finally, the application here is installed as a service because it is > not a user intractable application and it is the easiest way of doing > things. But yes, there may be another way of running it... messy, but > possible. But for general case, does windows have triggers that allow a > service to be started automatically when someone tried to connect to UDP > port 123 (example) or a named pipe? If yes, then I guess > ServiceControl's start attribute can be removed? > > - Adam > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
