Re: [WiX-users] Services + Vista + GAC
How does WiX handle the deletion of the user if rollback is disabled by policy? Rob Mensching [EMAIL PROTECTED] wrote: On the MSI 4.5 aspect I would caution you to not get your hopes up. I haven't looked at the final details but I thought on one pass through the Beta I saw that all commits by MSI are not done until the whole multi-package transaction is committed. This makes a lot of sense if you consider the things done during the MSI commit as things that cannot be rolled back. For example, WiX uses commit transactions to delete users. If those were committed in the middle of a multi-package transaction that was then canceled, we'd be screwed because there is no way to bring a user back (with the same SID anyway). János Brezniczky wrote: Sure, MSI should have the ability to combine complete MSI installation packages as phases of the installation, together with the transactional behaviour (including savepoints on the registry..)... is this something related to staged installation Windows Installer 4.5? Otherwise there might be several reasons for the lack of this feature, I know... would this have effects on security which make it better to forget about the whole misery? perhaps backward compatibility makes it impossible? or too much ado for something that can be avoided with hacks? - Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Services + Vista + GAC
Sure, MSI should have the ability to combine complete MSI installation packages as phases of the installation, together with the transactional behaviour (including savepoints on the registry..)... is this something related to staged installation Windows Installer 4.5? Otherwise there might be several reasons for the lack of this feature, I know... would this have effects on security which make it better to forget about the whole misery? perhaps backward compatibility makes it impossible? or too much ado for something that can be avoided with hacks? 2007/11/15, Christopher Painter [EMAIL PROTECTED]: 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 http://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) ..
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
Re: [WiX-users] Services + Vista + GAC
That's actually a very good question and I've not tested this scenario in MSI 4.5.Right now I can create a redist prereq and chain it in my bootstrapper before my install so that the assemblies are already in the GAC. In MSI 4.5, if I have Package 1 with component A that deploys to the gac and Package 2 with component B that consumes the assembly deployed by component A when the service starts. will the assembly be available or will the overall transaction not commit the assembly to the GAC and the problem remains? János Brezniczky [EMAIL PROTECTED] wrote: Sure, MSI should have the ability to combine complete MSI installation packages as phases of the installation, together with the transactional behaviour (including savepoints on the registry..)... is this something related to staged installation Windows Installer 4.5? Otherwise there might be several reasons for the lack of this feature, I know... would this have effects on security which make it better to forget about the whole misery? perhaps backward compatibility makes it impossible? or too much ado for something that can be avoided with hacks? 2007/11/15, Christopher Painter [EMAIL PROTECTED]: 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
Re: [WiX-users] Services + Vista + GAC
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
Re: [WiX-users] Services + Vista + GAC
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? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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
Re: [WiX-users] Services + Vista + GAC
Talk about to the tail wagging the dog.Customer requirements should dictate installation behavior, not the installation technology being used. There are a number of ways to work around this limitation of MSI. Some involve code changes to the service exe and some require using alternative methods to publish the assembly and/or start the service. But to imply that MSI is perfect ( works as contructed is the term Microsofties like to use ) and that the requirement must therefore be void reminds me of the side of MSI that I really don't like. Richard [EMAIL PROTECTED] 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? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download Legalize Adulthood! - 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: 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
Re: [WiX-users] Services + Vista + GAC
Wouldn't a true solution be writing a chainer (bootstrapper)? Otherwise I agree with Christopher: these why do you think answers are implications of something that lies in the philosophy and the state of art - if the developer is assigned to preparing the installation, the developer thinks like a coder, and is going to assume that he can do everything with a development environment, be it the WiX or anything else. So tries to code free... and will come up with tons of questions seeming to be obvious, but hard to answer. And tons of people (the developers, I mean) will have to learn WiX from the starts, thus preventing the more complex, constructive questions from appearing on the list. The only escape from this trap - I think - can be better organized and more comprehensive documentations on the subject... there is a need for improved/new tutorials, books etc.. But we still have to wait for these to appear AFAIK. 2007/11/14, Christopher Painter [EMAIL PROTECTED]: Talk about to the tail wagging the dog.Customer requirements should dictate installation behavior, not the installation technology being used. There are a number of ways to work around this limitation of MSI. Some involve code changes to the service exe and some require using alternative methods to publish the assembly and/or start the service. But to imply that MSI is perfect ( works as contructed is the term Microsofties like to use ) and that the requirement must therefore be void reminds me of the side of MSI that I really don't like. *Richard [EMAIL PROTECTED]* 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? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download Legalize Adulthood! - 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.http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs - 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
Re: [WiX-users] Services + Vista + GAC
Just mark your service as starting automaticly and you shouldn't have any problem. Then Windows will start the service when its needed. How does Windows know when the service needs to be started (other than boot time)? - 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
Re: [WiX-users] Services + Vista + GAC
Another solution that was suggested here was to use a deferred custom action to start the service. But that also doesn't seem to work. Using WiX 2.x branch and it results in a runtime error. The custom action works OK if run outside of the MSI. The error returned is Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. Currently I have it as, Binary Id=blah SourceFile=/ CustomAction Id=blah_ca ExeCommand= BinaryKey=blah Execute=deferred Impersonate=no Return=ignore / InstallExecuteSequence Custom Action=blah_ca OnExit=success / /InstallExecuteSequence Any ideas? I could be wrong but, I think your problem is that you're trying to use a binary that's embedded in the msi and this is only available between InstallInitialize and InstallFinalize. After InstallFinalize, all the temporary bits of your msi have been cleaned up. To run a custom action as late as you need, it has to be something you install or something already on the system. - 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
Re: [WiX-users] Services + Vista + GAC
In article [EMAIL PROTECTED], =?ISO-8859-1?Q?J=E1nos_Brezniczky?= [EMAIL PROTECTED] writes: these why do you think answers are They're not answers, they're questions. Over and over and over again, I see people asking how do I do task X? without ever stating the goal. Many times X is the wrong task to achieve the goal. Generally services don't need to be started after the install is complete if they are set to start automatically. So you can avoid the whole issue of how do I get my service to start? if its created in such a way that it will start when needed anyway. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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
Re: [WiX-users] Services + Vista + GAC
But it is possible to start services using MSI / WiX. I know. My installation does (I'm assuming it works for me because while the service is a .NET one, it is not installed in or dependent on the GAC). I guess what I'm trying to say is that there is merit to the ServiceControl element. Unfortunately, it doesn't apply equally for all choices of runtime environment. :-( Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of János Brezniczky Sent: Wednesday, November 14, 2007 10:09 AM To: Richard Cc: WiX Users Subject: Re: [WiX-users] Services + Vista + GAC Well, then what do you think, why is there a ServiceControl element with start on install functionality? Should not it be completely removed to prevent people from thinking that they can accomplish it with MSI/WiX? It seems to me like people just simply need more than the current features. [Remainder of message trimmed] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - 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
Re: [WiX-users] Services + Vista + GAC
I agree the probing for the real goal instead of anwering the exact question is a good thing, but when someone replies with the `why do you think` tone, it is clear that the presumption is that they already know the requirement and have voided it. It's not a good way of starting a good dialog and coming to a proper resolution of the real problem. To me that is one of the biggest traps in becoming married to MSI. Richard [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], =?ISO-8859-1?Q?J=E1nos_Brezniczky?= writes: these why do you think answers are They're not answers, they're questions. Over and over and over again, I see people asking how do I do task X? without ever stating the goal. Many times X is the wrong task to achieve the goal. Generally services don't need to be started after the install is complete if they are set to start automatically. So you can avoid the whole issue of how do I get my service to start? if its created in such a way that it will start when needed anyway. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download Legalize Adulthood! - 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 - Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.- 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
Re: [WiX-users] Services + Vista + GAC
If this really is the C runtime then it's not going into the GAC (are you using the merge modules?) but it is being committed to the SxS directory at InstallFinalize (on Vista) so the effect is the same as if you had a managed code service dependent on assemblies being installed into the GAC. If it is the C runtime case and you have a C++ service your choices are to start the service with a custom action after InstallFinalize or to build the C++ with static link to the required runtime libraries. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Tuesday, November 13, 2007 8:07 PM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Services + Vista + GAC Hi, I have a service I want to install and automatically start with an installer. Now, the runtime for the service is not available until after installer completed because the runtime goes into the GAC (it is just the VS2005 SP1 C runtime). One solution is to deploy the files locally (as in a per-user install), but that doesn't work because the service uses a plugin that is in a subdirectory of the installation. The location of the plugin is not easy to change. Another solution that was suggested here was to use a deferred custom action to start the service. But that also doesn't seem to work. Using WiX 2.x branch and it results in a runtime error. The custom action works OK if run outside of the MSI. The error returned is Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. Currently I have it as, Binary Id=blah SourceFile=/ CustomAction Id=blah_ca ExeCommand= BinaryKey=blah Execute=deferred Impersonate=no Return=ignore / InstallExecuteSequence Custom Action=blah_ca OnExit=success / /InstallExecuteSequence Any ideas? This problem will definitely keep surfacing regarding Vista and services. Is there something being done either in the Windows Installer or WiX to address this issue and allow services to start after GAC is updated? Or update the GAC, start services then commit installation?? Or is there a way to force GAC refresh (or whatever it is called) as an installation sequence? The current situation is a giant PITA. - Adam PS. I guess an alternative would be not to start the service on Vista and ask user either to start it manually or restart the machine. Not a good improvement from XP or 2003! - 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
Re: [WiX-users] Services + Vista + GAC
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
Re: [WiX-users] Services + Vista + GAC
In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: 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. As Phil mentioned, an easy solution to this is to link to the C runtime staticly and then *poof*, the problem goes away. ServiceControl start=install/ so, why have that? Please note that I'm not suggesting that ServiceControl has no point, or that there's never a need to control a service. I'm simply saying that most of the time a service exists to provide some functionality and you want that functionality to be there regardless of whether or not someone is logged into the machine. ServiceControl does more than *start* services. Plenty of times you need to stop services before you upgrade or install things, otherwise the service process keeps it loaded in memory and you can't update it without rebooting. IIS can hold onto your vdir, for instance. For your own services, you need to stop them before you can update them. I've used ServiceControl to start services I've installed plenty of times, but in this particular case (changes you need aren't done until InstallFinalize or later), it isn't working, so I was saying why not investigate if you can live without starting the service after you've installed it. Its a workaround. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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
Re: [WiX-users] Services + Vista + GAC
Richard wrote: In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: 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. As Phil mentioned, an easy solution to this is to link to the C runtime staticly and then *poof*, the problem goes away. Actually, that is not the 'easy' solution! There are other dependencies (not assembies, just regular DLLs) and those would have to reconfigurured and rebuilt. ServiceControl does more than *start* services. Plenty of times you need to stop services before you upgrade or install things, otherwise the service process keeps it loaded in memory and you can't update it without rebooting. IIS can hold onto your vdir, for instance. For your own services, you need to stop them before you can update them. I've used ServiceControl to start services I've installed plenty of times, but in this particular case (changes you need aren't done until InstallFinalize or later), it isn't working, so I was saying why not investigate if you can live without starting the service after you've installed it. Its a workaround. I know this. My question was why have the start attribute of the ServiceControl tag? Maybe a good feature for future release of WiX may be a delayed start of services. That is, the service is started after installation finalizes? - 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
Re: [WiX-users] Services + Vista + GAC
I, for one, am glad there is a Start attribute on the ServiceControl element. We have several services in our product that work in combination with each other and are needed to be started before the install finishes as several custom actions run utilities that configure the system and depend on the services being started. Not my design, but WiX does the right thing for me. But, one of our other services relies on a component in the GAC so for that one I use a delayed custom action to NET START the service. Here's an example of one service being started after InstallFinalize CustomAction Id=NETSTART Property=NETSTART Value=NET START quot;HFS Hosting Servicequot; HideTarget=yes / CustomAction Id=caNETSTART Return=check ExeCommand=[NETSTART] Directory=TARGETDIR HideTarget=yes / And in the InstallExecuteSequence Custom Action=NETSTART After=InstallFinalize![CDATA[FrameworkRole = 3]]/Custom Custom Action=caNETSTART After=NETSTART![CDATA[FrameworkRole = 3]]/Custom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Wednesday, November 14, 2007 11:08 AM To: WiX Users Subject: Re: [WiX-users] Services + Vista + GAC Richard wrote: In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: 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. As Phil mentioned, an easy solution to this is to link to the C runtime staticly and then *poof*, the problem goes away. Actually, that is not the 'easy' solution! There are other dependencies (not assembies, just regular DLLs) and those would have to reconfigurured and rebuilt. ServiceControl does more than *start* services. Plenty of times you need to stop services before you upgrade or install things, otherwise the service process keeps it loaded in memory and you can't update it without rebooting. IIS can hold onto your vdir, for instance. For your own services, you need to stop them before you can update them. I've used ServiceControl to start services I've installed plenty of times, but in this particular case (changes you need aren't done until InstallFinalize or later), it isn't working, so I was saying why not investigate if you can live without starting the service after you've installed it. Its a workaround. I know this. My question was why have the start attribute of the ServiceControl tag? Maybe a good feature for future release of WiX may be a delayed start of services. That is, the service is started after installation finalizes? - 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
Re: [WiX-users] Services + Vista + GAC
In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: ServiceControl does more than *start* services. [...] I know this. My question was why have the start attribute of the ServiceControl tag? Because ServiceControl does more than start services. Maybe a good feature for future release of WiX may be a delayed start of services. That is, the service is started after installation finalizes? As was also suggested, this would be better handled from a bootstrapper. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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
Re: [WiX-users] Services + Vista + GAC
Adam Majer wrote: I know this. My question was why have the start attribute of the ServiceControl tag? Because MSI supports it for low-dependency services. Maybe a good feature for future release of WiX may be a delayed start of services. That is, the service is started after installation finalizes? That works only when the service is ACLd to let standard users start it. Same with a post-InstallFinalize custom action, because it can't run elevated. -- sig://boB http://joyofsetup.com/ - 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
Re: [WiX-users] Services + Vista + GAC
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
[WiX-users] Services + Vista + GAC
Hi, I have a service I want to install and automatically start with an installer. Now, the runtime for the service is not available until after installer completed because the runtime goes into the GAC (it is just the VS2005 SP1 C runtime). One solution is to deploy the files locally (as in a per-user install), but that doesn't work because the service uses a plugin that is in a subdirectory of the installation. The location of the plugin is not easy to change. Another solution that was suggested here was to use a deferred custom action to start the service. But that also doesn't seem to work. Using WiX 2.x branch and it results in a runtime error. The custom action works OK if run outside of the MSI. The error returned is Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. Currently I have it as, Binary Id=blah SourceFile=/ CustomAction Id=blah_ca ExeCommand= BinaryKey=blah Execute=deferred Impersonate=no Return=ignore / InstallExecuteSequence Custom Action=blah_ca OnExit=success / /InstallExecuteSequence Any ideas? This problem will definitely keep surfacing regarding Vista and services. Is there something being done either in the Windows Installer or WiX to address this issue and allow services to start after GAC is updated? Or update the GAC, start services then commit installation?? Or is there a way to force GAC refresh (or whatever it is called) as an installation sequence? The current situation is a giant PITA. - Adam PS. I guess an alternative would be not to start the service on Vista and ask user either to start it manually or restart the machine. Not a good improvement from XP or 2003! - 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
