I agree, it does seem to be an MSI thing rather than a Fusion thing here. IAssemblyCache is documented - there's IAssemblyCache:InstallAssembly and IAssemblyCache:UninstallAssembly, and there seems to be no obvious reason why InstallAssembly can't be called when MSI installs the other files, and UninstallAssembly if it rolls back later, the same as for files in a normal file system. That assumes of course that these are the APIs that are used. There's nothing about those interfaces that is two-phase.
The documentation saying that the implementation is for rollback of unsuccessful installations seems completely irrelevant because the darn assembly is never in the GAC in the first place as far as any of us can tell. There might be some internal sense in which an assembly is somehow "in the GAC", but the issue we're describing here doesn't involve any rollback at all because they are never there to get rolled back! Not knowing the inside story here, my guess is that there's something nasty about UninstallAssembly and restoring the GAC state that would not work during the kind of rollback that would be necessary. As a result, InstallAssembly isn't called until InstallFinalize/Commit, so in fact there is never really an installer rollback of an assembly installed in the GAC. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Thursday, November 15, 2007 4:23 AM To: Rob Mensching; Adam Majer Cc: WiX Users Subject: Re: [WiX-users] Services + Vista + GAC Why not blame MSI? Sure they are dependant on Fusion, but why did they make the choice to wait to the commit phase to call fusion? The stated reason is to provide rollback capabilities but the problem I have with that is GAC is SN ... while rollback is nice to have, the risk of system instability should be next to none due to the very nature of GAC/SN. So I have an extra assembly in storage or I have an assembly with a higher AssemblyFileVersion. That should not be the end of the world but if they are still worried about it, they really, really should have found some way to be true to the transacted nature and execution phases so that this type of problem was mitigated. And adding the CRT as a static link for C++ developers only solves some problems. It wouldn't solve my problems. I work .NET SOA SaaS installs and without getting into all the details I have about a dozen application framework blocks that have to be deployed to the GAC for consumption across WebUI, WebServices ( 80+ ) and WindowsServices. The ASP.NET is fine because the assemblies won't be needed until the sites are accessed and the content JIT'd. But the WindowsServices need the files ( it's basically a client that consumes the web services ) The customer pays the bills and they say 1) don't copy the assemblies local 2) start the service right away 3) avoid a reboot. So while I could argue to change the code to break the dependency on the GAC, it ain't going to be happening. Rob Mensching <[EMAIL PROTECTED]> wrote: 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. 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. 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 > > > > 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 ________________________________________ Never miss a thing. Make Yahoo your homepage. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
