[WiX-users] XmlFile Failed to find node

[Jeremy]

Hello!

I am trying to use a couple XmlFile definitions to edit an app.config file
using the WiX 3.8 toolset. I got one XmlFile working perfectly, but am
getting a "Failed to find node" node error (-2147020584) with the others,
but am a bit stumped as to why. I am not an XPath pro but the failing
XmlFile entries are pretty much exactly like the working entry, I'm at a
loss as to why one works and the others don't.


Here is a stripped down version of the app.config. I'm trying to change
that appSettings/APIURL value element (working just fine), as well as the
"minlevel" element in those nlog/rules/logger entries.


  

  
  http://www.nlog-project.org/schemas/NLog.xsd"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>

  
  


  
  

  
  
http://localhost/API/"; />
  



My transforms are relying on these properties if it makes any difference:


  http://api.test.com/"; />
  
  

  https://api.real.com/"; />
  
  



Here is my first XmlFile transform which is working perfectly:



However when I try to target those NLog settings, these are causing the
"Failed to find node" errors. These three XmlFile entries are all in the
same component which contains my .exe.config file.





I also even tried a simpler
ElementPath="/configuration/nlog/rules/logger/@minlevel" but that also got
"Failed to find node".

The XPath query does seem to be correct, at least a couple random online
XPath testing websites showed me I really was targeting what I'm trying to
target. I also removed the name="*" from those logger lines in the xml
config, thinking maybe that was throwing off the parsing somehow, but that
didn't make any difference either. I also tried re-ordering the XmlFile
entries thinking maybe the first one would work for some strange reason and
all extra ones never will work, but that didn't help either.

Thanks for any and all assistance!

Best wishes
Jeremy
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile Failed to find node

[Jeremy]

On Fri, Jan 31, 2014 at 2:42 PM, John Cooper  wrote:

> Change your ElementPath to have the XPath without the /@value and add a
> Name attribute to util:XmlFile with the value "value".  It should work.
>


Thanks for the tip!

I tried that change with just the APIURL Util:XmlFile (which was working
before), it continued to work OK with that change. But when I add the other
Util:XmlFile's back in for the nlog entries, it errors again.


Action 15:33:02: ExecXmlFile.
ExecXmlFile:  Error 0x800710d8: failed to find node:
/configuration/nlog/rules/logger in XML file: C:\MyApp\MainApp.exe.config
Error 25532. Failed to find node:
/configuration/nlog/rules/logger[@writeTo='file'] in XML file:
C:\MyApp\MainApp.exe.config, system error: -2147020584
Action ended 15:33:03: InstallFinalize. Return value 3.
Action 15:33:03: Rollback. Rolling back action:


At the time of this error, before I hit "OK" and it gets rolled back, the
.config is present with the contents below. The APIURL is still set to
http://localhost instead of the replacement value too (which is weird since
that XmlFile entry worked great on its own), I guess it's trying to make a
temporary copy of the config somewhere and editing it elsewhere before
moving it into place?




  ... snip ...
  http://www.nlog-project.org/schemas/NLog.xsd"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>

  
  


  
  

  
  
http://localhost/api"; />
  



Here are the updated Util:XmlFile's I'm trying:









Cheers (from KC too no less, small world)!
Jeremy
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile Failed to find node

[Jeremy]

For the record and anyone curious, It seems to be XmlFile not liking
something about the xmlns in the nlog tag, somehow that's preventing it
from parsing the other elements.

i.e. with a plain  in the app.config, those Util:XmlFile's work
great. But these in app.config, XmlFile errors:

http://www.nlog-project.org/schemas/NLog.xsd"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>

http://www.nlog-project.org/schemas/NLog.xsd";>

Cheers,
-Jeremy
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] "must install nuget package Microsoft.Bcl.Build" woes

[Jeremy]

I'm having trouble squashing these warning messages:

All projects referencing Foo.Library.csproj must install nuget package
Microsoft.Bcl.Build. For more information, see
http://go.microsoft.com/fwlink/?LinkID=317569.

This solution consists of a few projects, most notably Foo.Service and
Foo.Library which are targeting .NET 4.0 and using the latest
Microsoft.Bcl.Async nuget package (Microsoft.Bcl.Build + Microsoft.Bcl)

My solution also contains 2 separate Wix projects, my main one Foo.Setup
and also Foo.Setup.Brand2 which is just for an alternate branding of the
same setup (it just includes references ("Add Existing Item / As Link") to
the first Foo.Setup project, plus a few different files for the alternate
logos/EULA/etc). Maybe this is what is confusing things?

Try as I might, I can't seem to get the Microsoft.Bcl.Build warnings to go
away. They also don't seem to be a type of warning with an ID that I can
make Visual Studio ignore as far as I can tell.

* Actually installing those NuGet packages into my 2 WiX projects does not
help.

* I tried following steps here
http://stackoverflow.com/questions/17180268/warning-all-projects-referencing-myproject-csproj-must-install-nuget-package-m--
Editing the .wixproj and
adding SkipValidatePackageReferences=true to my
's gave a ton of errors.

* Adding
SkipValidatePackageReferences=true
instead in the 's went back to merely giving me the
warnings about Microsoft.Bcl.Build but at least it did finish the build and
spit out the .msi files.

I really do need my two WiX projects to reference the Foo.Library and
Foo.Service projects to make sure there isn't a race condition when
rebuilding but also because I'm referencing $(var.Foo.Service.TargetDir)
etc in some of my WiX files.

Thanks for any insight! For now I am just leaving my WiX projects unloaded
so I don't see the warnings constantly, but surely there's a way to fix
this for good.

Cheers,
Jeremy
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Jeremy Farrell]

> From: Gerry Reno [mailto:gr...@verizon.net]
> Sent: Friday, December 20, 2013 6:28 PM
> On 12/20/2013 01:16 PM, Edwin Castro wrote:
> > On 12/20/13, 9:49 AM, Gerry Reno wrote:
> >> It's not a Windows program.  It's a CUI program that you launch from
> cmd.exe
> > Which you can still more easily start directly. If you insist in
> > wrapping the call with cmd.exe then you MUST adhere to cmd.exe's
> funky
> > quotation rules.
> >
> > Do it the easy way and remove cmd.exe from your invocation.
> >
> > It looks like you don't have command line arguments for
> myprogram.exe...
> >
> > Assuming the File/@Id for myprogram.exe is myprogram.exe, I would try
> >
> >  >   FileKey="myprogram.exe"
> >   ExeCommand=""
> >   Execute="deferred"
> >   Return="asyncWait"/>
> >
> > Or to run myprogram.exe without showing the Command Prompt window...
> >
> >  >  Before="Launch_myprogram.exe"
> >  Sequence="execute"
> >  Value=""[#myprogram.exe]""/>
> >  >   BinaryKey="CAQuietExec"
> >   Execute="deferred"
> >   Return="asyncWait"/>
> 
> I not certain this will work.  It might with something like a .bat file
> since the system knows that .bat files are
> executed by cmd.exe.
> 
> But what is there to tell the system that my exe requires being run by
> cmd.exe?

Why does your program require being run by cmd.exe? How does it know whether or 
not it was run by cmd.exe? It sounds rather unusual.

If myprogram.exe is a file which is being installed by this installer, you've 
got other complications as well.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Jeremy Farrell]

> From: Gerry Reno [mailto:gr...@verizon.net]
> Sent: Friday, December 20, 2013 6:46 PM
> On 12/20/2013 01:43 PM, Jeremy Farrell wrote:
> >> From: Gerry Reno [mailto:gr...@verizon.net]
> >> Sent: Friday, December 20, 2013 6:28 PM
> >> On 12/20/2013 01:16 PM, Edwin Castro wrote:
> >>> On 12/20/13, 9:49 AM, Gerry Reno wrote:
> >>>> It's not a Windows program.  It's a CUI program that you launch
> from
> >> cmd.exe
> >>> Which you can still more easily start directly. If you insist in
> >>> wrapping the call with cmd.exe then you MUST adhere to cmd.exe's
> >> funky
> >>> quotation rules.
> >>>
> >>> Do it the easy way and remove cmd.exe from your invocation.
> >>>
> >>> It looks like you don't have command line arguments for
> >> myprogram.exe...
> >>> Assuming the File/@Id for myprogram.exe is myprogram.exe, I would
> try
> >>>
> >>>  >>>   FileKey="myprogram.exe"
> >>>   ExeCommand=""
> >>>   Execute="deferred"
> >>>   Return="asyncWait"/>
> >>>
> >>> Or to run myprogram.exe without showing the Command Prompt
> window...
> >>>
> >>>  >>>  Before="Launch_myprogram.exe"
> >>>  Sequence="execute"
> >>>  Value=""[#myprogram.exe]""/>
> >>>  >>>   BinaryKey="CAQuietExec"
> >>>   Execute="deferred"
> >>>   Return="asyncWait"/>
> >> I not certain this will work.  It might with something like a .bat
> file
> >> since the system knows that .bat files are
> >> executed by cmd.exe.
> >>
> >> But what is there to tell the system that my exe requires being run
> by
> >> cmd.exe?
> > Why does your program require being run by cmd.exe? How does it know
> whether or not it was run by cmd.exe? It sounds rather unusual.
>
> Read first line.

The line which says it's a CUI program? That's clear, you've said it many 
times, but so what? Answer question.

> > If myprogram.exe is a file which is being installed by this
> installer, you've got other complications as well.
>
> How so?  Care to explain?

Not my area of expertise, plenty of discussion in the archives. Depending on 
the sequencing of the install the file may not be on the system at the time you 
want to execute it.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setup.exe cygwin question

[Jeremy Farrell]

Before that even, I suggest explaining what this is about. Cygwin
has a working installer. You're proposing creating a new installer
for Cygwin which looks just like the current one. Why? I can imagine
possible reasons, but without knowing some good ones it sound like
a great deal of work for no gain.

> From: Carter Young [mailto:ecyo...@grandecom.net]
> Sent: Tuesday, January 28, 2014 5:34 PM
> 
> First of All, I would contact the maintainers of
> Cygwin(http://www.redhat.com/services/custom/cygwin/) and ask how that
> setup is packaged before trying to retrofit a WiX installer...
> 
> Quoting Blair Murri :
> 
> > Certainly it is possible using a custom BA from a bundle. Somewhat
> > less so from an MSI. One big advantage of the bundle, however, is
> > that the entire set of packages can be divided up between some
> > arbitrary set of MSIs abstracted away from the end user (in fact,
> > the most logical would be to have each package be an MSI). In fact,
> > you might even be able to reuse your current UI in a custom bundle
> > and save much of the redevelopment effort.
> >
> > Not sure on the project leader part. What resources are available to
> > such a leader (types and experience of developers/testers/PMs, etc.)?
> >
> > Blair
> >
> >
> > From: BGINFO4X
> > Sent: ‏Friday‏, ‏January‏ ‏24‏, ‏2014 ‏7‏:‏25‏ ‏AM
> >
> > Attending your experience, do you think that is possible to build an
> > installer like the traditional setup.exe installer from cygwin.com?
> >
> > In the following url you can see the main screens.
> > http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html
> >
> > I ask basically for the screens number 11, 13, 15, 16.  Do you think
> > that this is possible with WIX?
> >
> > Does anyone would like to be the project leader of  such project?
> > "cygwin community" should agree with this.
> >
> > I must admit that I can't build such project, I don't have the
> > necessary experience and knowledge.
> >
> > Any recommendation is welcome.
> >
> > Thanks for your time and regards.

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall Previous Inno Setup Installed App

[Jeremy Farrell]

One thing is that it looks like you're not allowing for the automatic 
redirection of various things such as the registry when you run 32-bit things 
on a 64-bit system. If your installer is 32-bit and you run it on a 64-bit 
system, then references to 'SOFTWARE\Microsoft' will get silently redirected to 
'SOFTWARE\Wow6432Node\Microsoft' behind the scenes.

If the old installer was 32 bit and you new installer is 32-bit, you should 
just be able to create an installer as if you were targeting a 32-bit system 
and it will do the right thing on both 32 and 64 bit - that's the purpose of 
the automatic redirection system.

> From: Jammer [mailto:jam...@jammer.biz] 
> Sent: Friday, March 11, 2011 8:01 PM
> 
> Hi Again,
> 
> I've just created a log of my installer and it seems that 
> I've got some 
> of it work now but the last test just left me with a mangled install 
> that won't uninstall :(
> 
> According to the log both of these searches found their 
> registry values, 
> which is confusing since using regedit I can only find the first 
> Wow6432Node key:
> 
> 
>  Key='SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uni
> nstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1' 
> Name='UninstallString'>
> 
> 
> 
> 
>  Key='SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{413B
> 7644-1F93-4890-BD40-AC540C29935B}_is1' 
> Name='UninstallString'>
> 
> 
> 
> 
> I'm running Win7 64 and my old app is installed into Program 
> Files (x86) 
> is this why it ran the 32bit CustomAction?
> 
> 
>  Before="InstallFiles">VERSIONNT64
> NOT 
> VERSIONNT64
> 
> 
> MSI (s) (C4:64) [19:37:29:528]: Skipping action: 
> ca.RemovePreviousVersion64 (condition is false)
> MSI (s) (C4:64) [19:37:21:422]: Doing action: 
> ca.RemovePreviousVersion32
> 
> Pretty confused by this to be honest I tried VERSIONNT64 and 
> VERSIONNT 
> before this but both evaluated false
> 
> Is the VERSIONNT64 actually referring to Program Files (x86) 
> and not the 
> OS version?
> 
> Also, I think the InstallFiles is wrong as I've ended up with 
> only some 
> of the files from the MSI installer actually being installed.  Or did 
> the time the uninstall execute after some of the MSI files 
> had been copied.
> 
> Off to fix this utterly mangled install ...
> 
> Thanks,
> 
> James
> 
> --
> 
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] One install for multiple OS

[Jeremy Farrell]

And the problem is? 

> From: Robert Hermann [mailto:rob.herm...@nicewareintl.com] 
> 
> I've got an install for a backend service that needs to 
> consider a couple of OS and then scenarios within that os.
> 
> For the time being I need  my project to first detect the os 
> and if its not at least Windows 2003, to throw an error.
> 
> If its Windows 2008 R2, then the install needs to detect if 
> its being run from a Administrator command prompt or not.  If 
> its not, say something.
> 
> I can the logic to work if its either or but not together ...
> 
> Right now I've got
> 
> 
> 
> 
> 
> 
> 
> Rob
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to write INSTALLDIR to registry?

[Jeremy Farrell]

That defines a property called WIXUI_INSTALLDIR with the value "INSTALLDIR". it 
has nothing to do with a property called INSTALLDIR.

> From: Michel [mailto:mic...@acromania.nl] 
> Sent: Monday, March 28, 2011 7:33 AM
> 
> INSTALLDIR is defined:
> 
> 
> 
> ...
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and publish 
your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSVC problem on Vista (no SP)

[Jeremy Farrell]

You'd perhaps get a more useful answer if you told us what the problem is. 

> From: Michael Tissington [mailto:michael_tissing...@ciqual.com] 
> 
> I have a problem when doing a major upgrade  on Vista (no 
> service pack)
> 
> My install is using both MSVC 9.0 and 10.0 merge modules.
> The first time my install runs it does install MSVC without 
> any problems.
> My upgrade package does a RemoveExistingProducts and then 
> installs itself.
> The problem is ONLY on Vista without service pack, on XP and 
> Windows 7 my
> package works correctly.
> 
> Is this a known issue with MSVC and Vista?
> Is there a fix I can do in the install?
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] VC++ redistributable questions

[Jeremy Farrell]

> From: Tobias S [mailto:tobias.s1...@gmail.com] 
>
> ...
>
> - Most installs run in UI mode

Interesting, where did you get that information from? What's the ratio between 
UI-mode runs and silent, and how accurate is the estimate believed to be?
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Suppress Warning LGHT1008

[Jeremy Farrell]

> From: Simon Chromow [mailto:simon.chro...@bewotec.de] 
> 
> Hello everybody,
> is it possible to suppress the warning LGHT1008?
> 
> Thanks for your efforts
> Simon

http://lmgtfy.com/?q=wix+light+suppress+warnings
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why are we using a mailing list vs forum?

[Jeremy Farrell]

> From: john.bu...@telvent.com [mailto:john.bu...@telvent.com] 
> Subject: [WiX-users] Why are we using a mailing list vs forum?
> 
> Just curious.

Because mailing lists are easier and far more convenient to use.

> I find forums easier to use. :o)  ...

All down to personal preference. I believe there are web-based interfaces to 
this list available.
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Combined 32-bit and 64-bit MSI?

[Jeremy Farrell]

The fact that you need separate MSI files but can build them both from the same 
source? 

> From: Brad Lemings [mailto:b...@rebit.com] 
> 
> AFAICT, both links use separate MSI files for 32-bit and 
> 64-bit installs.
> 
> Did I miss something?
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
> 
> Two separate MSI files are recommended. 
> 
> http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-pa
> ckages-are-required-for-different-processor-architectures.aspx 
> 
> Same source though:
> 
> http://blogs.msdn.com/b/astebner/archive/2007/08/09/4317654.aspx 
> 
> Phil Wilson 
> 
> -Original Message-
> From: Brad Lemings [mailto:b...@rebit.com] 
> 
> Is it possible to combine a 32-bit and 64-bit install in the 
> same MSI file?  If so, are there some examples, tutorials to look at?
> 
> Thanks,
> Eric.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Can an x86 msi create a registry key under HKEY_CLASSES_ROOT\Wow6432Node on x64 systems?

[Jeremy Farrell]

If you run a 32-bit MSI then its registry entries will be created under 
Wow6432Node automatically on 64-bit versions of Windows. This is an feature of 
how Windows emulates the 32-bit environment on 64-bit Windows, nothing to do 
with WiX or Windows Installer.


> From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com] 
> 
> I have an x86 installer which needs to create a registry key 
> under HKEY_CLASSES_ROOT\Wow6432Node on 64-bit machines. I 
> created a component to do the task. The component installs 
> fine but does not create the key on x64 systems. Is there a 
> way to accomplish this with WiX? Your help will be greatly 
> appreciated.
> 
> Thanks a lot,
> Miaohsi
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help needed

[Jeremy Farrell]

> From: Kshitish Seet [mailto:kshitish.s...@nextsphere.com] 
> 
>  I am asked to use Windows Installer XML 
> (WiX) to create installation 
> package. I donot know where to start. If anybody have done 
> anything on this please advise.

The web page you mention would be an excellent place to start. It has links 
which lead off to manuals, an excellent tutorial, book references, FAQ lists, 
blogs, ...
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Explosion of LGHT0311 errors in WiX 3.5

[Jeremy Stanley]

I recently upgraded to WiX 3.5 (from 3.0) to solve a difxapp compatibility 
problem, and now I've got different problem. Several of the localized 
installers fail to build with LGHT0311 ("A string was provided with characters 
that are not available in the specified database code page '1252'"). In some 
languages, I found out-of-range characters in the corresponding .wxls (mostly 
Unicode-y dashes and spaces), replaced them with boring ASCII, and the build 
worked again. In other cases, I couldn't find the text light was complaining 
about. 

But the real question here is, what changed? Why didn't WiX 3.0 bug me about 
these problems? I have the product building now, but since our company allows 
third-party partners to create "branded" installers (with their own string 
tables and images), I worry many of these will break in WiX 3.5. 

It seems preposterous to me that, in 2011, I have to force all strings in an 
installer to fit in a single ANSI code page. A years-old comment in the code 
warned about the uninstaller becoming unintelligible if we try and use UTF-8, 
and web searches on the subject have corroborated this ... does anyone have a 
workaround for this problem? Because that's the only solution I can think of. 


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Explosion of LGHT0311 errors in WiX 3.5

[Jeremy Stanley]

> Because WiX v3.0 didn't check as thoroughly for codepage problems. IOW, 
> the problems always existed, WiX is just telling you about them now. 

What went into the MSI database before? Were unrepresentable characters simply 
replaced by question marks or something? 

And is there any way I can revert to this behavior? Since our branding process 
lets third party OEMs supply text for the installer, I would rather have one or 
two slightly messed-up strings that the OEM can fix if anybody notices it 
(nobody ever did for the three years we used WiX 3.0), rather than failing the 
entire branding operation (which I am certain somebody would notice). 
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] UI Custom Action displays dialog behing MSI UI

[Jeremy Farrell]

I had a similar situation where I needed to convert a mass of existing
code into MSI custom actions. This code called various driver
installation APIs which could create message boxes in unusual
situations, and these boxes were displaying behind (and hidden by) the
MSI UI.

I know almost nothing about UI programming so this solution may work
more by luck than design, but it works for me on Server OSes from 2000
to 2008 R2. I set the 'owner window' parameter on relevant API calls to
the MSI UI window, which I find with the FindWindow function as follows:

   hWindow = FindWindow(TEXT("MsiDialogNoCloseClass"), NULL);

I don't know to what extent I've been lucky with this; if anyone knows
of a better way to achieve the same thing, please let me know.

Regards,
jjf

> -Original Message-
> From: Tobi Ha [mailto:tob...@gmx.net] 
> Sent: Tuesday, December 15, 2009 1:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] UI Custom Action displays dialog behing MSI UI
> 
> Hello,
> 
> I have a WiX installation that shows within a custom action a 
> dialog from a dll that is installed during this installation. 
> It all works fine, except that the dialogs appears behind the 
> normal MSI UI.
> 
> Here a short example how my custom action looks like (instead 
> of message box, a real UI appears)
> 
> UINT __stdcall MessageBoxAction (MSIHANDLE hInstall) 
> {
>   Beep(500,2000);
> 
> LPCTSTR lpszText = L"A message box text";
> LPCTSTR lpszCaption = L"A message box title";
> UINT nType = MB_OK; 
>   MessageBox(NULL,lpszText,lpszCaption,nType);
> 
>   return ERROR_SUCCESS;
> }
> 
> Is there a way to display the own UI in foreground?
> 
> Cheers,
> Tobias

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix redistributable

[Jeremy Farrell]

Really? Why? I'm still using an old version of WiX which didn't include
such a warning - why was it added? Does something not work properly with
more recent versions of WiX if Visual Studio isn't present? 

> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com] 
> Sent: Tuesday, January 05, 2010 4:28 PM
> To: nagara...@symphony.cc; General discussion for Windows 
> 
> For info the WiX install doesn't require visual studio, it 
> just warns if it is not found.
> 
> Neil
> 
> -Original Message-
> From: nagaram.c [mailto:nagara...@symphony.cc] 
> Sent: 05 January 2010 12:07
> 
> Hi,
>
> I am using just smoke.exe to one of solutions I am working 
> right now, Is
> there any link by which only this light weight component be downloaded
> instead of wix toolkit that requires visual studio.
>
> Thanks,
> Nag

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix redistributable

[Jeremy Farrell]

Thanks Neil, that makes sense - it would be impressive if Votive worked
without VS ;). It's more a "common-sense informational" than a warning I
suppose ... The discussion had me worried that some dependency on VS had
crept into WiX itself.

> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com] 
> Sent: Tuesday, January 05, 2010 7:41 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix redistributable
> 
> Yes Votive doesn't work, everything else works fine. I assume it was
> added as it is not common to install it without VS (I only noticed it
> because I install to a build server that doesn't need VS).
> 
> This is the message: "Votive, the WiX project and editor package for
> Visual Studio, cannot be installed because Visual Studio 2005 or 2008
> Standard Edition or higher is not installed."
> 
> Neil
> 
> -Original Message-
> From: Jeremy Farrell [mailto:jfarr...@pillardata.com] 
> Sent: 05 January 2010 19:02
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix redistributable
> 
> Really? Why? I'm still using an old version of WiX which 
> didn't include
> such a warning - why was it added? Does something not work 
> properly with
> more recent versions of WiX if Visual Studio isn't present? 
> 
> > -Original Message-
> > From: Neil Sleightholm [mailto:n...@x2systems.com] 
> > Sent: Tuesday, January 05, 2010 4:28 PM
> > To: nagara...@symphony.cc; General discussion for Windows 
> > 
> > For info the WiX install doesn't require visual studio, it 
> > just warns if it is not found.
> > 
> > Neil
> > 
> > -Original Message-
> > From: nagaram.c [mailto:nagara...@symphony.cc] 
> > Sent: 05 January 2010 12:07
> > 
> > Hi,
> >
> > I am using just smoke.exe to one of solutions I am working 
> > right now, Is
> > there any link by which only this light weight component be 
> downloaded
> > instead of wix toolkit that requires visual studio.
> >
> > Thanks,
> > Nag
> 
> --
> --
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app 
> distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> 
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app 
> distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Building Votive - Email found in subject

[Jeremy Farrell]

Works for me as long as I correct for the line wrapping. 

> -Original Message-
> From: Jahanzeb Khan [mailto:jk...@commondesk.com] 
> Sent: Wednesday, January 06, 2010 9:32 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Building Votive - Email found in subject
> 
> Neil
> The url does not work; whats the new url for this.
> thnx
> 
> -Original Message-
> From: Neil Sleightholm [mailto:n...@x2systems.com] 
> Sent: Wednesday, January 06, 2010 3:38 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Building Votive - Email found in subject
> 
> This documents what you need for 3.0, it might help:
> http://neilsleightholm.blogspot.com/2008/10/how-to-create-wix-
> build-mach
> ine.html. 
> 
> The other thing to watch is that the last time I checked the 
> CVS source
> didn't contain the binary files saved correctly.
> 
> Neil
> 
> -Original Message-
> From: Adam Langley [mailto:alang...@winscribe.com] 
> Sent: 06 January 2010 20:25
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Building Votive
> 
> I would like to add some functionality to Votive (3.5 codebase), yet I
> am finding it rather difficult getting it to build in Visual Studio
> 2008.
> Is the environment setup documented anywhere?
> 
> Thanks
> 
> Adam Langley
> 
> 
> --
> --
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app 
> distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> --
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app 
> distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> 
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app 
> distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to handle Registry Redirection through WIXon64-bit Platform

[Jeremy Farrell]

> From: Pally Sandher [mailto:pally.sand...@iesve.com] 
> Sent: Wednesday, January 13, 2010 10:49 AM
>
> ...
> An MSI has a platform attribute which must be set to "Intel" for x86
> packages or "Intel64" for x64 packages (can also use "AMD64" for x64
> packages but it's deprecated by "Intel64").
> ...

Some confusion here? I believe it's

Intel   - 32-bit x86
Intel64 - Itanium family
AMD64   - 64-bit x86, deprecated
x64 - 64-bit x86


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Avoiding hard-coding the path to the WiX SDK when usingthe WDK

[Jeremy Farrell]

I recommend keeping the tools under source control, so you always know
where they are and what they are.

If you don't want to do that, the simplest thing is probably just to
normalize the WIX variable in the script you use to launch build.
Something like

for %%X in ("%WIX%") do set WIX=%%~fsX

should set it to its short-name form (and clean out any \..\ if there
were any).

> From: Bruce Cran [mailto:br...@cran.org.uk] 
> Sent: Friday, January 15, 2010 1:06 PM
> 
> I'm using the WDK to build a C++ custom action DLL that gets
> included in my MSI that I create using WiX 3.5.  The problem
> I've come across is that the WiX headers are located in
> C:\Program Files (x86)\Windows Installer XML v3.5\SDK\inc, and
> the WDK doesn't appear to recognise long filenames. 
> 
> I've tried adding $(WIX)SDK\inc both with and without
> quotes to the 'sources' file, but the only thing that works is
> using C:\PROGRA~2\WINDOWS~1.5\SDK\doc.  I'd rather not use that 
> because it'll be wrong on 32-bit Windows.
> 
> Does anyone know a way around this to avoid hard-coding paths that
> other developers are going to have to change for their machines?

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CNDL1033, LGHT1079 - question about long cabinet file names

[Jeremy Farrell]

I'd be very surprised if anyone could answer that question, certainly
not reliably and completely. As the message clearly says, it's
unsupported; and as the message helpfully explains, that means it's not
guaranteed to work. That means anything can happen. Developers of
everything which ever touches these names have been free to build in the
assumption that they have short names, or may even have built such
assumptions in by accident. Such assumptions could get added at any
time. Perhaps long names will always work perfectly in all situations.
Perhaps they'll cause very subtle problems which are extremely hard to
diagnose in very particular circumstances. Perhaps they'll cause
frequent obvious failures.

The one thing you can be sure of is that if they do cause problems you
won't get any support.

> From: Ondrej Zarevucky [mailto:ondrej.zarevu...@fine.cz] 
> Sent: Monday, January 18, 2010 3:47 PM
> 
> Hi everybody,
> I have question about these two warnings thrown by Candle and Light 
> tools: CNDL1033 and LGHT1079 - both are about long cabinet file names.
> 
> The warning is telling me I should use short (8.3) file names 
> referencing some Windows Installer team recommendation, but I 
> couldn't find any documentation describing the compatibility problems
> I can encounter. I would prefer using long file names for easier 
> work with the cabinet files. ("Program_Help_EN.CAB" is better name
> then "Prog_HEN.CAB")
> 
> Can you please tell me, what compatibility problems could result from 
> using long cabinet names? I'm targeting Windows XP with Windows 
> Installer 3.1.
> 
> Thank you for clarification
> 
> Sample warning from Candle:
> Media.wxi(15) : warning CNDL1033 : The Media/@Cabinet 
> attribute's value, 'LongCabinetName.CAB', is not a valid
> external cabinet name.  Legal cabinet names must follow 8.3
> format: they should contain no more than 8 characters followed
> by an optional extension of no more than 3 characters.  Any
> character except for the follow may be used: \ ? | > < 
> : / * " + , ; = [ ] (space).  The Windows Installer team has 
> recommended following the 8.3 format for external cabinet
> files and any other naming scheme is officially unsupported
> (which means its not guaranteed to work on all platforms).
> 
> Have a nice day
> zarevak

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch Type raw causes a '1' to bewrittenin RegLocater table - should be a '2'

[Jeremy Farrell]

Wow, that's incredibly ancient - an early development build from 2004 or
earlier. The bits have probably rotted. The release version of WIX 2.0
is 2.0.5805.0 which was released in 2008; since WiX 3.0 was released in
July 2009 though, even that is obsolescent.

If you want to stick to WiX 2.0 (perhaps to minimize any required
changes in your installer sources) I'd upgrade to the release version
and try again.

> From: Toews, Margaret [mailto:margaret.to...@wolterskluwer.com] 
> Sent: Thursday, January 28, 2010 3:24 PM
> 
> Wix version 2.0.1605.0
> 
> Margaret Toews
> Programmer Analyst
> ProSystem fx Engagement
> CCH, a Wolters Kluwer business
>  
> Phone: 316.612.5148
> Fax: 316.612.3406
> E-Mail: margaret.to...@wolterskluwer.com
> -Original Message-
> From: Blair [mailto:os...@live.com] 
> Sent: Wednesday, January 27, 2010 11:20 PM
> 
> Which build of the WiX toolset?
> 
> -Original Message-
> From: mtoews [mailto:margaret.to...@wolterskluwer.com] 
> Sent: Wednesday, January 27, 2010 8:14 AM
> 
> From a Wix newby: When I use the registrysearch element as below 
>  
>  Type='raw' 
>   Root='HKLM' 
>  
> Key='Software\Microsoft\Windows\CurrentVersion\Uninstall\{59FF
> 80EA-267A-418B-9C33-2CC4CC39A365}' 
>   Name='DisplayVersion' /> 
>  
> 
> the search fails unless I edit the msi package and change the value
> in the Type column of the RegLocator table from 1 to 2.  From 
> reading it seems to me that when 'raw' is specified as a type the
> RegLocator table Type column should be populated with a 2.  If I
> edit the package and change it to a 2 the search is successful.
> Any assistance is appreciated. 

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem installing a .NET installer-based service using InstallUtilLib.dll

[Jeremy Farrell]

Err ... perhaps I'm missing something, but: in the message you link to,
Brian describes the problem, then Neil points to the MSDN documentation
on how to avoid the problem, then Brian says this method "appears to
work perfectly". Have you tried the recommendations in the message you
linked to?

> -Original Message-
> From: Rajendra Magar [mailto:rma...@newfrontieradvisors.com] 
> Sent: Tuesday, February 23, 2010 10:38 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> Yes I did. I used 'Account="NT Authority\Network Service"' 
> and it worked in all of the machine configurations I tested 
> but the experience described in the link below tells me that 
> this value could be fragile.
> 
> http://www.mail-archive.com/wix-users@lists.sourceforge.net/ms
> g27992.html
> 
> Are you aware of a value that will work with 100% guarantee 
> in all the platforms? I can't seem to find any documentation on that.
> 
> Thank you,
> Raz
> 
> 
> 
> 
> 
> -Original Message-
> From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com]
> Sent: Tuesday, February 23, 2010 5:21 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> Did you try using Network Service? with std wix servicecontrol?
> 
> Arun Perregattur
> 
> -Original Message-
> From: Rajendra Magar [mailto:rma...@newfrontieradvisors.com]
> Sent: Tuesday, February 23, 2010 5:01 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> In my case I am required to use NetworkService because the 
> installer I am working on is supposed to install a client 
> that looks for problems to solve on a network drive.
> 
> Thank you,
> Raz
> 
> 
> 
> -Original Message-
> From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com]
> Sent: Tuesday, February 23, 2010 4:55 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> For our service we set the Account to LocalSystem and works fine.
> 
> Arun Perregattur
> 
> 
> -Original Message-
> From: Rajendra Magar [mailto:rma...@newfrontieradvisors.com]
> Sent: Tuesday, February 23, 2010 4:44 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> Arun and Phil, Thank you but I am stuck with a .NET installer 
> class which does much more than just install the service so I 
> did not use ServiceInstall and ServiceControl. Besides 
> ServiceInstall doesn't seem to obey the service parameters 
> set by the installer class. For example, the .NET installer 
> class I have sets the service account to NetworkService and 
> if I want to use NetworkService account to run the installed 
> service using ServiceInstall I have to specify Account="NT 
> Authority\Network Service", which I have been warned in 
> several forums may not always work for all Windows platforms. 
> Please let me know if you are aware of a good documentation 
> on what Account value to use that will work on all target machines.
> 
> Phil, thank you for the "condition" hint. The link I pasted 
> below 
> (http://blog.vagmim.com/2004/09/installing-windows-services-cr
> eated.html) had conditions around the custom actions. I am 
> afraid I seemed to have ignored them since I didn't 
> understand what they were exactly. I will try with those 
> conditions and provide an update.
> 
> Sincerely,
> Raz
> 
> 
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@invensys.com]
> Sent: Tuesday, February 23, 2010 4:20 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> It seems to me that you are calling your custom action to 
> uninstall the service *on an install* because you haven't got 
> a condition on it. That looks like your first point of failure.
> 
> Curious why don't you have a choice about doing it the 
> "proper" way as Arun described...
> 
> Phil Wilson
> 
> 
> -Original Message-
> From: Rajendra Magar [mailto:rma...@newfrontieradvisors.com]
> Sent: Tuesday, February 23, 2010 12:22 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Problem installing a .NET 
> installer-based service using InstallUtilLib.dll
> 
> Two of my attachments got clobbered on the way, so I am 
> copy+pasting them here.
> 
> (1) ServiceInstaller.wxs
> 
> 
> 
> http://schemas.microsoft.com/wix/2006/wi";>
>Version="1.0.0.0" Manufacturer="manufacturer name" 
> UpgradeCod

Re: [WiX-users] Wix 2.0 to Wix 3.0

[Jeremy Farrell]

Your question doesn't make sense. WiX 2.0 and WiX 3.0 are releases of
the WiX toolset which you use to build MSIs (product installers) - WiX
is not a product installer. To move from one to the other you just
upgrade the WiX toolset on your build machine, following the
instructions with the new release. Whether that's done by a patch or a
minor upgrade (or, much more likely, a major upgrade or an
uninstall/install) is decided by the team which creates the new release
- you just do what the instructions tell you to do.

Once you have the new version of WiX installed, you update your
installer sources (.wxs files and relatives) to the new WiX schema. The
wixcop tool in the new release should help a lot with these updates.

> From: Anurag Pahwa [mailto:apa...@microsoft.com] 
> Sent: Thursday, March 11, 2010 2:13 PM
> 
> Hi Guys,
> 
> Our product installer currently is WIX 2.0 and we are 
> thinking of moving to Wix 3.0. Is it possible to do that in a 
> patch or we have to do in a minor upgrade as there must be 
> huge changes between wix 2.0 and wix 3.0.
> 
> Thanks
> Anurag

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Beginner's Question: 32 Bit MSI on 64 Bit OS

[Jeremy Farrell]

I can't imagine why you'd consider that to be "obvious" - it's nonsense. WiX is 
software, it can have knowledge of anything its authors want, and it can build 
any knowledge it needs to into an msi. An msi for a 32-bit application doesn't 
need any knowledge of the 64-bit environment anyway.

You can use WiX on a 32-bit system to build an installer for a 32-bit 
application, and it will install and work fine on any of 32-bit, x64 or Itanium 
system. If it's an "all CPU" application rather than a 32-bit one, you may need 
to do a bit of extra coding in your WiX sources or the application itself to 
handle different environments. You can also use WiX on a 32-bit system to build 
installers for x64 or Itanium applications.

> -Original Message-
> From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com] 
> Sent: Thursday, March 25, 2010 11:41 AM
> 
> Well it is obvious that msi created on 32-bit machine has no 
> knowledge of 64-bit environment and if u wont to provide 
> support to both 64-bit and 32-bit OS, its required 
> man...sorry.. you can try with it.. 
> 
> -Original Message-
> From: Markus Karg [mailto:k...@quipsy.de] 
> Sent: Thursday, March 25, 2010 4:59 PM
> 
> But that's weird -- it would mean that it is impossible to 
> install a MSI on a 64 Bit machine that was created in times 
> when there was no 64 Bit around already... -- or that all 
> software vendors in the past obtained 64 Bit machines just to 
> create their 32 Bit MSIs THERE!? Can't believe that.
> 
> > From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com]
> > Sent: Donnerstag, 25. März 2010 12:20
> > 
> > Well you have to do it on 64-bit machine only then and then
> > only msi will be fully 64-bit\32-bit compatible. I already
> > encounter this issue in past and had to get 64-bit OS just
> > to solve this issue.
> > 
> > -Original Message-
> > From: Markus Karg [mailto:k...@quipsy.de]
> > Sent: Thursday, March 25, 2010 4:46 PM
> > 
> > But we do not own a 64 Bit machine, so how to do it on a
> > 32 Bit machine?
> > 
> > > From: Lodhiya, Harshil [mailto:harshil.lodh...@eclipsys.com]
> > > Sent: Donnerstag, 25. März 2010 12:14
> > >
> > > Just create your MSI on 64-bit machine with the DLLs created
> > > as target x86, and it will run on both 32-bit\64-bit machine.
> > > 64-bit OS will automatically take care of system folder.
> > >
> > > -Original Message-
> > > From: Markus Karg [mailto:k...@quipsy.de]
> > > Sent: Thursday, March 25, 2010 4:41 PM
> > >
> > > we need to write a MSI file that has to install a 32 Bit 
> > > software. It shall correctly install on both, Windows 32
> > > and Windows 64.
> > >
> > > Is it correct to do one setup that always installs into 
> > > SystemFolder, or do we have to take any special care for
> > > the Windows 64 case?

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] when can we expect Wix 3.5 RTM?

[Jeremy Farrell]

I'll be surprised if the date has moved much since this question was
answered yesterday, or even since the several times it and similar
questions have been answered in recent weeks.

> From: MYFLEX [mailto:shrinuen...@gmail.com] 
> Sent: Tuesday, April 13, 2010 5:41 AM
> 
> when can we expect Wix 3.5 RTM?
> Is it ok to use Wix 3.5 beta versions to build my setups?

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] when can we expect Wix 3.5 RTM?

[Jeremy Farrell]

If people can't be bothered to read the last day or two of the mailing
list, or to search the mailing list archives, I'm not convinced that
repeating the information elsewhere will have much value - it just gives
them somewhere else to not bother looking. On the other hand, your
suggestion can't do any harm; feel free to contribute the change. 

> -Original Message-
> From: Markus Karg [mailto:k...@quipsy.de] 
> Sent: Thursday, April 15, 2010 9:43 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM?
> 
> If it is really so frequently asked, maybe it would be a good idea to
> post the date in the WiX FAQ http://wix.sourceforge.net/faq.html or on
> the WiX web site's front page http://wix.sourceforge.net/ to prevent
> dumb people like me asking silly questions like this over and over
> again? ;-)
> 
> > -Original Message-
> > From: Jeremy Farrell [mailto:jfarr...@pillardata.com]
> > Sent: Dienstag, 13. April 2010 17:22
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] when can we expect Wix 3.5 RTM?
> > 
> > I'll be surprised if the date has moved much since this question was
> > answered yesterday, or even since the several times it and similar
> > questions have been answered in recent weeks.
> > 
> > > From: MYFLEX [mailto:shrinuen...@gmail.com]
> > > Sent: Tuesday, April 13, 2010 5:41 AM
> > >
> > > when can we expect Wix 3.5 RTM?
> > > Is it ok to use Wix 3.5 beta versions to build my setups?
> > 
> >
> --
> -
> > ---
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> 
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Speeding up Light command

[Jeremy Farrell]

That's funny, it only takes about 20 seconds for me. Perhaps if you provide 
some information about what you're doing, people may be able to work out what's 
going on and suggest fixes or workarounds.

http://www.catb.org/~esr/faqs/smart-questions.html

> -Original Message-
> From: S.P [mailto:iraniangirl9...@yahoo.com] 
> Sent: Thursday, April 15, 2010 12:45 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Speeding up Light command
> 
> Hi all,
>  
> I want to create an install package with WiX,but "light" 
> command is very very slow. It takes about 5 hours to run. 
> Could you please help me if there is anyway to speed this up, 
> without increasing the size of the resulting file?
>  
> Thanks in advance,
> Regards
> 
> 
>   New Email addresses available on Yahoo!
> Get the Email name you've always wanted on the new @ymail 
> and @rocketmail. 
> Hurry before someone else does!
> http://mail.promotions.yahoo.com/newdomains/aa/
> --
> 
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Quiet Execution of an executable embedded within the MSI

[Jeremy Farrell]

The traditional way to do this (discussed on this list a few times a few years 
ago) is a little hacky, but works well enough.

1) Put your executable in a self-extracting archive, using iexpress for example;

2) execute the self-extracting archive from the binary table in a 'quiet' mode, 
putting your executable in a well-known place (such as [TempFolder]);

3) use CAQuietExec to run your program from the well-known place;

4) use CAQuietExec to delete your program from the well-known place.

> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com] 
> Sent: Friday, June 18, 2010 4:29 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Quiet Execution of an executable 
> embedded within the MSI
> 
> Binary Elements are extracted to temporary directories using auto
> generated filenames (see a verbose log for an example). It's not
> possible to use an application in a Binary Element with 
> QtExec (I looked
> at the same thing a while ago for a plug-in installer). You'll either
> need to change it to use a File Element & modify the 
> CustomAction to use
> [#fileid] instead of "myexec.exe" or live without 
> QtExec or as
> Blair says, write your own Custom Actions to write the Binary 
> to disk in
> a known location so QtExec can run it.
> 
> Palbinder Sandher 
> Software Deployment & IT Administrator
> T: +44 (0) 141 945 8500 
> F: +44 (0) 141 945 8501 
> 
> http://www.iesve.com 
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456 
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
> 
> -Original Message-
> From: Leigh Wetmore [mailto:lwetm...@gmail.com] 
> Sent: 17 June 2010 18:29
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Quiet Execution of an executable embedded within
> the MSI
> 
> Hello,
> 
> I'm trying to figure out how to quietly execute (QtExec) an executable
> that I include within my MSI yet do not want installed on the user's
> machine.
> 
> I've been able to achieve this without using the quiet 
> execute feature,
> but I don't like the command window popping up during installation.
> Here is the code for that:
> 
> 
> 
>Id="LaunchCfgUpdateExe"
>   BinaryKey="CfgUpdateExe"
>   ExeCommand=""[TempFolder]UpdateLog.txt" 
> UpdateAppConfig
> "[DASLocation]myexec.exe.Config""
>   Execute="deferred"
>   Impersonate="no"
>   Return="asyncNoWait" />
> 
> 
>After="InstallInitialize">OLDERVERSIONDETECTED
> 
> 
> I use the binary element to bring the executable (myexe.exe) into the
> MSI, then launch a custom action with the necessary arguments.  I have
> it executing as deferred with no impersonation as I need the admin
> privileges already captured by the installer to carry through to the
> executable.
>  Again, this works fine.
> 
> However, if I try to convert this to use QtExec, I'm unable 
> to get it to
> work.  Looking in the MSI install log, I see:
> 
> CAQuietExec:  Error 0x80070002: Command failed to execute.
> CAQuietExec:  Error 0x80070002: CAQuietExec Failed
> 
> Here is my code so far:
> 
> 
> 
>Id="QtExecCommand"
>   Property="QtExecUserCfg"
>   Value=""myexec.exe"
> "[TempFolder]UpdateLog.txt"
> "UpdateAppConfig" 
> "[DASLocation]myexec.exe.Config""
>   Execute="immediate" />
>  DllEntry="CAQuietExec" Execute="deferred" Impersonate="no"
> Return="check"/>
> 
> 
>After="CostFinalize">OLDERVERSIONDETECTED
>After="InstallInitialize">OLDERVERSIONDETECTED
> 
> 
> I've left the binary element there, but I don't think the 
> custom actions
> know about it.  It looks like QtExec can't find the executable which
> makes sense (I can have it run notepad.exe no problem).  I'm thinking
> maybe the files in the MSI, including myexec.exe, get extracted to a
> temp directory during installation, and I can potentially 
> reference it,
> like Value=""[MSITempDir]myexec.exe...?
> 
> Thanks in advance for any help anyone can provide.
> 
> Leigh
> --
> --
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's
> Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit.  See the
> prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> 
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> ___
> WiX-users mailing list

Re: [WiX-users] Error when tryin to install the latest drop of the wix toolset

[Jeremy Farrell]

Other than the various people who've discussed it on this list and answered the 
questions about it in the last couple of days? 

> From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] 
> Sent: Sunday, July 04, 2010 9:47 AM
> Importance: High
> 
> Hi: 
> 
> When trying to install the latest drop of the Wix toolset the 
> installation
> doesn't proceed past the install feature selections dialog. 
> It takes me
> back to what looks like the welcome dialog.
> 
> Anyone else seen this problem?
> 
> Cheers
> 
> Sean.
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ldap_open/ldap_connect in Custom Action

[Jeremy Farrell]

Assuming the code is C or similar ... I know nothing about these APIs, but the 
way you're calling them doesn't make sense. If they expect to receive a pointer 
to a wide character as their first parameter, then they presumably expect that 
pointer to point to a wide character string - taking a pointer to something 
else and converting it to a pointer to a wide character (as you're doing here) 
is almost certainly wrong. If this is the problem, then replacing <(PWCHR)> 
with  should fix it.

If the APIs don't expect a pointer to a wide character as the first parameter, 
why are you casting it to PWCHR?

> From: Kun Shi (ofox) [mailto:s...@vmware.com]
> 
> I need to access LDAP when running a msi on a Windows server 2008 , so
> I have to call LDAP APIs using CA. I tried 2 approaches, but both
> failed with error code 0x51 " Cannot contact the LDAP server ".
> 
> 1. ldap_open((PWCHR)"localhost", 389)
> 2. ldap_init( (PWCHR)"127.0.01", 389 ), then ldap_connect(...)
> 
> I also tested with ldp.exe on the same machine, it could connect to
> LDAP server with localhost.
> 
> Am I doing anything wrong? Did anybody have similar experience?
> 
> Thanks!
> -ofox

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How can I make Wix install only modified files

[Jeremy Chiu]

Hi All,

  I'm trying to create an installer that drops down an exe + a few dlls.
 One of these dlls is infrequently changed and is injected into explorer
(it does icon overlays & explorer loads it when it launches).

  I'm using RemoveExistingProducts after InstallFinalize but I think the
installer is still trying to install the dll.  I suspect this because
msiexec will want to relaunch explorer when install is done even tho I have
not changed the dll's version # (or all at for that matter).  Msiexec is
relaunching explorer via restart manager.  It detects that explorer has a
handle to the dll and closes the explorer app.  My guess is that it is
doing this because it wants to drop down the dll again.  Thus my suspicion
that it is still installing that dll.

  I can 'fix' this problem by marking the dll's component as
NeverOverwrite.  That isn't a real fix tho.

  I've posted this question on
stackoverflow
&
Mike Baz pointed me to this forum.  Hopefully someone here can point me in
the right direction.

Thanks!
--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Where to install to by default nowadays; App Data or Program Files?

[Jeremy Farrell]

Googling 'msdn appdata' brought up 
http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx
 which might be useful.

> From: Katherine Moss [mailto:katherine.m...@gordon.edu]
> Sent: Wednesday, November 28, 2012 8:16 PM
> 
> Thanks.  I'll have to look at the certificate properties then and see
> if I can glean any more information on why the cert needs to be there.
> I always found it odd, but I also know that it is unprofessional to
> push professional developers especially if the source code is not
> publically available.  And in this case, it is a commercial product,
> and just because the dev works for my best friend doesn't really mean
> much; it doesn't mean that I'll use him as my go-to guy.  But anyway,
> then can somebody tell me why certain applications choose to place some
> stuff in app data while some of it is in program files?  Is that
> decision made  based on the needed permissions of the application, or
> is it based on the type of information stored in the directory.  For
> instance, Malwarebytes uses App Data to store logs and other things, so
> I'd assume that Malwarebytes corp thought it too much work to require
> admin priveleges just to install a log directory, right?  And you know
> something even !
>  more interesting?  I think it gets even more dicy when the person
> running the application chooses their own custom directory for the
> application installation.
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Tuesday, November 27, 2012 11:37 PM
> 
> App Data can be non-elevated writable. Program Files requires elevation
> to be placed there. If you go to Program Files you don't have to worry
> about your application being tampered with but an App Data install can
> happen without elevation.
> 
> The certificate comment doesn't make sense to me.
> 
> On Tue, Nov 27, 2012 at 8:12 PM, Katherine Moss
> wrote:
> 
> > I'm just wondering this since I have a program that installs to app
> > data by default rather than program files, and it's developer says
> > that the change of default directory has to do with special
> > permissions needed.  I mean, what is the point of the app data folder
> > anyway? I'd never understood it; why not just leave everything in one
> > directory or the other?  The developer of this application says that
> > the directory being app data also has something to do with a
> > certificate or something.  Could you folks shed any light on this?

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Add Templates

[Jeremy Farrell]

http://www.catb.org/~esr/faqs/smart-questions.html

> From: Chaitanya [mailto:chaita...@pointcross.com]
> Sent: Friday, December 14, 2012 7:46 AM
> 
> Hi,
> 
> How to add templates in wix.
> 
> Thanks for help
> 
> Chaitanya.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Read System IP adresss

[Jeremy Farrell]

To start with you need to define what you mean by "System IP address". The 
smallest Windows systems I use have four different IP addresses, others have 
many more.

> From: Chaitanya [mailto:chaita...@pointcross.com]
> Sent: Thursday, January 03, 2013 08:55
> 
> In wix I want to read system IP address.
> 
> In registry I need to give system name and IP address.I can
> read system name.
> 
> But I cant read System Ip address.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Could not load file or assembly 'GMap.NET.Core, Version=1.7.0.0, Culture=neutral, PublicKeyToken=b85b9027b614afef' or one of its dependencies. The system cannot find the file specified

[Jeremy Farrell]

I'm lost; what has this got to do with WiX?

> From: james pruett [mailto:gpscru...@gmail.com]
> 
> Hi,
> Can anyone spot what I am doing wrong?
> Thanks for looking.
> -cellurl
> 
> 
> VisualStudio10 comes up with this error:--
> 
> Could not load file or assembly 'GMap.NET.Core, Version=1.7.0.0,
> Culture=neutral, PublicKeyToken=b85b9027b614afef' or one of its
> dependencies. The system cannot find the file specified.
> 
> 
> 
> here is the .SED file-
> 
> [Version]
> Class=IEXPRESS
> SEDVersion=3
> [Options]
> PackagePurpose=InstallApp
> ShowInstallProgramWindow=0
> HideExtractAnimation=0
> UseLongFileName=0
> InsideCompressed=0
> CAB_FixedSize=0
> CAB_ResvCodeSigning=0
> RebootMode=N
> InstallPrompt=%InstallPrompt%
> DisplayLicense=%DisplayLicense%
> FinishMessage=%FinishMessage%
> TargetName=%TargetName%
> FriendlyName=%FriendlyName%
> AppLaunched=%AppLaunched%
> PostInstallCmd=%PostInstallCmd%
> AdminQuietInstCmd=%AdminQuietInstCmd%
> UserQuietInstCmd=%UserQuietInstCmd%
> SourceFiles=SourceFiles
> [Strings]
> InstallPrompt=
> DisplayLicense=
> FinishMessage=
> TargetName=C:\aaa_jim_test\Speedanator_installer.EXE
> FriendlyName=Speedanator
> AppLaunched=Demo.WindowsForms.exe
> PostInstallCmd=
> AdminQuietInstCmd=
> UserQuietInstCmd=
> FILE0="GMap.NET.WindowsForms.dll"
> FILE1="Demo.WindowsForms.exe"
> FILE2="GMap.NET.Core.dll"
> [SourceFiles]
> SourceFiles0=C:\aaa_jim_test\
> [SourceFiles0]
> %FILE0%=
> %FILE1%=
> %FILE2%=
> 
> 
> ---here are all the source files--
> 
> http://www.wikispeedia.org/speedo/
> ---

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Persisting Session Variables set in external Custom Actions to Dialog Input defaults?

[Jeremy Rimer]

I am new to WIX and have been tasked with creating an installer that does
the following:

*Deploys a build of our application without overwriting the App.Config file
for the application

*Loads the key/values in the App.Config file and prompts the user with the
"defaults" (existing values) and allows them to modify them before finishing

*SAVES the values the user provided (or defaults if the user made no
changes) back to the App.Config file for use with the application.

I've got the WIX dilalogs and custom actions laid out successfully where
after InstallFinalize, my "LoadDefaultOptions" CustomAction is executed,
which successfully takes the installation directory and the app config file
name, loads it in an XML reader, and parses the key/value pairs, setting
them into the session variable in this manner:

session[key.toUpper()] = value;

My custom action(s) are defined as:




The LoadDefaultOptions executes as such:



I have the custom dialog edit properties set like this:



There's a matching Property tag earlier in the WXS file like this:



...And the LoadDefaultOptions customAction overwrites the session var like
this:

session["CCPCONNECTIONSTRING"] = ;

According to session logs, this works as expected, the xml parse works, and
the session vars are set.

My problem is when my custom dialog comes around to prompt the user with
those stored defaults AFTER the LoadDefaultOptions CustomAction has run. The
ORIGINAL property values of the session variables seem to have "stuck"
instead of being overwritten by the custom action that loaded the defaults
via the xml file and stored them in the session. (they are blank as their
original properties are defined, or in the case I define them otherwise,
they show those values instead of the session written values)

How do you get Dialogs to "read" overridden session variables by
CustomActions?

Ultimately I want to load those values from the app config, prompt them back
to the user in an optional dialog prompt off the exit screen (which works so
far, aside from not getting updated session vars), and then on command from
that prompt dialog, run another custom action to re-write the App.Config
file with the settings provided from the custom dialog...

I just can't get the session vars to PERSIST!!!

Any ideas? am I completely off base attempting to use the session in this
manner? how else could I parse the app.config file, and allow an
installation user to change app settings if not by session?
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Persisting Session Variables set in external Custom Actions to Dialog Input defaults?

[Jeremy Rimer]

Blair,

What you've said below makes perfect sense, but unfortunately won't work for
my situation as the InstallUISequence runs BEFORE the
InstallExecuteSequence, and the app.config file I need to parse will not
have been deployed to be read at any point in the InstallUISequence during a
fresh install!

This leads me to believe what i'm trying to do is nearly impossible using
WIX (which may be true...)

However, If I only attempt to read the existing app.config file during an
UPGRADE installation, I can then set into the session the EXISTING settings
from the earlier installation's app.config file (which WOULD exist during
the InstallUISequence), which is another part of my puzzle to solve...

In fact, if I can do that, then I'll be "good enough" for this project.
...Now to figure out how to only run the custom action in the upgrade
situation :).

-Rimer

On Mon, Jul 12, 2010 at 5:36 PM, Blair  wrote:

> Dialogs read values from the UI session. If the custom action runs in the
> InstallUISequence then the properties will be available. If the custom
> action runs in the InstallExecuteSequence, then those properties will not
> be
> available to the dialogs, since properties only flow from the UI to the
> Execute sequence (and only a subset of the properties, at that).
>
> If the App.Config file comes from your application, it would be more
> typical
> to read those values in your build and set them in the MSI as default
> property values which you would then show to the User before the
> InstallExecuteSequence even begins. If the file is present already (because
> you are upgrading or modifying) you could read the resident App.Config file
> in a custom action in the UI sequence and change the properties to what you
> found as your new "defaults". Then you can write them to the App.Config
> inside of the install sequence between InstallInitialize and
> InstallFinalize.
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Monday, July 12, 2010 2:19 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Persisting Session Variables set in external Custom
> Actions to Dialog Input defaults?
>
> I am new to WIX and have been tasked with creating an installer that does
> the following:
>
> *Deploys a build of our application without overwriting the App.Config file
> for the application
>
> *Loads the key/values in the App.Config file and prompts the user with the
> "defaults" (existing values) and allows them to modify them before
> finishing
>
> *SAVES the values the user provided (or defaults if the user made no
> changes) back to the App.Config file for use with the application.
>
> I've got the WIX dilalogs and custom actions laid out successfully where
> after InstallFinalize, my "LoadDefaultOptions" CustomAction is executed,
> which successfully takes the installation directory and the app config file
> name, loads it in an XML reader, and parses the key/value pairs, setting
> them into the session variable in this manner:
>
> session[key.toUpper()] = value;
>
> My custom action(s) are defined as:
>
>  Execute="immediate" BinaryKey="aeserverDbDialogPackage.dll"
> DllEntry="LoadDefaultOptions"/>
>  BinaryKey="aeserverDbDialogPackage.dll" DllEntry="SetConfigOptions"/>
>
> The LoadDefaultOptions executes as such:
>
> 
>
> I have the custom dialog edit properties set like this:
>
>  Height="18" Property="CCPCONNECTIONSTRING" Indirect="no" />
>
> There's a matching Property tag earlier in the WXS file like this:
>
> 
>
> ...And the LoadDefaultOptions customAction overwrites the session var like
> this:
>
> session["CCPCONNECTIONSTRING"] = ;
>
> According to session logs, this works as expected, the xml parse works, and
> the session vars are set.
>
> My problem is when my custom dialog comes around to prompt the user with
> those stored defaults AFTER the LoadDefaultOptions CustomAction has run.
> The
> ORIGINAL property values of the session variables seem to have "stuck"
> instead of being overwritten by the custom action that loaded the defaults
> via the xml file and stored them in the session. (they are blank as their
> original properties are defined, or in the case I define them otherwise,
> they show those values instead of the session written values)
>
> How do you get Dialogs to "read" overridden session variables by
> CustomActions?
>
> Ultimately I want to load those values from the app config, prompt them
> back
> to the user in an optional dialog prompt off the exit screen (which works
> so
> far, as

[WiX-users] WIX Upgrade configuration

[Jeremy Rimer]

I've solved my App.Config issues with help from Blair (Thanks, buddy!!!),
but now I'm running into upgrade path problems...

To set the stage, I have a WIX installer that successfully deploys an
application to it's installation directory, and takes some input from the
user that calls a CA to overwrite some elements of the App.Config file that
were deployed, or were present before deployment (NeverOverwrite="yes" on
the App.Config file)...

On clean install, the files deploy perfectly, and the app.config overwrite
works great. Running the installer AGAIN, I get the Repair/Remove dialogs,
which indicates the installer is self-aware.

My problem is when I rebuild a new installer with a new product version, and
a new Product GUID Id. . .

It runs through the new installation path, and completes, but I end up with
a duplicate program installed. It shows up in Add/Remove programs twice,
instead of "RemovingExistingProducts" silently before the upgrade
installation first :(.

My upgrade definition is as follows:
=

  
  
  

==

In the InstallExecuteSequence, I've put the following:
==
PREVIOUSVERSIONSINSTALLED
==

...And before I attempt the upgrade, I rebuild the installer with a new ID
GUID for the Product definition, and a new $(var.ProductVersion) that is
greater than the original installations'...

Running it then, the installer seems to execute what seems like the "fresh
install" path, and results in a dupilcate entry in the Add/Remove Programs
dialog in windows if the installation is then completed. :\

Anything I'm missing that you can tell?

Thanks as always!
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WIX Upgrade configuration

[Jeremy Rimer]

Blair, as always, thanks for your replies! Unfortunately, this time I came
up empty :(.

I did the following but still ended up with a duplicate of my applications
installed in Add/Remove Programs after the Installer finished:

   - I modified my upgrade element as follows:

=

  
  
  

=

   - I generated a new GUID for my PRODUCT Id.
   - I incremented my ProductVersion from 2.9.0 to 2.10.0
   - I uninstalled all versions via Add/Remove Programs
   - I installed the 2.9.0 package
   - I installed the 2.10.0 package.
   - I checked out Add/Remove Programs, and saw both versions installed

I made the PREVIOUSVERSIONINSTALLED element my OnlyDetect="no" as it is the
one that should be uninstalled when encountered. I guess so should the same
version, but if that happens, you should get the remove/repair dialog
instead, right?

Anything else I could have missed?

On Tue, Jul 13, 2010 at 5:42 PM, Blair  wrote:

> In the UpgradeVersion element, OnlyDetect does exactly what it suggests: it
> only detects all matching products (setting the indicated property with the
> list of found ProductCodes), suppressing passing those ProductCodes to
> RemoveExistingProducts. Set OnlyDetect to "no" for those properties that
> contain the packages you intend to remove. Or remove it entirely for those
> same properties, since it defaults to "no".
>
> Leave OnlyDetect set to "yes" for those properties that you won't be
> removing (such as newer versions you use to block installation, etc.)
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Tuesday, July 13, 2010 12:36 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WIX Upgrade configuration
>
> I've solved my App.Config issues with help from Blair (Thanks, buddy!!!),
> but now I'm running into upgrade path problems...
>
> To set the stage, I have a WIX installer that successfully deploys an
> application to it's installation directory, and takes some input from the
> user that calls a CA to overwrite some elements of the App.Config file that
> were deployed, or were present before deployment (NeverOverwrite="yes" on
> the App.Config file)...
>
> On clean install, the files deploy perfectly, and the app.config overwrite
> works great. Running the installer AGAIN, I get the Repair/Remove dialogs,
> which indicates the installer is self-aware.
>
> My problem is when I rebuild a new installer with a new product version,
> and
> a new Product GUID Id. . .
>
> It runs through the new installation path, and completes, but I end up with
> a duplicate program installed. It shows up in Add/Remove programs twice,
> instead of "RemovingExistingProducts" silently before the upgrade
> installation first :(.
>
> My upgrade definition is as follows:
> =
> 
>  OnlyDetect='yes'
>Property='PREVIOUSVERSIONSINSTALLED'
>  Minimum='0.0.0.0'
>IncludeMinimum='yes'
>  Maximum='$(var.ProductVersion)'
>IncludeMaximum='no' />
>  OnlyDetect='yes'
>Property='SELFFOUND'
>  Minimum='$(var.ProductVersion)'
>IncludeMinimum='yes'
>Maximum='$(var.ProductVersion)'
>IncludeMaximum='yes' />
>  OnlyDetect='yes'
>Property='NEWERFOUND'
>  Minimum='$(var.ProductVersion)'
>IncludeMinimum='no' />
>
> ==
>
> In the InstallExecuteSequence, I've put the following:
> ==
> 
> After="InstallInitialize">PREVIOUSVERSIONSINSTALLED
> ==
>
> ...And before I attempt the upgrade, I rebuild the installer with a new ID
> GUID for the Product definition, and a new $(var.ProductVersion) that is
> greater than the original installations'...
>
> Running it then, the installer seems to execute what seems like the "fresh
> install" path, and results in a dupilcate entry in the Add/Remove Programs
> dialog in windows if the installation is then completed. :\
>
> Anything I'm missing that you can tell?
>
> Thanks as always!
>
> 
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> 

Re: [WiX-users] WIX Upgrade configuration

[Jeremy Rimer]

Hahaha nevermind... I see that I totally got it backwards... I reversed my
OnlyDetects below and it works great... You rock... Sorry!

-Jeremy

On Wed, Jul 14, 2010 at 9:20 AM, Jeremy Rimer  wrote:

> Blair, as always, thanks for your replies! Unfortunately, this time I came
> up empty :(.
>
> I did the following but still ended up with a duplicate of my applications
> installed in Add/Remove Programs after the Installer finished:
>
>- I modified my upgrade element as follows:
>
> =
> 
>OnlyDetect="yes"
> Property="PREVIOUSVERSIONSINSTALLED"
>   Minimum="0.0.0.0"
> IncludeMinimum="yes"
>   Maximum="$(var.ProductVersion)"
> IncludeMaximum="no" />
>OnlyDetect="no"
> Property="SELFFOUND"
>   Minimum="$(var.ProductVersion)"
> IncludeMinimum="yes"
> Maximum="$(var.ProductVersion)"
> IncludeMaximum="yes" />
>OnlyDetect="no"
> Property="NEWERFOUND"
>   Minimum="$(var.ProductVersion)"
> IncludeMinimum="no" />
> 
> =
>
>- I generated a new GUID for my PRODUCT Id.
>- I incremented my ProductVersion from 2.9.0 to 2.10.0
>- I uninstalled all versions via Add/Remove Programs
>- I installed the 2.9.0 package
>- I installed the 2.10.0 package.
>- I checked out Add/Remove Programs, and saw both versions installed
>
> I made the PREVIOUSVERSIONINSTALLED element my OnlyDetect="no" as it is the
> one that should be uninstalled when encountered. I guess so should the same
> version, but if that happens, you should get the remove/repair dialog
> instead, right?
>
> Anything else I could have missed?
>
>
> On Tue, Jul 13, 2010 at 5:42 PM, Blair  wrote:
>
>> In the UpgradeVersion element, OnlyDetect does exactly what it suggests:
>> it
>> only detects all matching products (setting the indicated property with
>> the
>> list of found ProductCodes), suppressing passing those ProductCodes to
>> RemoveExistingProducts. Set OnlyDetect to "no" for those properties that
>> contain the packages you intend to remove. Or remove it entirely for those
>> same properties, since it defaults to "no".
>>
>> Leave OnlyDetect set to "yes" for those properties that you won't be
>> removing (such as newer versions you use to block installation, etc.)
>>
>> -Original Message-
>> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
>> Sent: Tuesday, July 13, 2010 12:36 PM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] WIX Upgrade configuration
>>
>> I've solved my App.Config issues with help from Blair (Thanks, buddy!!!),
>> but now I'm running into upgrade path problems...
>>
>> To set the stage, I have a WIX installer that successfully deploys an
>> application to it's installation directory, and takes some input from the
>> user that calls a CA to overwrite some elements of the App.Config file
>> that
>> were deployed, or were present before deployment (NeverOverwrite="yes" on
>> the App.Config file)...
>>
>> On clean install, the files deploy perfectly, and the app.config overwrite
>> works great. Running the installer AGAIN, I get the Repair/Remove dialogs,
>> which indicates the installer is self-aware.
>>
>> My problem is when I rebuild a new installer with a new product version,
>> and
>> a new Product GUID Id. . .
>>
>> It runs through the new installation path, and completes, but I end up
>> with
>> a duplicate program installed. It shows up in Add/Remove programs twice,
>> instead of "RemovingExistingProducts" silently before the upgrade
>> installation first :(.
>>
>> My upgrade definition is as follows:
>> =
>> 
>>  >OnlyDetect='yes'
>>Property='PREVIOUSVERSIONSINSTALLED'
>>  Minimum='0.0.0.0'
>>IncludeMinimum='yes'
>>  Maximum='$(var.ProductVersion)'
>>IncludeMaximum='no' />
>>  >OnlyDetect='yes'
>>Property='SELFFOUND'
>>  Minimum='$(var.ProductVersion)'
>>IncludeMinimum='yes'
>>Maximum='$(var.Pr

[WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

I have one last problem before my installer is completely working:

I have a custom EXIT dialog that I created called MyExitDialog that contains
an extra button that spawns a custom dialog to gather application settings
from the user to write into the App.Config file that was deployed and/or
existed during installation or repair.

The dialog does its job, but unfortunately it also displays (and does its
job) after an application has been removed with the installer, which is
useless, of course since there's no more app.config file to care about on a
removal of the application.

I see in the Publish elements how to conditionally control what a button *
does*, but how do you conditionally control when a button *shows itself* in
its dialog?

If this is impossible, how can I force the installer to display the standard
WIX ExitDialog instead of MyExitDialog in the case of a REMOVE operation
(vs. repair or new installation?).

my MyExitDialog definition is as follows, and the Control with
Id="ApplicationSettings" is my button I'd like to hide on product removals:












  WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
Installed


  WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND
NOT Installed

  


Thanks again,

Rimer
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

I must also add that under my custom exit dialog, I have this:
==







==
... but this just causes NO exit dialog to show in both Install and Remove
paths of the installer :(
-Jeremy


On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer wrote:

> I have one last problem before my installer is completely working:
>
> I have a custom EXIT dialog that I created called MyExitDialog that
> contains an extra button that spawns a custom dialog to gather application
> settings from the user to write into the App.Config file that was deployed
> and/or existed during installation or repair.
>
> The dialog does its job, but unfortunately it also displays (and does its
> job) after an application has been removed with the installer, which is
> useless, of course since there's no more app.config file to care about on a
> removal of the application.
>
> I see in the Publish elements how to conditionally control what a button *
> does*, but how do you conditionally control when a button *shows itself*in 
> its dialog?
>
> If this is impossible, how can I force the installer to display the
> standard WIX ExitDialog instead of MyExitDialog in the case of a REMOVE
> operation (vs. repair or new installation?).
>
> my MyExitDialog definition is as follows, and the Control with
> Id="ApplicationSettings" is my button I'd like to hide on product removals:
> 
>  Title="!(loc.ExitDialog_Title)">
>  Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
> 
>  Width="130" Height="17" Default="no" Cancel="no" Text="Modify Application
> Settings" >
>  Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
>  Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
> 
>  Height="0" />
>  Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish button
> to exit the Setup Wizard. Alternatively, Click the Modify Application
> Settings button to alter the behavior of the application." />
>  Height="60" Transparent="yes" NoPrefix="yes" Text="!(loc.ExitDialogTitle)"
> />
>  Height="80" Transparent="yes" NoPrefix="yes" Hidden="yes"
> Text="[WIXUI_EXITDIALOGOPTIONALTEXT]">
>   WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
> Installed
> 
>  Width="220" Height="40" Hidden="yes"
> Property="WIXUI_EXITDIALOGOPTIONALCHECKBOX" CheckBoxValue="1"
> Text="[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT]">
>   WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND
> NOT Installed
> 
>   
> 
>
> Thanks again,
>
> Rimer
>
>
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

I put  in those Show elements, but it still
showed the MyExitDialog in both the Remove and Install paths... ?

On Wed, Jul 14, 2010 at 10:55 AM, Dan Hoeger wrote:

> INSTALLED is still undefined at the end of the initial install.
>
> So you would want the condition below to be "NOT INSTALLED" to be true for
> the initial install.
>
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Wednesday, July 14, 2010 10:25 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installer action (installed vs. removed vs. repaired, etc)
>
> I must also add that under my custom exit dialog, I have this:
> ==
> 
> OnExit="success">
> 
>
> 
> >
> 
> ==
> ... but this just causes NO exit dialog to show in both Install and Remove
> paths of the installer :( -Jeremy
>
>
> On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer  >wrote:
>
> > I have one last problem before my installer is completely working:
> >
> > I have a custom EXIT dialog that I created called MyExitDialog that
> > contains an extra button that spawns a custom dialog to gather
> > application settings from the user to write into the App.Config file
> > that was deployed and/or existed during installation or repair.
> >
> > The dialog does its job, but unfortunately it also displays (and does
> > its
> > job) after an application has been removed with the installer, which
> > is useless, of course since there's no more app.config file to care
> > about on a removal of the application.
> >
> > I see in the Publish elements how to conditionally control what a
> > button * does*, but how do you conditionally control when a button *shows
> itself*in its dialog?
> >
> > If this is impossible, how can I force the installer to display the
> > standard WIX ExitDialog instead of MyExitDialog in the case of a
> > REMOVE operation (vs. repair or new installation?).
> >
> > my MyExitDialog definition is as follows, and the Control with
> > Id="ApplicationSettings" is my button I'd like to hide on product
> removals:
> > 
> >  > Title="!(loc.ExitDialog_Title)">
> >  > Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
> > 
> >  Y="243"
> > Width="130" Height="17" Default="no" Cancel="no" Text="Modify
> > Application Settings" >
> >  > Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
> >  > Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
> > 
> >  > Height="0" />
> >  > Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish
> > button to exit the Setup Wizard. Alternatively, Click the Modify
> > Application Settings button to alter the behavior of the application." />
> >  > Height="60" Transparent="yes" NoPrefix="yes"
> Text="!(loc.ExitDialogTitle)"
> > />
> >  Width="220"
> > Height="80" Transparent="yes" NoPrefix="yes" Hidden="yes"
> > Text="[WIXUI_EXITDIALOGOPTIONALTEXT]">
> >   WIXUI_EXITDIALOGOPTIONALTEXT AND
> > NOT Installed
> > 
> >  > Width="220" Height="40" Hidden="yes"
> > Property="WIXUI_EXITDIALOGOPTIONALCHECKBOX" CheckBoxValue="1"
> > Text="[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT]">
> >> Action="show">WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND NOT
> Installed
> > 
> >   
> > 
> >
> > Thanks again,
> >
> > Rimer
> >
> >
>
> --
> This SF.net email is sponsored by Sprint What will you do first with EVO,
> the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

Unfortunately not with the way it is currently written...

This custom MyExitDialog occurs at the right time during every run of the
installer, in lieu of the WIX standard ExitDialog. I have a button on it
that spawns an extra dialog (if you don't press finish instead, which quits
the installer), which then spawns the configuration input dialog for users
to modify some database settings before exiting the installer... I need to
either NOT SHOW that button, or show the standard WIX ExitDialog in the case
of a removal path...

On Wed, Jul 14, 2010 at 11:06 AM, Blair  wrote:

> Could your custom action be written such that it simply exits early with a
> success code if it doesn't find the App.Config file?
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Wednesday, July 14, 2010 8:25 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installer
> action (installed vs. removed vs. repaired, etc)
>
> I must also add that under my custom exit dialog, I have this:
> ==
> 
> OnExit="success">
> 
>
> 
> >
> 
> ==
> ... but this just causes NO exit dialog to show in both Install and Remove
> paths of the installer :(
> -Jeremy
>
>
> On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer  >wrote:
>
> > I have one last problem before my installer is completely working:
> >
> > I have a custom EXIT dialog that I created called MyExitDialog that
> > contains an extra button that spawns a custom dialog to gather
> application
> > settings from the user to write into the App.Config file that was
> deployed
> > and/or existed during installation or repair.
> >
> > The dialog does its job, but unfortunately it also displays (and does its
> > job) after an application has been removed with the installer, which is
> > useless, of course since there's no more app.config file to care about on
> a
> > removal of the application.
> >
> > I see in the Publish elements how to conditionally control what a button
> *
> > does*, but how do you conditionally control when a button *shows
> itself*in
> its dialog?
> >
> > If this is impossible, how can I force the installer to display the
> > standard WIX ExitDialog instead of MyExitDialog in the case of a REMOVE
> > operation (vs. repair or new installation?).
> >
> > my MyExitDialog definition is as follows, and the Control with
> > Id="ApplicationSettings" is my button I'd like to hide on product
> removals:
> > 
> >  > Title="!(loc.ExitDialog_Title)">
> >  > Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
> > 
> >  Y="243"
> > Width="130" Height="17" Default="no" Cancel="no" Text="Modify Application
> > Settings" >
> >  > Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
> >  > Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
> > 
> >  > Height="0" />
> >  > Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish
> button
> > to exit the Setup Wizard. Alternatively, Click the Modify Application
> > Settings button to alter the behavior of the application." />
> >  > Height="60" Transparent="yes" NoPrefix="yes"
> Text="!(loc.ExitDialogTitle)"
> > />
> >  Width="220"
> > Height="80" Transparent="yes" NoPrefix="yes" Hidden="yes"
> > Text="[WIXUI_EXITDIALOGOPTIONALTEXT]">
> >   WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
> > Installed
> > 
> >  > Width="220" Height="40" Hidden="yes"
> > Property="WIXUI_EXITDIALOGOPTIONALCHECKBOX" CheckBoxValue="1"
> > Text="[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT]">
> >   WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT
> AND
> > NOT Installed
> > 
> >   
> > 
> >
> > Thanks again,
> >
> > Rimer
> >
> >
>
> 
> --
> This SF.

Re: [WiX-users] Conditionally Show Dialog Button based on Installeraction (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

funny you mention that... The original requirements of this installer were
to prompt the user the defaults provided in the App.Config file of the
deployed program, which meant that we COULDNT prompt the user for settings
before the files were copied. It turned out that particular action was
impossible ANYWAY, because you can't modify the session for use in dialogs
AFTER the files are copied, only prior in the UI sequence... So perhaps if I
re-engineered this whole thing to prompt FIRST, I can avoid these problems?

The way it is currently written, you can either overwrite, or set the
settings OPTIONALLY before exiting the installer. (i.e. leave the app.config
unmolested from the installation, or prior installation, OR, branch off and
edit the entries, and submit to update the deployed app.config file...


On Wed, Jul 14, 2010 at 11:29 AM, Pally Sandher wrote:

> Wouldn't it be better to ask the user the configuration questions during
> the UI Sequence & make the modifications to the app.config using
> XMLConfig as part of the install process? That way you could condition
> when your dialog is shown more appropriately instead of needing multiple
> ExitDialogs and you'd be following standard expected installer
> conventions.
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
>
> http://www.iesve.com
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: 14 July 2010 17:09
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installeraction (installed vs. removed vs. repaired, etc)
>
> I put  in those Show elements, but it still
> showed the MyExitDialog in both the Remove and Install paths... ?
>
> On Wed, Jul 14, 2010 at 10:55 AM, Dan Hoeger
> wrote:
>
> > INSTALLED is still undefined at the end of the initial install.
> >
> > So you would want the condition below to be "NOT INSTALLED" to be true
>
> > for the initial install.
> >
> >
> > -Original Message-
> > From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> > Sent: Wednesday, July 14, 2010 10:25 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> > Installer action (installed vs. removed vs. repaired, etc)
> >
> > I must also add that under my custom exit dialog, I have this:
> > ==
> > 
> > > OnExit="success">
> > 
> >
> > 
> > > >
> > 
> > ==
> > ... but this just causes NO exit dialog to show in both Install and
> > Remove paths of the installer :( -Jeremy
> >
> >
> > On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer  > >wrote:
> >
> > > I have one last problem before my installer is completely working:
> > >
> > > I have a custom EXIT dialog that I created called MyExitDialog that
> > > contains an extra button that spawns a custom dialog to gather
> > > application settings from the user to write into the App.Config file
>
> > > that was deployed and/or existed during installation or repair.
> > >
> > > The dialog does its job, but unfortunately it also displays (and
> > > does its
> > > job) after an application has been removed with the installer, which
>
> > > is useless, of course since there's no more app.config file to care
> > > about on a removal of the application.
> > >
> > > I see in the Publish elements how to conditionally control what a
> > > button * does*, but how do you conditionally control when a button
> > > *shows
> > itself*in its dialog?
> > >
> > > If this is impossible, how can I force the installer to display the
> > > standard WIX ExitDialog instead of MyExitDialog in the case of a
> > > REMOVE operation (vs. repair or new installation?).
> > >
> > > my MyExitDialog definition is as follows, and the Control with
> > > Id="ApplicationSettings" is my button I'd like to hide on product
> > removals:
> > > 
> > >  > > Title="!(loc.ExitDialog_Title)">
> > >  Width="56&q

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

Hmmm...

I did this:
===







===

and it still shows it on both install and uninstall...

I put "ALL" in quotes, and it DOESNT show it on install... :(

-J


On Wed, Jul 14, 2010 at 12:33 PM, Blair  wrote:

> Condition the button to be hidden if REMOVE=ALL ?
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Wednesday, July 14, 2010 9:25 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installer
> action (installed vs. removed vs. repaired, etc)
>
> Unfortunately not with the way it is currently written...
>
> This custom MyExitDialog occurs at the right time during every run of the
> installer, in lieu of the WIX standard ExitDialog. I have a button on it
> that spawns an extra dialog (if you don't press finish instead, which quits
> the installer), which then spawns the configuration input dialog for users
> to modify some database settings before exiting the installer... I need to
> either NOT SHOW that button, or show the standard WIX ExitDialog in the
> case
> of a removal path...
>
> On Wed, Jul 14, 2010 at 11:06 AM, Blair  wrote:
>
> > Could your custom action be written such that it simply exits early with
> a
> > success code if it doesn't find the App.Config file?
> >
> > -Original Message-
> > From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> > Sent: Wednesday, July 14, 2010 8:25 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> > Installer
> > action (installed vs. removed vs. repaired, etc)
> >
> > I must also add that under my custom exit dialog, I have this:
> > ==
> > 
> > > OnExit="success">
> > 
> >
> > 
> > > >
> > 
> > ==
> > ... but this just causes NO exit dialog to show in both Install and
> Remove
> > paths of the installer :(
> > -Jeremy
> >
> >
> > On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer  > >wrote:
> >
> > > I have one last problem before my installer is completely working:
> > >
> > > I have a custom EXIT dialog that I created called MyExitDialog that
> > > contains an extra button that spawns a custom dialog to gather
> > application
> > > settings from the user to write into the App.Config file that was
> > deployed
> > > and/or existed during installation or repair.
> > >
> > > The dialog does its job, but unfortunately it also displays (and does
> its
> > > job) after an application has been removed with the installer, which is
> > > useless, of course since there's no more app.config file to care about
> on
> > a
> > > removal of the application.
> > >
> > > I see in the Publish elements how to conditionally control what a
> button
> > *
> > > does*, but how do you conditionally control when a button *shows
> > itself*in
> > its dialog?
> > >
> > > If this is impossible, how can I force the installer to display the
> > > standard WIX ExitDialog instead of MyExitDialog in the case of a REMOVE
> > > operation (vs. repair or new installation?).
> > >
> > > my MyExitDialog definition is as follows, and the Control with
> > > Id="ApplicationSettings" is my button I'd like to hide on product
> > removals:
> > > 
> > >  > > Title="!(loc.ExitDialog_Title)">
> > >  Width="56"
> > > Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
> > > 
> > >  > Y="243"
> > > Width="130" Height="17" Default="no" Cancel="no" Text="Modify
> Application
> > > Settings" >
> > >  Width="56"
> > > Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
> > >  > > Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
> > > 
> > >  > > Height="0" />
> > >  Width="220"
> > > Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish
> > button
> >

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

To be more specific...

It seems that with  in there, It shows the
MyExitDialog in BOTH scenarios...

I even tried putting something like this in:
==









==

But I'm getting "The InstallUISequence table contains an action 'ExitDialog'
that is declared in two different locations.  Please remove one of the
actions or set the Overridable='yes' attribute on one of their elements."
errors when I do this...

Additionally, it seems to always do the same thing either way... it either
shows MyExitDialog in both situations (remove/install), or shows NO exit
dialog, and skips that step and auto-finishes and closes the installer once
the program completes ...

-J




On Wed, Jul 14, 2010 at 12:57 PM, Jeremy Rimer wrote:

> Hmmm...
>
> I did this:
> ===
> 
>  OnExit="success">
> 
>
> 
>  >
> 
> ===
>
> and it still shows it on both install and uninstall...
>
> I put "ALL" in quotes, and it DOESNT show it on install... :(
>
> -J
>
>
>
> On Wed, Jul 14, 2010 at 12:33 PM, Blair  wrote:
>
>> Condition the button to be hidden if REMOVE=ALL ?
>>
>> -Original Message-
>> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
>> Sent: Wednesday, July 14, 2010 9:25 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
>> Installer
>> action (installed vs. removed vs. repaired, etc)
>>
>> Unfortunately not with the way it is currently written...
>>
>> This custom MyExitDialog occurs at the right time during every run of the
>> installer, in lieu of the WIX standard ExitDialog. I have a button on it
>> that spawns an extra dialog (if you don't press finish instead, which
>> quits
>> the installer), which then spawns the configuration input dialog for users
>> to modify some database settings before exiting the installer... I need to
>> either NOT SHOW that button, or show the standard WIX ExitDialog in the
>> case
>> of a removal path...
>>
>> On Wed, Jul 14, 2010 at 11:06 AM, Blair  wrote:
>>
>> > Could your custom action be written such that it simply exits early with
>> a
>> > success code if it doesn't find the App.Config file?
>> >
>> > -Original Message-
>> > From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
>> > Sent: Wednesday, July 14, 2010 8:25 AM
>> > To: General discussion for Windows Installer XML toolset.
>> > Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
>> > Installer
>> > action (installed vs. removed vs. repaired, etc)
>> >
>> > I must also add that under my custom exit dialog, I have this:
>> > ==
>> > 
>> >> > OnExit="success">
>> > 
>> >
>> > 
>> >> > >
>> > 
>> > ==
>> > ... but this just causes NO exit dialog to show in both Install and
>> Remove
>> > paths of the installer :(
>> > -Jeremy
>> >
>> >
>> > On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer > > >wrote:
>> >
>> > > I have one last problem before my installer is completely working:
>> > >
>> > > I have a custom EXIT dialog that I created called MyExitDialog that
>> > > contains an extra button that spawns a custom dialog to gather
>> > application
>> > > settings from the user to write into the App.Config file that was
>> > deployed
>> > > and/or existed during installation or repair.
>> > >
>> > > The dialog does its job, but unfortunately it also displays (and does
>> its
>> > > job) after an application has been removed with the installer, which
>> is
>> > > useless, of course since there's no more app.config file to care about
>> on
>> > a
>> > > removal of the application.
>> > >
>> > > I see in the Publish elements how to conditionally control what a
>> button
>> > *
>> > > does*, but how do you conditionally control when a button *shows
>> > itself*in
>> > its dialog?
>> > >
>> > > If this is impossible, how can I force the installer to display the
>> > > standard WIX ExitDialog instead of MyExitDialog in the case of a
>> REMOVE
>> > > operation (vs. repair or n

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

Here's MyExitDialog:













  WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
Installed


  WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND
NOT Installed

  


If I try to put a conditional in the Control element, I get WIX compile
errors... How do you control the display of a button in a dialog
conditionally?


On Wed, Jul 14, 2010 at 1:11 PM, Blair  wrote:

> Use MyExitDialog always, and hide the button in that dialog that runs your
> CA.
>
> -Original Message-----
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Wednesday, July 14, 2010 11:04 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installer
> action (installed vs. removed vs. repaired, etc)
>
> To be more specific...
>
> It seems that with  in there, It shows the
> MyExitDialog in BOTH scenarios...
>
> I even tried putting something like this in:
> ==
> 
> OnExit="success">
> OnExit="success">
> 
>
> 
> >
> OnExit="success">
> 
> ==
>
> But I'm getting "The InstallUISequence table contains an action
> 'ExitDialog'
> that is declared in two different locations.  Please remove one of the
> actions or set the Overridable='yes' attribute on one of their elements."
> errors when I do this...
>
> Additionally, it seems to always do the same thing either way... it either
> shows MyExitDialog in both situations (remove/install), or shows NO exit
> dialog, and skips that step and auto-finishes and closes the installer once
> the program completes ...
>
> -J
>
>
>
>
> On Wed, Jul 14, 2010 at 12:57 PM, Jeremy Rimer  >wrote:
>
> > Hmmm...
> >
> > I did this:
> > ===
> > 
> >  > OnExit="success">
> > 
> >
> > 
> >  > >
> > 
> > ===
> >
> > and it still shows it on both install and uninstall...
> >
> > I put "ALL" in quotes, and it DOESNT show it on install... :(
> >
> > -J
> >
> >
> >
> > On Wed, Jul 14, 2010 at 12:33 PM, Blair  wrote:
> >
> >> Condition the button to be hidden if REMOVE=ALL ?
> >>
> >> -Original Message-
> >> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> >> Sent: Wednesday, July 14, 2010 9:25 AM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> >> Installer
> >> action (installed vs. removed vs. repaired, etc)
> >>
> >> Unfortunately not with the way it is currently written...
> >>
> >> This custom MyExitDialog occurs at the right time during every run of
> the
> >> installer, in lieu of the WIX standard ExitDialog. I have a button on it
> >> that spawns an extra dialog (if you don't press finish instead, which
> >> quits
> >> the installer), which then spawns the configuration input dialog for
> users
> >> to modify some database settings before exiting the installer... I need
> to
> >> either NOT SHOW that button, or show the standard WIX ExitDialog in the
> >> case
> >> of a removal path...
> >>
> >> On Wed, Jul 14, 2010 at 11:06 AM, Blair  wrote:
> >>
> >> > Could your custom action be written such that it simply exits early
> with
> >> a
> >> > success code if it doesn't find the App.Config file?
> >> >
> >> > -Original Message-
> >> > From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> >> > Sent: Wednesday, July 14, 2010 8:25 AM
> >> > To: General discussion for Windows Installer XML toolset.
> >> > Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> >> > Installer
> >> > action (installed vs. removed vs. repaired, etc)
> >> >
> >> > I must also add that under my custom exit dialog, I have this:
> >> > ==
> >> > 
> >> > >> > OnExit="success">
> >> > 
> >> >
> >> > 
> >> > >> > >
> >> > 
> >> > ==
> >> > ... but this just causes NO exit dialog to show in

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

M I think we're on the right track, but using what you have below NEVER
shows the button, regardless of REMOVE path or INSTALL path... are there any
other conditionals that would match those states at the time this dialog is
shown? (which is AFTER install)?

On Wed, Jul 14, 2010 at 1:33 PM, Blair  wrote:

> You have to specify what action the condition will invoke. In this case, I
> would assume you would use Action="hide" in your Condition element under
> your control.
>
> Width="130" Height="17" Default="no" Cancel="no" Text="Modify Application
> Settings" >REMOVE=ALL
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: Wednesday, July 14, 2010 11:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> Installer
> action (installed vs. removed vs. repaired, etc)
>
> Here's MyExitDialog:
>
> 
>  Title="!(loc.ExitDialog_Title)">
> Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
>
> Width="130" Height="17" Default="no" Cancel="no" Text="Modify Application
> Settings" >
> Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
> Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
>
> Height="0" />
> Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish button
> to exit the Setup Wizard. Alternatively, Click the Modify Application
> Settings button to alter the behavior of the application." />
> Height="60" Transparent="yes" NoPrefix="yes" Text="!(loc.ExitDialogTitle)"
> />
> Height="80" Transparent="yes" NoPrefix="yes" Hidden="yes"
> Text="[WIXUI_EXITDIALOGOPTIONALTEXT]">
>  WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
> Installed
>
> Width="220" Height="40" Hidden="yes"
> Property="WIXUI_EXITDIALOGOPTIONALCHECKBOX" CheckBoxValue="1"
> Text="[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT]">
>  WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND
> NOT Installed
>
>  
> 
>
> If I try to put a conditional in the Control element, I get WIX compile
> errors... How do you control the display of a button in a dialog
> conditionally?
>
>
> On Wed, Jul 14, 2010 at 1:11 PM, Blair  wrote:
>
> > Use MyExitDialog always, and hide the button in that dialog that runs
> your
> > CA.
> >
> > -Original Message-
> > From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> > Sent: Wednesday, July 14, 2010 11:04 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Conditionally Show Dialog Button based on
> > Installer
> > action (installed vs. removed vs. repaired, etc)
> >
> > To be more specific...
> >
> > It seems that with  in there, It shows the
> > MyExitDialog in BOTH scenarios...
> >
> > I even tried putting something like this in:
> > ==
> > 
> > > OnExit="success">
> > > OnExit="success">
> > 
> >
> > 
> > > >
> > > OnExit="success">
> > 
> > ==
> >
> > But I'm getting "The InstallUISequence table contains an action
> > 'ExitDialog'
> > that is declared in two different locations.  Please remove one of the
> > actions or set the Overridable='yes' attribute on one of their elements."
> > errors when I do this...
> >
> > Additionally, it seems to always do the same thing either way... it
> either
> > shows MyExitDialog in both situations (remove/install), or shows NO exit
> > dialog, and skips that step and auto-finishes and closes the installer
> once
> > the program completes ...
> >
> > -J
> >
> >
> >
> >
> > On Wed, Jul 14, 2010 at 12:57 PM, Jeremy Rimer  > >wrote:
> >
> > > Hmmm...
> > >
> > > I did this:
> > > ===
> > > 
> > >  > > OnExit="success">
> > > 
> > >
> > > 
> > >  > > >
> > > 

Re: [WiX-users] Conditionally Show Dialog Button based onInstalleraction (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

Sorry if I wasn't clear...

There are database connection strings stored in the app.config file of the
deployed application...
The WIX installer's purpose is to provide a sysops team the ability to
easily deploy our application across multiple system installations, all
needing different connectivity strings for the DB...

So far, the installer I wrote does the following:

Fresh Install:

   - Deploys the software to the InstallDir
   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish exits the
   program leaving the deployed App.Config alone.
   - clicking MODIFY CONFIG Prompts the user for connectivity settings with
   empty input fields (no defaultsI originally wanted the defaults that
   came in the App.Config that was deployed, but later we decided it was
   unnecessary to prompt ANY default on fresh install.).
   - Saving and Exiting will run one more CA to overwrite the App.Config
   file with the provided DB strings. (or you can cancel and exit leaving the
   program installed with defaults.)

Repair

   - Deploys the software to the InstallDir, loading the existing DB strings
   from the deployed App.Config file for later prompting
   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish exits the
   program leaving the deployed App.Config alone.
   - clicking MODIFY CONFIG Prompts the user for connectivity settings with
   the default values from the existing configuration
   - Saving and Exiting will run one more CA to overwrite the App.Config
   file with the provided DB strings. (or you can cancel and exit leaving the
   program installed with defaults.)

Upgrade

   - Detects existing version, and silently removes it.
   - loads the existing DB strings from the deployed App.Config file for
   later prompting
   - Deploys the software to the InstallDir
   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish exits the
   program leaving the deployed App.Config alone.
   - clicking MODIFY CONFIG Prompts the user for connectivity settings with
   the default values from the existing configuration
   - Saving and Exiting will run one more CA to overwrite the App.Config
   file with the provided DB strings. (or you can cancel and exit leaving the
   program installed with defaults.)

REMOVE

   - UNINSTALLS and removes the deployed software
   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish exits the
   program leaving the deployed App.Config alone.
   - clicking MODIFY CONFIG Prompts the user for connectivity settings (I'm
   trying to quash this part)...

...I need to figure out how to suppress the  MODIFY CONFIG button from the
MyExitDialog given a REMOVE path... I think the point in the installation at
which this button is shown that REMOVE="ALL" and things aruond installation
are no longer "checkable"... I think I may need to save another Session
Property to set at a certain time in the installation to 1 or 0 depending on
REMOVE="ALL" then or something... Sound right?




On Thu, Jul 15, 2010 at 4:25 AM, Pally Sandher wrote:

> So you're telling us you have trouble knowing the contents of a file
> you're installing on the target machine until after it's been installed?
>
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
>
> http://www.iesve.com
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: 14 July 2010 17:40
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button based
> onInstalleraction (installed vs. removed vs. repaired, etc)
>
> funny you mention that... The original requirements of this installer
> were to prompt the user the defaults provided in the App.Config file of
> the deployed program, which meant that we COULDNT prompt the user for
> settings before the files were copied. It turned out that particular
> action was impossible ANYWAY, because you can't modify the session for
> use in dialogs AFTER the files are copied, only prior in the UI
> sequence... So perhaps if I re-engineered this whole thing to prompt
> FIRST, I can avoid these problems?

Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

I'm still struggling to hide a dialog button in an uninstallation case :\.

Since REMOVE="ALL" didn't seem to ever be "true" despite the path through
the installer (fresh install/repair/remove), I tried to base the
Action="hide" Condition off a Secure Property that can be modified earlier
in the code...

The result seems to be the same, REMOVE~="ALL" never is true, despite a
"REMOVE" path through the installer...

Given my setup below, how can I get the secure property
SHOWMODIFYCONFIGBUTTON to = 0 in the case of REMOVE paths through my
installer?

Here's my Property:
===
1
===

Here's the CustomAction that will modify the value of that property:
===

===

Here's the InstallUI and InstallExecute Sequences:
===





REMOVE~="ALL"






NEWERFOUND


===

Here's the dialog button I wish to hide during uninstalls:
===

SHOWMODIFYCONFIGBUTTON=0 

===




On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer wrote:

> I have one last problem before my installer is completely working:
>
> I have a custom EXIT dialog that I created called MyExitDialog that
> contains an extra button that spawns a custom dialog to gather application
> settings from the user to write into the App.Config file that was deployed
> and/or existed during installation or repair.
>
> The dialog does its job, but unfortunately it also displays (and does its
> job) after an application has been removed with the installer, which is
> useless, of course since there's no more app.config file to care about on a
> removal of the application.
>
> I see in the Publish elements how to conditionally control what a button *
> does*, but how do you conditionally control when a button *shows itself*in 
> its dialog?
>
> If this is impossible, how can I force the installer to display the
> standard WIX ExitDialog instead of MyExitDialog in the case of a REMOVE
> operation (vs. repair or new installation?).
>
> my MyExitDialog definition is as follows, and the Control with
> Id="ApplicationSettings" is my button I'd like to hide on product removals:
> 
>  Title="!(loc.ExitDialog_Title)">
>  Height="17" Default="yes" Cancel="yes" Text="!(loc.WixUIFinish)" />
> 
>  Width="130" Height="17" Default="no" Cancel="no" Text="Modify Application
> Settings" >
>  Height="17" Disabled="yes" Text="!(loc.WixUICancel)" />
>  Height="234" TabSkip="no" Text="!(loc.ExitDialogBitmap)" />
> 
>  Height="0" />
>  Height="40" Transparent="yes" NoPrefix="yes" Text=" Click the Finish button
> to exit the Setup Wizard. Alternatively, Click the Modify Application
> Settings button to alter the behavior of the application." />
>  Height="60" Transparent="yes" NoPrefix="yes" Text="!(loc.ExitDialogTitle)"
> />
>  Height="80" Transparent="yes" NoPrefix="yes" Hidden="yes"
> Text="[WIXUI_EXITDIALOGOPTIONALTEXT]">
>   WIXUI_EXITDIALOGOPTIONALTEXT AND NOT
> Installed
> 
>  Width="220" Height="40" Hidden="yes"
> Property="WIXUI_EXITDIALOGOPTIONALCHECKBOX" CheckBoxValue="1"
> Text="[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT]">
>   WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT AND
> NOT Installed
> 
>   
> 
>
> Thanks again,
>
> Rimer
>
>
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Show Dialog Button basedonInstalleraction (installed vs. removed vs. repaired, etc)

[Jeremy Rimer]

I only did it in this manner because original requirements dictated the
application be copied to the installdir before reading back defaults for
entry... turns out the "defaults" are actually blank strings in the
application, so nothing ever really needed to be read on fresh install...
they do on upgrades/repairs though. I got everything working this way, so
figured why change it...

On Thu, Jul 15, 2010 at 11:28 AM, Pally Sandher wrote:

> Given all that I still don't see why you're trying to do user config on
> the ExitDialog instead of during the InstallUISequence. The only thing
> you'd need to implement in anything resembling custom code to accomplish
> those 4 scenarios would be reading the entries from the app.config to
> populate the fields in the repair & upgrade scenarios as reading XML
> doesn't have a Standard Custom Action AFAIK in WiX (yet). You seem
> pretty set on doing it your way however so good luck.
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
>
> http://www.iesve.com
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>
> -Original Message-
> From: Jeremy Rimer [mailto:jeremyri...@gmail.com]
> Sent: 15 July 2010 15:17
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Conditionally Show Dialog Button
> basedonInstalleraction (installed vs. removed vs. repaired, etc)
>
> Sorry if I wasn't clear...
>
> There are database connection strings stored in the app.config file of
> the deployed application...
> The WIX installer's purpose is to provide a sysops team the ability to
> easily deploy our application across multiple system installations, all
> needing different connectivity strings for the DB...
>
> So far, the installer I wrote does the following:
>
> Fresh Install:
>
>   - Deploys the software to the InstallDir
>   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
>   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish
> exits the
>   program leaving the deployed App.Config alone.
>   - clicking MODIFY CONFIG Prompts the user for connectivity settings
> with
>   empty input fields (no defaultsI originally wanted the defaults
> that
>   came in the App.Config that was deployed, but later we decided it was
>   unnecessary to prompt ANY default on fresh install.).
>   - Saving and Exiting will run one more CA to overwrite the App.Config
>   file with the provided DB strings. (or you can cancel and exit
> leaving the
>   program installed with defaults.)
>
> Repair
>
>   - Deploys the software to the InstallDir, loading the existing DB
> strings
>   from the deployed App.Config file for later prompting
>   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
>   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish
> exits the
>   program leaving the deployed App.Config alone.
>   - clicking MODIFY CONFIG Prompts the user for connectivity settings
> with
>   the default values from the existing configuration
>   - Saving and Exiting will run one more CA to overwrite the App.Config
>   file with the provided DB strings. (or you can cancel and exit
> leaving the
>   program installed with defaults.)
>
> Upgrade
>
>   - Detects existing version, and silently removes it.
>   - loads the existing DB strings from the deployed App.Config file for
>   later prompting
>   - Deploys the software to the InstallDir
>   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
>   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish
> exits the
>   program leaving the deployed App.Config alone.
>   - clicking MODIFY CONFIG Prompts the user for connectivity settings
> with
>   the default values from the existing configuration
>   - Saving and Exiting will run one more CA to overwrite the App.Config
>   file with the provided DB strings. (or you can cancel and exit
> leaving the
>   program installed with defaults.)
>
> REMOVE
>
>   - UNINSTALLS and removes the deployed software
>   - MyExitDialog at the Finish screen has these buttons showing "MODIFY
>   CONFIG" "FINISH" "CANCEL(disabled at this point)". Clicking Finish
> exits the
>   program leaving the deployed App.Config alone.
>   - clicking MODIFY CONFIG Prompts the user for connectivity settin

Re: [WiX-users] Logging Error

[Jeremy Farrell]

Perhaps Windows path separators (\) in the paths?

> From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] 
> 
> I am attempting to log the installation of a package I 
> created.  When I run the following command line:
> 
> msiexec.exe /I "C:/comp/code/libdbg/tfuInstaller.msi" /l*v 
> "C:/Documents and Settings/name/My Documents/tfuInstaller.txt"
> 
> I get an error message that states:
> This installation package could not be opened.  Verify that 
> the package exists and that you can access it, or contact the 
> application vendor to verify that this is a valid Windows 
> Installer Package.
> 
> If I go to the directory and run the .msi from there, the 
> installer runs.  Am I doing something wrong?
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] CustomAction in InstallUISequence doesn't complete until InstallInitialize

[Jeremy Rimer]

Greetings WiX Users!

Not so long ago I posted my dilemma regarding Custom Actions not persisting
session data through to UI dialogs... I modified the ExitDialog to have a
button that took you to further configuration options so that it could read
in default options from the deployed App.Config file that was installed with
the installer's payload as defaults in the edit fields...

A gentleman suggested I get back inline with the common expected methodology
of MSI installers to take the configuration options BEFORE the installation
deployed its payload, and so I did that.

I'm running into a problem, however, that my CustomAction
(LoadDefaultOptions), while called very early in the UI sequence, doesn't
seem to EXECUTE until after InstallInitialize occurs, which is beyond the
time I need the data generated by the Custom Action!

I have a database setting dialog (ModifyConfigOptionsDlg)  that occurs in
the UI Sequence after the WelcomeDlg. As you can see in the log below,
LoadDefaultOptions gets called initially just after FindRelatedProducts
(Before="LaunchConditions"). HOWEVER, though it is called there, the actual
execution doesn't seem to occur until after InstalIInitialize, which is
AFTER the ModifyConfigOptionsDlg is shown to the user, too late in the
process to provide the defaults in session variables to the dialog. Notice
that I have set the Return="asyncWait", which I would THINK would pause the
script until the CA completed, but that is not the behavior the log or
application seems to be exhibiting...

Is there a reason that my CA is not executing when it is called in the
script, and waiting until InstallInitialize?

This is the pertinent data from my WIX XML definition:

=






  
  


  
  
  
  

=

This is the log generated during a fresh install up to the point of the
LoadDefaultOptions custom action executing:
=
=== Logging started: 7/26/2010  13:28:13 ===
Action 13:28:13: INSTALL.
Action start 13:28:13: INSTALL.
Action 13:28:13: FindRelatedProducts. Searching for related applications
Action start 13:28:13: FindRelatedProducts.
Action ended 13:28:13: FindRelatedProducts. Return value 1.
Action 13:28:13: LoadDefaultOptions.
Action start 13:28:13: LoadDefaultOptions.
Action 13:28:13: LaunchConditions. Evaluating launch conditions
Action start 13:28:13: LaunchConditions.
Action ended 13:28:13: LaunchConditions. Return value 0.
Action 13:28:13: ValidateProductID.
Action start 13:28:13: ValidateProductID.
Action ended 13:28:13: ValidateProductID. Return value 1.
Action 13:28:13: CostInitialize. Computing space requirements
Action start 13:28:13: CostInitialize.
Action ended 13:28:13: CostInitialize. Return value 1.
Action 13:28:13: FileCost. Computing space requirements
Action start 13:28:13: FileCost.
Action ended 13:28:13: FileCost. Return value 1.
Action 13:28:13: CostFinalize. Computing space requirements
Action start 13:28:13: CostFinalize.
Action ended 13:28:13: CostFinalize. Return value 1.
Action 13:28:13: WelcomeDlg.
Action start 13:28:13: WelcomeDlg.
Info 2898. For WixUI_Font_Normal textstyle, the system created a 'Tahoma'
font, in 1 character set, of 13 pixels height.
Info 2898. For WixUI_Font_Bigger textstyle, the system created a 'Tahoma'
font, in 1 character set, of 19 pixels height.
Action 13:28:13: WelcomeDlg. Dialog created
Info 2898. For WixUI_Font_Normal__UL textstyle, the system created a
'Tahoma' font, in 0 character set, of 13 pixels height.
Action 13:28:14: ModifyConfigOptionsDlg. Dialog created
Info 2898. For WixUI_Font_Title textstyle, the system created a 'Tahoma'
font, in 1 character set, of 14 pixels height.
Action 13:28:19: InstallDirDlg. Dialog created
Action 13:28:20: WixUIValidatePath.
Action start 13:28:20: WixUIValidatePath.
Action ended 13:28:20: WixUIValidatePath. Return value 1.
Action 13:28:20: VerifyReadyDlg. Dialog created
SFXCA: Extracting custom action to temporary directory:
C:\DOCUME~1\ELOY06~1\LOCALS~1\Temp\MSI1FD7.tmp-\
Action ended 13:28:21: WelcomeDlg. Return value 1.
Action 13:28:21: ProgressDlg.
Action start 13:28:21: ProgressDlg.
Action 13:28:21: ProgressDlg. Dialog created
Action ended 13:28:21: ProgressDlg. Return value 1.
Action 13:28:21: ExecuteAction.
Action start 13:28:21: ExecuteAction.
SFXCA: Binding to CLR version v2.0.50727
Action 13:28:21: INSTALL.
Action start 13:28:21: INSTALL.
Action 13:28:21: FindRelatedProducts. Searching for related applications
Action start 13:28:21: FindRelatedProducts.
Action ended 13:28:21: FindRelatedProducts. Return value 0.
Action 13:28:21: ValidateProductID.
Action start 13:28:21: ValidateProductID.
Action ended 13:28:21: ValidateProductID. Return value 1.
Action 13:28:21: CostInitialize. Computing space requirements
Action start 13:28:21: CostInitialize.
Action ended 13:28:21: CostInitialize. Return value 1.
Action 13:28:21: FileCost. Computing space requirements
Action start 13:28:

Re: [WiX-users] WiX proposal on Area51

[Jeremy Farrell]

Would this be instead of the mailing list, rather than as well as it or 
gatewayed to it like the existing nabble interface? If so, I'd hate the idea, 
can't stand these horrible "web-based forums".

Regards,
jjf 

> From: Rob Mensching [mailto:r...@robmensching.com] 
> Sent: Wednesday, July 28, 2010 7:47 PM
> 
> I love this idea. I was actually looking at using their 
> hosted solution for
> a while then they took it off the market. I didn't realize 
> they opened a new way to get the same thing.
> 
> On Tue, Jul 27, 2010 at 5:20 AM, Yan Sklyarenko 
>  wrote:
> >
> > Hello WiX Community,
> >
> > I'm sure you know about StackOverflow.com. The authors of 
> > this fantastic
> > resource opened another service, called Area51. It allows building a
> > community around a certain topic and create an ad hoc site like
> > StackOverflow.com for free. Take a look here:
> > http://area51.stackexchange.com/faq
> >
> > I thought it might be a good occasion to try to build something like
> > http://wix.stackexchange.com as a substitution for this 
> > list. Imagine a
> > site like StackOverflow.com devoted to WiX(MSI)-related Q&A! :)
> >
> > If you like the idea, you're welcome to follow and support this
> > proposal:
> > 
> > http://area51.stackexchange.com/proposals/15242/wix-windows-installer-xml?referrer=QMsccxqTnYmfDpFmz1HCvA2
> >
> > If you don't, let me know - probably it is not as bright as 
> > it seems to me. :)
> >
> > -- Yan
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How author wix file to uninstall previous MSI version?

[Jeremy Farrell]

 http://lmgtfy.com/?q=wix+uninstall+previous+upgrade

> From: Lucius Fleuchaus [mailto:luci...@microsoft.com] 
> 
> Hello, I like to author an MSI in such a way that it first 
> uninstalls any previous version using the same upgrade code.  
> What is the key element of a wix file that enables this scenario?
> Thank you!

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapping and Burn

[Jeremy Farrell]

> From: Bruce Cran [mailto:br...@cran.org.uk] 
> Sent: Friday, September 03, 2010 6:55 PM
> 
> On Fri, 3 Sep 2010 10:31:34 -0700 (PDT)
> Christopher Painter  wrote:
> 
> > Well said other then I don't agree that InstallShield is the reason
> > people don't want to write installs.  ( Although this seems to be
> > supported by tweats and blogs that I read. )  I just can't buy
> > it based on my experience using the tool for the last 14 years.
> > Maybe I'm just hard headed enough to look past the tools faults.
> 
> I used it for a while and found it to be awful. For a start it's
> expensive enough that we could only buy a single copy - that ruled out
> other developers creating their own installers, and eventually caused
> us to abandon it in favour of Visual Studio 2003's Setup & Deployment
> project. I did try and recommend WiX but the senior developers didn't
> want to learn a new language just to write an installer.

We tried to use it, despite not liking products which advertise themselves all 
over what they produce. We began to lose interest when it failed to install, 
claiming we were installing it on an unsupported version of Windows - despite 
the error message and the box listing the version we were installing it on as 
one of the supported versions. We lost interest completely when their "Customer 
Support" refused to help unless we bought a support contract. I have doubts 
about installer development programs which fail to install, produce an 
incorrect message about why, and regard that as something that I should pay a 
lot of money to fix.

WiX was wonderful, even in its early 2.x iterations. We were off to a flying 
start when it installed successfully ...
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to stop msiserver after installation;

[Jeremy Farrell]

Then the customer needs to speak to Microsoft and get them to change how their 
Windows package installation system works. The MSI service is part of the 
Operating System. It has nothing directly to do with your installation, in the 
sense that your installation doesn't control anything about it. It is up to the 
Operating System when it starts and stops this service. How do you know it 
isn't doing other things which have nothing to do with your package 
installation?

> -Original Message-
> From: Bisht, Pradeep [mailto:pradeep_bi...@yahoo.com] 
> Sent: Tuesday, September 28, 2010 11:06 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] how to stop msiserver after installation;
> 
> when our installer starts I see that: under processes 
> "msiexec.exe" starts 
> running and under services "msiserver" start running. Once 
> our installer 
> completes, msiexec is no longer visible in task manager while 
> msiserver keeps 
> running untill after 10 minutes and then its status changes 
> to "stopped". 
> Customer's requirement is to stop msiserver immediately after 
> our installation 
> completes. All of our custom actions are synchronous return=check.
> 
> 
> 
> - Original Message 
> From: "Castro, Edwin G. (Hillsboro)" 
> To: General discussion for Windows Installer XML toolset. 
> 
> Sent: Tue, September 28, 2010 2:53:43 PM
> Subject: Re: [WiX-users] how to stop msiserver after installation;
> 
> I don't think you should be trying to stop "msiserver.exe".
> 
> 1.) I don't know what "msiserver.exe" is. I would expect to 
> see msiexec.exe but 
> you certainly don't want to stop these process as one of them 
> will be yourself.
> 2.) The Windows Installer architecture uses a client process 
> and a server 
> process. You really want the OS to determine when the server 
> process is ready to 
> die if at all. The client process should not be killed as 
> that will kill 
> yourself as I mentioned above.
> 
> Seems to me like the requirement interpretation should be 
> "make sure you wait 
> for any exe custom actions your spin up during your 
> installation." WiX will let 
> you wait for their completion already.
> 
> Edwin G. Castro
> Software Developer - Staff
> Electronic Banking Services
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> P Please consider the environment before printing this e-mail
> 
> > -Original Message-
> > From: Bisht, Pradeep [mailto:pradeep_bi...@yahoo.com]
> > Sent: Tuesday, September 28, 2010 2:42 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] how to stop msiserver after installation;
> > 
> > Thanks for responding.
> > 
> > The top installer is not ours it is of our customer who 
> takes software from us
> > and several other vendors. Their top level installer 
> expects our installer to
> > stop all the processes that started for our installation 
> and that includes
> > msiserver.exe also. If I use service APIs what will be the 
> id for the 
> msiserver
> > service? Can you please point me to a sample code. Thanks.
> > 
> > 
> > 
> > - Original Message 
> > From: "Wilson, Phil" 
> > To: General discussion for Windows Installer XML toolset.
> > 
> > Sent: Tue, September 28, 2010 12:33:08 PM
> > Subject: Re: [WiX-users] how to stop msiserver after installation;
> > 
> > It sounds like you have a design that expects the Windows 
> Installer service
> > (or some number of processes called msiexec.exe?) to stop 
> when a bunch of
> > your installs have finished. The Windows Installer service 
> isn't a child 
> >process!
> > Like any other Windows service you stop it with the service 
> APIs, but really,
> > your design is just very very wrong. If those other 
> installs are completely 
> out
> > of your control (and you can't install them yourself so you 
> *know* when
> > they
> > complete) you'd be better off polling for the ProductCode 
> of last one you
> > launched to see when it is finally installed.
> > 
> > 
> > Phil Wilson
> > 
> > -Original Message-
> > From: Bisht, Pradeep [mailto:pradeep_bi...@yahoo.com]
> > Sent: Tuesday, September 28, 2010 12:05 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] how to stop msiserver after installation;
> > 
> > After my installer finishes, msiserver keeps running for 
> long time. How can I
> > stop it? Our top level installer package (not MSI based) 
> waits for all the 
> >child
> > 
> > processes launched by a specific installer to end/stop 
> before it can proceed
> > with the installation of other packages. How can I stop 
> msiserver? Any help
> > will
> > 
> > be highly appreciated. Thanks.
> > 
> > 
> > 
> > 
> > 
> --
> 
> > Start uncovering the many advantages of virtual appliances 
> and start using
> > them to simplify application deployment and accelerate your 
> shift to cloud
> > c

Re: [WiX-users] Issues when evaluating a condition

[Jeremy Farrell]

http://lmgtfy.com/?q=msi+verbose+log

> -Original Message-
> From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] 
> Sent: Monday, October 04, 2010 9:52 PM
> 
> Ok, how do I gereragte a verose log?
> Cheers
> Seanm.
> 
> -Original Message-
> From: Blair [mailto:os...@live.com] 
> Sent: 04 October 2010 21:15
> 
> You change both because the actions will run run in the 
> execute sequence only if the UI sequence didn't run.
> 
> Generate a verbose log and see what is going on.
--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Dealing with packages bigger than 2Gb

[Jeremy Farrell]

So you're assuming that whoever wrote the error message included three 
different ways to fix the problem, but chose not to mention the best way? Why 
do you assume that?

> From: vivekanandan balaguru [mailto:vivb...@gmail.com] 
> Sent: Wednesday, October 06, 2010 7:49 PM
> 
> We are trying to build a MSI package that includes multiple 
> files and total size of all files around 2.3 GB.
> While building we get the error below, Whats the best 
> solution to fix this error?
> 
> 2>light.exe(0,0): error LGHT0296: An error (E_FAIL) was returned
> while adding files to a CAB file. This most commonly happens when 
> creating a CAB file 2 GB or larger. Either reduce the size of your 
> installation package, raise Media/@CompressionLevel to a higher
> compression level, or split your installation package's files into
> more than one CAB file.
> 
> thanks,
> Vivek

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action

[Jeremy Farrell]

No, the CA DLL doesn't get installed at all if you've set it up correctly. It's 
a binary stream in the MSI and is available at uninstall time.

Hard to tell what's wrong without seeing your WiX code and the relevant bits of 
a verbose log.

> From: sagar shinde [mailto:sagar.i...@gmail.com] 
> 
> Hi,
> 
> I think u got it wrong,
> i did it in same way
> u can use that dll in custom action while installation but at 
> uninstall time
> that dll will be uninstalled with other files and i want to use it at
> uninstall timehow can i do this
> 
> On Thu, Nov 11, 2010 at 3:08 PM, Umeshj 
>  wrote:
> >
> > Why are you copying this to the user's system?
> >
> > Just use it like this:
> >
> > 
> >
> > refer to it with the id.
> >
> > This way it will stay with your MSI and uninstall will have 
> > access to it.
> >
> > Umesh
> >
> > sagar shinde wrote:
> > >
> > > Hi,
> > >
> > > I created one custom action dll file,
> > > which is copied to destination computer.
> > > while installation of product
> > > But the problem is i want to use that dll.
> > > at uninstall time but it get deleted before it
> > > is used by installer so it shows error while
> > > uninstall
> > > please suggest me proper way to do it,or how
> > > can i use  that dll at the uninstall time
> > >
> > > Thank you.
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Hide commandline parameters in CAQuietExec

[Jeremy Farrell]

The '"/c" switch in the commandline' is - how can I put this - in the 
commandline ;). It's a parameter of the command, just data as far as WiX is 
concerned. It can't affect Wix's behaviour.

> -Original Message-
> From: David Binkovic [mailto:david.binko...@googlemail.com] 
> Sent: Thursday, November 11, 2010 8:38 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Hide commandline parameters in CAQuietExec
> 
> Hi,
> 
> this statement doesn't even compile here:
> "The CustomAction/@Value attribute cannot be specified without
> attribute Directory or Property present."
> 
> But again, even when using the "/c" switch in the commandline,
> CAQuietExec still prints out everything inside the "Value" attribute
> to the .msi log.
> 
> David
> 
> 2010/11/10 sagar shinde :
> > This is how i used it.Which is working efficiently in my work.
> >
> >  Value='/c rmdir /S /Q
> > "[LOCATION]"' Execute="immediate" Return="check"/>
> >
> > On Wed, Nov 10, 2010 at 6:30 PM, David Binkovic <
> > david.binko...@googlemail.com> wrote:
> >
> >> Hi,
> >>
> >> I've tried that, but still the complete commandline is logged from
> >> CAQuietExe like this:
> >> CAQuietExec:  "C:\WINDOWS\system32\cmd.exe" /c 
> 
> >>
> >> David
> >>
> >> 2010/11/10 sagar shinde :
> >> > You can try "/C" switch in ur commandline while u send 
> your command value
> >> or
> >> > ExeCommand
> >> >
> >> > On Fri, Nov 5, 2010 at 2:42 PM, David Binkovic <
> >> > david.binko...@googlemail.com> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I have a password string the user enters in the UI of 
> the installation
> >> >> wizard that needs to be passed to a commandline application in a
> >> >> custom action.
> >> >>
> >> >> I'm using the "CAQuietExec" function in the "WixCA" 
> library. I was
> >> >> able to hide the commandline being logged during its creation by
> >> >> setting "HideTarget="yes"", but the commandline still 
> gets logged when
> >> >> "CAQuietExec" is invoked, e.g.:
> >> >>
> >> >> MSI (s) (A4:58) [09:52:40:402]: Executing op:
> >> >>
> >> >>
> >> 
> CustomActionSchedule(Action=CreateProfile,ActionType=11265,Sou
rce=BinaryData,Target=**,CustomActionData=**)
> >> >> MSI (s) (A4:30) [09:52:40:406]: Invoking remote custom 
> action. DLL:
> >> >> C:\Windows\Installer\MSIE213.tmp, Entrypoint: CAQuietExec
> >> >> CAQuietExec:  
> >> >>
> >> >> Is is possible to hide this log output, too?
> >> >>
> >> >> Thanks,
> >> >> David
> >> >>
> >> >>
> >> >>
> >> 
> --
> 
> >> >> The Next 800 Companies to Lead America's Growth: New 
> Video Whitepaper
> >> >> David G. Thomson, author of the best-selling book 
> "Blueprint to a
> >> >> Billion" shares his insights and actions to help propel your
> >> >> business during the next growth cycle. Listen Now!
> >> >> http://p.sf.net/sfu/SAP-dev2dev
> >> >> ___
> >> >> WiX-users mailing list
> >> >> WiX-users@lists.sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >> >>
> >> >
> >> 
> --
> 
> >> > The Next 800 Companies to Lead America's Growth: New 
> Video Whitepaper
> >> > David G. Thomson, author of the best-selling book "Blueprint to a
> >> > Billion" shares his insights and actions to help propel your
> >> > business during the next growth cycle. Listen Now!
> >> > http://p.sf.net/sfu/SAP-dev2dev
> >> > ___
> >> > WiX-users mailing list
> >> > WiX-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >> >
> >>
> >>
> >> 
> --
> 
> >> The Next 800 Companies to Lead America's Growth: New Video 
> Whitepaper
> >> David G. Thomson, author of the best-selling book "Blueprint to a
> >> Billion" shares his insights and actions to help propel your
> >> business during the next growth cycle. Listen Now!
> >> http://p.sf.net/sfu/SAP-dev2dev
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> > 
> --
> 
> > The Next 800 Companies to Lead America's Growth: New Video 
> Whitepaper
> > David G. Thomson, author of the best-selling book "Blueprint to a
> > Billion" shares his insights and actions to help propel your
> > business during the next growth cycle. Listen Now!
> > http://p.sf.net/sfu/SAP-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> --
> 
> Centralized Desktop

Re: [WiX-users] How do you fix this error? (id is too long, 72 characters max)

[Jeremy Farrell]

Maybe it's just my lack of understanding, but you don't seem to be giving us 
many clues here. You say the problem Id is in "a generated file" - what file, 
generated by what? 

> -Original Message-
> From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] 
> Sent: Thursday, December 09, 2010 10:58 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you fix this error? (id is 
> too long, 72 characters max)
> 
> This is the full contents of the WiX file, I don't see how I 
> can shorten it based on what you replied.
> 
> 
> http://schemas.microsoft.com/wix/2006/wi";
>   xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension";
>   xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
> 
>   
>   
>Version="$(var.MajorVersion).$(var.MinorVersion).$(var.BuildNumber)">
> Manufacturer="XPT" />
> 
>   
>   
> 
> 
>Name='$(var.Core.Data.DataManagement.Plugins.Client.TargetFile
> Name)' 
> Source='$(var.Core.Data.DataManagement.Plugins.Client.TargetPath)' />
>Name='XPedient.Core.Data.DataManagement.Plugins.Client.pdb' 
> Source='$(var.Core.Data.DataManagement.Plugins.Client.TargetDi
> r)XPedient.Core.Data.DataManagement.Plugins.Client.pdb' />
> 
> 
> 
>Name='$(var.Core.MetaData.Plugins.Model.Client.TargetFileName)
> ' Source='$(var.Core.MetaData.Plugins.Model.Client.TargetPath)' />
>Name='XPedient.Core.MetaData.Plugins.Model.Client.pdb' 
> Source='$(var.Core.MetaData.Plugins.Model.Client.TargetDir)XPe
dient.Core.MetaData.Plugins.Model.Client.pdb' />
> 
> 
> 
>Name='$(var.Core.Repository.Plugins.Client.TargetFileName)' 
> Source='$(var.Core.Repository.Plugins.Client.TargetPath)' />
>Name='XPedient.Core.Repository.Plugins.Client.pdb' 
> Source='$(var.Core.Repository.Plugins.Client.TargetDir)XPedien
t.Core.Repository.Plugins.Client.pdb' />
> 
> 
> 
>Name='$(var.Core.System.Plugins.Client.TargetFileName)' 
> Source='$(var.Core.System.Plugins.Client.TargetPath)' />
>Name='XPedient.Core.System.Plugins.Client.pdb' 
> Source='$(var.Core.System.Plugins.Client.TargetDir)XPedient.Co
> re.System.Plugins.Client.pdb' />
> 
> 
> 
>Name='$(var.Core.System.Plugins.Presenter.TargetFileName)' 
> Source='$(var.Core.System.Plugins.Presenter.TargetPath)' />
>Name='XPedient.Core.System.Plugins.Presenter.pdb' 
> Source='$(var.Core.System.Plugins.Presenter.TargetDir)XPedient
.Core.System.Plugins.Presenter.pdb' />
> 
> 
>   
>   
>   
> 
> 
> 
> -Original Message-
> From: Paden, Patrick [mailto:patrick.pa...@wolterskluwer.com] 
> Sent: Thursday, December 09, 2010 9:57 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How do you fix this error? (id is 
> too long, 72 characters max)
> 
> -=-=-=-
> 
> error:
> 
> The DirectoryRef/@Id of attributes value, 
> 'Application.managementserver.plugins.authentication.native.cl
> ient.symbo
> ls' is too long for an identifier, standard identifiers are 
> 72 characters or less.
> 
>  Id="Application.ManagementServer.Plugins.Authentication.Native
> .Client.Sy
> mbols">
> 
> -=-=-=-
> The  in the above text-cut is 73 characters 
> long, this is what needs to be changed down to 72 characters or less.
> Your  elsewhere in the code most likely needs to 
> be changed too.
> 
> Hope this helps,
> Patrick Paden
> 
> --
> 
> ___
> 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] Uninstall shortcut?

[Jeremy Farrell]

Are you saying that the example doesn't work? In what way does it fail? 

> From: Kevin Burton [mailto:kev...@buyseasons.com] 
> Sent: Tuesday, January 25, 2011 5:14 PM
> 
> The link to install an uninstall link seems to be outdated:
> 
> http://wix.sourceforge.net/manual-wix3/create_an_uninstall_sho
> rtcut.htm
> 
> Specifically  the registry entry does not exist. I am 
> thinking it should be something like 
> HKCU/Micosoft/Installer/Products. Also the application name 
> doesn't seem to come into play. In the registry there is what 
> looks like a GUID that is the key name. I am not sure where 
> this value is derived.
> 
> Here is the exported key for an installed product:
> 
> Windows Registry Editor Version 5.00
> 
> [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products]
> 
> [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> 7D85B17F234682FCB1D7916A797]
> "ProductName"="Bsi WebServices"
> "PackageCode"="34C74D484BB32C140A1D3766499CFCD3"
> "Language"=dword:0409
> "Version"=dword:0200
> "Assignment"=dword:
> "AdvertiseFlags"=dword:0184
> "InstanceType"=dword:
> "AuthorizedLUAApp"=dword:
> "Clients"=hex(7):3a,00,00,00,00,00
> 
> [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> 7D85B17F234682FCB1D7916A797\SourceList]
> "PackageName"="DebugBsiServices.msi"
> "LastUsedSource"=hex(2):6e,00,3b,00,31,00,3b,00,43,00,3a,00,5c
> ,00,54,00,65,00,\
>   6d,00,70,00,5c,00,00,00
> 
> [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> 7D85B17F234682FCB1D7916A797\SourceList\Media]
> "1"=";"
> 
> [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> 7D85B17F234682FCB1D7916A797\SourceList\Net]
> "1"=hex(2):43,00,3a,00,5c,00,54,00,65,00,6d,00,70,00,5c,00,00,00
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall shortcut?

[Jeremy Farrell]

In what sense is it not right? It's a registry key private to your installer 
which the example creates to meet the requirements of the ICE tests, as 
explained in the documentation. If you consider the path or name "not right" 
use different ones, as others have already suggested. I wouldn't go anywhere 
near Windows Installer's private entries such as the ones you quoted though. 

> From: Kevin Burton [mailto:kev...@buyseasons.com] 
> Sent: Tuesday, January 25, 2011 7:13 PM
> 
> I haven't tried the example but based on other installed 
> applications it seems that the registry settings that the 
> example is using are not right. I didn't want to run an 
> example that didn't meet the sniff test especially when 
> modifying the registry. The sniff test for me was looking at 
> other installed applications and seeing what registry 
> settings they establish. So unless WiX has some special 
> registry settings it seems that these registry settings are incorrect.
> 
> Kevin Burton
> Senior Software Engineer
> BUYSEASONS
> 262-901-2000 Office
> 262-901-2312 Fax
> kev...@buyseasons.com 
> 
> -Original Message-
> From: Jeremy Farrell [mailto:jfarr...@pillardata.com] 
> Sent: Tuesday, January 25, 2011 12:16 PM
> 
> Are you saying that the example doesn't work? In what way 
> does it fail? 
> 
> > From: Kevin Burton [mailto:kev...@buyseasons.com]
> > Sent: Tuesday, January 25, 2011 5:14 PM
> > 
> > The link to install an uninstall link seems to be outdated:
> > 
> > http://wix.sourceforge.net/manual-wix3/create_an_uninstall_sho
> > rtcut.htm
> > 
> > Specifically  the registry entry does not exist. I am thinking it 
> > should be something like HKCU/Micosoft/Installer/Products. Also the 
> > application name doesn't seem to come into play. In the 
> registry there 
> > is what looks like a GUID that is the key name. I am not sure where 
> > this value is derived.
> > 
> > Here is the exported key for an installed product:
> > 
> > Windows Registry Editor Version 5.00
> > 
> > [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products]
> > 
> > [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> > 7D85B17F234682FCB1D7916A797]
> > "ProductName"="Bsi WebServices"
> > "PackageCode"="34C74D484BB32C140A1D3766499CFCD3"
> > "Language"=dword:0409
> > "Version"=dword:0200
> > "Assignment"=dword:
> > "AdvertiseFlags"=dword:0184
> > "InstanceType"=dword:
> > "AuthorizedLUAApp"=dword:
> > "Clients"=hex(7):3a,00,00,00,00,00
> > 
> > [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> > 7D85B17F234682FCB1D7916A797\SourceList]
> > "PackageName"="DebugBsiServices.msi"
> > "LastUsedSource"=hex(2):6e,00,3b,00,31,00,3b,00,43,00,3a,00,5c
> > ,00,54,00,65,00,\
> >   6d,00,70,00,5c,00,00,00
> > 
> > [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> > 7D85B17F234682FCB1D7916A797\SourceList\Media]
> > "1"=";"
> > 
> > [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\77A86
> > 7D85B17F234682FCB1D7916A797\SourceList\Net]
> > "1"=hex(2):43,00,3a,00,5c,00,54,00,65,00,6d,00,70,00,5c,00,00,00
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Where is DesktopFolder?

[Jeremy Farrell]

It means much the same as having ProgramFilesFolder underneath the TARGETDIR - 
the shortcut will go where you want it to go and the installer will build.

> From: Kevin Burton [mailto:kev...@buyseasons.com] 
> Sent: Thursday, January 27, 2011 1:57 AM
> 
> So what does it mean to have "DesktopFolder" underneath the 
> TARGETDIR. That is certainly not the hierarchy that is on my computer.
> 
> -Original Message-
> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
> Sent: Wednesday, January 26, 2011 5:51 PM
> 
> The first error tells you what you must do.
> 
> "There may only be a single root directory per product or 
> module and its Id attribute value must be 'TARGETDIR' and its 
> Name attribute value must be 'SourceDir'."
> 
> I assume you already have one of these otherwise you would 
> not be able to install any files:
> 
> 
> 
> 
> 
> You have two options:
> 
> 1) Add the  declaration for DesktopFolder in the 
> existing TARGETDIR 
> 
> 
> 
> 
> 
> 
> 2) Add the  declaration for DesktopFolder under a 
>  for TARGETDIR
> 
> 
> 
> 
> 
> All errors I see already tell you what to do... just read 
> them more carefully.
> 
> Edwin G. Castro
> Software Developer - Staff
> Electronic Banking Services
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> 
> > From: Kevin Burton [mailto:kev...@buyseasons.com]
> > Sent: Wednesday, January 26, 2011 10:09 AM
> > 
> > When I change the DirectoryRef to Directory I get two errors:
> > 
> > Directory with Id 'DesktopFolder' is not a valid root directory.  
> > There may only be a single root directory per product or module and 
> > its Id attribute value must be 'TARGETDIR' and its Name 
> attribute value must be 'SourceDir'.
> > 
> > The Directory element requires the Name attribute because 
> there is no 
> > parent Directory element.
> > 
> > -Original Message-
> > From: Pally Sandher [mailto:pally.sand...@iesve.com]
> > Sent: Wednesday, January 26, 2011 10:06 AM
> > 
> > Yes you do have a directory with Id="DesktopFolder".
> > 
> > 
> > 
> > A cursory search for Id="DesktopFolder" found that in 
> seconds in your code.
> > That should be Directory not DirectoryRef which is what the 
> error is 
> > telling you. You're trying to reference something which 
> doesn't exist 
> > as far as your code is concerned.
> > 
> > I would suggest looking into contracting out your installation 
> > development if basic things like this are tripping you up to the 
> > extent that you're asking the list users for help.
> > 
> > Palbinder Sandher
> > Software Deployment & IT Administrator
> > T: +44 (0) 141 945 8500
> > F: +44 (0) 141 945 8501
> > 
> > http://www.iesve.com
> > **Design, Simulate + Innovate with the ** 
> > Integrated Environmental Solutions Limited. Registered in 
> Scotland No.
> > SC151456
> > Registered Office - Helix Building, West Of Scotland Science Park, 
> > Glasgow
> > G20 0SP Email Disclaimer
> > 
> > -Original Message-
> > From: Kevin Burton [mailto:kev...@buyseasons.com]
> > Sent: 26 January 2011 15:30
> > 
> > No, I don't have a directory with Id="DesktopFolder". I 
> have included 
> > the WiX source that I am using below (sorry about the 
> length but I it 
> > looks like I cannot attached a file) The applicable source 
> is toward the end.
> > 
> > 
> > 
> > I still get the error:
> > 
> > 
> > 
> > 
> C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServ
> > i
> > c
> > es\Product.wxs(318,0): error LGHT0094: Unresolved reference 
> to symbol 
> > 'Directory:DesktopFolder' in section 
> > 'Product:{8D768A77-71B5-432F-86F2-
> > BCD197617A79}'.
> > 
> > 
> > 
> > Thank you.
> > 
> > 
> > 
> > Kevin
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] install location not preserved while upgradation

[Jeremy Farrell]

Feel free to contribute the implementation and documentation. 

> From: Sanjay Rao [mailto:s...@noida.interrasystems.com] 
> Sent: Wednesday, February 02, 2011 8:48 PM
> 
> There should be simpler method like "MigrateFeatures" in 
> "UpgradeVersion"element.
> 
> On 02-02-2011 12:24, Neil Sleightholm wrote:
> > I believe the registry is the only way:
> > 
> http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-R
> emember-Pr
> > operty-pattern
> >
> > You could set the ARPINSTALLLOCATION
> > 
> http://robmensching.com/blog/posts/2011/1/14/ARPINSTALLLOCATIO
> N-and-how-
> > to-set-it-with-the-WiX-toolset but I don't know how you would recall
> > that.
> >
> > Neil
> >
> > -Original Message-
> > From: Sanjay Rao [mailto:s...@noida.interrasystems.com]
> > Sent: 02 February 2011 19:01
> >
> > Hi,
> >
> > Every time when I upgrade my software, install location 
> dialog shows the
> > default install location, It does not picks the previously installed
> > location automatically. Is there any way to do this other than
> > storing/searching registry keys. Pointer to a article is 
> also welcome.
> >
> > Thanks in advance.
> >
> > Regards,
> > Sanjay Rao
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Completely revert installation on install failure

[Jeremy Farrell]

Yes, David Watson did at 2012-01-11 18:09:28 GMT:
>
> Rollback should and does happen automatically. If you have any custom
> actions they need to cater for this. What does a verbose log say?
>
> How are you installing the service, are you using the 
> element?


From: Kevin Hebert [mailto:ke...@legendary-immersion.com]
> 
> Anyone have any suggestions about this?  Thank you.
> 
> On 1/11/2012 12:06 PM, AxiomaticImpact wrote:
> > My installer is installing a service (which starts automatically
> > upon installation) and a program.  Now, if the install fails for
> > any reason, the service is still installed, but fails to start.
> > How can I go about doing a complete rollback upon failure?  Is a
> > custom action that calls the installers uninstall portion feasible?
> > Thanks.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstallation

[Jeremy Farrell]

> From: DellaRosa, James [mailto:jdellar...@aspexcorp.com]
> 
>   I have been trying, for about two days not, to get my product to use
> the same .msi to install and uninstall.

I've no idea what you're trying to say here. WI usually works by using the same 
MSI to install and uninstall. What are you trying to do that's unusual?

> I have am using separate .wxs
> files for all of my custom dialogs and then have one .wxs that I
> reference from my main Product.wxs to reference the rest (not user if I
> explained that too well or not).

That depends what you were trying to explain. What you say here makes sense and 
is clear, but I don't see what it's got to do with your first sentence.

> I am not sure what else to do here...any ideas?

Just the usual - explain clearly what you're trying to do, how you're trying to 
do it, in what way it fails, exactly what error messages or other indications 
are seen when it fails, and what your verbose installer log says about it.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Check for Installed app

[Jeremy Farrell]

http://wix.tramontana.co.hu/


> From: Joel Palmer [mailto:jpalmer1...@comcast.net]
> Sent: Monday, March 24, 2014 6:17 PM
> 
> Can you give me the code to check for a previously installed
> version of my app?  Then, prevent install if it is there?
> 
> Currently, I am allowed to install the same app twice and
> I want to prevent that.
>
> Also, do you have example code on how to check for an "old"
> version installed?  Then, uninstall when old and replace
> with new version?

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Preserving install directory on upgrade

[Jeremy Farrell]

Perhaps I'm missing something, or this just works by luck, but it seems to work 
for me in WiX v2:

  
 
  
  
 
  

If I'm living on borrowed time, I'd value an explanation.


> From: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: Friday, April 18, 2014 6:56 PM
> 
> There is a kind of built-in way, and that's to set the
> ARPINSTALLLOCATION property (with a type 51 set property CA) after you
> know the folder location. The good part about this is that it exposes
> the location to the standard APIs such as using MsiGetProductInfo
> (INSTALLPROPERTY_INSTALLLOCATION... ) and the equivalents in
> script etc. The bad part about it is that retrieving it requires code
> because the registry search to find it is awkward.
> ---
> Phil Wilson
> 
> 
> On Fri, Apr 18, 2014 at 9:45 AM, Neil Sleightholm 
> wrote:
> > Does that persist across an upgrade? (Last time I checked, admittedly
> in v3.6, it didn't.)
> >
> > Neil
> >
> > -Original Message-
> > From: Phill Hogland [mailto:phogl...@rimage.com]
> > Sent: 18 April 2014 17:16
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Preserving install directory on upgrade
> >
> > If your msi package will always be launched by a burn bundle, then
> you could initialize and set Persisted=yes" on the burn string
> variable, which is then passed as a MsiProperty to the package.  But if
> the msi package will be launched by on-demand msiexec install due to
> advertising or a repair issue, or if the user would ever launch the msi
> directly, then the value of properties used in the initial install
> should be saved and initialized the next time the package is launched,
> as indicated previously.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveFolderEx really slow on large folders

[Jeremy Farrell]

How does rollback work with your CA?

> From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
> 
> Yes, what it is getting hung up on is enumerating a hundred
> thousand files one by one and adding them up to a giant string
> that is passed on to the MSI engine.
> 
> I looked at the RemoveFolderEx C++ implementation and it
> confirmed all my suspicions, so I went ahead and took it out
> and created my own managed custom action instead, which does
> the whole thing in one line:
> Directory.Delete(path, true) :-)
> 
> Of course I added proper error handling and session return
> codes etc. but now it's super fast and doing exactly what
> I needed it to do. I'll probably do a blog post on it, I'll
> update this thread with the link when it's up.

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstalling Service on Windows Server 2012 Not Removing Service

[Jeremy Farrell]

No. What does a verbose log show?

> From: Greg Edwards [mailto:gedwa...@polariswireless.com]
> Sent: Monday, May 19, 2014 9:53 PM
> 
> I have a WIX installer build to install a Windows Service. When the
> uninstaller is run on a Windows 8, it properly removes the service. But
> when run on a Windows Server 2012, the service remains. In order to
> remove the service on a 2012 server, we are forced to issue an "sc.exe
> delete" from the console.
> 
>  Is there additional parameters that need to be included on a Windows
> Server 2012 service installer?

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Torch output, how to force wixmst XML output instead of CAB

[Jeremy Farrell]

ASCII (the One True ASCII, ANSI X3.4-1986) is the 7 bit subset of both Windows 
"ANSI" and Unicode. In UTF-8 encoding, this subset is a 7-bit value, so ends up 
in a single byte which makes it identical to the ASCII and "ANSI" encodings.

The top half of Windows "ANSI" (values 128 to 255) does not match ASCII or 
Unicode.

So it depends what Stephen means by "the file is encoded in ANSI". If it only 
uses  the ASCII subset, then it's equally valid to describe it as encoded in 
ASCII, UTF-8 or Windows "ANSI". If it uses characters from the top half of 
Windows "ANSI" then it's not UTF-8. 

> -Original Message-
> From: Rob Mensching [mailto:r...@firegiant.com]
> Sent: Friday, June 13, 2014 8:53 AM
> 
> I always get this mixed up but I thought that ASCII was basically a
> subset of ANSI and UTF-8 and they all look the same (unless you write a
> BOM) until you use non-ASCII characters. The grand majority of internal
> WiX goo is ASCII without a BOM so it all looks the same...
> 
> I think Joel agrees with my memory
> (http://www.joelonsoftware.com/articles/Unicode.html):
> 
>   This has the neat side effect that English text looks
>   exactly the same in UTF-8 as it did in ASCII, so
>   Americans don't even notice anything wrong.
> 
> -Original Message-
> From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
> Sent: Thursday, June 12, 2014 6:25 PM
> 
> Also, I have been looking at this file in more detail.
> 
> The file itself is encoded with ANSI, but the XML header tag states
> that the XML is in UTF-8.  Is this intentional?

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WSX file contains extra files?

[Jeremy Farrell]

You'll probably find it useful to read 
http://www.catb.org/~esr/faqs/smart-questions.html and follow its advice.

On 23/02/2015 15:56, Chrys Perdue wrote:
> Does anyone have a solution for this? I keep getting this error but don't
> understand why it is saying that I have these extra dlls. What does that
> error mean I can't imagine that I'm the only that has ever had a problem
> with this.
>
> -Original Message-
> From: Chrys Perdue [mailto:chrys.per...@synesis7.com]
> Sent: Friday, February 20, 2015 11:14 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] WSX file contains extra files?
>
> I don't understand what causes this error in visual studio 2008.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Writing a C++ Custom Action Project

[Jeremy Farrell]

Your checks for an empty string are wrong - constructs like

ip == L""

need to be

*ip == 0

or similar.

Check the documentation for the sprintf() implementation you're using. 
In Standard C %s is for a normal character string but you're using it 
for wide character strings - that would explain an IP address starting 
with a 1 getting printed as just a single "1". Microsoft's 
implementation does weird things under some circumstances, you need to 
be using whatever is appropriate for a wide string here.

You're getting "ipaddress" and spaces in the output because that's what 
you told it to put there.

Regards,
 jjf

On 13/03/2015 17:40, Sarvagya Pant wrote:
> I have written a C# Custom Action that is supposed to get the Values of
> Properties passed to the installer and create some config file. Since the
> C# Custom action was done, my installer depends upon .Net too. I want to
> avoid this dependency, thus I am opting to write the Custom action in C++.
>
> Following is the C# code that I'm trying to convert in C++:
>
> session.Log("Entering WriteFileToDisk");string ipAddress =
> session["IPADDRESS"];string productCode =
> session["ProductCode"];string config_path =
> "C:\\SomeFolderToInstall\\";string compression =
> session["COMPRESSION"];string ssl = session["SSL"];if
> (string.IsNullOrEmpty(compression)){
>compression = "True"; //default true}if (string.IsNullOrEmpty(ssl)){
>ssl = "False"; //default false}if (string.IsNullOrEmpty(ipAddress)){
>ipAddress = "127.0.0.1";}string temp = @"
> {{
>""logpoint_ip"" : ""{0}"",
>""compression"" : ""{1}"",
>""ssl"": ""{2}""
> }}";string filePath =
> "C:\\SomeFolderToInstall\\lpa.config";System.IO.FileInfo file = new
> System.IO.FileInfo(filePath);
> file.Directory.Create(); // If the directory already exists, this
> method does nothing.System.IO.File.WriteAllText(file.FullName,
> config);System.IO.File.WriteAllText(config_path + "productcode.txt",
> productCode);
> session.Log("Confile file is written");
> session.Log("Product Code file is written");return ActionResult.Success;
>
> The Visual C++ code is given below:
>
> #include "stdafx.h"
>
>
> UINT __stdcall WriteFileToDisk(MSIHANDLE hInstall){
>  HRESULT hr = S_OK;
>  UINT er = ERROR_SUCCESS;
>
>  hr = WcaInitialize(hInstall, "WriteFileToDisk");
>  ExitOnFailure(hr, "Failed to initialize");
>
>  LPWSTR ip = NULL;
>  hr = WcaGetProperty(L"IPADDRESS",&ip);
>  ExitOnFailure(hr, "Failure in IPADDRESS");
>
>  if(ip == L"" || ip == NULL)
>  {
>  ip = L"127.0.0.1";
>  }
>  WcaLog(LOGMSG_STANDARD, (PCSTR)ip);
>  LPWSTR ssl = NULL;
>  hr = WcaGetProperty(L"SSL",&ssl);
>  ExitOnFailure(hr, "Failure in SSL");
>
>  if(ssl == L"" || ssl == NULL)
>  {
>  ssl = L"False";
>  }
>  LPWSTR comp = NULL;
>  hr = WcaGetProperty(L"COMPRESSION",&comp);
>  ExitOnFailure(hr, "Failure in COMPRESSION");
>
>  if(comp == L"" || comp == NULL)
>  {
>  comp = L"True";
>  }
>
>  WcaLog(LOGMSG_STANDARD, "Got the Parameters");
>  char buffer[150];
>  sprintf(buffer, "{\n\"ipaddress\": \"%s\",\n\"ssl\":
> \"%s\",\n\"compression\":\"%s\"\n}",ip,ssl,comp);
>  WcaLog(LOGMSG_STANDARD, "Config Generated is : ");
>  WcaLog(LOGMSG_STANDARD, buffer);
>
>  HANDLE hFile;
>  hFile = CreateFile(L"C://LogPointAgent//some_config.config",
>   // name of the write
> GENERIC_WRITE,  // open for writing
> 0,  // do not share
> NULL,   // default security
> CREATE_NEW, // create new file only
> FILE_ATTRIBUTE_NORMAL,  // normal file
> NULL);
>
>   if (hFile == INVALID_HANDLE_VALUE)
>  {
>  WcaLog(LOGMSG_STANDARD, "Invalid Handle for Config File");
>  ExitFunction();
>  }
>   BOOL bErrorFlag;
>   DWORD dwBytesToWrite = (DWORD)strlen(buffer);
>   DWORD dwBytesWritten = 0;
>   bErrorFlag = WriteFile(
>  hFile,   // open file handle
>  buffer,  // start of data to write
>  dwBytesToWrite,  // number of bytes to write
>  &dwBytesWritten, // number of bytes that were written
>  NULL);// no overlapped structure
>
>
>   if (FALSE == bErrorFlag)
>  {
>  WcaLog(LOGMSG_STANDARD, "Terminal failure: Unable to write to 
> file.\n");
>  }
>  else
>  {
>  if (dwBytesWritten != dwBytesToWrite)
>  {
>  // This is an error because a synchronous write that results in
>  // success (WriteFile returns TRUE) should write all data as
>  // requested. This would not necessarily be the case for
>  // asynchro

Re: [WiX-users] Per-User Previlage To Write to Program Files

[Jeremy Farrell]

As I understand this, the original problem wasn't explained at all 
clearly. The issue is not about a limited user being unable to install 
to Program Files. The issue is that with the IS per-user installer, the 
user gets offered a UAC prompt and the installation proceeds if he 
authenticates correctly. With the equivalent default WiX per-user 
installer, he just gets told that he can't install there (that is, he 
doesn't get offered a UAC prompt) and he can't install.

If my understanding is wrong, sorry for adding to the confusion ...

On 11/05/2015 17:43, Phil Wilson wrote:
> Well it asked me for elevation on my system and installed to
> ProgramFiles. It also doesn't actually TELL you or show you the
> install destination and there is no browse dialog.  So Rob is correct,
> and it's as I basically said before, it's one of those IS packages
> that redirects to ProgramData by calling a custom action called
> SetAllUsersProfile2k. If a limited user installs it then it won't go
> to ProgramFiles folder.
> ---
> Phil Wilson
>
>
> On Mon, May 11, 2015 at 9:05 AM, Rob Mensching  wrote:
>> In this case, a verbose log file would be more useful.
>>
>>
>> -Original Message-
>> From: Scott Ferguson [mailto:scott.fergu...@a2ktechnologies.co.nz]
>> Sent: Monday, May 11, 2015 12:21 AM
>>
>> Not sure about the internal filters that might be set and I wouldn't know 
>> what to look for using Orca to view the .msi file to see what might be 
>> allowing me to install to Program Files in a per-user install. I do know it 
>> is installing to Program Files and not Program Data.
>>
>> If you are curious and wanted to have a look I have created a simple test 
>> app and an InstallShield LE installer where the ALLUSERS switch is set to 
>> per-user and the data installs to Program Files. The resulting .msi file is 
>> in the top level of the zip. I have zipped them and placed them in dropbox 
>> if you wanted to download.
>>
>> This is a x64 installer.: 
>> https://www.dropbox.com/s/f78ijq0z8qpuwn3/Test%20Project.zip?dl=0

-- 
J. J. Farrell

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Is there a walkthrough that works for installingdrivers in an MSI, wix v 3 (5120)?

[Jeremy Farrell]

Perhaps MSDN will be helpful:

 http://msdn.microsoft.com/en-us/library/ms790295.aspx?ppud=4

Regards,
 jjf

> -Original Message-
> From: Mark Roden [mailto:mmro...@gmail.com] 
> Sent: Wednesday, July 29, 2009 8:06 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Is there a walkthrough that works 
> for installingdrivers in an MSI, wix v 3 (5120)?
> 
> Well, now I get the drivers tags, but the driver itself still isn't
> getting installed.
> 
> Seriously, is there a walkthrough or anything on how to use this?
> I've found numerous sites where people _ask_ the question, but none
> with actual responses with actual code that says "Here is how you take
> an inf and a sys and install it."
> 
> Thanks,
> Mark
> 
> On Wed, Jul 29, 2009 at 7:56 AM, Mark Roden wrote:
> > I had not done that.  Hopefully, that will be all I need to 
> get it done.
> >
> > Thanks,
> > Mark
> >
> > On Wed, Jul 29, 2009 at 12:28 AM, Blair wrote:
> >> Are you talking about Intellisense in VisualStudio? You added the
> >> DifxAppExtension's namespace, right?
> >>
> >> Here is a short example (warning: not tested):
> >>
> >> http://schemas.microsoft.com/wix/2006/wi";
> >> xmlns:dfx="http://schemas.microsoft.com/wix/DifxAppExtension";>
> >> ...
> >>    
> >>      
> >>      
> >> ...
> >>
> >> -Original Message-
> >> From: Mark Roden [mailto:mmro...@gmail.com]
> >> Sent: Tuesday, July 28, 2009 10:18 PM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] Is there a walkthrough that works 
> for installing
> >> drivers in an MSI, wix v 3 (5120)?
> >>
> >> It doesn't work.  The driver tags aren't showing up.  According to
> >> what I can see in the schema, the driver tags are derived from
> >> component, and neither the component tag has driver tags, 
> nor does it
> >> contain driver tags, nor is a driver tag being recognized. 
>  They are
> >> all failing.  So, I figure I'm probably doing something wrong.
> >>
> >> I've updated to the release version, in case that was the 
> problem.  It
> >> didn't help.
> >>
> >> On Tue, Jul 28, 2009 at 8:33 PM, Blair wrote:
> >>> DifxApp?
> >>>
> >>> See the Difxapp Schema page in wix.chm.
> >>>
> >>> -Original Message-
> >>> From: Mark Roden [mailto:mmro...@gmail.com]
> >>> Sent: Tuesday, July 28, 2009 4:17 PM
> >>> To: wix-users@lists.sourceforge.net
> >>> Subject: [WiX-users] Is there a walkthrough that works 
> for installing
> >>> drivers in an MSI, wix v 3 (5120)?
> >>>
> >>> Hi all,
> >>>
> >>> I'm running wix v 3.0.5120, and I need to install a driver.
> >>> Basically, it's one inf file and onesys files, and I'm 
> having no joy.
> >>> I've tried this:
> >>>
> >>>
> >>>      
> >>>
> >>> ...
> >>>
> >>>
> >>>    
> >>>      
> >>>         >>>              Source="..\Includes\cyusb.inf" />
> >>>      
> >>>      
> >>>         >>>              Source="..\Includes\cyusb.sys" />
> >>>      
> >>>    
> >>>
> >>> I've also tried putting things into system32.  The 
> drivers are there,
> >>> and they work perfectly well on a vista machine if I tell 
> the system
> >>> exactly where to look, but I'd like it to Just Work.
> >>>
> >>> Thanks!
> >>> Mark
> >>>
> >>>
> >> 
> --
> --
> >>> --
> >>> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008
> >> 30-Day
> >>> trial. Simplify your report design, integration and 
> deployment - and focus
> >>> on
> >>> what you do best, core application coding. Discover 
> what's new with
> >>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >>> ___
> >>> WiX-users mailing list
> >>> WiX-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>>
> >>>
> >> 
> --
> --
> >> --
> >>> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008
> >> 30-Day
> >>> trial. Simplify your report design, integration and 
> deployment - and focus
> >> on
> >>> what you do best, core application coding. Discover 
> what's new with
> >>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >>> ___
> >>> WiX-users mailing list
> >>> WiX-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>
> >> 
> --
> --
> >> --
> >> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day
> >> trial. Simplify your report design, integration and 
> deployment - and focus
> >> on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://

Re: [WiX-users] warning LGHT1076: ICE47

[Jeremy Farrell]

When you ask for a way to get rid of a warning without fixing the
problem and without suppressing the warning, it's hard to imagine what
could be suggested. 

> -Original Message-
> From: Vuchuru, Surekha (SBT US EXT) 
> [mailto:surekha.vuchuru@siemens.com] 
> Sent: Tuesday, August 11, 2009 4:57 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] warning LGHT1076: ICE47
> 
> 
> Any suggestions please?
> 
> Thanks and Regards,
> Surekha Vuchuru 
> 
> -Original Message-
> From: Vuchuru, Surekha (SBT US EXT) 
> Sent: Friday, August 07, 2009 2:45 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] warning LGHT1076: ICE47
> 
> Hello All,
>  
> I am getting a lot of Wix compilation warmings. This is one of them.
>  
> warning LGHT1076: ICE47: Feature 'NetworkGatewayFeature' has 878
> components. This could cause problems on Win9X systems. You should try
> to have fewer than 817 components per feature.
>  
> Please let me know how I can get rid of this warning without 
> supressing
> it and without reducing the number of components...Is this a 
> limitation
> in Wix?
>  
> Thanks and Regards,
> Surekha Vuchuru
> --
> --
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and
> focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> 
> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and 
> deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to treat support files that do not getinstalledontarget machine?

[Jeremy Farrell]

You sounds a bit confused about merge modules. Think of them as source
code; they're used when building your MSI, to include functionality
defined by a third party. The merge module doesn't exist when you get to
the machine on which you're installing you're MSI.

As a parallel, suppose I sent you a .c file which contained the code for
a custom action; you'd build the .c into a Custom Action DLL and include
and reference it in your MSI. When you run that MSI to install your
product, the functionality described by my .c file gets used, but the .c
file itself never gets anywhere near the installation machine. A merge
module is conceptually similar.

A different possibility is where you want to distribute a merge module
as part of your product, to enable other people to build an MSI using
the functionality you've defined in the merge module. In this case, the
merge module is just a file which is part of your product, like any
other, and would be installed as a file.

If you need to put files on the installation system which are used as
helpers of some sort during the installation, one way is to include them
in a self-extracting archive which you execute as an executable custom
action. I then use another customer action to delete them once they've
been used. I believe a slightly more favoured way to do this sort of
thing is to include the files as binary streams in the MSI and use
custom actions to extract and manipulate them. It should only rarely be
necessary to do this sort of thing, though.

> -Original Message-
> From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] 
> Sent: Tuesday, August 11, 2009 6:16 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to treat support files that do 
> not getinstalledontarget machine?
> 
> 
>  
> Sorry.  I was wondering what the normal practice would be 
> when you have
> files that are utility files for the installation and not apart of the
> application. They are not supposed to be installed, such as a merge
> module. The msm doesn't get "installed" however it's content will be
> installed. 
> 
> Thanks,
> Jim
> 
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com] 
> Sent: Tuesday, August 11, 2009 7:45 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to treat support files that do not
> getinstalled ontarget machine?
> 
> Your question is a bit vague (and contradictory). What do you 
> want to do
> with these "support" files exactly?
> 
> If they're required for your product then use a bootstrapper 
> to install
> them before your product. Since you have a merge module for the XML
> Parser simply merge it into your MSI using the Merge & 
> MergeRef nodes if
> that's the case.
> 
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501 
> 
> http://www.iesve.com
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP Email Disclaimer
>  
> 
> -Original Message-
> From: MacDiarmid, James D [mailto:james.macdiar...@eds.com]
> Sent: 10 August 2009 20:08
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to treat support files that do not get
> installed ontarget machine?
> 
> 
> I have some support files that I would like to include on the
> installation disk. What's the typical practice for dealing with these
> types of files that do not get installed? For example, I have a merge
> module for the MS XML Parser that I want to call in my install.
> 
> Thanks,
> Jim
> 
> 
> --
> --
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and 
> deployment -
> and focus on what you do best, core application coding. 
> Discover what's
> new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> --
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and
> focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> 
> Let Crystal Reports handle the reporting - Free Crystal 
> 

Re: [WiX-users] Can an installer use a file (extracted to the temparory file extraction directory) but not actually install it?

[Jeremy Farrell]

> From: Lian Jiang [mailto:lji...@microsoft.com] 
> Sent: Sunday, August 16, 2009 4:45 AM
> 
> I have a driver file mydriver.sys which will be installed to 
> c:\windows\system32. What I am doing is:
> 
> Step 1: install mydriver.sys to c:\program files\myapp;
> Step 2: a custom action install this driver file to 
> c:\windows\systems.

Have you looked at DIFxApp, the official way to install drivers using
Windows Installer and WiX?

> Therefore, after installation, mydriver.sys exists in two 
> locations mentioned above, which is confusing.

Why so? It's a normal thing to do. The laptop I'm using has about 50
.sys files under the 'program files' directory where they've been put a
part of the installation of various packages. The application
installations then went on to use these as the source files for the
driver installation steps which copied them into the system directory.

> I want to remove the one in c:\program files\myapp to clear 
> the confusion. Candidate solutions include:
> 
> Solution 1: make this file hidden in step 1.
> Solution 2: after Step 2, use a custom action to delete this 
> file under %PROGRAMFILES%.
> Solution 3: Do not install this file in Step 1 at all. 
> Instead, just extract it to the temporary file extraction 
> directory, and the driver installation custom action directly 
> installs this driver file from the temporary extraction 
> directory. After installation, this driver file is deleted 
> together with the temporary extraction directory.
> 
> To me solution 3 is cleaner than 1 and 2. But is it possible?

Yes.

> For example, is it possible to pack a file and extract it to 
> temporary directory but not install it? Is it possible to 
> access the temporary directory directly from a custom action?
> 
> I know solution 3 may go into the wild a little but am 
> interested having some discussion.

Why not just review the countless previous exhaustive discussions of
this subject on this list? The most recent pass through it that I'm
aware of was my message six days ago in the thread "How to treat support
files that do notgetinstalledontarget machine?"; it's been discussed
every few months for several years if that instance isn't adequate.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Multiple Driver Packages

[Jeremy Farrell]

> From: Slide [mailto:slide.o@gmail.com] 
> 
> I have two drivers that I need to install, I currently have 
> two inf files for them. Apparently DIFXAPP doesn't support
> this as I get the following error:
> 
> ...
> DIFXAPP: ERROR: more than one driver package found in 'C:\Program
> Files\MYAPP\'
> DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
> DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
> Action ended 20:52:22: InstallFinalize. Return value 3.
> 
> Do I have to combine the two drivers into a single inf file?

Just based on the error message, it looks like putting the different
packages in different directories would work.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] using dism.exe in my custom action

[Jeremy Farrell]

You missed the wonderful file system redirector. Whichever of the two
names you use, Windows forces the 32-bit custom action to use the file
in SysWOW64. 

[WindowsFolder]Sysnative\dism.exe should do what you need.


> From: Lian Jiang [mailto:lji...@microsoft.com] 
> Sent: Friday, September 18, 2009 1:07 AM
> 
> I am trying to use dism.exe in one of my custom actions for 
> Windows server 2008 R2.
> 
> There are two dism.exe, one in c:\windows\system, the other 
> in c:\windows\syswow64. No matter which one I use, running 
> msi fails with this error:
> 
> You cannot service a running 64-bit operating system with a 
> 32-bit version of DISM. Please use the version of DISM that 
> corresponds to your computer's architecture.
> 
> Here is my custom action:
> 
>Property="InstallNetFrameworkDeferred"
>   Value='"[WindowsFolder]SysWOW64\dism.exe" 
> /online /enable-feature /featurename:NetFx3'
>   Execute='immediate'
>   Return='check'/>
>BinaryKey='WixCA'
>   DllEntry="CAQuietExec"
>   Execute="deferred"
>   Return="check"
>   Impersonate="no" />
> 
> Did I miss anything?

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Cannot install in any other drive, except c drive

[Jeremy Farrell]

> From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com] 
> 
>   I have a strange problem with my installer.
>When I select a drive other than C drive for installation.
>The installation is failing.
>   Can you please let me know, what could be the problem?
> 
> 
> Thanks & Regards,
> Srivardhan.

You've probably got something wrong in one of your WiX source files. A
verbose log of the installation failing might help you see what's wrong;
if it doesn't help you, it might help someone here help you.

See also http://www.catb.org/~esr/faqs/smart-questions.html

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows 2003 Server 64 bit and XP 64 bit

[Jeremy Farrell]

You missed the MsiNTProductType property.

Regards,
  jjf

> -Original Message-
> From: John Lalande [mailto:johnlala...@gmail.com] 
> Sent: Friday, October 16, 2009 10:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Windows 2003 Server 64 bit and XP 64 bit
> 
> Since XP64 is based on Win2k3 64, their OS installer properties are
> identical.  Is there another way to distinguish the two 
> operating systems?
> We would like to add a launch condition that allows XP64 but 
> not Win2k3
> Server 64.
> 
> John
> --
> 
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. 
> Jumpstart your
> developing skills, take BlackBerry mobile applications to 
> market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Are short names even useful anymore?

[Jeremy Farrell]

Don't forget that the WI team are still living back before UNICODE was invented.

WI, the team that time forgot.

> -Original Message-
> From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
> Sent: Saturday, October 17, 2009 6:27 PM
> To: d...@tramontana.co.hu; General discussion for Windows 
> Installer XML toolset.
> Subject: Re: [WiX-users] Are short names even useful anymore?
> 
> I think the point is all of this is pointless and yes, quite 
> useless to the vast majority of the world.
> 
> Case in point..  Rename SomeDotNetAssembly.dll to 
> SomeDo~1.dll or some other hashed/transformed representation 
> like WiX does and try referencing the classes in it after 
> it's installed.   The CLR will throw an exception in a heartbeat.
> 
> I suppose someone out there still needs this functionality 
> but it's got to be a .1% use case by now.
> 
> If I'm wrong, I'd love to know of real world use cases other 
> then someone might be trying to do an HTTP stream ( which no 
> one does anyways ) or passing a public property that would 
> break my application anyways.
> 
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread 
> that deserves attention? E-Mail Me
> 
> 
> --- On Sat, 10/17/09, Rob Mensching  wrote:
> 
> > From: Rob Mensching 
> > Subject: Re: [WiX-users] Are short names even useful anymore?
> > To: d...@tramontana.co.hu, "General discussion for Windows 
> Installer XML toolset." 
> > Date: Saturday, October 17, 2009, 10:39 AM
> > That and if you try to use the
> > "install an MSI over HTTP" (which is such a
> > pain to deal with it isn't worth it) the Windows Installer
> > will use short
> > names as well. Oh, and the user can technically speaking
> > always pass in the
> > SHORTFILENAMES Property and force your MSI to use short
> > filenames.
> > I don't quite follow the question though. MSI requires
> > short filenames. WiX
> > v3 will auto-generate them in a stable and highly-unlikely
> > to collide sort
> > of way. Why does it matter?
> > 
> > virtually, Rob Mensching - http://robmensching.com
> > 
> > 2009/10/17 DEÁK JAHN, Gábor 
> > 
> > > On Tue, 13 Oct 2009 15:17:32 -0700, Blair wrote:
> > >
> > > Blair,
> > >
> > > the last time I heard this question mentioned from
> > some of the developers,
> > > maybe Rob, the answer always was that the only real
> > reason for short names
> > > was that some old Novel servers couldn't cope with
> > long names and removing
> > > this would make it impossible to make network
> > installations on those
> > > servers. I don't know if this is still an issue
> > today.
> > >
> > > Bye,
> > >   Gábor
> > >
> > >
> > ---
> > > DEÁK JAHN, Gábor -- Budapest, Hungary
> > > E-mail: d...@tramontana.co.hu
> > >
> > >
> > >
> > 
> --
> 
> > > Come build with us! The BlackBerry(R) Developer
> > Conference in SF, CA
> > > is the only developer event you need to attend this
> > year. Jumpstart your
> > > developing skills, take BlackBerry mobile applications
> > to market and stay
> > > ahead of the curve. Join us from November 9 - 12,
> > 2009. Register now!
> > > http://p.sf.net/sfu/devconference
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > 
> --
> 
> > Come build with us! The BlackBerry(R) Developer Conference
> > in SF, CA
> > is the only developer event you need to attend this year.
> > Jumpstart your
> > developing skills, take BlackBerry mobile applications to
> > market and stay 
> > ahead of the curve. Join us from November 9 - 12, 2009.
> > Register now!
> > http://p.sf.net/sfu/devconference
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> 
> 
>   
> 
> --
> 
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. 
> Jumpstart your
> developing skills, take BlackBerry mobile applications to 
> market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skill

Re: [WiX-users] InstallShield 2010 vs InstallAware 9

[Jeremy Farrell]

I don't know where you draw the line between 'simple' and 'top shelf', a few of 
the products whose installers were developed entirely with WiX are:

Microsoft Office Enterprise 2007 (over 4,600 files and 53,000 registry keys)
Microsoft Visual Studio 2008
Sun Microsystems MySQL 

> -Original Message-
> From: Matt Walker [mailto:matt.wal...@synergis.com] 
> Sent: Thursday, November 12, 2009 7:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] InstallShield 2010 vs InstallAware 9
> 
> >From just initially talking about or thinking about WiX my 
> first guess would be that this would be the option for 
> simpler installation processes/tasks and that the 'Top Shelf' 
> products (with regard to price not quality) would pull the 
> heavier weighted install stuff.
> 
> I would be interested in the cons of WiX, but I don't know if 
> that would offend anyone in this group.
> 
> Here is the list of what our installations do...  what can't 
> be done or is difficult to do with WiX?
> 
> -Install\Configure a web site (with the help of some Custom 
> Actions to tweak some config files)
> -Various Custom Actions: call windows installer .dlls, call 
> executables stored in the .msi, call executables on 
> destination or installed w/application
> -Dialog addition and editing
> -Copy, Move and Delete File operations (Wise - basically 
> populates the Move.. and RemoveFile tables
> -Query the Registry up front for launch condition values and 
> values to populate dialog controls in the UI
> -Add, update INI files
> -Add File Associations/Extensions
> -Create and control Windows Services
> -Install Pre-requisite checking
> -Language localization support
> 
> 
> 
> 
> -Original Message-
> From: Christopher Painter [mailto:chr...@deploymentengineering.com] 
> Sent: Thursday, November 12, 2009 1:34 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] InstallShield 2010 vs InstallAware 9
> 
> Anything?  Really?   I'm sorry, I like WiX a lot but I can 
> list out a couple dozen glaring feature and usability gaps.   
> WiX is nice but let's keep some perspective here.
> 
> --- On Thu, 11/12/09, Brian Simoneau 
>  wrote:
> 
> > From: Brian Simoneau 
> > Subject: Re: [WiX-users] InstallShield 2010 vs InstallAware 9
> > To: "General discussion for Windows Installer XML toolset." 
> 
> > Date: Thursday, November 12, 2009, 11:05 AM
> > My company was using InstallShield
> > before switching to WiX.  I have
> > never used InstallAware, but the only advice I can give is
> > to use WiX.
> > It's free and can do anything that the commercial products
> > do, sometimes
> > better.
> > 
> > -Brian Simoneau
> > 
> > -Original Message-
> > From: Matt Walker [mailto:matt.wal...@synergis.com]
> > 
> > Sent: Thursday, November 12, 2009 9:10 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] InstallShield 2010 vs InstallAware 9
> > 
> > Hi All,
> > 
> >  
> > 
> > I'm new to the group and was pointed here by an individual
> > from whom
> > I've received valuable assistance on many .NET, install
> > related topics
> > over the past several years.  I know this is a Wix
> > users group, but I'm
> > hoping someone can give me some insight, guidance, etc.
> > 
> >  
> > 
> > We as a company are looking to switch our install build
> > product.  The
> > company whose product we use has undergone several company
> > takeovers/changes recently and it doesn't look like the
> > development
> > effort is there for this particular product.
> > 
> >  
> > 
> > We've been focusing on InstallShield 2010 and InstallAware
> > 9.  I've used
> > InstallShield products in the past and never really had any
> > major
> > problems to speak of.  IS seemed fairly easy to use
> > and suited all of
> > our needs.  This seems to be the case with
> > InstallShield 2010.
> > 
> >  
> > 
> > InstallAware is a tool of a different kind as it appears to
> > be primarily
> > script based but does have a Visual interface as
> > well.  It might be
> > because I could be subconsciously hooked on InstallShield,
> > but
> > InstallAware seems cumbersome to me.  I guess that may
> > also be that I'm
> > just not used to their way of doing things. 
> > Conversion for us would
> > take a larger amount of time with this product, but if it
> > works and is
> > stable, that really won't matter much to me.
> > 
> >  
> > 
> > What I've heard and from what I already knew, they are both
> > major
> > players with InstallShield having a longer lifespan so
> > far.  I've been
> > told that InstallAware claims to be on the cutting edge,
> > but their
> > installs at times display weird behavior.
> > 
> >  
> > 
> > I'm trying to find an individual(s) that has used both or
> > similar
> > products for a compare and contrast of sorts.  What
> > are the pros and
> > cons?  Early on, 
> > 
> >  
> > 
> > Of course price will be a factor for us, but I just want to
> > be sure
> > after 

Re: [WiX-users] _Validation table

[Jeremy Farrell]

So MSDN is wrong when it says "This table is not shipped with the
installer database"? In that case I assume either that it's intending to
say something other than what it says, or it's presuming the use of a
particular toolset which strips the table. As far as WIX is concerned
though, this table is shipped with the installer database unless
something non-WIXy is done to strip it out after building the MSI and
before shipping it.

> -Original Message-
> From: Blair [mailto:os...@live.com] 
> Sent: Wednesday, December 02, 2009 4:45 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] _Validation table
> 
> >From a functionality point-of-view, the table is not 
> considered part of the
> installation database (it is ignored if present by the 
> routines involved in
> installation & maintenance of your product). However, many 
> administrators
> depend on guidance from the ICE tests and other tests which 
> often depend on
> this table in determining if they will allow any given 
> application on their
> networks. Being OSS or not, you still need customers for most 
> software, and
> that can be valuable information that others will use in 
> helping gauge the
> quality of the package being offered.
> 
> I would recommend leaving it in.
> 
> -Original Message-
> From: Piotr Fusik [mailto:pi...@fusik.info] 
> Sent: Wednesday, December 02, 2009 2:21 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] _Validation table
> 
> Ok, I dropped this table with Orca and the MSI is just 19kB 
> smaller which 
> is no big deal (however nice for open source software where 
> you don't care 
> about certification).
> 
> Could you please explain "This table is not shipped with the 
> installer 
> database" from the MSDN article linked below?
> 
> Thanks,
> Piotr
> 
> "Sebastian Brand \(Instyler Software\)" 
>  wrote:
> > I think you need to keep this table to ensure others your 
> app was ICE
> > validated, I remember this was part of the "Designed for Windows"
> > requirement or so.
> >
> > Best regards,
> > Sebastian Brand
> >
> > Deployment consultant
> > E-Mail: sebast...@instyler.com
> > Blog: www.sebastianbrand.com
> >
> >> -Original Message-
> >> From: Piotr Fusik [mailto:pi...@fusik.info]
> >> Sent: Wednesday, December 02, 2009 10:05
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] _Validation table
> >>
> >> A quick look with a hex editor into my MSI reveals that 
> this table is
> >> 50
> > kB or
> >> so. I'd be happy to drop it if it's optional, preferably with a WiX
> > option. End
> >> users won't read Descriptions anyway, why are they so long then?
> >>
> >> Piotr
> >>
> >> "Blair"  wrote:
> >>> Besides what is available on MSDN (e.g.
> >>> http://msdn.microsoft.com/library/aa372930.aspx) what more do you
> >> need
> >>> to
> >>>
> >>> know?
> >>>
> >>> -Original Message-
> >>> From: Piotr Fusik [mailto:pi...@fusik.info]
> >>> Sent: Tuesday, December 01, 2009 2:39 AM
> >>> To: wix-users@lists.sourceforge.net
> >>> Subject: [WiX-users] _Validation table
> >>>
> >>> Hello,
> >>>
> >>> Could you please explain what's the purpose of the 
> _Validation table
> >>>
> >>> in MSI files? How is the long Description column used? How much
> >>> overhead does this table add to my MSI and how can I reduce it?
> >>>
> >>> Thank you,
> >>> Piotr
> >>>
> >>>
> >>> 
> --
> >>> ---
> >>> ---
> >>> --
> >>> Join us December 9, 2009 for the Red Hat Virtual 
> Experience, a free
> >>> event focused on virtualization and cloud computing.
> >>> Attend in-depth sessions from your desk. Your couch. Anywhere.
> >>> http://p.sf.net/sfu/redhat-sfdev2dev
> >>> ___
> >>> WiX-users mailing list
> >>> WiX-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>>
> >>> 
> --
> >>> ---
> >>> -
> >>> Join us December 9, 2009 for the Red Hat Virtual 
> Experience, a free
> >>> event focused on virtualization and cloud computing.
> >>> Attend in-depth sessions from your desk. Your couch. Anywhere.
> >>> http://p.sf.net/sfu/redhat-sfdev2dev
> >>> ___
> >>> WiX-users mailing list
> >>> WiX-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >>
> >>
> >>
> > 
> --
> ---
> > ---
> > --
> >> Join us December 9, 2009 for the Red Hat Virtual Experience, a free
> >> event
> >> focused on virtualization and cloud computing.
> >> Attend in-depth sessions from your desk. Your couch. Anywhere.
> >> http://p.sf.net/sfu/redhat-sfdev2dev
> >> ___
> >> WiX-users mailing list
> >> WiX-users

[WiX-users] Using $(TargetPath) for localized wix projects.

[Jeremy Lew]

When I added a Resources_en-US.wxl file to my Wix 3.0 wixproj, the msi
is now being placed in a subdirectory of $(TargetPath) with the name
"en-US".  Fine, except the value of $(TargetPath) is the original
subdirectory (one level up from en-us) and no .msi exists there.  I have
a postbuild step which needs to know where the output actually is. Is
this a bug? By design?  

 

Thanks,

Jeremy

 

 

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using $(TargetPath) for localized wix projects.

[Jeremy Lew]

I was on 3.0.4401.0, I will try upgrading to build 4827, thanks for the
tip!

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Friday, December 26, 2008 6:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using $(TargetPath) for localized wix projects.

Jeremy Lew wrote:
> When I added a Resources_en-US.wxl file to my Wix 3.0 wixproj, the msi
> is now being placed in a subdirectory of $(TargetPath) with the name
> "en-US".  Fine, except the value of $(TargetPath) is the original
> subdirectory (one level up from en-us) and no .msi exists there.  I
have
> a postbuild step which needs to know where the output actually is. Is
> this a bug? By design?  
>   

Which version of WiX are you using? There have been fixes in the past 
few weeks/months in the MSBuild targets.

-- 
sig://boB
http://joyofsetup.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] WIX 3 - Suggestions

[Jeremy Lew]

Can you elaborate on which of the component rules #2 presents problem
for? I wrote a tool to auto-gen my components from my web structure as
well.  It puts every file in its own component with a new Guid for the
id.  Is this approach problematic?  Is it different than what Visual
Studio Installer does?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Monday, December 29, 2008 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

1.  It would be fantastic if someone wrote the extension that made it
easy to author VS packages or wrote a harvester so heat could generate
much of it automatically.  At the very least, you could open a Feature
Request.

2.  This is a particular challenge with the Windows Installer due to the
Component Rules.  If you have a solution for including large number of
files that does not violate the Component Rules that'd be a great thing
to add to the WiX toolset.

3.  Documentation always needs lots of work.Are you offering
to help improve it?  Many people make this suggestion, no one steps up
to help.  The active volunteers on the WiX toolset are all busy fixing
bugs.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WIX 3 - Suggestions

[Jeremy Lew]

So, does heat -ag not solve the component rules problem?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Monday, December 29, 2008 4:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Uhh, heat already supports that with the -ag switch.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Monday, December 29, 2008 13:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

2. I would suggest that the most reliable solution would be to have a
solution that set the component guid to "*". This isn't very well
documented but I believe it sets the guid to an MD5 hash of the folder
name and component name (see here:
http://installing.blogspot.com/2006/09/automatically-generating-componen
t.html)

I am working on something like this at the moment, if I get it working
I'll post details.

Neil

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: 29 December 2008 20:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Can you elaborate on which of the component rules #2 presents problem
for? I wrote a tool to auto-gen my components from my web structure as
well.  It puts every file in its own component with a new Guid for the
id.  Is this approach problematic?  Is it different than what Visual
Studio Installer does?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

1.  It would be fantastic if someone wrote the extension that made it
easy to author VS packages or wrote a harvester so heat could generate
much of it automatically.  At the very least, you could open a Feature
Request.

2.  This is a particular challenge with the Windows Installer due to the
Component Rules.  If you have a solution for including large number of
files that does not violate the Component Rules that'd be a great thing
to add to the WiX toolset.

3.  Documentation always needs lots of work.Are you offering
to help improve it?  Many people make this suggestion, no one steps up
to help.  The active volunteers on the WiX toolset are all busy fixing
bugs.


--
___
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] WIX 3 - Suggestions

[Jeremy Lew]

I played around with it a bit, and in my particular case I'm not sure it
will work due to collisions with directory, component, and filename Id
values.  My installer installs two different web applications with
subdirectories having the same name, etc.  I would have to seed it with
some kind of prefix to make the uniqueness work out.

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Monday, December 29, 2008 5:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

For Components with one file each... maybe.  It's the closest we've
come.  Still experimental (one reason it isn't documented well).

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: Monday, December 29, 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

So, does heat -ag not solve the component rules problem?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 4:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Uhh, heat already supports that with the -ag switch.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Monday, December 29, 2008 13:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

2. I would suggest that the most reliable solution would be to have a
solution that set the component guid to "*". This isn't very well
documented but I believe it sets the guid to an MD5 hash of the folder
name and component name (see here:
http://installing.blogspot.com/2006/09/automatically-generating-componen
t.html)

I am working on something like this at the moment, if I get it working
I'll post details.

Neil

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: 29 December 2008 20:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Can you elaborate on which of the component rules #2 presents problem
for? I wrote a tool to auto-gen my components from my web structure as
well.  It puts every file in its own component with a new Guid for the
id.  Is this approach problematic?  Is it different than what Visual
Studio Installer does?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

1.  It would be fantastic if someone wrote the extension that made it
easy to author VS packages or wrote a harvester so heat could generate
much of it automatically.  At the very least, you could open a Feature
Request.

2.  This is a particular challenge with the Windows Installer due to the
Component Rules.  If you have a solution for including large number of
files that does not violate the Component Rules that'd be a great thing
to add to the WiX toolset.

3.  Documentation always needs lots of work.Are you offering
to help improve it?  Many people make this suggestion, no one steps up
to help.  The active volunteers on the WiX toolset are all busy fixing
bugs.


--
___
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] WIX 3 - Suggestions

[Jeremy Lew]

Well, I was talking about the Id values not the Guid values.  They need
to be unique as well, no?  Or only within their directory?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com] 
Sent: Monday, December 29, 2008 6:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

You mean like the Directory/@ComponentGuidGenerationSeed?

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: Monday, December 29, 2008 14:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

I played around with it a bit, and in my particular case I'm not sure it
will work due to collisions with directory, component, and filename Id
values.  My installer installs two different web applications with
subdirectories having the same name, etc.  I would have to seed it with
some kind of prefix to make the uniqueness work out.

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 5:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

For Components with one file each... maybe.  It's the closest we've
come.  Still experimental (one reason it isn't documented well).

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: Monday, December 29, 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

So, does heat -ag not solve the component rules problem?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 4:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Uhh, heat already supports that with the -ag switch.

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Monday, December 29, 2008 13:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

2. I would suggest that the most reliable solution would be to have a
solution that set the component guid to "*". This isn't very well
documented but I believe it sets the guid to an MD5 hash of the folder
name and component name (see here:
http://installing.blogspot.com/2006/09/automatically-generating-componen
t.html)

I am working on something like this at the moment, if I get it working
I'll post details.

Neil

-Original Message-
From: Jeremy Lew [mailto:j...@liquidmachines.com]
Sent: 29 December 2008 20:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

Can you elaborate on which of the component rules #2 presents problem
for? I wrote a tool to auto-gen my components from my web structure as
well.  It puts every file in its own component with a new Guid for the
id.  Is this approach problematic?  Is it different than what Visual
Studio Installer does?

-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Monday, December 29, 2008 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX 3 - Suggestions

1.  It would be fantastic if someone wrote the extension that made it
easy to author VS packages or wrote a harvester so heat could generate
much of it automatically.  At the very least, you could open a Feature
Request.

2.  This is a particular challenge with the Windows Installer due to the
Component Rules.  If you have a solution for including large number of
files that does not violate the Component Rules that'd be a great thing
to add to the WiX toolset.

3.  Documentation always needs lots of work.Are you offering
to help improve it?  Many people make this suggestion, no one steps up
to help.  The active volunteers on the WiX toolset are all busy fixing
bugs.


--
___
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