Re: [WiX-users] Burn and Files in Use / Restart Manager
What I do in this scenario is scan the logs to find out what files are in use and causing the reboot - look for a return code of 3010 from one of your MSIs - burn will only do a reboot if one of the packages (MSI or EXE) requests it. Once you know that you can decide how to handle it more effectively. For example, if a service is running you can stop it, if it is an application you can use the WiX CloseApplication element. Hope this helps. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 22 October 2012 21:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn and Files in Use / Restart Manager Hi all, I've been successfully using WiX for a long time now and I'm very happy with it. Many thanks for all the effort you are putting into this project. Currently I'm using WiX together with a standard Visual Studio bootstrapper for .NET and other prerequisites. I want to replace this with Burn which seems to be a very nice solution. All is working very good and using Burn is mostly straightforward. But one thing bothers me: There seems to be no standard way for dealing with files in use and especially together with the restart manager. Burn will by default always trigger a restart/ask for restarting if something is in use. For normal applications this is very annoying for users. Additionally if I remember correctly there was a Windows logo requirement which disallows this practice. Therefore I'm currently trying to extend the standard bootstrapper application (unmanaged) with "files in use" and restart manager capabilities. My current understanding is that this is not possible for an bootstrapper application without changing the engine. E.g. it seems OnExecuteFilesInUse() is never called for MSI packages; not even thinking about the Windows installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm no windows installer or WiX guru, but when looking at the Burn source there is no message filter added for either INSTALLLOG_FILESINUSE or (if supported by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI is initialized. But I might be missing something here. I've started playing around with the Burn 3.7 source (because it's using MSBuild only) and got the messages working, but there are other side effects. E.g. the engine will always suppress results from the UI trying to pass only expected values back to the installer; but in case of the restart manager there are more possibilities which are not included into the message. I just wanted to ask what the plans are for supporting this functionality or if I'm totally going into the wrong direction and there is an obvious solution I'm not aware of. Thanks for reading! Yours sincerely, Georg von Kries -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WIX Start Menu Shortcut
I've got an installer that is working, with the exception of making start menu shortcuts. I've done this before in wix 3.5, but now I keep getting the following error: The installer has insufficient privileges to access this directory: C:\Program Files (x86)\MyApp. The installation cannot continue. Log on as administrator or contact your system administrator. I've tried the .msi itself as well as running it from a burn bundle that has already elevated itself. I've tried a number of different ways, from using separate components, to using a shortcut under the main executable with advertise=true, but they all result in the same error. Does anyone have working examples of start menu shortcur\ts in WiX 3.6? Adam -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Strategy for 3rd party Merge Modules
Usually, the issue is that the Merge Modules do not have all the necessary actions to correctly install themselves (which is incorrect to the spec). If you're missing actions, you can add them to your package by just adding the action name, like: and you're package will have what the Merge Module should have added. On Mon, Oct 22, 2012 at 10:00 PM, Ingo Fischer wrote: > > Hello, > what is the strategy if a 3rd-party Merge Module does not install > correctly?With 3rd-party I mean, I have the files of the Merge Module, only > the msm file. > In my case, if I put the msm in a VS-Installer made msi, it works.If it is > in a WIX made msi, some dll ( COM ) are not registered right. > I thought about extracting the files of the MM using dark and harvest them > again using heat.But what if the MM has custom actions ? > BR-ingo > > > > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Strategy for 3rd party Merge Modules
Hello, what is the strategy if a 3rd-party Merge Module does not install correctly?With 3rd-party I mean, I have the files of the Merge Module, only the msm file. In my case, if I put the msm in a VS-Installer made msi, it works.If it is in a WIX made msi, some dll ( COM ) are not registered right. I thought about extracting the files of the MM using dark and harvest them again using heat.But what if the MM has custom actions ? BR-ingo -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing to inetpub\wwwroot...
figured it out... saw a build warning about a property I created with another property as part of the path, you have to create a custom action to do that: NOT Installed Sigh it pays to look at warnings... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-to-inetpub-wwwroot-tp7581451p7581516.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn and Files in Use / Restart Manager
Hi all, I've been successfully using WiX for a long time now and I'm very happy with it. Many thanks for all the effort you are putting into this project. Currently I'm using WiX together with a standard Visual Studio bootstrapper for .NET and other prerequisites. I want to replace this with Burn which seems to be a very nice solution. All is working very good and using Burn is mostly straightforward. But one thing bothers me: There seems to be no standard way for dealing with files in use and especially together with the restart manager. Burn will by default always trigger a restart/ask for restarting if something is in use. For normal applications this is very annoying for users. Additionally if I remember correctly there was a Windows logo requirement which disallows this practice. Therefore I'm currently trying to extend the standard bootstrapper application (unmanaged) with "files in use" and restart manager capabilities. My current understanding is that this is not possible for an bootstrapper application without changing the engine. E.g. it seems OnExecuteFilesInUse() is never called for MSI packages; not even thinking about the Windows installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm no windows installer or WiX guru, but when looking at the Burn source there is no message filter added for either INSTALLLOG_FILESINUSE or (if supported by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI is initialized. But I might be missing something here. I've started playing around with the Burn 3.7 source (because it's using MSBuild only) and got the messages working, but there are other side effects. E.g. the engine will always suppress results from the UI trying to pass only expected values back to the installer; but in case of the restart manager there are more possibilities which are not included into the message. I just wanted to ask what the plans are for supporting this functionality or if I'm totally going into the wrong direction and there is an obvious solution I'm not aware of. Thanks for reading! Yours sincerely, Georg von Kries -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstaller for harvested file
Retrying this as the last attempt bounced.. If you are using heat you could provide it with a -t and an XSLT transform which would be used to tweak the default output to your liking. This would allow you to only have the need for the generated file. Jacob -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: Monday, October 22, 2012 9:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstaller for harvested file Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional util:XmlFile change...
decided to use two components that modify the .config file and condition it one if a Server install the other if a Client install... Thanks Rob and Peter for your input :) Cheers, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Conditional-util-XmlFile-change-tp7581487p7581513.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ServiceInstaller for harvested file
Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing to inetpub\wwwroot...
I really need help on this... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-to-inetpub-wwwroot-tp7581451p7581511.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Sourceforge cooperated with me now, so I filed a feature request: https://sourceforge.net/p/wix/feature-requests/709/ Daniel E. Bruce > -Original Message- > From: Daniel Bruce [mailto:daniel.br...@prediktor.no] > Sent: 22. oktober 2012 13:00 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Getting started writing a custom Bootstrapper > interface > > > -Original Message- > > From: Igor Brejc [mailto:igor.br...@gmail.com] > > Sent: 20. oktober 2012 20:04 > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Getting started writing a custom Bootstrapper > > interface > > > > Hi, > > > > Some more pointers from me. I've implemented a custom managed > > bootstrapper using WinForms. The GUI actually looks pretty much the > > same as the standard MSI setup wizard, but implemented with custom > C# > > code using MVP > > (model-view-presenter) pattern. This enables me to unit-test the > > wizard without actually running the installation. > > > > I've also "hidden" the WiX bootstrapper engine behind an adapter > > interface (I called it IInstallEngine). This way I can run the wizard > > as a "normal" > > Windows Forms application and click through it (again, without the > > need to run the actual Windows installation), since in that mode the > > wizard uses a mocked implementation of IInstallEngine. I just simply > > added the static Main method which has the similar logic to the Run(). > > > > (Note to Rob: perhaps it would be a good idea to change the design of > > the managed bootstrapper so that it works with interfaces instead of > > concrete implementations, this would be really helpful for unit > > testing and simulation). > > I absolutely agree with this point. It would be very helpful to have > interfaces defined for BootstrapperApplication containing the events it > exposes, as well as for the Engine class. It's nigh impossible to do unit > tests on the interface classes without this step. I've created my own, but > that feels kind of hacky. > > I would file a feature request, but the sourceforge website seems to be > throwing Error 500s right now. > > > The wizard has one added feature: a debug window which can be > turned > > on through the command line and displays all the install log messages > > directly in the setup wizard. > > > > The documentation for the managed BS is pretty scarce, so I had to > > look into WiX's source code and do a lot of trials and errors to get > > to this point (and I still have some issues to work through). > > Pretty much what I had to do too. I really hope the documentation > situation is going to improve before the 3.7 release, because right now > it's kind of ridiculous. I feel like I just have wishful thinking and > half-truths > to go on and many times during the development process things broke > because my assumptions (based on what I could glean from source code > and random > postings) were not correct. I'm kind of worrying about what's going to > break next due to something that is not obvious from the source code. > > > Best regards, > > Igor Brejc > > Regards, > Daniel E. Bruce > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
> -Original Message- > From: Igor Brejc [mailto:igor.br...@gmail.com] > Sent: 20. oktober 2012 20:04 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Getting started writing a custom Bootstrapper > interface > > Hi, > > Some more pointers from me. I've implemented a custom managed > bootstrapper using WinForms. The GUI actually looks pretty much the > same as the standard MSI setup wizard, but implemented with custom > C# code using MVP > (model-view-presenter) pattern. This enables me to unit-test the wizard > without actually running the installation. > > I've also "hidden" the WiX bootstrapper engine behind an adapter > interface (I called it IInstallEngine). This way I can run the wizard as a > "normal" > Windows Forms application and click through it (again, without the need > to run the actual Windows installation), since in that mode the wizard > uses a mocked implementation of IInstallEngine. I just simply added the > static Main method which has the similar logic to the Run(). > > (Note to Rob: perhaps it would be a good idea to change the design of > the managed bootstrapper so that it works with interfaces instead of > concrete implementations, this would be really helpful for unit testing > and simulation). I absolutely agree with this point. It would be very helpful to have interfaces defined for BootstrapperApplication containing the events it exposes, as well as for the Engine class. It's nigh impossible to do unit tests on the interface classes without this step. I've created my own, but that feels kind of hacky. I would file a feature request, but the sourceforge website seems to be throwing Error 500s right now. > The wizard has one added feature: a debug window which can be turned > on through the command line and displays all the install log messages > directly in the setup wizard. > > The documentation for the managed BS is pretty scarce, so I had to look > into WiX's source code and do a lot of trials and errors to get to this point > (and I still have some issues to work through). Pretty much what I had to do too. I really hope the documentation situation is going to improve before the 3.7 release, because right now it's kind of ridiculous. I feel like I just have wishful thinking and half-truths to go on and many times during the development process things broke because my assumptions (based on what I could glean from source code and random postings) were not correct. I'm kind of worrying about what's going to break next due to something that is not obvious from the source code. > Best regards, > Igor Brejc Regards, Daniel E. Bruce -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with MSCOMCT2 OCX/MSM
Yes, you'r right REINSTALLMODE is set to "amus" by an earlier developer. I have to figure out why it's done and if I can change to "omus". I believe the REINSTALLMODE also affect all the mergemodules as well? Oivind -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problem-with-MSCOMCT2-OCX-MSM-tp7308299p7581507.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fwd: Define as x64
Official docs here http://msdn.microsoft.com/en-us/library/windows/desktop/aa372855%28v=vs.85%29 .aspx After that, you will find my colleague's blog article useful http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou rce-file/ and search this mailing list at nabble.com where the topic comes up often. -Original Message- From: jpalmer1...@comcast.net [mailto:jpalmer1...@comcast.net] Sent: 22 October 2012 05:23 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Fwd: Define as x64 - Forwarded Message - From: jpalmer1...@comcast.net To: wix-users@lists.sourceforge.net Sent: Saturday, October 20, 2012 7:38:53 PM Subject: Define as x64 I have a windows service that needs to be installed on a 64 bit server. Can someone point me to the documentation or tutorial that explains how to define a project as 64 bit and WiX does differently when it is so defined? Joel Palmer - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Specifying PackageGroup Id on button click
Thanks Rob, unfortunately I cannot find any information about the OnPackagePlan callbacks online nor can I see it used in the WixBA source code. Could you point me in the right direction? Thanks! On Fri, Oct 19, 2012 at 6:59 PM, Rob Mensching wrote: > Check on the OnPackagePlan callbacks. > > On Fri, Oct 19, 2012 at 5:19 AM, Hans ter Horst > wrote: > > > Hello, i have several simple installers that I would like group behind a > > Burn interface and start depending on the button clicked from the > > Bootstrapper interface I am designing which will have several buttons. > > For a simple bootstrapper I know > > I can use Bootstrapper.Engine.Plan(LaunchAction.Install); on hitting an > > install button and Bootstrapper.Engine.Plan(LaunchAction.Uninstall); for > > an uninstall button. How can I extend this to refer to PackageA or > PackageB > > in my Bundle.wxs file so i can differentiate between the MSI files > started? > > > > Thanks! > > -- > > http://monochrome.me.uk/blog/ > > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > virtually, > >Rob Mensching >http://RobMensching.com LLC > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- http://monochrome.me.uk/blog/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional util:XmlFile change...
Also you could have 2 different components - one for each service type - with
opposite conditions. It'll be easier to maintain if the 2 versions of the
files differ further as time goes on.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 20 October 2012 18:43
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Conditional util:XmlFile change...
Condition the Component.
On Fri, Oct 19, 2012 at 1:44 PM, StevenOgilvie wrote:
> I have a .config file I need to change if the install running is the
> client install and NOT the server install (we share the services
> between client and server installations)
>
> I have this code:
> Guid="{76DCFB0D-B7BD-4089-AD4D-945931CD73FD}" Permanent="no"
> SharedDllRefCount="yes" Shared="yes">
> Name="MyCorp.Enterprise.Service.dll.config"
>
>
Source="$(var.tssSourcePath)\MyCorp.Enterprise.Service\MyCorp.Enterprise.Serv
ice.dll.config"
> />
>SelectionLanguage="XPath"
>
> File="[WixLibRedirectFolder]MyCorp.Enterprise.Service.dll.config"
>
>
>
ElementPath="//applicationSettings/MyCorp.Enterprise.Service.Properties.Setti
ngs/setting[\[]@name='IsMyCorpServer'[\]]/value"
> Action="setValue"
> Sequence="1"
> Value="false"/>
>
> and I want to do something like this:
> < ! [CDATA[CLIENT_INSTALL="1"] ] >
>
> but I can't add that conditional since I get this error:
> Error 41 Schema validation failed with the following error at line
> 1, column
> 3113: The element cannot contain text. Content model is empty.
> C:\Dev\Core
>
>
Technologies\Main\Setup\TitusServices\TitusEnterpriseManagementServicesMergeM
odule\MergeModule.wxs
> 18 1 TitusEnterpriseManagementServicesMergeModule
>
>
> how can I make a XmlFile change conditional? Can't use XmlConfig
> element since I have a text in the Value="false"
>
> Guid="{76DCFB0D-B7BD-4089-AD4D-945931CD73FD}" Permanent="no"
> SharedDllRefCount="yes" Shared="yes">
> Name="MyCorp.Enterprise.Service.dll.config"
>
>
Source="$(var.tssSourcePath)\MyCorp.Enterprise.Service\MyCorp.Enterprise.Serv
ice.dll.config"
> />
> Action="delete"
>
> File="[WixLibRedirectFolder]MyCorp.Enterprise.Service.dll.config"
>
>
>
ElementPath="//applicationSettings/MyCorp.Enterprise.Service.Properties.Setti
ngs/setting[\[]@name='IsMyCorpServer'[\]]/value"
>
>
>
VerifyPath="//applicationSettings/MyCorp.Enterprise.Service.Properties.Settin
gs/setting[\[]@name='IsMyCorpServer'[\]]/value"
> On="install"
> Node="element"
> Sequence="2"
> Value="false" >
> < ! [CDATA[CLIENT_INSTALL="1"] ] >
>
> since I get this error:
> Error 34 The util:XmlConfig/@Value attribute cannot be specified
> when the
> element has body text as well. Specify either the attribute or the
> body, but
> not both. C:\Dev\Core
>
>
Technologies\Main\Setup\TitusServices\TitusEnterpriseManagementServicesMergeM
odule\MergeModule.wxs
> 34 1 TitusEnterpriseManagementServicesMergeModule
>
>
> Steve
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Conditio
> nal-util-XmlFile-change-tp7581487.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
virtually,
Rob Mensching
http://RobMensching.com LLC
-
-
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free
today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY,
UK.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
htt
