[WiX-users] Running WiX tools from Cygwin, environment variables
Hi, new to the group! My question is this: I have a Cygwin shell script which sets an environment variable called "REVISION" (set to "anotherversion"). My .wxs has the following code in it: I know the variable exists, but Candle doesn't seem to pick it up. The idea is that BUILD should be set to anotherversion. Has anyone else tried to run WiX in this way? My job needs this, so any tips are welcome! I've had zero success exploring the usual avenues (Google, FAQs, etc.). I'm also new to XML, is there a way that I can show the incoming env. vars from within my .wxs file? Thanks to all. GLK -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] We are getting some unexpected and undesirable behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see if we are doing something wrong.
Setting the SKIPCONFIGUREIIS property via an immediate CA (scheduled prior to ConfigureIIs of course) to simply skip IIS configuration when the target host already has the website installed would require us having some way to determine if the target host already has the website installed wouldn't it? Yes Is there some wix syntax supporting that check? No, you would need to write a CA to query the IIS metabase. Also wouldn't doing this actually cause not only our AppPool and WebSite settings from not being applied but also all of our iis:WebVirtualDir and iis:WebApplication settings that we do want to recreate every time as we do remove those components during uninstall. I'm afraid so, as Rob pointed out, it's a nuke. The addition of the ConfigureIfExists="no" option to our iis:WebSite element sounds promising since it sounds like it may prevent the activity that is traversing any of the child vdirs that someone may have added to the website, outside of what our installer creates, and resetting their appPool setting to whatever is defined for the iis:WebSite. I wouldn't be so sure. It'll certainly bail out early and skip some configuration (AutoStart, ConnectionTimeout etc and perhaps a select set of child elements e.g. SSL certificates and HTTP headers) but all bets are off without poking about in the source first. IMO, the behavior is not entirely unsurprising but is clearly undesirable for your requirements. Perhaps an alternate approach to the aforementioned nuke, once the exact behaviour of the extension source has been understood, is to insert temporary rows into specific IIs tables via immediate CAs that are conditionalised on the state of the box i.e. the presence/absence of certain items. This should allow you to dynamically adjust the install/uninstall behaviour of your IIs configuration process. -- View this message in context: http://n2.nabble.com/We-are-getting-some-unexpected-and-undesirable-behavior-from-iis%3AWebAppPool-and-iis%3AWebSite-extensions%2C-just-checking-to-see-if-we-are-doing-something-wrong.-tp2577603p2583759.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unable to remove website during uninstall
Thanks for you reply! I checked the log file. Action is absent: MSI (s) (4C:B4) [17:47:48:175]: Component: Site; Installed: Local; Request: Absent; Action: Absent Also I check "WriteMetabaseChanges" in the log file. I don't see any errors or warnings: MSI (s) (4C!DC) [17:47:52:125]: PROPERTY CHANGE: Adding WriteMetabaseChanges property. Its value is 'ConfigureIIs'. MSI (s) (4C!DC) [17:47:52:126]: Doing action: WriteMetabaseChanges Action start 17:47:52: WriteMetabaseChanges. Action ended 17:47:52: WriteMetabaseChanges. Return value 1. MSI (s) (4C:B4) [17:47:53:519]: Executing op: ActionStart(Name=WriteMetabaseChanges,Description=Installing Metabase Keys and Values,) MSI (s) (4C:B4) [17:47:53:520]: Executing op: CustomActionSchedule(Action=WriteMetabaseChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (4C:60) [17:47:53:527]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIF900.tmp, Entrypoint: WriteMetabaseChanges Property(S): WriteMetabaseChanges = ConfigureIIs Finally the version I tried just now is 3.0.5127.0. Again, thank you very much for you kindly suggestions! Regards, Gavin Cheng -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New wix binary delta patching doesn't work
I am using old-style patchwiz.dll patching with success on daily builds and I
haven't updated WIX for 4 months already.
Nevertheless, there are several reason to prefer new style delta patching so I
will let you know how it works with the latest WIX version as soon as I get
some extra iteration time.
Thanks for info!
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: Friday, April 03, 2009 3:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] New wix binary delta patching doesn't work
Are you still having the same problem with recent builds? A month or two ago
changes were made to fix a couple of issues with delta patching.
On Tue, Aug 19, 2008 at 5:57 AM, Tony Juricic wrote:
> Ok, that makes sense. However, I can't get it to work either way. The
> problem is not in changing just the 4th version number either. I created
> a simple C# console executable that has one line of code:
>
> Console.Writeln("This is version 1.0.0.0");
>
> and assembly info AssemblyVersion("1.0.0.0")] and
> AssemblyFileVersion("1.0.0.0")].
>
> I build WiX test project referencing this program with -bf -xo linker
> options.
>
> The output is WixTest1.msi but it is not msi file since it can't be
> opened with Orca. Is it wixpdb or wixout? Torch doesn't like wixpdb
> extension (error TRCH0048) but accepts wixout.
>
> I then update console program by changing all the strings 1.0.0.0 above
> to 1.0.1.0, then rebuild exe and WiX project, changing also Product
> element, Version attribute to 1.0.1.0. This gives me the second wixout
> file for input to torch and I get 31 KB large Diff.wixmst.
>
> When I run Pyro it comes with PYRO0252 error meaning that it can't find
> any transform.
>
> Torch and Pyro invoking batch files content is the following:
>
> "%WIX%bin\torch.exe" -p -xi -v -val g -val l -val r -val z
> Version1000\WiXTest1000.wixout Version1010\WiXTest1010.wixout -out
> Patch\Diff.Wixmst
>
> "%WIX%bin\candle.exe" Patch.wxs
> "%WIX%bin\light.exe" Patch.wixobj -out Patch\Patch.WixMsp
> REM "%WIX%bin\pyro.exe" -delta Patch\Patch.WixMsp -out Patch\Patch.msp
> -t RTM Patch\Diff.wixmst
> "%WIX%bin\pyro.exe" Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM
> Patch\Diff.wixmst
>
> Note above REMarked -delta option.
>
> Patch.wxs content is:
>
>
> http://schemas.microsoft.com/wix/2006/wi";>
> ClientPatchId="WiXTest1" Id="*" DisplayName="WiXTest1 Update"
> Manufacturer="WiXTest1" MoreInfoURL="http://www.WiXTest1.com";
> Description="Minor Update Patch" TargetProductName="WixTest1">
> Source="FIRSTPATCH_PROP">
>
>
>
>
>
>
>
> Supersede="no">
>
>
>
>
>
>
> Obviously, I am doing something horribly wrong in my adaptation of Peter
> Marcu's blog example or there is a nasty bug somewhere in there.
>
>
> -Original Message-
> From: Blair Murri [mailto:bmu...@microsoft.com]
> Sent: Monday, August 11, 2008 1:56 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] New wix binary delta patching doesn't work
>
> The "-delta" switch of pyro builds on top of the whole-file patch
> support in pyro, so if that isn't working, the delta addition won't do
> anything to help you.
>
> If you get pyro to build a whole file patch that updates your binaries,
> then add the -delta switch and test the results.
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
Good to know, thanks! -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Friday, April 03, 2009 3:16 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? In a verbose log Windows Installer 3.1+ will add a line line "SELMGR: A component *foo* is registered to feature *bar*, but was removed from the feature.", followed immediately by something like "SELMGR: Removal of components from a feature is not supported." But this will not fail the patch. Instead it will advertise the feature and the content of that feature will never be repaired again. See http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx for more information. MSIENFORCEUPGRADECOMPONENTRULES merely turns that into an error, so instead of silently breaking the product the property (and the corresponding machine policy) will fail the install. So a small update or minor upgrade patch will apply if you break this component violation, but the feature will forever be broken until explicitly added back into the local state. See http://blogs.msdn.com/heaths/archive/2009/01/27/repairing-products-after-patches-advertised-features.aspxfor some suggestions of how to do that. On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic wrote: > It just goes to show how easy it is to commit gross component rules > violations even after months of reading articles and blogs on component > rules! > > However, it seems that I have also misunderstood the purpose of > MSIENFORCEUPGRADECOMPONENTRULES property. I was under the impression > that it would add to verbose log. I mean, if MSI *knows* that there is > component violation, it would be of great help if it could add a > sentence to the log saying at least something along the lines of: > There is component rules violation of some sort! > > After reading all that I could find on MSIENFORCEUPGRADECOMPONENTRULES > property I can't say that I am 100% sure about what is it that it really > does? How can the consequences of having this property defined or not be > seen on some practical example? I was certainly none the wiser in this > specific case since verbose logs were identical with or without it, for > all that I could see. > > It *seems* that a small update patch may be applied by MSI in some cases > even if there was a component rule violation and this property prevents > it. > > -Original Message- > From: Bob Arnson [mailto:b...@joyofsetup.com] > Sent: Saturday, August 02, 2008 1:10 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version > number? > > Tony Juricic wrote: > > but reading the install.log I cannot find anything a bit more explicit > > about this violation. It is certainly not saying something like "you > > changed the name of your root installation folder and you shouldn't" > :) > > > > Sorry, it's not that polite. The "Windows Installer Components" topic > > summarizes the magic of component rules with two bullets: > >In brief, these rules are: > >* Each component must be stored in a single folder. >* No file, registry entry, shortcut, or other resources should > ever be shipped as a member of more than one component. This > applies across products, product versions, and companies. > > So changing the directory violates 50 percent of the component rules. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact
Re: [WiX-users] Unable to remove website during uninstall
In your verbose log, what does Windows Installer think is the "Action" state for this component on uninstall? You're looking for a line that says something like this: MSI (s) (4C:88) [14:30:42:128]: Component: Site; Installed: Local; Request: Absent; Action: Absent It should say "Action: Absent" in the uninstall case - if not, there is something going on with your component GUID and/or authoring, unrelated to the custom action. Also, when searching through the verbose log, did you try searching for "WriteMetabaseChanges:"? This should display any warnings / errors specific to the IIS's deferred custom action. Finally, what version of WiX are you using? Quite a lot of things have been fixed in the IIS custom action in just the past couple of months - you may want to try again with the latest weekly build to see if the problem still occurs. Thanks, Mike Carlson -Original Message- From: Gang Cheng [mailto:gang.cheng...@gmail.com] Sent: Friday, April 03, 2009 11:13 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Unable to remove website during uninstall I have this wxs file to install binarys and a website in IIS. The installation works fine. But just during uninstall, only the binary folders are removed. The IIS website remains there (though the status becomes unknown). I tried the verbose log, but didn't see any error/warning there. Can someone give me some help/hints? More generally, besides logging, is there any debugger for wix? Thank you very much. http://schemas.microsoft.com/wix/2006/wi"; xmlns:util=" http://schemas.microsoft.com/wix/UtilExtension"; xmlns:iis=" http://schemas.microsoft.com/wix/IIsExtension";> ... -- Cheers, Gang Cheng -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Patching, Merge Module problem?
MSMs would already be merged into the the MSI at that point, so any differences in your MSMs will be visible. But it depends on your patch authoring. What does your patch source file look like? Can you post it or a sample online? On Fri, Apr 3, 2009 at 11:24 AM, Stryder Crown wrote: > Learning WiX, getting into patching and have all sorts of confusion. But, > maybe someone can clarify for me: > > When running torch on two .msi files (the original and the updated one), > torch isn't going to find differences in referenced merge modules is it? > Which means my transform file isn't going to contain any 'new things', and > that's why I'm getting these 'no valid transforms' error, right? > > What is the recommended strategy for patching if the update is in one of > the > merge modules? Or am I missing something? > > Stryder > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
That does seem to be the problem; if I use a sample C# project, it works fine.
It would be nice if this was more obvious. Sigh.
-Original Message-
From: Christopher Karper [mailto:christopher.kar...@gmail.com]
Sent: Friday, April 03, 2009 11:56 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using Wix and Visual Studio
Yeah, I believe that would be the problem. That's the missing piece of the
puzzle.
Chris
On Fri, Apr 3, 2009 at 2:40 PM, Simon Dahlbacka
wrote:
> I seem to remember that VC++ projects are not supported as project
> references as they do not use msbuild. Please correct me if I'm wrong
> though..
>
> /Simon
>
> On Fri, Apr 3, 2009 at 9:31 PM, Eric Brown (REDMOND)
> wrote:
> >
> > simple
> > {51fd4fe2-5128-4557-b23c-be67ca3fe745}
> > True
> >
> >
> > -Original Message-
> > From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com]
> > Sent: Friday, April 03, 2009 11:22 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >
> > how does the tag look in your .wixproj file?
> >
> > On Fri, Apr 3, 2009 at 9:13 PM, Eric Brown (REDMOND)
> > wrote:
> >> Multiple times. It always comes back yellow. There's no tooltip to
> provide any further feedback. (Also, I've tried this with a separate dummy
> project - I get the same problem.)
> >>
> >> -Original Message-
> >> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
> >> Sent: Friday, April 03, 2009 11:07 AM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>
> >> That is VS saying the reference is invalid somehow. I'm not sure what
> the
> >> specific problem is, but have you tried deleting the reference and
> >> recreating it? Sorry I can't do more to help right now, but I'm
> wrestling
> >> TFS and Team Build, and it's winning.
> >>
> >> Chris
> >>
> >> On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) <
> >> eric.br...@microsoft.com> wrote:
> >>
> >>> Also, there is that yellow warning icon on the project reference. I
> don't
> >>> know what that means, and I can't find a reference in the
> documentation.
> >>>
> >>> -Original Message-
> >>> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
> >>> Sent: Friday, April 03, 2009 10:17 AM
> >>> To: General discussion for Windows Installer XML toolset.
> >>> Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>>
> >>> I use spaces in my project names and project references, and they're
> all
> >>> fine.
> >>> I suspect his problem is something else. I'm not sure what that is,
> since
> >>> this exact scenario, even down to the environment seems to match.
> >>>
> >>> Chris
> >>>
> >>> On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) <
> >>> eric.br...@microsoft.com> wrote:
> >>>
> >>> > Tried using underscores and renaming; still get the same error
> (CNDL0150:
> >>> > Undefined preprocessor variable).
> >>> >
> >>> > -Original Message-
> >>> > From: Jason Ginchereau [mailto:jason...@microsoft.com]
> >>> > Sent: Thursday, April 02, 2009 5:55 PM
> >>> > To: wix-users@lists.sourceforge.net
> >>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>> >
> >>> > Any characters in the project name that are invalid for WiX
> preprocessor
> >>> > variable names get automatically converted to underscores. So without
> >>> > renaming the project this should work:
> >>> >
> >>> > $(var.My_Test_Project.TargetFilename)
> >>> >
> >>> >
> >>> > -Original Message-
> >>> > From: Alex Cater [mailto:alex.ca...@apdcomms.com]
> >>> > Sent: Thursday, April 02, 2009 4:28 PM
> >>> > To: wix-users@lists.sourceforge.net
> >>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>> >
> >>> >
> >>> > I'm guessing that you cannot have spaces in a project reference
> >>> variable...
> >>> >
> >>> > $(var.My Test Project.TargetFileName)
> >>> >
> >>> > Try renaming your test project to MyTestProject so the project
> reference
> >>> > variable becomes:
> >>> >
> >>> > $(var.MyTestProject.TargetFileName)
> >>> >
> >>> > --
> >>> > View this message in context:
> >>> >
> http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html
> >>> > Sent from the wix-users mailing list archive at Nabble.com.
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> --
> >>> > ___
> >>> > WiX-users mailing list
> >>> > WiX-users@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> --
> >>> > ___
> >>> > WiX-users mailing list
> >>> > WiX-users@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >>> >
Re: [WiX-users] Using Wix and Visual Studio
Yeah, I believe that would be the problem. That's the missing piece of the
puzzle.
Chris
On Fri, Apr 3, 2009 at 2:40 PM, Simon Dahlbacka
wrote:
> I seem to remember that VC++ projects are not supported as project
> references as they do not use msbuild. Please correct me if I'm wrong
> though..
>
> /Simon
>
> On Fri, Apr 3, 2009 at 9:31 PM, Eric Brown (REDMOND)
> wrote:
> >
> > simple
> > {51fd4fe2-5128-4557-b23c-be67ca3fe745}
> > True
> >
> >
> > -Original Message-
> > From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com]
> > Sent: Friday, April 03, 2009 11:22 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >
> > how does the tag look in your .wixproj file?
> >
> > On Fri, Apr 3, 2009 at 9:13 PM, Eric Brown (REDMOND)
> > wrote:
> >> Multiple times. It always comes back yellow. There's no tooltip to
> provide any further feedback. (Also, I've tried this with a separate dummy
> project - I get the same problem.)
> >>
> >> -Original Message-
> >> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
> >> Sent: Friday, April 03, 2009 11:07 AM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>
> >> That is VS saying the reference is invalid somehow. I'm not sure what
> the
> >> specific problem is, but have you tried deleting the reference and
> >> recreating it? Sorry I can't do more to help right now, but I'm
> wrestling
> >> TFS and Team Build, and it's winning.
> >>
> >> Chris
> >>
> >> On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) <
> >> eric.br...@microsoft.com> wrote:
> >>
> >>> Also, there is that yellow warning icon on the project reference. I
> don't
> >>> know what that means, and I can't find a reference in the
> documentation.
> >>>
> >>> -Original Message-
> >>> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
> >>> Sent: Friday, April 03, 2009 10:17 AM
> >>> To: General discussion for Windows Installer XML toolset.
> >>> Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>>
> >>> I use spaces in my project names and project references, and they're
> all
> >>> fine.
> >>> I suspect his problem is something else. I'm not sure what that is,
> since
> >>> this exact scenario, even down to the environment seems to match.
> >>>
> >>> Chris
> >>>
> >>> On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) <
> >>> eric.br...@microsoft.com> wrote:
> >>>
> >>> > Tried using underscores and renaming; still get the same error
> (CNDL0150:
> >>> > Undefined preprocessor variable).
> >>> >
> >>> > -Original Message-
> >>> > From: Jason Ginchereau [mailto:jason...@microsoft.com]
> >>> > Sent: Thursday, April 02, 2009 5:55 PM
> >>> > To: wix-users@lists.sourceforge.net
> >>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>> >
> >>> > Any characters in the project name that are invalid for WiX
> preprocessor
> >>> > variable names get automatically converted to underscores. So without
> >>> > renaming the project this should work:
> >>> >
> >>> > $(var.My_Test_Project.TargetFilename)
> >>> >
> >>> >
> >>> > -Original Message-
> >>> > From: Alex Cater [mailto:alex.ca...@apdcomms.com]
> >>> > Sent: Thursday, April 02, 2009 4:28 PM
> >>> > To: wix-users@lists.sourceforge.net
> >>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
> >>> >
> >>> >
> >>> > I'm guessing that you cannot have spaces in a project reference
> >>> variable...
> >>> >
> >>> > $(var.My Test Project.TargetFileName)
> >>> >
> >>> > Try renaming your test project to MyTestProject so the project
> reference
> >>> > variable becomes:
> >>> >
> >>> > $(var.MyTestProject.TargetFileName)
> >>> >
> >>> > --
> >>> > View this message in context:
> >>> >
> http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html
> >>> > Sent from the wix-users mailing list archive at Nabble.com.
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> --
> >>> > ___
> >>> > WiX-users mailing list
> >>> > WiX-users@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> --
> >>> > ___
> >>> > WiX-users mailing list
> >>> > WiX-users@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> --
> >>> > ___
> >>> > WiX-users mailing list
> >>> > WiX-users@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >>> >
> >>>
> >>>
> -
Re: [WiX-users] Using Wix and Visual Studio
I seem to remember that VC++ projects are not supported as project
references as they do not use msbuild. Please correct me if I'm wrong
though..
/Simon
On Fri, Apr 3, 2009 at 9:31 PM, Eric Brown (REDMOND)
wrote:
>
> simple
> {51fd4fe2-5128-4557-b23c-be67ca3fe745}
> True
>
>
> -Original Message-
> From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com]
> Sent: Friday, April 03, 2009 11:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Using Wix and Visual Studio
>
> how does the tag look in your .wixproj file?
>
> On Fri, Apr 3, 2009 at 9:13 PM, Eric Brown (REDMOND)
> wrote:
>> Multiple times. It always comes back yellow. There's no tooltip to
>> provide any further feedback. (Also, I've tried this with a separate dummy
>> project - I get the same problem.)
>>
>> -Original Message-
>> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
>> Sent: Friday, April 03, 2009 11:07 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Using Wix and Visual Studio
>>
>> That is VS saying the reference is invalid somehow. I'm not sure what the
>> specific problem is, but have you tried deleting the reference and
>> recreating it? Sorry I can't do more to help right now, but I'm wrestling
>> TFS and Team Build, and it's winning.
>>
>> Chris
>>
>> On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) <
>> eric.br...@microsoft.com> wrote:
>>
>>> Also, there is that yellow warning icon on the project reference. I don't
>>> know what that means, and I can't find a reference in the documentation.
>>>
>>> -Original Message-
>>> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
>>> Sent: Friday, April 03, 2009 10:17 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] Using Wix and Visual Studio
>>>
>>> I use spaces in my project names and project references, and they're all
>>> fine.
>>> I suspect his problem is something else. I'm not sure what that is, since
>>> this exact scenario, even down to the environment seems to match.
>>>
>>> Chris
>>>
>>> On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) <
>>> eric.br...@microsoft.com> wrote:
>>>
>>> > Tried using underscores and renaming; still get the same error (CNDL0150:
>>> > Undefined preprocessor variable).
>>> >
>>> > -Original Message-
>>> > From: Jason Ginchereau [mailto:jason...@microsoft.com]
>>> > Sent: Thursday, April 02, 2009 5:55 PM
>>> > To: wix-users@lists.sourceforge.net
>>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
>>> >
>>> > Any characters in the project name that are invalid for WiX preprocessor
>>> > variable names get automatically converted to underscores. So without
>>> > renaming the project this should work:
>>> >
>>> > $(var.My_Test_Project.TargetFilename)
>>> >
>>> >
>>> > -Original Message-
>>> > From: Alex Cater [mailto:alex.ca...@apdcomms.com]
>>> > Sent: Thursday, April 02, 2009 4:28 PM
>>> > To: wix-users@lists.sourceforge.net
>>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
>>> >
>>> >
>>> > I'm guessing that you cannot have spaces in a project reference
>>> variable...
>>> >
>>> > $(var.My Test Project.TargetFileName)
>>> >
>>> > Try renaming your test project to MyTestProject so the project reference
>>> > variable becomes:
>>> >
>>> > $(var.MyTestProject.TargetFileName)
>>> >
>>> > --
>>> > View this message in context:
>>> > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html
>>> > Sent from the wix-users mailing list archive at Nabble.com.
>>> >
>>> >
>>> >
>>> >
>>> --
>>> > ___
>>> > WiX-users mailing list
>>> > WiX-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>>> >
>>> >
>>> >
>>> >
>>> --
>>> > ___
>>> > WiX-users mailing list
>>> > WiX-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>>> >
>>> >
>>> >
>>> >
>>> --
>>> > ___
>>> > WiX-users mailing list
>>> > WiX-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>>> >
>>>
>>> --
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>
>>> --
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://l
Re: [WiX-users] Using Wix and Visual Studio
simple
{51fd4fe2-5128-4557-b23c-be67ca3fe745}
True
-Original Message-
From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com]
Sent: Friday, April 03, 2009 11:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using Wix and Visual Studio
how does the tag look in your .wixproj file?
On Fri, Apr 3, 2009 at 9:13 PM, Eric Brown (REDMOND)
wrote:
> Multiple times. It always comes back yellow. There's no tooltip to provide
> any further feedback. (Also, I've tried this with a separate dummy project
> - I get the same problem.)
>
> -Original Message-
> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
> Sent: Friday, April 03, 2009 11:07 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Using Wix and Visual Studio
>
> That is VS saying the reference is invalid somehow. I'm not sure what the
> specific problem is, but have you tried deleting the reference and
> recreating it? Sorry I can't do more to help right now, but I'm wrestling
> TFS and Team Build, and it's winning.
>
> Chris
>
> On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) <
> eric.br...@microsoft.com> wrote:
>
>> Also, there is that yellow warning icon on the project reference. I don't
>> know what that means, and I can't find a reference in the documentation.
>>
>> -Original Message-
>> From: Christopher Karper [mailto:christopher.kar...@gmail.com]
>> Sent: Friday, April 03, 2009 10:17 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Using Wix and Visual Studio
>>
>> I use spaces in my project names and project references, and they're all
>> fine.
>> I suspect his problem is something else. I'm not sure what that is, since
>> this exact scenario, even down to the environment seems to match.
>>
>> Chris
>>
>> On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) <
>> eric.br...@microsoft.com> wrote:
>>
>> > Tried using underscores and renaming; still get the same error (CNDL0150:
>> > Undefined preprocessor variable).
>> >
>> > -Original Message-
>> > From: Jason Ginchereau [mailto:jason...@microsoft.com]
>> > Sent: Thursday, April 02, 2009 5:55 PM
>> > To: wix-users@lists.sourceforge.net
>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
>> >
>> > Any characters in the project name that are invalid for WiX preprocessor
>> > variable names get automatically converted to underscores. So without
>> > renaming the project this should work:
>> >
>> > $(var.My_Test_Project.TargetFilename)
>> >
>> >
>> > -Original Message-
>> > From: Alex Cater [mailto:alex.ca...@apdcomms.com]
>> > Sent: Thursday, April 02, 2009 4:28 PM
>> > To: wix-users@lists.sourceforge.net
>> > Subject: Re: [WiX-users] Using Wix and Visual Studio
>> >
>> >
>> > I'm guessing that you cannot have spaces in a project reference
>> variable...
>> >
>> > $(var.My Test Project.TargetFileName)
>> >
>> > Try renaming your test project to MyTestProject so the project reference
>> > variable becomes:
>> >
>> > $(var.MyTestProject.TargetFileName)
>> >
>> > --
>> > View this message in context:
>> > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html
>> > Sent from the wix-users mailing list archive at Nabble.com.
>> >
>> >
>> >
>> >
>> --
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>> >
>> >
>> >
>> --
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>> >
>> >
>> >
>> --
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>>
>> --
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>> --
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ---
[WiX-users] WiX Patching, Merge Module problem?
Learning WiX, getting into patching and have all sorts of confusion. But, maybe someone can clarify for me: When running torch on two .msi files (the original and the updated one), torch isn't going to find differences in referenced merge modules is it? Which means my transform file isn't going to contain any 'new things', and that's why I'm getting these 'no valid transforms' error, right? What is the recommended strategy for patching if the update is in one of the merge modules? Or am I missing something? Stryder -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
how does the tag look in your .wixproj file? On Fri, Apr 3, 2009 at 9:13 PM, Eric Brown (REDMOND) wrote: > Multiple times. It always comes back yellow. There's no tooltip to provide > any further feedback. (Also, I've tried this with a separate dummy project > - I get the same problem.) > > -Original Message- > From: Christopher Karper [mailto:christopher.kar...@gmail.com] > Sent: Friday, April 03, 2009 11:07 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Using Wix and Visual Studio > > That is VS saying the reference is invalid somehow. I'm not sure what the > specific problem is, but have you tried deleting the reference and > recreating it? Sorry I can't do more to help right now, but I'm wrestling > TFS and Team Build, and it's winning. > > Chris > > On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) < > eric.br...@microsoft.com> wrote: > >> Also, there is that yellow warning icon on the project reference. I don't >> know what that means, and I can't find a reference in the documentation. >> >> -Original Message- >> From: Christopher Karper [mailto:christopher.kar...@gmail.com] >> Sent: Friday, April 03, 2009 10:17 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] Using Wix and Visual Studio >> >> I use spaces in my project names and project references, and they're all >> fine. >> I suspect his problem is something else. I'm not sure what that is, since >> this exact scenario, even down to the environment seems to match. >> >> Chris >> >> On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) < >> eric.br...@microsoft.com> wrote: >> >> > Tried using underscores and renaming; still get the same error (CNDL0150: >> > Undefined preprocessor variable). >> > >> > -Original Message- >> > From: Jason Ginchereau [mailto:jason...@microsoft.com] >> > Sent: Thursday, April 02, 2009 5:55 PM >> > To: wix-users@lists.sourceforge.net >> > Subject: Re: [WiX-users] Using Wix and Visual Studio >> > >> > Any characters in the project name that are invalid for WiX preprocessor >> > variable names get automatically converted to underscores. So without >> > renaming the project this should work: >> > >> > $(var.My_Test_Project.TargetFilename) >> > >> > >> > -Original Message- >> > From: Alex Cater [mailto:alex.ca...@apdcomms.com] >> > Sent: Thursday, April 02, 2009 4:28 PM >> > To: wix-users@lists.sourceforge.net >> > Subject: Re: [WiX-users] Using Wix and Visual Studio >> > >> > >> > I'm guessing that you cannot have spaces in a project reference >> variable... >> > >> > $(var.My Test Project.TargetFileName) >> > >> > Try renaming your test project to MyTestProject so the project reference >> > variable becomes: >> > >> > $(var.MyTestProject.TargetFileName) >> > >> > -- >> > View this message in context: >> > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html >> > Sent from the wix-users mailing list archive at Nabble.com. >> > >> > >> > >> > >> -- >> > ___ >> > WiX-users mailing list >> > WiX-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wix-users >> > >> > >> > >> > >> -- >> > ___ >> > WiX-users mailing list >> > WiX-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wix-users >> > >> > >> > >> > >> -- >> > ___ >> > WiX-users mailing list >> > WiX-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wix-users >> > >> >> -- >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> >> -- >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___
Re: [WiX-users] Using Wix and Visual Studio
Multiple times. It always comes back yellow. There's no tooltip to provide any further feedback. (Also, I've tried this with a separate dummy project - I get the same problem.) -Original Message- From: Christopher Karper [mailto:christopher.kar...@gmail.com] Sent: Friday, April 03, 2009 11:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using Wix and Visual Studio That is VS saying the reference is invalid somehow. I'm not sure what the specific problem is, but have you tried deleting the reference and recreating it? Sorry I can't do more to help right now, but I'm wrestling TFS and Team Build, and it's winning. Chris On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) < eric.br...@microsoft.com> wrote: > Also, there is that yellow warning icon on the project reference. I don't > know what that means, and I can't find a reference in the documentation. > > -Original Message- > From: Christopher Karper [mailto:christopher.kar...@gmail.com] > Sent: Friday, April 03, 2009 10:17 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Using Wix and Visual Studio > > I use spaces in my project names and project references, and they're all > fine. > I suspect his problem is something else. I'm not sure what that is, since > this exact scenario, even down to the environment seems to match. > > Chris > > On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) < > eric.br...@microsoft.com> wrote: > > > Tried using underscores and renaming; still get the same error (CNDL0150: > > Undefined preprocessor variable). > > > > -Original Message- > > From: Jason Ginchereau [mailto:jason...@microsoft.com] > > Sent: Thursday, April 02, 2009 5:55 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > > Any characters in the project name that are invalid for WiX preprocessor > > variable names get automatically converted to underscores. So without > > renaming the project this should work: > > > > $(var.My_Test_Project.TargetFilename) > > > > > > -Original Message- > > From: Alex Cater [mailto:alex.ca...@apdcomms.com] > > Sent: Thursday, April 02, 2009 4:28 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > > > > I'm guessing that you cannot have spaces in a project reference > variable... > > > > $(var.My Test Project.TargetFileName) > > > > Try renaming your test project to MyTestProject so the project reference > > variable becomes: > > > > $(var.MyTestProject.TargetFileName) > > > > -- > > View this message in context: > > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Unable to remove website during uninstall
I have this wxs file to install binarys and a website in IIS. The installation works fine. But just during uninstall, only the binary folders are removed. The IIS website remains there (though the status becomes unknown). I tried the verbose log, but didn't see any error/warning there. Can someone give me some help/hints? More generally, besides logging, is there any debugger for wix? Thank you very much. http://schemas.microsoft.com/wix/2006/wi"; xmlns:util=" http://schemas.microsoft.com/wix/UtilExtension"; xmlns:iis=" http://schemas.microsoft.com/wix/IIsExtension";> ... -- Cheers, Gang Cheng -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
That is VS saying the reference is invalid somehow. I'm not sure what the specific problem is, but have you tried deleting the reference and recreating it? Sorry I can't do more to help right now, but I'm wrestling TFS and Team Build, and it's winning. Chris On Fri, Apr 3, 2009 at 1:24 PM, Eric Brown (REDMOND) < eric.br...@microsoft.com> wrote: > Also, there is that yellow warning icon on the project reference. I don't > know what that means, and I can't find a reference in the documentation. > > -Original Message- > From: Christopher Karper [mailto:christopher.kar...@gmail.com] > Sent: Friday, April 03, 2009 10:17 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Using Wix and Visual Studio > > I use spaces in my project names and project references, and they're all > fine. > I suspect his problem is something else. I'm not sure what that is, since > this exact scenario, even down to the environment seems to match. > > Chris > > On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) < > eric.br...@microsoft.com> wrote: > > > Tried using underscores and renaming; still get the same error (CNDL0150: > > Undefined preprocessor variable). > > > > -Original Message- > > From: Jason Ginchereau [mailto:jason...@microsoft.com] > > Sent: Thursday, April 02, 2009 5:55 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > > Any characters in the project name that are invalid for WiX preprocessor > > variable names get automatically converted to underscores. So without > > renaming the project this should work: > > > > $(var.My_Test_Project.TargetFilename) > > > > > > -Original Message- > > From: Alex Cater [mailto:alex.ca...@apdcomms.com] > > Sent: Thursday, April 02, 2009 4:28 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > > > > I'm guessing that you cannot have spaces in a project reference > variable... > > > > $(var.My Test Project.TargetFileName) > > > > Try renaming your test project to MyTestProject so the project reference > > variable becomes: > > > > $(var.MyTestProject.TargetFileName) > > > > -- > > View this message in context: > > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
On Fri, Apr 3, 2009 at 8:24 PM, Eric Brown (REDMOND) wrote: > Also, there is that yellow warning icon on the project reference. I don't > know what that means, and I can't find a reference in the documentation. Normally that means that Visual Studio has failed to resolve the reference -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
Also, there is that yellow warning icon on the project reference. I don't know what that means, and I can't find a reference in the documentation. -Original Message- From: Christopher Karper [mailto:christopher.kar...@gmail.com] Sent: Friday, April 03, 2009 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using Wix and Visual Studio I use spaces in my project names and project references, and they're all fine. I suspect his problem is something else. I'm not sure what that is, since this exact scenario, even down to the environment seems to match. Chris On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) < eric.br...@microsoft.com> wrote: > Tried using underscores and renaming; still get the same error (CNDL0150: > Undefined preprocessor variable). > > -Original Message- > From: Jason Ginchereau [mailto:jason...@microsoft.com] > Sent: Thursday, April 02, 2009 5:55 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Using Wix and Visual Studio > > Any characters in the project name that are invalid for WiX preprocessor > variable names get automatically converted to underscores. So without > renaming the project this should work: > > $(var.My_Test_Project.TargetFilename) > > > -Original Message- > From: Alex Cater [mailto:alex.ca...@apdcomms.com] > Sent: Thursday, April 02, 2009 4:28 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > I'm guessing that you cannot have spaces in a project reference variable... > > $(var.My Test Project.TargetFileName) > > Try renaming your test project to MyTestProject so the project reference > variable becomes: > > $(var.MyTestProject.TargetFileName) > > -- > View this message in context: > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html > Sent from the wix-users mailing list archive at Nabble.com. > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
I use spaces in my project names and project references, and they're all fine. I suspect his problem is something else. I'm not sure what that is, since this exact scenario, even down to the environment seems to match. Chris On Fri, Apr 3, 2009 at 12:29 PM, Eric Brown (REDMOND) < eric.br...@microsoft.com> wrote: > Tried using underscores and renaming; still get the same error (CNDL0150: > Undefined preprocessor variable). > > -Original Message- > From: Jason Ginchereau [mailto:jason...@microsoft.com] > Sent: Thursday, April 02, 2009 5:55 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Using Wix and Visual Studio > > Any characters in the project name that are invalid for WiX preprocessor > variable names get automatically converted to underscores. So without > renaming the project this should work: > > $(var.My_Test_Project.TargetFilename) > > > -Original Message- > From: Alex Cater [mailto:alex.ca...@apdcomms.com] > Sent: Thursday, April 02, 2009 4:28 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Using Wix and Visual Studio > > > I'm guessing that you cannot have spaces in a project reference variable... > > $(var.My Test Project.TargetFileName) > > Try renaming your test project to MyTestProject so the project reference > variable becomes: > > $(var.MyTestProject.TargetFileName) > > -- > View this message in context: > http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html > Sent from the wix-users mailing list archive at Nabble.com. > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Wix and Visual Studio
Tried using underscores and renaming; still get the same error (CNDL0150: Undefined preprocessor variable). -Original Message- From: Jason Ginchereau [mailto:jason...@microsoft.com] Sent: Thursday, April 02, 2009 5:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using Wix and Visual Studio Any characters in the project name that are invalid for WiX preprocessor variable names get automatically converted to underscores. So without renaming the project this should work: $(var.My_Test_Project.TargetFilename) -Original Message- From: Alex Cater [mailto:alex.ca...@apdcomms.com] Sent: Thursday, April 02, 2009 4:28 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using Wix and Visual Studio I'm guessing that you cannot have spaces in a project reference variable... $(var.My Test Project.TargetFileName) Try renaming your test project to MyTestProject so the project reference variable becomes: $(var.MyTestProject.TargetFileName) -- View this message in context: http://n2.nabble.com/Using-Wix-and-Visual-Studio-tp2578030p2578131.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unexpected supersedence behavior
Conditions are only evaluated at initial install unless they are transitive. To better diagnose the issue, do you have verbose install logs from installing QFE2 and SP1? On Fri, Jan 2, 2009 at 10:34 AM, Ryan Parlee wrote: > > I am trying to understand why some things are not behaving the way I > expect. > I have the following packages: > >MNP2000.msi (v.1.40) >MNP2000-QFE1.mcp (targeted on v1.40, patch sequence = 1.40.1, > supersedence = no) >MNP2000-QFE2.mcp (targeted on v1.40, patch sequence = 1.40.2, > supersedence = no) >MNP2000-SP1.mcp (targeted on v1.40, patch sequence = 1.41.0, > supersedence = yes, upgrades ProductVersion = 1.41) > > In the packages above, QFE1 updates the Concert.txt file. QFE2 removes the > Dance.txt file by updating the Dance component condition with 1=0. SP1 > contains the fixes in QFE1 but keeps the Dance component with condition > 1=1. > > > The problem I am having is that when SP1 is applied the Dance.txt file does > not get reinstalled. > > Additional notes: > > 1. Dance.txt does correctly reinstall if I remove both SP1 and then QFE2. > > 2. I am getting what I believe to be correct experience from within > appwiz.cpl: > - Initial Install: MNP2000 [version = 1.40] > - After install QFE1:MNP2000 + QFE1 [version = 1.40] > - After install QFE2:MNP2000 + QFE1 + QFE2 [version = 1.40] > - After install SP1:MNP2000 + SP1 [version = 1.41] > - After uninstall SP:MNP2000 + QFE1 + QFE2 [version = 1.40] > ... > > What I think is happening is that the diff between Initial Install and SP1 > that is recorded in the SP1 patch does not contain data to restore the > condition of the Dance component to 1=1. > > > So my question is: How do I get SP1 to work the way I want? Shouldn't the > installation of SP1 remove prior patches because its supersedence bit it > set? If it worked that way, Component(Dance).Condition would be restored > to > 1=1. What am I missing? > *** > > > Thanks, > Ryan Parlee > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Letters in ProductVersion
Along those same lines, you should consider never using the ProductVersion property in your installation for things like directories or registry keys (if you change them in a major upgrade, you break component rules). That said, you might consider not showing the ProductVersion property for the same reason (keep this purely MSI concept separate from your product display). So define a new property like AppProductVersion that you can set however you like and change whenever you like without negative ramification to Windows Installer. On Tue, Jan 6, 2009 at 6:39 PM, Michael Osmond wrote: > Hi, > > The approach I would recommend is try not to put so much meaning into > the version number. Make the MSI version number something simple, which > always changes. > > We have deliberately restricted things to Major.Minor.build for the MSI > version number. Internally the buil number is rolled every time > anything changes, so nothing would be released that would not be > different (well almost but that's a different story). > > If you want or need the other information put it somewhere else - in a > reg key, in the product name in Add/Remove programs, in the Summary > Information. > > Michael > > > -Original Message- > From: lesterbangs [mailto:datapa...@gmail.com] > Sent: Wednesday, 7 January 2009 11:26 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Letters in ProductVersion > > > > Polite bump on this... > Am I approaching this from the wrong angle? I mean, I know I can easily > add a registry entry with the version string in any format I want, but I > am more concerned about how to identify the product in x.y.z format in > order for upgrades to work. > There must be someone else here that has to deal with weird product > versions... > > lesterbangs wrote: > > > > Our product versions mostly conform to the major.minor.build > > convention specified by the MSI standard, but sometimes we have to put > > > letters in the strings to indicate an update or "hotfix", i.e. > 1.0.5.U1 or 2.4.16.HF02. > > > > Obviously this is a big no-no to have letters in ProductVersion > property. > > Worse, sometimes we have updates to hotfixes, or vice-versa, such as > > 3.1.72.U1.HF04. > > > > I imagine we would have to come up with some sort of "translation > table" > > to convert a numbers-letters string to a pure numbers string that MSI > > can understand. I.e. 2.4.16.HF02 becomes 2.4.1602 and 1.0.5.U1 becomes > > > 1.0.5100. > > > > According to the specification, Windows Installer ignores anything > > after the 3rd field. So even if we were able to change it to all > > numbers, > > 3.1.72.U1.HF04 would become 3.1.72.01.04, but only 3.1.72 would be > > recognized. 3.1.720104 would also not work, as field 3 cant be larger > > than 65536. 3.1.7214 would work but only for update numbers less than > 10. > > > > This could get confusing very fast. Is anyone in a similar situation? > > What is the easiest way to mitigate this issue? > > > > -- > View this message in context: > http://n2.nabble.com/Letters-in-ProductVersion-tp2113603p2120366.html > Sent from the wix-users mailing list archive at Nabble.com. > > > > -- > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstalling not default transform instances
As long as your shared resources are in a component with the same GUID (i.e., your instance transforms do not re-GUID your components) yes, Windows Installer (and fusion for GAC assemblies) do keep a reference count. Bear in mind, however, that if you uninstall a patch for any instance files are downgraded (shared component ref counts don't guard against that) *unless*you are installing with MSI 4.5 and specify the Component/@Shared="yes" attribute. If you are applying your instance transforms as secure transforms (transfor...@emea_instance) you do not need to specify them again even during uninstall. When you look in a verbose installer log (msiexec.exe ... /L*vx install.log) does the log say the action was skipped because the condition evaluated to false? After a product is installed (after InstallFinalize returns) the property Installed should always be defined. On Tue, Jan 13, 2009 at 4:35 PM, wrote: > I have created a number of instance transforms in my WiX installer as > below: > > > > > ProductCode="4E7CC0E0-BECC-4e79-A626-20028B93C8C9" ProductName="MSS DAO > Windows Service" Id="DAO_Instance"/> > ProductCode="3F164DA9-8C57-49e9-9346-A06DA9B5580D" ProductName="MSS EMEA > Windows Service" Id="EMEA_Instance"/> > ProductCode="35646A8B-F991-44b1-AAE8-57DF08B30272" ProductName="MSS APJ > Windows Service" Id="APJ_Instance"/> > > > ProductCode="14CAA264-8CF9-48d8-B174-0A5B298C561E" ProductName="MSS DAO > UAT Windows Service" Id="DAO_UAT_Instance"/> > ProductCode="CD94A497-0091-4522-AD60-E21A7CFBDFF0" ProductName="MSS EMEA > UAT Windows Service" Id="EMEA_UAT_Instance"/> > ProductCode="2D226523-ADF4-40fa-BA1E-624FE84EF1CF" ProductName="MSS APJ > UAT Windows Service" Id="APJ_UAT_Instance"/> > > > When uninstalling one of these non-default instances, I need to make > sure that my custom actions get run. Most of the time I will be leaving > other instances on the machine. > > > After="InstallFinalize">Installed > > This custom action does not run when uninstalling with msiexec /u > TRANSFORMS="EMEA_Instance ... > > However, the rest of the app instance gets uninstalled fine. Does > someone know the correct condition to use? > > On a related note when GACd assemblies and shared COM objects are > removed for one instance, does the MSI and/or windows keep a usage count > so that other instances are not broken? > > Thanks. > > - Phil > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem reading Environment variables
The documentation for the WriteEnvironmentStrings action @ http://msdn2.microsoft.com/library/aa372883.aspx state that the variables are not effective in the current installation. So when you launch your console app from the installer process the environment variables are inherited from the installer process which will not include your new environment variables. On Fri, Apr 3, 2009 at 3:21 AM, sandun css wrote: > Hi, > > I set few environment variables from my wix installer, and refer them from > a > console application (C#), whcih gets launched at the end of my WiX > installer. (I have a custom action to launch that console app, when the > user > presses the 'Finish' button of the msi) > > But my console application fails to read the env. variables set by the msi. > When I look at the env varibles (from 'control panel -> System -> Advanced > System settings -> Env variables'), I can see them as well. > > I am using Windows Server 2008. > > Can you please advice me on this? > > Thanks, > Sandun > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] We are getting some unexpected and undesirable behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see if we are doing something wrong.
Thanks for responses. 1. setting the SKIPCONFIGUREIIS property via an immediate CA (scheduled prior to ConfigureIIs of course) to simply skip IIS configuration when the target host already has the website installed would require us having some way to determine if the target host already has the website installed wouldn't it? Is there some wix syntax supporting that check? Also wouldn't doing this actually cause not only our AppPool and WebSite settings from not being applied but also all of our iis:WebVirtualDir and iis:WebApplication settings that we do want to recreate every time as we do remove those components during uninstall. 2. the addition of the ConfigureIfExists="no" option to our iis:WebSite element sounds promising since it sounds like it may prevent the activity that is traversing any of the child vdirs that someone may have added to the website, outside of what our installer creates, and resetting their appPool setting to whatever is defined for the iis:WebSite. Presumably setting this iis:WebSite attribute doesn't preclude processing of our iis:WebVirtualDir and iis:WebApplication settings that we do want to recreate every time as we do remove those components during uninstall. -Original Message- From: Rob Mensching [mailto:r...@wixtoolset.org] Sent: Thursday, April 02, 2009 10:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] We are getting some unexpected and undesirable behavior from iis:WebAppPool and iis:WebSite extensions, just checking to see if we are doing something wrong. Also, WebSite has a ConfigureIfExists property. AppPool though probably always sets its settings so Alex's suggestion below may be the nuke you need. Alex Cater wrote: > The condition for ConfigureIIs (the scheduling CA) is: > > NOT SKIPCONFIGUREIIS AND VersionNT > 400 > > You could set the SKIPCONFIGUREIIS property via an immediate CA (scheduled > prior to ConfigureIIs of course) to simply skip IIS configuration when the > target host already has the website installed. > > > -- > View this message in context: > http://n2.nabble.com/We-are-getting-some-unexpected-and-undesirable-behavior-from-iis%3AWebAppPool-and-iis%3AWebSite-extensions%2C-just-checking-to-see-if-we-are-doing-something-wrong.-tp2577603p2578018.html > Sent from the wix-users mailing list archive at Nabble.com. > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] GroupBox Text Color
Hi, Im trying to change the default blue color of groupbox text, but no
success.
Tried to apply other font with other colors but still default blue
{\WixUI_Font_Normal}Modelos e Recomendações
Arthur Curvello
arthur.curve...@conv.com.br
tel +55 21 2494-5476
cel +55 21 9762-4284
Confidencialidade: A informação contida nesta mensagem de e-mail, incluindo
quaisquer anexos, é confidencial e está reservada apenas à pessoa ou
entidade para a qual foi endereçada. Se você não é o destinatário ou a
pessoa responsável por encaminhar esta mensagem ao destinatário, você está,
por meio desta, notificado que não deverá rever, retransmitir, imprimir,
copiar, usar ou distribuir esta mensagem de e-mail ou quaisquer anexos. Caso
você tenha recebido esta mensagem por engano, por favor, contate o remetente
imediatamente e apague esta mensagem de seu computador ou de qualquer outro
banco de dados. Grato.
Confidentiality Notice: The information contained in this email message,
including any attachment, is confidential and is intended only for the
person or entity to which it is addressed. If you are neither the intended
recipient nor the employee or agent responsible for delivering this message
to the intended recipient, you are hereby notified that you may not review,
retransmit, convert to hard copy, copy, use or distribute this email message
or any attachments to it. If you have received this email in error, please
contact the sender immediately and delete this message from any computer or
other data bank. Thank you.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction following specific CustomAction fails
I was on vacation during that time in February, so I missed this thread until
Jesper brought it to my attention privately.
I think this problem was a bug in DTF, #2710297 on SourceForge. The bug was
that DTF CAs could fail to launch when a previous CA changed the working
directory (because MSI recycles the CA process). In this case, the browse
dialog in the C++ CA was changing the working directory of the process.
Normally there would be some more messages in the log about the DTF CA failing
to launch, except CAs cannot write to the log when called from a DoAction
control event.
Fortunately, I fixed that bug last week. Unfortunately, there wasn't a build
published last week, I'm not sure why. Please try this week's WiX build
3.0.5203, it should be published later today.
-Jason-
-Original Message-
From: jballe [mailto:j...@visionpeople.dk]
Sent: Wednesday, February 25, 2009 11:37 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction following specific CustomAction fails
Both customactions are executed during UI for the mentioned buttons
(browsefile and execute managed action) I publish the DoAction.
The original problem was:
In the UI the user can select to install a license file. I have a C++
customaction which opens the OpenFile dialog and sets it to a property.
Later in the UI is invoked some managed CustomActions for IIS or MSMQ stuff
depending on the user's selections.
If the C++ customaction is run the next customaction (no matter which one)
fails with the error code 2896 (Executing action xxx failed). If the C++
custom action is not run, it works as it is supposed to.
I have created this small project with an almost empty managed action (it
just opens a messagebox) and it is clear that if I select a file in the
browsedialog action, the installer fails when the managed action should
execute (but the messagebox is not displayed). The messagebox shows
correctly if i open the browse dialog and not select a file (just canelling
the dialog) or if I not press the browsefile button.
John Nannenga wrote:
>
> Your CA isn't running because although you've defined the custom action
> within Product.wxs you haven't scheduled it for execution (you have no
> sequences defined which would invoke your CA).
>
> For example...
>
> .
> .
> .
>
>After="LaunchConditions">1
>
>
>
>
> -Original Message-
> From: jballe [mailto:j...@visionpeople.dk]
> Sent: Wednesday, February 25, 2009 2:29 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] CustomAction following specific CustomAction
> fails
>
>
> Can I do anything to find out what is happening in this install project. I
> guess the OpenDialog customaction seems okay, with the change Rob
> suggested.
> Yan, you had a good suggestion but it doesn't seems like the managed
> action
> is actually invoked.
>
> My guess is that it is related to the action invoking the managed action
> (is
> it the part called DTF?) but I do not have a clear understanding of what
> is
> going on.
> Does it make sense to try some kind of weekly build pr anything?
> Can I do anything to find out, ask anyone or can I do anything?
>
> Thank you!
>
> Kind regards,
> Jesper
>
>
> jballe wrote:
>>
>>
>> I have created a small test project with only the parts related to this
>> from
>> my original project.
>> It includes my c++ customaction and I think the smallest manged
>> CustomAction
>> possible:
>>
>> [CustomAction]
>> public static ActionResult TestAction(Session session)
>> {
>> session.Log("Begin MyTestAction");
>> System.Windows.Forms.MessageBox.Show("Stop for debugging:
>> MyManagedTestCA", Process.GetCurrentProcess().ProcessName);
>>
>> return ActionResult.Success;
>> }
>>
>> I have included two custom dialogs. The one I use for my openfiledialog
>> (jumping betweeen two identical dialogs to reflect the property change)
>> and
>> a dialog with a button to start the managed custom action.
>>
>> If I open my oopenfiledialog, selects a file and starts the custom action
>> the managed custom action fails before showing the message box.
>> If I don't open the dialog and - I just found out - if I open the dialog
>> but
>> don't select a file, the messagebox shows correctly.
>>
>> Does that make any kind of sense? I attach the solution and project
>> including binaries (in all 1,32 MB):
>> http://www.nabble.com/file/p21980336/TestProject.zip TestProject.zip
>>
>> I really appreciate your help.
>>
>> Kind regards
>> Jesper
>>
>>
>
> --
> View this message in context:
> http://n2.nabble.com/CustomAction-following-specific-CustomAction-fails-tp2292259p2382577.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles th
[WiX-users] Multiple file extensions per ProgID
The following code causes MyApp.wxs(MyLineNo) : error LGHT0130 : The primary key 'regCEECC3C927D10BCB192BEE13F4F46715' is duplicated in table 'Registry'. Please remove one of the entries or rename a part of the primary key to avoid the collision. ... Removing one of the Extension elements fixes this error. The application has two extensions since we need to support the old three letter extension that many users' files still use while new documents are created with a longer extension that does not conflict with Windows Media Player. The Wix documentation indicates that multiple Extension elements are supported. Am I doing anything wrong? TIA, Nathan -- View this message in context: http://n2.nabble.com/Multiple-file-extensions-per-ProgID-tp2580359p2580359.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional installation of different versions of a DLL
Hello, I tried to redo what I did in my first attempt and now get the following warnings (although I think my first attempt resulted in some error): C:\Code\SVN\Deployment\CoreRelease.wxs(106): warning LGHT1076: ICE30: The target file 'snyxsaz9.dll|PropertyDB-DL might be installed in '[ProgramFilesFolder]\Products\EXE\' by two different conditionalized components on an LFN system 'PropertyDB_DLL_10g.dll' and 'PropertyDB_DLL_920.dll'. If the conditions are not mutually exclusive, this will break the component eference counting system. C:\Code\SVN\Deployment\VtPlanCoreRelease.wxs(100): warning LGHT1076: ICE30: The target file 'snyxsaz9.dll|PropertyDB-DL might be installed in '[ProgramFilesFolder]\Products\EXE\' by two different conditionalized components on an LFN system 'PropertyDB_DLL_10g.dll' and 'PropertyDB_DLL_920.dll'. If the conditions are not mutually exclusive, this will break the component Reference counting system. Probably I can live with the warning and keep an eye on the consistency of my conditions. Lars -Ursprüngliche Nachricht- Von: "Rob Mensching" Gesendet: 03.04.09 07:34:45 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Conditional installation of different versions of a DLL Can you be more specific about the error? Is it an ICE error or ICE warning or some other error? Lars von Wedel wrote: > Hello, > > I am trying to install different versions of a DLL depending on the > version of a further application on the target machine. > > I tried to define two components that contain files for the same > output DLL and conditionally install either component > based on a condition to be figured out by the installer. > > Unfortunately light.exe tells me, that this will break component > reference counting. > > What is the correct way to install different versions of a DLL figured > out at installation time ? > > Thanks in advance, > Lars > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Edit Configuration file
This will completely break silent / unatended installations. You should prompt the user in your installer UI using public properties (they can pass to the installer whether running silent, basic, or reduced UI (required then) or in full UI (just defaults then). WiX does have custom actions for updating an XML file, but the format of the XML file is completely up to you. XML defines no standard schema, so your service can read whatever XML schema it needs. It could be incredibly simple like: http://foo bar So if you needed to customize and , you can use WiX's XmlConfig elements using propeties passed from the UI. Bringing up notepad is ot a good user experience, nor is it always possible. On Thu, Apr 2, 2009 at 4:04 AM, Niaz Khan wrote: > > > > Hi, > > I need some help on wix. The installer works fine it installs the service > and then starts the service. The service starts as soon as it is installed. > i want to launch a notepad (Configuration file) in the middle of service > install and start. > Ideally I want that when the installation of service is completed the > installer should lanunch the notepad rather than starting the service > directly and when the user edits and save the notepad then it should start > the service. > I am able to launch the notepad on the exit dialog with a checkbox but i > want it to be launched in the middle of service install and start. > I am not quite sure if it is possible in wix. > After some research on the internet I found that has been used to > edit the config files, but I am not quite sure of using this one because my > config file has multiple sub elements for some elements. I think this > approach is better when we have to edit small number of values. > > I am not sure if someone has used approach for large config file, > any other alternatives or ideas will be really appreciated. > > cheers. > > > > Niaz > > > > > > This e-mail is intended only for the above addressee. It may contain > privileged > information. If you are not the addressee you must not copy, distribute, > disclose > or use any of the information in it. If you have received it in error > please delete > it and immediately notify the sender. > > PureCM.com Limited. Registered in England and Wales. > Company Number : 0505 3024 > > Registered Office : Charter House, Charter Way, Hurdsfield, Macclesfield, > Cheshire. SK10 2NG > > > > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem reading Environment variables
Hi, I set few environment variables from my wix installer, and refer them from a console application (C#), whcih gets launched at the end of my WiX installer. (I have a custom action to launch that console app, when the user presses the 'Finish' button of the msi) But my console application fails to read the env. variables set by the msi. When I look at the env varibles (from 'control panel -> System -> Advanced System settings -> Env variables'), I can see them as well. I am using Windows Server 2008. Can you please advice me on this? Thanks, Sandun -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Best Practice for using Variables
Hi All, i am stumbling around with my first Wix Project using variables. Could someone explain when i had to use $(var.xyz) and !(loc.abc)? Why i couldn't write things like that in my Directory Attribute? Error: Undefined preprocessor variable '$(var.abc)'. Error: The Directory/@Id attribute's value, 'unique_id!(loc.abc)', is not a legal identifier. Why i couldn't write $(var.name) in my Source Attribute, but !(loc.name) works? All "var"s are defined in a include.wxi not in a .wixproj file All "loc" are defined in WixLocalization file. Wix Version 3.0.5120.0 <3.0.5120.0/> Best regards Kai-Uwe -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] EventSource EventMessageFile and NETFRAMEWORK20INSTALLROOTDIR
That did the trick - I had a feeling it would turn out to be something pretty simple..! Thanks Neil Have you include in you code? Neil -Original Message- From: Paul Nearney [mailto:paul_near...@hotmail.com] Sent: 02 April 2009 17:07 To: wix-users@lists.sourceforge.net Subject: [WiX-users] EventSource EventMessageFile and NETFRAMEWORK20INSTALLROOTDIR Hi all, I suspect there may be a really simple answer to this (I am new to WiX) - I am struggling to get the NETFRAMEWORK20INSTALLROOTDIR property to work in the EventMessageFile attribute of an EventSource. I am using the VS2008 integration for WiX, and have added a reference to WixVSExtension.dll. I have also referenced the namespace like so: http://schemas.microsoft.com/wix/2006/wi"; xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension"; > In my component, I am trying to create an event log source using the following: When installed, the event log source gets created, but the EventMessageFile entry in the source's registry key is set to "EventLogMessages.dll", rather than "C:\Windows\...blah...\EventLogMessages.dll". If I use [WindowsFolder] in the EventMessageFile attribute, this resolves to C:\Windows correctly. If it helps, using Orca to look at the MSI shows the registry value as being "#%[NETFRAMEWORK20INSTALLROOTDIR]EventLogMessages.dll" - I don't yet know enough to know if this is correct or not. Could this be because [NETFRAMEWORK20INSTALLROOTDIR] is defined in a different namespace to the doc I am using it in? Thanks, Paul _ View your Twitter and Flickr updates from one place - Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/EventSource-EventMessageFile-and-NETFRAMEWORK20INSTALLROOTDIR-tp2576086p2579754.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent downgrading when doing Minor Upgrade
I assume you mean a minor upgrade MSI, since for a patch this shouldn't be a problem unless you're using a minor upgrade MSP with bad validation bits targeting newer ProductVersions). A minor upgrade MSI won't apply by default. It has to be reinstalled - explicitly setting the REINSTALL property (or using msiexec /f, which is equivalent); optionally, REINSTALLMODE will contain "v" to cache the minor upgrade (otherwise the ProductVersion will not change and a subsequence repair will regress files). So whatever bootstrap application you're using to conditionally install the minor upgrade MSI - can't that check the product version of what's already installed? Seems you're doing something along these lines anyway to detect if the product is installed. If using MsiGetProductInfo(Ex)() for example, get the INSTALLPROPERTY_VERSIONSTRING property. You can then compare that with the ProductVersion you're trying to install and determine if they're newer. On Thu, Apr 2, 2009 at 5:46 PM, Rajesh P wrote: > Hi > > Is there a way iw WiX to prevent downgrade with minor upgrades. > Can we write a custom action to verify and compare installed product > version. If yes, can someone suggest some Msi api's that can use in my VC++ > custom action dll. > Is there any other easier way to achieve this. > > Thanks, > Rajesh > > -- > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Kevin Zhang is out of the office.
I will be out of the office starting 04/03/2009 and will not return until 04/26/2009. I will respond to your message when I return. If anything urgent, please contact Brad Smith -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Check for IIS application pools
Hello, can i check for an installed IIS and list the available application pools? The avaliable application pools should be listed in a listbox control. Thanks Thomas Bahn -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to start an existing service
So I guess the answer is that I have to write a custom action!? Chris Does it still do this if the "wait" value is zero? (or no). It won't start it, but I'm wondering if it will still be catastrophic. Phil Wilson -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Thursday, April 02, 2009 2:41 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to start an existing service Yep. Boils up to the "Verify you have sufficient privileges to start..." -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Thursday, April 02, 2009 1:42 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to start an existing service You can't start a disabled service, it is disabled. You have to set it to Manual or Automatic before it can be started. Neil -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 02 April 2009 20:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to start an existing service Hey Phil - I'm wondering if ServiceControl can work on a Disabled service, though. OP seemed to indicate the service is disabled by default, which I see on my XP box here as being the case, too. I'm writing a sample install that tries to start a Disabled service to see how it reacts. Chad -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: Thursday, April 02, 2009 12:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to start an existing service You should be able to do this with a ServiceControl element. I don't know the WiX details, but the ServiceControl table in MSI is not directly connected to installing that service. Phil Wilson -Original Message- From: Gremlin [mailto:postingpl...@gmail.com] Sent: Thursday, April 02, 2009 4:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to start an existing service Hello, I want to start the service NetTcpPortSharing which is installed (and set to disabled) with the installation of the .Net 3.5 framework. How can I start the service in my installation? Is it possible with the ServiceInstall/ServiceControl - tags? I tried this, but I got an error... Thank's, Chris -- View this message in context: http://n2.nabble.com/How-to-start-an-existing-service-tp2574657p2574657. html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/How-to-start-an-existing-service-tp2574657p2579412.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
In a verbose log Windows Installer 3.1+ will add a line line "SELMGR: A component *foo* is registered to feature *bar*, but was removed from the feature.", followed immediately by something like "SELMGR: Removal of components from a feature is not supported." But this will not fail the patch. Instead it will advertise the feature and the content of that feature will never be repaired again. See http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx for more information. MSIENFORCEUPGRADECOMPONENTRULES merely turns that into an error, so instead of silently breaking the product the property (and the corresponding machine policy) will fail the install. So a small update or minor upgrade patch will apply if you break this component violation, but the feature will forever be broken until explicitly added back into the local state. See http://blogs.msdn.com/heaths/archive/2009/01/27/repairing-products-after-patches-advertised-features.aspxfor some suggestions of how to do that. On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic wrote: > It just goes to show how easy it is to commit gross component rules > violations even after months of reading articles and blogs on component > rules! > > However, it seems that I have also misunderstood the purpose of > MSIENFORCEUPGRADECOMPONENTRULES property. I was under the impression > that it would add to verbose log. I mean, if MSI *knows* that there is > component violation, it would be of great help if it could add a > sentence to the log saying at least something along the lines of: > There is component rules violation of some sort! > > After reading all that I could find on MSIENFORCEUPGRADECOMPONENTRULES > property I can't say that I am 100% sure about what is it that it really > does? How can the consequences of having this property defined or not be > seen on some practical example? I was certainly none the wiser in this > specific case since verbose logs were identical with or without it, for > all that I could see. > > It *seems* that a small update patch may be applied by MSI in some cases > even if there was a component rule violation and this property prevents > it. > > -Original Message- > From: Bob Arnson [mailto:b...@joyofsetup.com] > Sent: Saturday, August 02, 2008 1:10 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version > number? > > Tony Juricic wrote: > > but reading the install.log I cannot find anything a bit more explicit > > about this violation. It is certainly not saying something like "you > > changed the name of your root installation folder and you shouldn't" > :) > > > > Sorry, it's not that polite. The "Windows Installer Components" topic > > summarizes the magic of component rules with two bullets: > >In brief, these rules are: > >* Each component must be stored in a single folder. >* No file, registry entry, shortcut, or other resources should > ever be shipped as a member of more than one component. This > applies across products, product versions, and companies. > > So changing the directory violates 50 percent of the component rules. > > -- > sig://boB > http://joyofsetup.com/ > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New wix binary delta patching doesn't work
Are you still having the same problem with recent builds? A month or two ago
changes were made to fix a couple of issues with delta patching.
On Tue, Aug 19, 2008 at 5:57 AM, Tony Juricic wrote:
> Ok, that makes sense. However, I can't get it to work either way. The
> problem is not in changing just the 4th version number either. I created
> a simple C# console executable that has one line of code:
>
> Console.Writeln("This is version 1.0.0.0");
>
> and assembly info AssemblyVersion("1.0.0.0")] and
> AssemblyFileVersion("1.0.0.0")].
>
> I build WiX test project referencing this program with -bf -xo linker
> options.
>
> The output is WixTest1.msi but it is not msi file since it can't be
> opened with Orca. Is it wixpdb or wixout? Torch doesn't like wixpdb
> extension (error TRCH0048) but accepts wixout.
>
> I then update console program by changing all the strings 1.0.0.0 above
> to 1.0.1.0, then rebuild exe and WiX project, changing also Product
> element, Version attribute to 1.0.1.0. This gives me the second wixout
> file for input to torch and I get 31 KB large Diff.wixmst.
>
> When I run Pyro it comes with PYRO0252 error meaning that it can't find
> any transform.
>
> Torch and Pyro invoking batch files content is the following:
>
> "%WIX%bin\torch.exe" -p -xi -v -val g -val l -val r -val z
> Version1000\WiXTest1000.wixout Version1010\WiXTest1010.wixout -out
> Patch\Diff.Wixmst
>
> "%WIX%bin\candle.exe" Patch.wxs
> "%WIX%bin\light.exe" Patch.wixobj -out Patch\Patch.WixMsp
> REM "%WIX%bin\pyro.exe" -delta Patch\Patch.WixMsp -out Patch\Patch.msp
> -t RTM Patch\Diff.wixmst
> "%WIX%bin\pyro.exe" Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM
> Patch\Diff.wixmst
>
> Note above REMarked -delta option.
>
> Patch.wxs content is:
>
>
> http://schemas.microsoft.com/wix/2006/wi";>
> ClientPatchId="WiXTest1" Id="*" DisplayName="WiXTest1 Update"
> Manufacturer="WiXTest1" MoreInfoURL="http://www.WiXTest1.com";
> Description="Minor Update Patch" TargetProductName="WixTest1">
> Source="FIRSTPATCH_PROP">
>
>
>
>
>
>
>
> Supersede="no">
>
>
>
>
>
>
> Obviously, I am doing something horribly wrong in my adaptation of Peter
> Marcu's blog example or there is a nasty bug somewhere in there.
>
>
> -Original Message-
> From: Blair Murri [mailto:bmu...@microsoft.com]
> Sent: Monday, August 11, 2008 1:56 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] New wix binary delta patching doesn't work
>
> The "-delta" switch of pyro builds on top of the whole-file patch
> support in pyro, so if that isn't working, the delta addition won't do
> anything to help you.
>
> If you get pyro to build a whole file patch that updates your binaries,
> then add the -delta switch and test the results.
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
What version of WiX v3 are you using. A while back I made a change to support the actual database schema so if your MSIs don't match the schema WiX expects it shouldn't be a problem. Now, if your target and upgrade database schemas different the error is there because Windows Installer will fail to install such a patch and it's really hard to diagnose. Rather than failing with an error message stating something like, "The transform is invalid", the database will be garbled within the transform and the failure code could be almost anything depending on what data is garbled and when it's used. Transforms - and by extension patches, since they just contain a bunch of transforms - cannot change the database schemas except to add a new column or a new table. See https://blogs.msdn.com/heaths/archive/2007/09/01/column-types-cannot-be-changed-in-a-patch-or-transform.aspxfor more information. On Sun, Sep 14, 2008 at 1:28 PM, Robert O'Brien wrote: > Thanks that appears to be exactly what my issue was with my adminInstall > output. I used orca to reconfigure the feature level settings in my v1.0 > msi so I could generate a useable adminInstall of it and configured my in > progress v1.1 sources to instead use the following feature install condition > logic so its build output will directly support generation of a useable > adminInstall. > >DATABASES=0 > versus what I had > >DATABASES=1 > > At this point using new wix3 way for patch generation is spitting out the > following torch.exe processing command error. If I switch to the old > msimsp way for patch generation it doesn't seem to have that same issue. I > even tried rebuilding my v1.0 msi output using the same wix framework > release as I'm using for my v1.1 work and it didn't make the torch.exe > RadioButton error go away. > > Error 2 The table definition of 'RadioButton' in the target > database does not match the table definition in the updated database. A > transform requires that the target database schema match the updated > database schema. D:\tfswf\ws0\RXD_RXG_PTF\RXP > Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification > Service.msi 0 1 Patch > > > Manufacturer="!(loc.ProductName)" MoreInfoURL="!(loc.ProductUrl)" > Classification="Update" DisplayName="!(loc.ProductName)"> > > > > > > > > > > Supersede="yes"> > > > > > Patch.wixproj | postBuild event > move /y "$(TargetDir)en-us\$(TargetName).msi" > "$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp" > robocopy "\\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt" > "$(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt" /mir /r:0 > if not exist "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" md > "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" > rem msiexec.exe /a "$(Setup.TargetDir)en-us\$(Setup.TargetFileName)" /qn > TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* > "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification > Service.log" > if "$(IsDesktopBuild)" == "" msiexec.exe /a > "$(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification > Service.msi" /qn > TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* > "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification > Service.log" > if "$(IsDesktopBuild)" == "false" msiexec.exe /a "$(OutDir)en-us\RP Event > Notification Service.msi" /qn > TARGETDIR="$(ProjectDir)obj\$(Configuration)\v1.1adminInstall" /l* > "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification > Service.log" > "$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe" -p -ax > "$(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries" > "$(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification > Service.msi" "$(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event > Notification Service.msi" -out > "$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst" > "$(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe > "$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp" -out > "$(TargetDir)en-us\$(TargetName).msp" -t Rtm > "$(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst" > cmd /c echo end processing patch post-build event command lines > > > Patch.wixproj | postBuild event > >CleanWorkingFolder="yes" >OutputPath="!(loc.ProductName).pcp" >WholeFilesOnly="yes"> > >Description="!(loc.ProductName)" >Comments="!(loc.ProductName)" >ShortNames="no" Languages="1033" Compressed="yes" >Manufacturer="!(loc.ProductManufacturer)" /> > >Description="!(loc.ProductName)" >ManufacturerName="!(loc.ProductManufacturer)" >TargetProductName="!(loc.ProductName)" >MoreInfoURL="!(loc.ProductUrl)" >Classification="U
Re: [WiX-users] Patch creation problems
If you explicitly set REINSTALL then all other feature properties like ADDLOCAL are ignored (because REINSTALL takes precedence; see http://msdn.microsoft.com/en-us/library/aa371175.aspx). The default REINSTALLMODE is also "omus", so unless it is explicitly set or defined in the Property table (this should generally not be done) it will be "omus". Any non-versioned files updated - where the modification timestamp is > the creation timestamp - will not be overwritten by default. This is by design. Unless all files are overwritten when REINSTALLMODE contains "a" - and this applies to ALL files in a product, it is not granular at the file, component, or feature level - it is not updated because it's considered a user edit. If you're installing files that you expect a user to edit, either 1) don't install them; just create them on first launch, or 2) service their content using a custom action (for example, XmlConfig in WiX is good for changes to XML files that users might edit). See http://blogs.msdn.com/heaths/archive/2006/12/21/installation-guidelines-for-user-editable-configuration.aspxfor some ideas of how to service user-editable files. Of course, if you're installing a user-editable file in a per-machine app either you're installing to a user-editable directory - and per-machine applications should not write per-user data during installation; or you're requiring elevated privileges to write your file with on Vista+ may not be a good customer experience. Just something to consider when designing your app composition. As for why the maintenance dialog is coming up when installing a patch - that's because really all patch operations are is a reinstall of your product with a transform or transforms applied (or removed if uninstalling a patch). See http://blogs.msdn.com/heaths/archive/2005/09/12/464047.aspx for more details. On Tue, Sep 23, 2008 at 5:20 AM, Ilya Slobodin wrote: > Hi, > > REINSTALL=ALL REINSTALLMODE=omus are set from the UI when Repair > button is pressed. Haven't you changed the test.txt before the patch > is applied? > > My experiments show that patches are installed better without setting > REINSTALL and REINSTALLMODE. If these properties are set, this can > cause problems with component action state dependencies, e.g. MoveFile > records. See my post "Patch install: MoveFiles and component action > states" earlier in this list. There is also a sample that patches the > text file. > > The problem is that when REINSTALL=ALL REINSTALLMODE=omus are set, > action state of all components becomes "Local" but no action is really > executed on the components not included in the patch. > > When REINSTALL=ALL REINSTALLMODE=omus are not set, action states of > the files being patched are set to "Local" by the msi engine. > > Best regards, > Ilya Slobodin > > - Original Message - > From: "Robert O'Brien" > To: "'General discussion for Windows Installer XML toolset.'" > > Sent: Tuesday, September 23, 2008 7:23 AM > Subject: Re: [WiX-users] Patch creation problems > > > > You need to launch the msp using the command line and the properties > > REINSTALL=ALL REINSTALLMODE=omus. If you want to be able to use > > your msp by double clicking on it you need to add something like the > > following to your wix sources so that those property values will get > > assigned automatically before processing begins. > > > > > > > Property="REINSTALL" Value="ALL" /> > > > Id="SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty" > > Property="REINSTALLMODE" Value="omus" /> > > > > > > > After="LaunchConditions">PATCH And Installed > > > Action="SetMspSmallUpdateOrMinorUpgradeReInstallModeProperty" > > After="LaunchConditions">PATCH And Installed > > > > > > -Original Message- > > From: Scott Sam [mailto:s...@clearviewecm.com] > > Sent: Monday, September 22, 2008 9:00 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Patch creation problems > > > > > > When I double click on my msp file I get the welcome dialog, > > followed > > by the maintenance dialog, giving me the choice to change, repair or > > remove. Choosing repair or change, will cause the patch to show up > > in > > add/remove programs, but the text file does not show the changes > > that I > > made. > > > > Problem 1: Why do I get the maintenance dialog? I would like to > > just > > double click the msp file and then have the patch be applied. Is > > there > > any way to do this? > > Problem 2: the changes aren't being applied. How do I fix this? > > > > I'm using wix version 3.0.4429.0 > > > > To create my patch I'm using the following method: > > 1. Compile original msi > > 2. Change a text file that is included in the msi. > > 3. Compile new msi > > 4. Create a transform between the two msi's. > > torch.exe -p -xi original\Product.wixpdb Product.wixpdb -out > > Patch\Diff.Wixmst > > 5. Build the patch > > pyro.exe Patch\Patch.WixMsp -out Pat
