Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

[NIkolaj Steensgaard]

On 01/11/2012 01:23 PM, Peter Hull wrote:
>
> Hi Nikolaj!
>
> Could you comment on whether your installer was signed (the bundle and the 
> actual engine which is unpacked out of it - see this link 
> https://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVc1c2h3QuYsiXWcR8A1Xtk38Z3W2KCyAvuP3hMjYqKAiA%40mail.gmail.com&forum_name=wix-users
>  )
Yes the Bundle is signed with Thawte code signing certificate and also 
the engine ( msi ) included is signed with same certificate.
>
> I'm glad someone else has seen this problem, especially as you have more 
> control over your environment than I do!
Me 2 as it is quite a problem not being able to install a exe created 
from Wix 3.6.
Does anyone have a Idea how to debug this issue ?

The MSI itself does not write to the RunOnce as far as i know 
>
> Peter
>
>
>> Date: Wed, 11 Jan 2012 12:16:37 +0100
>> From: n...@panorama9.com
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
>>
>> We have built a EXE with Wix 3.6 beta which are detected by Trend Micro
>> as "Malware behavior" and
>> we are looking for the reason for this.
>>
>> This is the log entry from Trend Micro
>> ---
>> Malware behavior blocking Terminate Registry High
>> C:\Documents and Settings\administrator.ADTEST\Local
>> Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
>>
>>
>> Write
>> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
>>
>> ---
>>
>> Snip from previous case:
>> ---
>> Burn-based installers trigger Trend OfficeScan (v.10.5) when they write
>> to the RunOnce registry key.
>> The virus checker terminates the installer immediately.
>> ---
>>
>> We have a complete testing enviroment where we can tweak, monitor and
>> reproduce this error and are more than
>> willing to assist in debugging this issue.
>>
>> Please let me know anything we can provide to debug and solve this
>>
>> Regards
>>
>> Nikolaj Steensgaard
>>
>>
>> --
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>   
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


--
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] Two security prompts when the burn bootstrapper is downloaded from the internet

[Rob Mensching]

Not fixed in the Beta, fixed after the Beta. Weekly releases coming soon.

On Wed, Jan 11, 2012 at 9:18 PM, Sunny Li  wrote:

> Hi there,
>
> Currently I've built a bundle and uploaded the bootstrapper to one of our
> webservers. When I download the bootstrapper from the web and run it,
> windows shows two "Open File - Security Warnings" which is kind of
> annoying. I read from
>
> http://sourceforge.net/tracker/?func=detail&aid=3418715&group_id=105970&atid=642714that
> this bug should be fixed, but is that fix included in the wix 3.6
> beta? If it is not, is there anyway that we could fix this issue?
>
> Also... I'm not sure if these two issues are related, but when we try
> upgrade the bundle, the "Open file - security warning" pops up again at the
> phase where we're trying to uninstall the other older bundle. This popup is
> very annoying and can be confusing for the end user. It also stops the
> upgrade from going any farther until the user reacts... I believe if you
> click cancel here, the install just gets stuck. Is there anyway to make it
> such that the prompt does not show up here or when we do an uninstall?
>
> Thanks,
>
> --
> Sunny Li
>
> --
> 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
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
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

[WiX-users] Run exe in BinaryTable from custom action dll

[Naim Kingston]

Hey,

I have a 3rd party executable to detect some hardware, and since it's a general 
purpose exe, not detecting the hardware isn't a condition that has the exe 
return a failure (I guess, to be expected and completely fair).

So, in order to determine whether the hardware I'm looking for is present on 
the system, I need to be able to catch the output that this exe outputs to the 
standard output stream, so I'm trying to create a C# custom action dll to run 
the exe using System.Diagnostics.Process and redirect its output to a string 
where I can parse it to look for certain values to ensure the hardware is 
present and correctly configured.

My problem is that the tool isn't going to be present on the system prior to 
installation, and actually isn't needed by the final product, only to determine 
the hardware state of the machine to make a decision on what to install (which 
will actually be one of two other msi files, but running multiple msi files is 
a problem for another day), so it's not going to be installed with the rest of 
the product.

So, I've used the Binary tag to embed the exe into the installer, and I can run 
it directly via custom action, but how do I run it from a dll custom action? 
Can I somehow access it and run it while embedded? Or do I need to write it out 
to the temp folder, run it, and then delete it?

And then, I need to set a variable or property so the data will be passed back 
to the installer from the dll custom action.

But running the embedded exe from a custom action is what's giving me issues 
right now. Has anyone done anything like this before? I've tried googling for 
most of the day but haven't found anything particularly useful.

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

[WiX-users] Two security prompts when the burn bootstrapper is downloaded from the internet

[Sunny Li]

Hi there,

Currently I've built a bundle and uploaded the bootstrapper to one of our
webservers. When I download the bootstrapper from the web and run it,
windows shows two "Open File - Security Warnings" which is kind of
annoying. I read from
http://sourceforge.net/tracker/?func=detail&aid=3418715&group_id=105970&atid=642714that
this bug should be fixed, but is that fix included in the wix 3.6
beta? If it is not, is there anyway that we could fix this issue?

Also... I'm not sure if these two issues are related, but when we try
upgrade the bundle, the "Open file - security warning" pops up again at the
phase where we're trying to uninstall the other older bundle. This popup is
very annoying and can be confusing for the end user. It also stops the
upgrade from going any farther until the user reacts... I believe if you
click cancel here, the install just gets stuck. Is there anyway to make it
such that the prompt does not show up here or when we do an uninstall?

Thanks,

-- 
Sunny Li
--
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] Patching

[Sanjay Poria]

Thanks for the information Peter. Some follow up:

1) In previous versions of our app, we distributed patches to the customer as a 
set of files in a zip that the customer simply unzips into the application 
directory. While this isn't ideal (because of the problems associated with 
uninstalling patches etc.) it is very flexible in that we can distribute any 
number of patches that are not dependant on each other, and the customer can 
install and test the features in any order.

For example, If we deliver patch P1 and P2 to the customer in that order, they 
may decide to install P2 first because it requires a smaller test effort than 
P1. I'm not sure how I achieve the same using the MSI patching. Let's say we 
have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When 
release Patch1 we use the transform (mainprod->patch1). Then we release patch2 
which is not dependant on patch1 so we use the transforms (mainprod->patch2 and 
patch1->patch2) to generate it. But that wouldn't work if the customer decided 
to install patch2 first and then patch1 would it?   Might be that i'm missing 
something obvious here!

3) I think I prefer to segment my components into different fragments and use 
the wixpdb to generate the mappings as doing admin install is a bit of a pain 
and potentially more error prone for us. Does anyone know if there is an easy 
way to do this (eg, if I harvest files using heat for my initial release, can 
it generate a different fragment for each component?).

Another question and potential issue I thought of:

Most of the files we distribute are binary (PowerBuilder) files. Will torch be 
able to generate the transform correctly for these?

thanks
sanjay

> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: 11 January 2012 10:49
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Patching
> 
> I'll try and answer this but it's best to seek some other opinions too.
> 
> 1. The order of patch installation wont usually matter. When you create
> a
> patch, you target it at a particular version or even multiple versions
> (eg
> patched/upgraded installations) and MSI works out the right sequence.
> See the
> MS patching whitepaper at
> http://www.microsoft.com/download/en/details.aspx?id=19013
> You do this by creating one or more transforms (diffs) with the torch
> tool
> and passing them when you create the patch with pyro.
> 
> 2. The 4th version field of the MSI product version is ignored by
> Windows
> installer. You can use it for information but we don't - some APIs will
> retrieve the 4th field however. We use [major version].[service
> pack].[build]
> The files in your installer have no such restrictions. Version those in
> whatever way suits you.
> 
> 3. The way we do that currently is to build the patch from
> administrative
> installations of the released and updated MSIs instead of using
> wixpdbs.
> http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-
> you-didn
> t-build-with-wix-using-wix-.aspx
> and other articles in that blog.
> 
> 4. MSI records what patches are applied to a product. It depends on how
> you
> want to retrieve the information. You can use MsiEnumPatches() from C++
> for
> example. You could also install something to act as a marker.
> 
> Useful links include:
> MSDN on Windows installer
> Peter Marcu's blog
> Heath Stewart's blog
> Rob Menchsings blog (and others on the Wix team)
> This mailing list's archives
> Wix docs
> 
> 
> -Original Message-
> From: Sanjay Poria [mailto:sanjay.po...@xanalys.com]
> Sent: 10 January 2012 23:18
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Patching
> 
> I am in the process of writing an installer for a company product (we
> were
> previously using Installshield). Once, released we will need the
> produce
> patches for bug fixes and enhancements. The expectation that these
> patches
> will consist of simply updating some of the released files and/or
> adding new
> files not part of the initial distribution.   I think we will generally
> do a
> minor upgrade. In some cases the patches are dependent on a previous
> patch
> and in other cases not.
> 
> Therefore I've been reading material about how we should structure our
> initial release of the product to best enable but still have some
> questions
> about things that aren't clear. Can someone help me here:
> 
> 1.   How can we generate the diff against the installed version for
> the
> patches that can be installed in any order. We are not sure what the
> users
> machine will have because they may have already applied one of the
> other
> patches. Surely we don't need to generate a patch for each possible
> order of
> installation of all the patches.
> 2.   We can update the 3rd or 4th  component of product version
> when
> doing an upgrade/patch for some. Can someone explain the consequences
> of each
> option. When we generate a diff for th

Re: [WiX-users] Signing the burn bootstrapper

[Rob Mensching]

There are like four Sign* targets in wix2010.targets. Create a target named
the same for each and all of your things can be signed. It's actually
really easy.

On Wed, Jan 11, 2012 at 2:13 PM, sunniejai  wrote:

> Thanks Rob, a blog post would be great!
>
> As I am not that familiar with modifying the MSBuild sequence, do I just
> specify something like  SignTargetPath="PathToMyExe"/>
> in my wixproj?
>
> I guess I should probably sign all my MSI's with a digital certificate
> using
> the signtool before calling that?
>
> Thanks,
> Sunny
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Signing-the-burn-bootstrapper-tp7174715p7178031.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing the burn bootstrapper

[sunniejai]

Thanks Rob, a blog post would be great!

As I am not that familiar with modifying the MSBuild sequence, do I just
specify something like 
in my wixproj? 

I guess I should probably sign all my MSI's with a digital certificate using
the signtool before calling that?

Thanks,
Sunny

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Signing-the-burn-bootstrapper-tp7174715p7178031.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile element issues - any XPath experts out there?

[Rob Mensching]

Yeah, XPath is horrid in those attributes given the escaping necessary to
pass through to MSI. Sadly, two "languages" designed in completely
different silos whose special characters collided really badly. 

On Wed, Jan 11, 2012 at 8:20 AM, Dan Gough  wrote:

> D'oh - solved.  I was incorrectly escaping the square brackets, using a
> forward slash instead of a backslash!  All working great now.
>
> Dan
>
> On Wed, Jan 11, 2012 at 3:43 PM, Dan Gough  wrote:
>
> > Hi,
> >
> > I've successfully set up a few xml file configuration items using the
> > XmlFile element, but I have an instance that is not working as expected,
> > hopefully somebody out there can help!
> >
> > This is a cut down sample of my xml file:
> >
> > 
> > 
> > 
> > 
> > UPDATEME
> > 
> > 
> > UPDATEME
> > 
> > 
> > 
> >
> >
> > And this is my WiX markup:
> >
> >
> >  >
> ElementPath="/evidence_gatherer/evidence/evidence_type[/[]@type='notification'[/]]/xslt_sql"
> > File="[#evidence_gatherer.xml]" Value="[#notification_sql.xsl]"/>
> >  >
> ElementPath="/evidence_gatherer/evidence/evidence_type[/[]@type='ts_feature'[/]]/xslt_sql"
> > File="[#evidence_gatherer.xml]" Value="[#ts_feature_sql.xsl]"/>
> >
> >
> > The result I get is that both statements end up selecting the same first
> > node (where type='notification'), which ends up being left set to the
> value
> > of the last operation.
> >
> > I believe I am correctly escaping the square brackets above.  If I try to
> > refer to them in order, e.g.
> > /evidence_gatherer/evidence/evidence_type[1]/xslt_sql, that does not work
> > either.  Have I stumbled upon a bug (I'm using v3.6) or are my XPath
> > statements wrong?
> >
> > Thanks,
> > Dan
> >
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
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

[David Watson]

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?

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: check for MSI existence and validity

[jhennessey]

Created SF Feature Request 3472491: 
https://sourceforge.net/tracker/?func=detail&aid=3472491&group_id=105970&atid=642717
https://sourceforge.net/tracker/?func=detail&aid=3472491&group_id=105970&atid=642717
.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7177156.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
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

[AxiomaticImpact]

Dear lord why did it add to this.  I am sorry.  Can ignore my post. :(

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-First-Bundle-tp7173712p7177148.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Completely revert installation on install failure

[AxiomaticImpact]

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.

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Completely-revert-installation-on-install-failure-tp7177153p7177153.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Completely revert installation on install failure

[Kevin Hebert]

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

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] My First Bundle! :)

[James Green]

Hi Rob, yeah I noticed I was using the Id rather than the variable name just 
after posting this and that worked.  Just a bit confusing since sometimes you 
need to reference things by ID and sometimes by variable name.

I'm using the latest 3.6 Beta build of WiX.

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 11 January 2012 15:50
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] My First Bundle! :)

Can you try chaning your condition to "NOT FindDotNet40ClientInstallRegValue" 
and let's see if that works. I agree this should work, I'm a little surprised 
it doesn't.

What version of WIX toolset are you using?

On Wed, Jan 11, 2012 at 2:00 AM, James Green wrote:

> Hi Again,
>
> I spoke too soon.
>
> I've confirmed that .NET 4.0 isn't installed on the machine.  My 
> Bundle has an install condition of:
>
> FindDotNet40ClientInstallRegValue = 0
>
> Which is a RegistrySearch:
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework 
> Setup\NDP\v4\Client"
> Value="Install"
> Variable="DotNetFramework40ClientInstallRegValue"
> />
>
> [011C:0408][2012-01-11T09:44:42]: Condition 
> 'FindDotNet40ClientInstallRegValue = 0' evaluates to false.
>
> Which according to the log evaluated to false, I'm obviously terribly 
> mistaken but I would assume that if the key isn't present it would 
> evaluate to 0 meaning that " FindDotNet40ClientInstallRegValue = 0" 
> would evaluate to true and install .net on the machine.
>
> [011C:0408][2012-01-11T09:44:40]: Registry key not found. Key = 
> 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client'
> [011C:0408][2012-01-11T09:44:40]: Registry key not found. Key = 
> 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
>
> Then the entire packaged failed to install anything subsequently.
>
> [011C:0408][2012-01-11T09:44:46]: Error 0x80070643: Failed to execute 
> apply.
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 11 January 2012 05:26
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] My First Bundle! :)
>
> Take a look at the log file that should be created in your %TEMP% 
> directory. Hopefully that will show how the condition evaluated and 
> explain why uninstall failed.
>
> On Tue, Jan 10, 2012 at 12:00 PM, Jammer  wrote:
>
> > Hi All,
> >
> > I'm creating my first bootstapper installer and I have a few questions.
> >
> > My entire script looks like this:
> >
> > 
> > http://schemas.microsoft.com/wix/2006/wi";
> > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
> >
> >  > Version="1.0.0.0"
> > Manufacturer="Mango-Solutions"
> > UpgradeCode="340fe3b1-b98d-42fc-9a15-d1d36ca83922"
> > HelpTelephone="+44 (0)1249 767700"
> > HelpUrl="http://www.mango-solutions.com";
> > Compressed="yes">
> >
> >
> >  > fL
> > icense"/>
> >
> >  > Root="HKLM"
> > Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client"
> > Value="Install"
> > Variable="DotNetFramework40ClientInstallRegValue"/>
> >
> >  > Root="HKLM"
> > Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
> > Value="Install"
> > Variable="DotNetFramework40FullInstallRegValue"/>
> > 
> >
> >  > SourceFile="..\..\lib\net_client_profile\dotNetFx40_Client_x86_x64.e
> > xe "/>  > SourceFile="..\Build\Mango.Analyse.Installer.msi"/>
> > 
> > 
> > 
> >
> > Even though I have a conditional set on the client profile exe it 
> > always runs this package.  As far as I can tell this is correct syntax.
> >
> > I also just noticed that in the Add/Remove Programs under winXP SP3 
> > I ended up with .NET 4.0 client profile installed, the Mango.Analyse 
> > application AND an entry for this boot strapper ... when I tried to 
> > uninstall the bootstrapper it just gave an error saying that it 
> > couldn't proceed ...
> >
> > Would appreciate any pointers as I don't seem to be able to find 
> > much documentation for this task.
> > --
> > *Jammer*
> > WWW.JAMMER.BIZ  TWITTER 
> >  LINKEDIN
> > **
> >
> > 
> > --
> > 
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development.
> > Create new or port existing apps to sell to consumers worldwide.
> > Explore the Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev 
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
>
> --
>  Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't 
> need a complex

Re: [WiX-users] XmlFile element issues - any XPath experts out there?

[Dan Gough]

D'oh - solved.  I was incorrectly escaping the square brackets, using a
forward slash instead of a backslash!  All working great now.

Dan

On Wed, Jan 11, 2012 at 3:43 PM, Dan Gough  wrote:

> Hi,
>
> I've successfully set up a few xml file configuration items using the
> XmlFile element, but I have an instance that is not working as expected,
> hopefully somebody out there can help!
>
> This is a cut down sample of my xml file:
>
> 
> 
> 
> 
> UPDATEME
> 
> 
> UPDATEME
> 
> 
> 
>
>
> And this is my WiX markup:
>
>
>  ElementPath="/evidence_gatherer/evidence/evidence_type[/[]@type='notification'[/]]/xslt_sql"
> File="[#evidence_gatherer.xml]" Value="[#notification_sql.xsl]"/>
>  ElementPath="/evidence_gatherer/evidence/evidence_type[/[]@type='ts_feature'[/]]/xslt_sql"
> File="[#evidence_gatherer.xml]" Value="[#ts_feature_sql.xsl]"/>
>
>
> The result I get is that both statements end up selecting the same first
> node (where type='notification'), which ends up being left set to the value
> of the last operation.
>
> I believe I am correctly escaping the square brackets above.  If I try to
> refer to them in order, e.g.
> /evidence_gatherer/evidence/evidence_type[1]/xslt_sql, that does not work
> either.  Have I stumbled upon a bug (I'm using v3.6) or are my XPath
> statements wrong?
>
> Thanks,
> Dan
>
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Insignia in 3.6

[Rob Mensching]

That looks right. Please file a bug if the command-line help wasn't
helpful. 

On Wed, Jan 11, 2012 at 7:32 AM, Peter Hull  wrote:

>
> Am I right to say that the documentation for the insignia tool is a bit
> out of date in the 3.6 beta?
> The output from insignia /? doesn't mention the options -ab, -ib or -im.
>
> Is the following correct usage?
> - To inscribe a database installer.msi with external cabs:
> 1. Sign the cabs
> 2. insignia -im installer.msi
> 3. Sign installer.msi
>
> - To sign a bundle setup.exe
> 1. insignia -ib setup.exe -o tmp.exe
> 2. Sign tmp.exe
> 3. insignia -ab tmp.exe setup.exe -o setup.exe
> 4. Sign setup.exe
>
> Thanks for your help,
>
> Pete
>
>
>
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: check for MSI existence and validity

[Rob Mensching]

Yep, reasonable.

On Wed, Jan 11, 2012 at 6:28 AM, jhennessey wrote:

> I can also verify that BootstrapperApplicationData.xml doesn't contain the
> payload information...it's in the manifest file.
>
> I think it would be advantageous to include all of the information from the
> manifest in the BootstrapperApplicationData.xml file (or at least write the
> manifest to the temporary directory so it can be read by the BA).
>
> In my scenario, I would also like to be able to verify the external
> packages
> before presenting the user with the installation options. This will allow
> us
> to maintain one bundle that can be used to present only the particular
> products that a customer has paid for (we'll give them all the same bundle
> but only the MSIs they need). If I had access to the payload information
> then I could accomplish this quite easily.
>
> Reasonable feature request?
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7176343.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] My First Bundle! :)

[Rob Mensching]

Can you try chaning your condition to "NOT
FindDotNet40ClientInstallRegValue" and let's see if that works. I agree
this should work, I'm a little surprised it doesn't.

What version of WIX toolset are you using?

On Wed, Jan 11, 2012 at 2:00 AM, James Green wrote:

> Hi Again,
>
> I spoke too soon.
>
> I've confirmed that .NET 4.0 isn't installed on the machine.  My Bundle
> has an install condition of:
>
> FindDotNet40ClientInstallRegValue = 0
>
> Which is a RegistrySearch:
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework
> Setup\NDP\v4\Client"
> Value="Install"
> Variable="DotNetFramework40ClientInstallRegValue"
> />
>
> [011C:0408][2012-01-11T09:44:42]: Condition
> 'FindDotNet40ClientInstallRegValue = 0' evaluates to false.
>
> Which according to the log evaluated to false, I'm obviously terribly
> mistaken but I would assume that if the key isn't present it would evaluate
> to 0 meaning that " FindDotNet40ClientInstallRegValue = 0" would evaluate
> to true and install .net on the machine.
>
> [011C:0408][2012-01-11T09:44:40]: Registry key not found. Key =
> 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client'
> [011C:0408][2012-01-11T09:44:40]: Registry key not found. Key =
> 'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
>
> Then the entire packaged failed to install anything subsequently.
>
> [011C:0408][2012-01-11T09:44:46]: Error 0x80070643: Failed to execute
> apply.
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: 11 January 2012 05:26
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] My First Bundle! :)
>
> Take a look at the log file that should be created in your %TEMP%
> directory. Hopefully that will show how the condition evaluated and explain
> why uninstall failed.
>
> On Tue, Jan 10, 2012 at 12:00 PM, Jammer  wrote:
>
> > Hi All,
> >
> > I'm creating my first bootstapper installer and I have a few questions.
> >
> > My entire script looks like this:
> >
> > 
> > http://schemas.microsoft.com/wix/2006/wi";
> > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
> >
> >  > Version="1.0.0.0"
> > Manufacturer="Mango-Solutions"
> > UpgradeCode="340fe3b1-b98d-42fc-9a15-d1d36ca83922"
> > HelpTelephone="+44 (0)1249 767700"
> > HelpUrl="http://www.mango-solutions.com";
> > Compressed="yes">
> >
> >
> >  > icense"/>
> >
> >  > Root="HKLM"
> > Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client"
> > Value="Install"
> > Variable="DotNetFramework40ClientInstallRegValue"/>
> >
> >  > Root="HKLM"
> > Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
> > Value="Install"
> > Variable="DotNetFramework40FullInstallRegValue"/>
> > 
> >
> >  > SourceFile="..\..\lib\net_client_profile\dotNetFx40_Client_x86_x64.exe
> > "/>  > SourceFile="..\Build\Mango.Analyse.Installer.msi"/>
> > 
> > 
> > 
> >
> > Even though I have a conditional set on the client profile exe it
> > always runs this package.  As far as I can tell this is correct syntax.
> >
> > I also just noticed that in the Add/Remove Programs under winXP SP3 I
> > ended up with .NET 4.0 client profile installed, the Mango.Analyse
> > application AND an entry for this boot strapper ... when I tried to
> > uninstall the bootstrapper it just gave an error saying that it
> > couldn't proceed ...
> >
> > Would appreciate any pointers as I don't seem to be able to find much
> > documentation for this task.
> > --
> > *Jammer*
> > WWW.JAMMER.BIZ  TWITTER
> >  LINKEDIN
> > **
> >
> > --
> > 
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development.
> > Create new or port existing apps to sell to consumers worldwide.
> > Explore the Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> LEGAL NOTICE
> This message is intended for the use of the nam

[WiX-users] XmlFile element issues - any XPath experts out there?

[Dan Gough]

Hi,

I've successfully set up a few xml file configuration items using the
XmlFile element, but I have an instance that is not working as expected,
hopefully somebody out there can help!

This is a cut down sample of my xml file:





UPDATEME


UPDATEME





And this is my WiX markup:






The result I get is that both statements end up selecting the same first
node (where type='notification'), which ends up being left set to the value
of the last operation.

I believe I am correctly escaping the square brackets above.  If I try to
refer to them in order, e.g.
/evidence_gatherer/evidence/evidence_type[1]/xslt_sql, that does not work
either.  Have I stumbled upon a bug (I'm using v3.6) or are my XPath
statements wrong?

Thanks,
Dan
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Insignia in 3.6

[Peter Hull]

Am I right to say that the documentation for the insignia tool is a bit out of 
date in the 3.6 beta?
The output from insignia /? doesn't mention the options -ab, -ib or -im.

Is the following correct usage?
- To inscribe a database installer.msi with external cabs:
1. Sign the cabs
2. insignia -im installer.msi 
3. Sign installer.msi

- To sign a bundle setup.exe
1. insignia -ib setup.exe -o tmp.exe
2. Sign tmp.exe
3. insignia -ab tmp.exe setup.exe -o setup.exe
4. Sign setup.exe

Thanks for your help,

Pete



  
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] patches and custom actions

[Keith.Douglas]

Hi everyone,

If I create a package with a custom action and an upgrade of same with the same 
custom action, can I change the properties in the upgraded one in such a way 
that when the patch creator is run the resulting MSP package not only does the 
CA run in the patch, but also the relevant change in properties is also 
reflected in the patch so the CA runs appropriately?

For example, the original install installs (amongst other things):

LibA.dll
LibB.dll

and writes information to two files via CA
1.xml
2.xml

This requires (due to the way an application works) creating the WXS for this 
installer in such a way as to create the details for 1.xml and 2.xml via 
properties.

Later, as part of supporting new features in the applications, I want to add 
another of the "support libraries", call it

LibC.dll

In order for the application now to use it, we need to write again to 1.xml and 
2.xml via CA
But the CA has to have its properties fed in again (basically the name of 
LibC.dll) to configure those files successfully. Can this be done automatically 
as part of the MSP generation?

(For what it is worth, this is part of an upgrade to an existing application 
which includes "device detection and management code" as part of a "hands free" 
transmission application using various cellular modems. The LibX.dll mentioned 
are our libraries for detecting a given device, configuring it for the 
specified carrier, etc. They use a standard interface known by the application 
and abstract away from the vendor specifics.)

- * -

Alternatively, if I release future installers that do the equivalent (call it a 
"small installer") of what the aforementioned MSP is *supposed* to do (i.e. 
install an additional file or two, update some configurations with the CA), 
what will happen when the large upgrade comes along and wants to install the 
same files as the small installer as well as updates to the main application, 
will this work? Will it "damage" the installation of the small installed bits? 
If so, does that matter? The contents of the small installed bits will likely 
at most be libraries written in managed code and perhaps their native 
counterparts for p/invoke or the like purposes, whereas the larger updates will 
include changes to the two applications that make use of these libraries.


Thanks,


Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada 



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: check for MSI existence and validity

[jhennessey]

I can also verify that BootstrapperApplicationData.xml doesn't contain the
payload information...it's in the manifest file. 

I think it would be advantageous to include all of the information from the
manifest in the BootstrapperApplicationData.xml file (or at least write the
manifest to the temporary directory so it can be read by the BA).

In my scenario, I would also like to be able to verify the external packages
before presenting the user with the installation options. This will allow us
to maintain one bundle that can be used to present only the particular
products that a customer has paid for (we'll give them all the same bundle
but only the MSIs they need). If I had access to the payload information
then I could accomplish this quite easily.

Reasonable feature request?

--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7176343.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Selection of features Based on Conditions

[Rohini S]

Hi,

I need to select different types of features based on condition.

the selection is like tree model,if select the last child parent child
files also should include.
for this type any example??


Thank You,
S.Rohini
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

[Peter Hull]

Hi Nikolaj!

Could you comment on whether your installer was signed (the bundle and the 
actual engine which is unpacked out of it - see this link 
https://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVc1c2h3QuYsiXWcR8A1Xtk38Z3W2KCyAvuP3hMjYqKAiA%40mail.gmail.com&forum_name=wix-users
 )

I'm glad someone else has seen this problem, especially as you have more 
control over your environment than I do!

Peter


> Date: Wed, 11 Jan 2012 12:16:37 +0100
> From: n...@panorama9.com
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
>
> We have built a EXE with Wix 3.6 beta which are detected by Trend Micro
> as "Malware behavior" and
> we are looking for the reason for this.
>
> This is the log entry from Trend Micro
> ---
> Malware behavior blocking Terminate Registry High
> C:\Documents and Settings\administrator.ADTEST\Local
> Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
>
>
> Write
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
>
> ---
>
> Snip from previous case:
> ---
> Burn-based installers trigger Trend OfficeScan (v.10.5) when they write
> to the RunOnce registry key.
> The virus checker terminates the installer immediately.
> ---
>
> We have a complete testing enviroment where we can tweak, monitor and
> reproduce this error and are more than
> willing to assist in debugging this issue.
>
> Please let me know anything we can provide to debug and solve this
>
> Regards
>
> Nikolaj Steensgaard
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Anybody using Paraffin?

[Dan Gough]

Ok, I have Paraffin working nicely now.  I initially used Heat.exe with the
-suid option so that my IDs have friendly names, then modified the
resulting wxs into Paraffin format.

When I run Paraffin however, the resulting .PARAFFIN file only contains the
default namespace declaration, and not the one I added to the intial wxs
file for the util extension:

http://schemas.microsoft.com/wix/2006/wi";
 *xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"*>

John, can you add a feature request to retain the original attributes on
the root element when creating the Paraffin file?

I may have a go myself since I have the source, but my C# is very rusty and
haven't used LINQ before!  Anybody come across this problem and have a
solution already?

Cheers,
Dan


On Wed, Jan 11, 2012 at 11:55 AM, Dan Gough  wrote:

> Just tried again and the XmlFile tags are no longer being removed, must
> have made a mistake somewhere!  Also confirmed that test values for
> registry and service entries are left untouched also.
>
> Plodding on, wish me luck!
>
> Cheers,
> Dan
>
>
> On Wed, Jan 11, 2012 at 11:33 AM, Dan Gough  wrote:
>
>> Ok, I've got an initial fragment created and sussed out how to perform an
>> update.  However, some of my components have  entries, and these
>> get dropped when updating.  I tried putting these entries into
>> .paraffinmold files, but then if I want it associated with the original
>> component, I end up getting duplicate component entries which then produces
>> errors at compile time.
>>
>> I will eventually be adding registry and service information to some of
>> these components and am thinking Paraffin might strip these out also when
>> updating, can anybody confirm?
>>
>> I would appreciate any advice at this point on the best way forward.
>>
>> Thanks,
>> Dan
>>
>>
>> On Wed, Jan 11, 2012 at 2:25 AM, John Robbins wrote:
>>
>>> Thanks all for the kind words about Paraffin! *blush*
>>>
>>> If you're just getting started with Paraffin make sure to read the Zen
>>> of Paraffin to help you get started. (
>>> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
>>> )
>>>
>>> As always, if anyone has any bugs or feature requests, please let me
>>> know and I'll get on them.
>>>
>>> John
>>> Wintellect
>>> http://www.wintellect.com
>>> +1-877-968-5528
>>>
>>> On Jan 10, 2012, at 10:00 AM, Bourne, Kevin wrote:
>>>
>>> > Using it here too, with great success. Easy to use with our TFS build
>>> server. Also love the fact that we have the source code.
>>> >
>>> >
>>> >
>>> > Kevin Bourne | Software Developer Lead | Chase Paymentech
>>> > ...
>>> > kevin.bou...@chasepaymentech.com
>>> >
>>> > JPMorgan Chase & Co.
>>> >
>>> >
>>> > -Original Message-
>>> > From: Justin Hull [mailto:justin.h...@assetpoint.com]
>>> > Sent: Tuesday, January 10, 2012 12:31 PM
>>> > To: General discussion for Windows Installer XML toolset.
>>> > Subject: Re: [WiX-users] Anybody using Paraffin?
>>> >
>>> > In short I have used it to good success.  It took a little bit to work
>>> through the options, but in the end I got a nice fragment file I could
>>> include in a dynamic build.  After the fact I learned that MISInstaller
>>> prefers each file have its own component, I used paraffin to group by
>>> directory.  When we stich over to a major release I will adjust my scripts
>>> to conform to default behavior.
>>> > I also like that you can dig into the source code.  It is worth a look.
>>> >
>>> > Justin Hull
>>> > Sr. Developer
>>> >
>>> >
>>> > Maximizing Asset Performance
>>> > (864) 679-3513  Office
>>> >
>>> > -Original Message-
>>> > From: Dan Gough [mailto:goug...@gmail.com]
>>> > Sent: Tuesday, January 10, 2012 12:16 PM
>>> > To: General discussion for Windows Installer XML toolset.
>>> > Subject: [WiX-users] Anybody using Paraffin?
>>> >
>>> > Hi,
>>> >
>>> > I want to have my automated WiX build automatically pick up the
>>> occasional
>>> > new file (and drop the odd deleted one) without regenerating any
>>> component
>>> > GUIDs.  I've found this tool named Paraffin that's designed to solve
>>> the
>>> > problem, but it hasn't been updated in a while:
>>> >
>>> >
>>> http://www.wintellect.com/CS/blogs/jrobbins/archive/tags/Paraffin/default.aspx
>>> >
>>> > I'd like to know if any users out there have had experience using this
>>> with
>>> > WiX v3.6 Beta?
>>> >
>>> > Thanks in advance,
>>> > Dan
>>> >
>>> --
>>> > Write once. Port to many.
>>> > Get the SDK and tools to simplify cross-platform app development.
>>> Create
>>> > new or port existing apps to sell to consumers worldwide. Explore the
>>> > Intel AppUpSM program developer opportunity.
>>> appdeveloper.intel.com/join
>>> > http://p.sf.net/sfu/intel-appdev
>>> > ___
>>> > WiX-users mailing list
>>> > WiX-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/wix-us

Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

[Peter Shirtcliffe]

It all looks reasonable. I'd probably go back and examine the text file in
the 2 MSIs that you're building the patch from. It could be a build problem.
Do an administrative install of both MSIs and the version of the text file
from each admin install.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz] 
Sent: 11 January 2012 11:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

I think that the patch doesn't include this text file. At least ORCA shows
only the file "Szenariorechner.exe" to be changed by the patch. The file
"Version.txt" is marked as unchanged.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 12:21
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

I'd generate a verbose log while installing the patch to try and work out why
the text file is not updated.
 
The product version is just a property like any other and often seems not to
be mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this
written in any documentation/book and I have overlooked it?
And I didn't know about the "View Patch" feature in Orca. This makes life a
lot easier!

My patch family now looks like this:

  
  
  


However, the text file with the version  string is still not replaced. This
is a separate component, in the same component group as the managed assembly
and both are in the same fragment. I read that it should be enough to
reference one component in each fragment to trigger the inclusion of all
components in that fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  

  

  



  
  

  


 
.







..

  

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 11:23
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

Add a propertyref to the ProductVersion property. If your text file is in a
separate component from the exe then add a componentref to that too.
Orca will only show 2 tables because the rest of the changes are in 2
transforms embedded in the patch. Use the View Patch menu item in Orca after
loading the base MSI to get a better idea of what it changes.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 08:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe"
patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi
..\Releases\V126\SzenariorechnerSetup.wixpdb
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst "c:\Program
Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp -out
patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

First, you can use Orca to see what the patch is modifying. After that, I
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version num

Re: [WiX-users] Anybody using Paraffin?

[Dan Gough]

Just tried again and the XmlFile tags are no longer being removed, must
have made a mistake somewhere!  Also confirmed that test values for
registry and service entries are left untouched also.

Plodding on, wish me luck!

Cheers,
Dan


On Wed, Jan 11, 2012 at 11:33 AM, Dan Gough  wrote:

> Ok, I've got an initial fragment created and sussed out how to perform an
> update.  However, some of my components have  entries, and these
> get dropped when updating.  I tried putting these entries into
> .paraffinmold files, but then if I want it associated with the original
> component, I end up getting duplicate component entries which then produces
> errors at compile time.
>
> I will eventually be adding registry and service information to some of
> these components and am thinking Paraffin might strip these out also when
> updating, can anybody confirm?
>
> I would appreciate any advice at this point on the best way forward.
>
> Thanks,
> Dan
>
>
> On Wed, Jan 11, 2012 at 2:25 AM, John Robbins  wrote:
>
>> Thanks all for the kind words about Paraffin! *blush*
>>
>> If you're just getting started with Paraffin make sure to read the Zen of
>> Paraffin to help you get started. (
>> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
>> )
>>
>> As always, if anyone has any bugs or feature requests, please let me know
>> and I'll get on them.
>>
>> John
>> Wintellect
>> http://www.wintellect.com
>> +1-877-968-5528
>>
>> On Jan 10, 2012, at 10:00 AM, Bourne, Kevin wrote:
>>
>> > Using it here too, with great success. Easy to use with our TFS build
>> server. Also love the fact that we have the source code.
>> >
>> >
>> >
>> > Kevin Bourne | Software Developer Lead | Chase Paymentech
>> > ...
>> > kevin.bou...@chasepaymentech.com
>> >
>> > JPMorgan Chase & Co.
>> >
>> >
>> > -Original Message-
>> > From: Justin Hull [mailto:justin.h...@assetpoint.com]
>> > Sent: Tuesday, January 10, 2012 12:31 PM
>> > To: General discussion for Windows Installer XML toolset.
>> > Subject: Re: [WiX-users] Anybody using Paraffin?
>> >
>> > In short I have used it to good success.  It took a little bit to work
>> through the options, but in the end I got a nice fragment file I could
>> include in a dynamic build.  After the fact I learned that MISInstaller
>> prefers each file have its own component, I used paraffin to group by
>> directory.  When we stich over to a major release I will adjust my scripts
>> to conform to default behavior.
>> > I also like that you can dig into the source code.  It is worth a look.
>> >
>> > Justin Hull
>> > Sr. Developer
>> >
>> >
>> > Maximizing Asset Performance
>> > (864) 679-3513  Office
>> >
>> > -Original Message-
>> > From: Dan Gough [mailto:goug...@gmail.com]
>> > Sent: Tuesday, January 10, 2012 12:16 PM
>> > To: General discussion for Windows Installer XML toolset.
>> > Subject: [WiX-users] Anybody using Paraffin?
>> >
>> > Hi,
>> >
>> > I want to have my automated WiX build automatically pick up the
>> occasional
>> > new file (and drop the odd deleted one) without regenerating any
>> component
>> > GUIDs.  I've found this tool named Paraffin that's designed to solve the
>> > problem, but it hasn't been updated in a while:
>> >
>> >
>> http://www.wintellect.com/CS/blogs/jrobbins/archive/tags/Paraffin/default.aspx
>> >
>> > I'd like to know if any users out there have had experience using this
>> with
>> > WiX v3.6 Beta?
>> >
>> > Thanks in advance,
>> > Dan
>> >
>> --
>> > Write once. Port to many.
>> > Get the SDK and tools to simplify cross-platform app development. Create
>> > new or port existing apps to sell to consumers worldwide. Explore the
>> > Intel AppUpSM program developer opportunity.
>> appdeveloper.intel.com/join
>> > http://p.sf.net/sfu/intel-appdev
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>> >
>> --
>> > Write once. Port to many.
>> > Get the SDK and tools to simplify cross-platform app development. Create
>> > new or port existing apps to sell to consumers worldwide. Explore the
>> > Intel AppUpSM program developer opportunity.
>> appdeveloper.intel.com/join
>> > http://p.sf.net/sfu/intel-appdev
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> > --
>> > Learn more about Chase Paymentech Solutions,LLC payment processing
>> services at www.chasepaymentech.com.
>> >
>> > THIS MESSAGE IS CONFIDENTIAL.  This e-mail message and any attachments
>> are proprietary and confidential information intended only for the use of
>> the recipient(s) named above.  If you are not the intended recipient, you
>> may not prin

Re: [WiX-users] Anybody using Paraffin?

[Dan Gough]

Ok, I've got an initial fragment created and sussed out how to perform an
update.  However, some of my components have  entries, and these
get dropped when updating.  I tried putting these entries into
.paraffinmold files, but then if I want it associated with the original
component, I end up getting duplicate component entries which then produces
errors at compile time.

I will eventually be adding registry and service information to some of
these components and am thinking Paraffin might strip these out also when
updating, can anybody confirm?

I would appreciate any advice at this point on the best way forward.

Thanks,
Dan

On Wed, Jan 11, 2012 at 2:25 AM, John Robbins  wrote:

> Thanks all for the kind words about Paraffin! *blush*
>
> If you're just getting started with Paraffin make sure to read the Zen of
> Paraffin to help you get started. (
> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
> )
>
> As always, if anyone has any bugs or feature requests, please let me know
> and I'll get on them.
>
> John
> Wintellect
> http://www.wintellect.com
> +1-877-968-5528
>
> On Jan 10, 2012, at 10:00 AM, Bourne, Kevin wrote:
>
> > Using it here too, with great success. Easy to use with our TFS build
> server. Also love the fact that we have the source code.
> >
> >
> >
> > Kevin Bourne | Software Developer Lead | Chase Paymentech
> > ...
> > kevin.bou...@chasepaymentech.com
> >
> > JPMorgan Chase & Co.
> >
> >
> > -Original Message-
> > From: Justin Hull [mailto:justin.h...@assetpoint.com]
> > Sent: Tuesday, January 10, 2012 12:31 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Anybody using Paraffin?
> >
> > In short I have used it to good success.  It took a little bit to work
> through the options, but in the end I got a nice fragment file I could
> include in a dynamic build.  After the fact I learned that MISInstaller
> prefers each file have its own component, I used paraffin to group by
> directory.  When we stich over to a major release I will adjust my scripts
> to conform to default behavior.
> > I also like that you can dig into the source code.  It is worth a look.
> >
> > Justin Hull
> > Sr. Developer
> >
> >
> > Maximizing Asset Performance
> > (864) 679-3513  Office
> >
> > -Original Message-
> > From: Dan Gough [mailto:goug...@gmail.com]
> > Sent: Tuesday, January 10, 2012 12:16 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Anybody using Paraffin?
> >
> > Hi,
> >
> > I want to have my automated WiX build automatically pick up the
> occasional
> > new file (and drop the odd deleted one) without regenerating any
> component
> > GUIDs.  I've found this tool named Paraffin that's designed to solve the
> > problem, but it hasn't been updated in a while:
> >
> >
> http://www.wintellect.com/CS/blogs/jrobbins/archive/tags/Paraffin/default.aspx
> >
> > I'd like to know if any users out there have had experience using this
> with
> > WiX v3.6 Beta?
> >
> > Thanks in advance,
> > Dan
> >
> --
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> --
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > --
> > Learn more about Chase Paymentech Solutions,LLC payment processing
> services at www.chasepaymentech.com.
> >
> > THIS MESSAGE IS CONFIDENTIAL.  This e-mail message and any attachments
> are proprietary and confidential information intended only for the use of
> the recipient(s) named above.  If you are not the intended recipient, you
> may not print, distribute, or copy this message or any attachments.  If you
> have received this communication in error, please notify the sender by
> return e-mail and delete this message and any attachments from your
> computer.
> >
> >
> >
> >
> >
> >
> --
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> >

Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

[Ulrich Proeller]

I think that the patch doesn't include this text file. At least ORCA shows only 
the file "Szenariorechner.exe" to be changed by the patch. The file 
"Version.txt" is marked as unchanged.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 12:21
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

I'd generate a verbose log while installing the patch to try and work out why 
the text file is not updated.
 
The product version is just a property like any other and often seems not to be 
mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this written 
in any documentation/book and I have overlooked it?
And I didn't know about the "View Patch" feature in Orca. This makes life a lot 
easier!

My patch family now looks like this:

  
  
  


However, the text file with the version  string is still not replaced. This is 
a separate component, in the same component group as the managed assembly and 
both are in the same fragment. I read that it should be enough to reference one 
component in each fragment to trigger the inclusion of all components in that 
fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  

  

  



  
  

  


 
.







..

  

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 11:23
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

Add a propertyref to the ProductVersion property. If your text file is in a 
separate component from the exe then add a componentref to that too.
Orca will only show 2 tables because the rest of the changes are in 2 
transforms embedded in the patch. Use the View Patch menu item in Orca after 
loading the base MSI to get a better idea of what it changes.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 08:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and 
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs 
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe"
patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi 
..\Releases\V126\SzenariorechnerSetup.wixpdb
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst "c:\Program 
Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp -out 
patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key 
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

First, you can use Orca to see what the patch is modifying. After that, I 
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version number.
>
> My patch definition file looks as follows:
>
>   xmlns="http://schemas.microsoft.com/wix/2006/wi";>
>   Classification="Update"
> Comments="Patch"
> Description="Patch"
> DisplayName="Patch"
> Manufacturer="..."
> MoreInfoURL="http://...";
> TargetProductName="Szenario Rechner"
> Codepage="1252">
>
>  
>
>
>  
>
>  
> 
>
> First, I tried the official WIX 3.6 Beta but always got

[WiX-users] Reopen Burn triggers virus checker - ID: 3431068

[NIkolaj Steensgaard]

We have built a EXE with Wix 3.6 beta which are detected by Trend Micro 
as "Malware behavior" and
we are looking for the reason for this.

This is the log entry from Trend Micro
---
Malware behavior blocking Terminate Registry High
C:\Documents and Settings\administrator.ADTEST\Local 
Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
 


Write 
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
 

---

Snip from previous case:
---
Burn-based installers trigger Trend OfficeScan (v.10.5) when they write 
to the RunOnce registry key.
The virus checker terminates the installer immediately.
---

We have a complete testing enviroment where we can tweak, monitor and 
reproduce this error and are more than
willing to assist in debugging this issue.

Please let me know anything we can provide to debug and solve this

Regards

Nikolaj Steensgaard


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version

[Peter Shirtcliffe]

I'd generate a verbose log while installing the patch to try and work out why
the text file is not updated.
 
The product version is just a property like any other and often seems not to
be mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz] 
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this
written in any documentation/book and I have overlooked it?
And I didn't know about the "View Patch" feature in Orca. This makes life a
lot easier!

My patch family now looks like this:

  
  
  


However, the text file with the version  string is still not replaced. This
is a separate component, in the same component group as the managed assembly
and both are in the same fragment. I read that it should be enough to
reference one component in each fragment to trigger the inclusion of all
components in that fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  

  

  



  
  

  


 
.







..

  

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 11:23
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

Add a propertyref to the ProductVersion property. If your text file is in a
separate component from the exe then add a componentref to that too.
Orca will only show 2 tables because the rest of the changes are in 2
transforms embedded in the patch. Use the View Patch menu item in Orca after
loading the base MSI to get a better idea of what it changes.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 08:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe"
patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi
..\Releases\V126\SzenariorechnerSetup.wixpdb
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst "c:\Program
Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp -out
patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

First, you can use Orca to see what the patch is modifying. After that, I
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version number.
>
> My patch definition file looks as follows:
>
>   xmlns="http://schemas.microsoft.com/wix/2006/wi";>
>   Classification="Update"
> Comments="Patch"
> Description="Patch"
> DisplayName="Patch"
> Manufacturer="..."
> MoreInfoURL="http://...";
> TargetProductName="Szenario Rechner"
> Codepage="1252">
>
>  
>
>
>  
>
>  
> 
>
> First, I tried the official WIX 3.6 Beta but always got warnings about 
> an empty .cab file and the patch file size was just 20 kb.
> After switching to WIX 3.5 the patch creation process was without 
> warnings or errors and I  got a 480 kb patch file.
>
> However, when applying the patch file, which works without problems, 
> only the managed exe file was replaced. The version number is still
> 1.2.6.0 and the text file still shows the old content (1.2.6).
>
> Can please anybody give me an advice what I am doing wrong. I've 
> alr

[WiX-users] Reopen Burn triggers virus checker - ID: 3431068

[NIkolaj Steensgaard]

We have built a EXE with Wix 3.6 beta which are detected by Trend Micro 
as "Malware behavior" and
we are looking for the reason for this.

This is the log entry from Trend Micro
---
Malware behavior blocking Terminate Registry High
C:\Documents and Settings\administrator.ADTEST\Local 
Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
 


Write 
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
 

---

Snip from previous case:
---
Burn-based installers trigger Trend OfficeScan (v.10.5) when they write 
to the RunOnce registry key.
The virus checker terminates the installer immediately.
---

We have a complete testing enviroment where we can tweak, monitor and 
reproduce this error and are more than
willing to assist in debugging this issue.

Please let me know anything we can provide to debug and solve this

Regards

Nikolaj Steensgaard


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

[Ulrich Proeller]

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this written 
in any documentation/book and I have overlooked it?
And I didn't know about the "View Patch" feature in Orca. This makes life a lot 
easier!

My patch family now looks like this:

  
  
  


However, the text file with the version  string is still not replaced. This is 
a separate component, in the same component group as the managed assembly and 
both are in the same fragment. I read that it should be enough to reference one 
component in each fragment to trigger the inclusion of all components in that 
fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  

  

  



  
  

  


 
.







..

  

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 11:23
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

Add a propertyref to the ProductVersion property. If your text file is in a 
separate component from the exe then add a componentref to that too.
Orca will only show 2 tables because the rest of the changes are in 2 
transforms embedded in the patch. Use the View Patch menu item in Orca after 
loading the base MSI to get a better idea of what it changes.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 08:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and 
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs 
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe"
patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi 
..\Releases\V126\SzenariorechnerSetup.wixpdb
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst "c:\Program 
Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp -out 
patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key 
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

First, you can use Orca to see what the patch is modifying. After that, I 
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version number.
>
> My patch definition file looks as follows:
>
>   xmlns="http://schemas.microsoft.com/wix/2006/wi";>
>   Classification="Update"
> Comments="Patch"
> Description="Patch"
> DisplayName="Patch"
> Manufacturer="..."
> MoreInfoURL="http://...";
> TargetProductName="Szenario Rechner"
> Codepage="1252">
>
>  
>
>
>  
>
>  
> 
>
> First, I tried the official WIX 3.6 Beta but always got warnings about 
> an empty .cab file and the patch file size was just 20 kb.
> After switching to WIX 3.5 the patch creation process was without 
> warnings or errors and I  got a 480 kb patch file.
>
> However, when applying the patch file, which works without problems, 
> only the managed exe file was replaced. The version number is still
> 1.2.6.0 and the text file still shows the old content (1.2.6).
>
> Can please anybody give me an advice what I am doing wrong. I've 
> already checked every line in the tutorial and in the WIX book and I 
> have googled for any related problem, without success!
>
> Thanks in advance, Ulrich
>
> --
> 
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. 
> Create new or port existing apps to sell to consumers worldwide. 
> Explore the Intel AppUpSM program developer opportunity. 
> appdeveloper.intel.c

Re: [WiX-users] Patching

[Peter Shirtcliffe]

I'll try and answer this but it's best to seek some other opinions too.

1. The order of patch installation wont usually matter. When you create a
patch, you target it at a particular version or even multiple versions (eg
patched/upgraded installations) and MSI works out the right sequence. See the
MS patching whitepaper at
http://www.microsoft.com/download/en/details.aspx?id=19013
You do this by creating one or more transforms (diffs) with the torch tool
and passing them when you create the patch with pyro.

2. The 4th version field of the MSI product version is ignored by Windows
installer. You can use it for information but we don't - some APIs will
retrieve the 4th field however. We use [major version].[service pack].[build]
The files in your installer have no such restrictions. Version those in
whatever way suits you.

3. The way we do that currently is to build the patch from administrative
installations of the released and updated MSIs instead of using wixpdbs. 
http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didn
t-build-with-wix-using-wix-.aspx
and other articles in that blog.

4. MSI records what patches are applied to a product. It depends on how you
want to retrieve the information. You can use MsiEnumPatches() from C++ for
example. You could also install something to act as a marker.

Useful links include:
MSDN on Windows installer
Peter Marcu's blog
Heath Stewart's blog
Rob Menchsings blog (and others on the Wix team)
This mailing list's archives
Wix docs


-Original Message-
From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] 
Sent: 10 January 2012 23:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Patching

I am in the process of writing an installer for a company product (we were
previously using Installshield). Once, released we will need the produce
patches for bug fixes and enhancements. The expectation that these patches
will consist of simply updating some of the released files and/or adding new
files not part of the initial distribution.   I think we will generally do a
minor upgrade. In some cases the patches are dependent on a previous patch
and in other cases not.
 
Therefore I've been reading material about how we should structure our
initial release of the product to best enable but still have some questions
about things that aren't clear. Can someone help me here:
 
1.   How can we generate the diff against the installed version for the
patches that can be installed in any order. We are not sure what the users
machine will have because they may have already applied one of the other
patches. Surely we don't need to generate a patch for each possible order of
installation of all the patches. 
2.   We can update the 3rd or 4th  component of product version when
doing an upgrade/patch for some. Can someone explain the consequences of each
option. When we generate a diff for the patch, does the generated patch use
the product version and only patch against it or does it only patch products
with matching Product GUID and file versions.
3.   When creating a patch, I want to explicitly specify the collection
of files (DLLs etc.) to be upgraded. I don't want any other existing files to
be touched. I have read that when you specify a patch components (i.e. via
ComponentRef) inside a PatchFamily element, any components in the same
fragment will also be updated.   Can I avoid this without having to create
different fragments for every component in my product which is a bit of a
pain.
4.   As far as I can tell, you can always apply a patch (msp) multiple
times even if the product is already patched. Is there a way to flag that the
patch is already installed without updating the product version. 
 
If there are any good sources of material which answer some of these
questions, please point them out to me.
 
Thanks in advance
sanjay
-
-
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT res

Re: [WiX-users] Weekly builds

[David Watson]

No not naive, I don't think anyone can really anticipate the degree that your
life changes.
Congrats on your new bundle.

Dave

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 11 January 2012 05:27
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Weekly builds

Working on it I promise. Getting close. New baby sucking time (in a good
way) that I did not anticipate (yes, call me naive).

On Tue, Jan 10, 2012 at 4:54 AM, David Watson  wrote:

> Forgive me if I am being dim but did the weekly builds stop happening?
> There
> appears to be check-ins in December but the only 3.6 build i can see is
> from
> October, on codeplex.
>
> I recall there being some problems with bandwidth and talk of moving to
> wixtoolset.org but I don't see any changes anywhere.
>
> I don't really fancy setting up an build environment...
>
> Cheers
> Dave
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.
>  Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
> 7DY, UK.
>
>
>
>
-
-
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
virtually, Rob Mensching - http://RobMensching.com LLC
-
-
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally Include based on Build Configuration

[Peter Shirtcliffe]

The Wix help contains a section "Working with visual studio". The "Using
Project References and Variables" topic under there describes how visual
studio settings map to Wix pre-processor variables. The one youre interested
in is var..FullConfiguration. There are some others that may be
of use too.

-Original Message-
From: Daniel Sniderman [mailto:dani...@magenic.com] 
Sent: 10 January 2012 18:21
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditionally Include based on Build Configuration

I'm working on automating our Build - and migrating from VS Setup to WIX.

We have a Windows Forms Application that has two different Configurations -
One to Deploy to Citrix Servers and another for occasionally connected Laptop
Users (plus several "environments" dev/qa/prod etc)

For the two different configurations the differences are in differing config
settings (which I've already figured out how to)

What I need help with - the Laptop MSI needs include an additional EXE and a
few corresponding files - and add a shortcut to the additional EXE to the
startup folder.

Ideally I'd like one WIX solution (and wxs file if possible) that based on
the "Configuration to Build" setting (ideally both from a desktop build and a
TFS 2010 build) create the appropriate MSI.   (IE - I don't want a single
type of MSI that requires the user to select based on UI).

What is the best way to implement this?

Thanks!

Daniel P. Sniderman| Sr Consultant| Magenic
MCSD.NET, MCTS: Team Foundation Server 2010 Administration

333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
Mobile: 847-668-4882  | eFax 847-390-7810
magenic.com | dani...@magenic.com


-
-
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

[Peter Shirtcliffe]

Add a propertyref to the ProductVersion property. If your text file is in a
separate component from the exe then add a componentref to that too.
Orca will only show 2 tables because the rest of the changes are in 2
transforms embedded in the patch. Use the View Patch menu item in Orca after
loading the base MSI to get a better idea of what it changes.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz] 
Sent: 11 January 2012 08:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe"
patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi
..\Releases\V126\SzenariorechnerSetup.wixpdb
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp
-out patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com] 
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

First, you can use Orca to see what the patch is modifying. After that, I
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version number.
>
> My patch definition file looks as follows:
>
>   xmlns="http://schemas.microsoft.com/wix/2006/wi";>
>   Classification="Update"
> Comments="Patch"
> Description="Patch"
> DisplayName="Patch"
> Manufacturer="..."
> MoreInfoURL="http://...";
> TargetProductName="Szenario Rechner"
> Codepage="1252">
>
>  
>
>
>  
>
>  
> 
>
> First, I tried the official WIX 3.6 Beta but always got warnings about 
> an empty .cab file and the patch file size was just 20 kb.
> After switching to WIX 3.5 the patch creation process was without 
> warnings or errors and I  got a 480 kb patch file.
>
> However, when applying the patch file, which works without problems, 
> only the managed exe file was replaced. The version number is still 
> 1.2.6.0 and the text file still shows the old content (1.2.6).
>
> Can please anybody give me an advice what I am doing wrong. I've 
> already checked every line in the tutorial and in the WIX book and I 
> have googled for any related problem, without success!
>
> Thanks in advance, Ulrich
>
> --
> 
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. 
> Create new or port existing apps to sell to consumers worldwide. 
> Explore the Intel AppUpSM program developer opportunity. 
> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually, Rob Mensching - http://RobMensching.com LLC
-
-
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

Re: [WiX-users] creating a WIX small or minor patch

[Peter Shirtcliffe]

That is a example from one of our released products. The Id in the
patchbaseline is something you invent and only appears otherwise on the pyro
command line. 
Why do you say that your files are relevant ?

-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] 
Sent: 10 January 2012 11:21
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] creating a WIX small or minor patch

Yea, that I got from the sample, the problem is that our build.wxs files are
a "bit" more complicated than the example ones...
We are using HearDirectory to create our file list, and the file list
generated doesn't have a nice ID that I can reference too...
What I really need is a good example, an example that shows how to work with
real life scenarios...
Thanks.

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Monday, January 09, 2012 6:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] creating a WIX small or minor patch

This goes in the Patch element.

  
   
  
  


-Original Message-
From: tome...@qualisystems.com [mailto:tome...@qualisystems.com]
Sent: 09 January 2012 15:31
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] creating a WIX small or minor patch

HI all,
I'm having problems creating a WIX small or minor patch...
My wsx files that I use to create the installation use HeatDirectory to
harvest the files I need to put in my MSI (I'm not using cab, it's in a
folder besides the MSI), anyway, I have 2 versions of the installation MSI
and the wixpdb files that go along with them, the problem I'm having is
creating the right patch.wsx to work with the diff.wixmst I create with the
torch...
The call to this command:
pyro.exe out\patch\patch.wixmsp -out out\patch\patch.msp -t RTM
out\patch\diff.wixmst
throws:
pyro.exe : error PYRO0252 : No valid transforms were provided to attach to
the patch. Check to make sure the transforms you passed on the command line
have a matching baseline authored in the patch. Also, make sure there are
differences between your target and upgrade.
And it figures... I don't have an RTM id anywhere... please help...
Any link to a patch.wsx sample with a bit MORE details will be MUCH
appreciated.



Tomer Cohen
InSight Team Leader, R&D
QualiSystems
20 Hacarmel St.
Ganey Tikva, Israel 55900

Fax: +972-77-9014099
phone: +972-77-9014094
Mobile: +972-52-3362846
Email: tome...@qualisystems.com
Web: www.qualisystems.com

QualiSystems | 20 Hacarmel St. Ganey Tikva, Israel 55900
  
Learn about our NEW Test Automation Solution - TestShell Studio Join our QA
Test Automation Group on LinkedIn

Standards of Excellence
This email including any attachment may contain confidential and/or
privileged information intended solely for the use of the specified
addressee[s]. Its contents shall not be copied, reproduced, changed or
communicated to another - either in whole or in part. If you have received
this email or parts thereof in error we request that you immediately notify
us and delete this email.



-
-
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6
7DY, UK.


-
-
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
-
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdevelop

Re: [WiX-users] My First Bundle! :)

[James Green]

Hi Again,

I spoke too soon.

I've confirmed that .NET 4.0 isn't installed on the machine.  My Bundle has an 
install condition of:

FindDotNet40ClientInstallRegValue = 0

Which is a RegistrySearch:



[011C:0408][2012-01-11T09:44:42]: Condition 'FindDotNet40ClientInstallRegValue 
= 0' evaluates to false.

Which according to the log evaluated to false, I'm obviously terribly mistaken 
but I would assume that if the key isn't present it would evaluate to 0 meaning 
that " FindDotNet40ClientInstallRegValue = 0" would evaluate to true and 
install .net on the machine.  

[011C:0408][2012-01-11T09:44:40]: Registry key not found. Key = 
'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client'
[011C:0408][2012-01-11T09:44:40]: Registry key not found. Key = 
'SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'

Then the entire packaged failed to install anything subsequently.

[011C:0408][2012-01-11T09:44:46]: Error 0x80070643: Failed to execute apply.


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 11 January 2012 05:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] My First Bundle! :)

Take a look at the log file that should be created in your %TEMP% directory. 
Hopefully that will show how the condition evaluated and explain why uninstall 
failed.

On Tue, Jan 10, 2012 at 12:00 PM, Jammer  wrote:

> Hi All,
>
> I'm creating my first bootstapper installer and I have a few questions.
>
> My entire script looks like this:
>
> 
> http://schemas.microsoft.com/wix/2006/wi";
> xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
>
>  Version="1.0.0.0"
> Manufacturer="Mango-Solutions"
> UpgradeCode="340fe3b1-b98d-42fc-9a15-d1d36ca83922"
> HelpTelephone="+44 (0)1249 767700"
> HelpUrl="http://www.mango-solutions.com";
> Compressed="yes">
>
>
>  icense"/>
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client"
> Value="Install"
> Variable="DotNetFramework40ClientInstallRegValue"/>
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
> Value="Install"
> Variable="DotNetFramework40FullInstallRegValue"/>
> 
>
>  SourceFile="..\..\lib\net_client_profile\dotNetFx40_Client_x86_x64.exe
> "/>  SourceFile="..\Build\Mango.Analyse.Installer.msi"/>
> 
> 
> 
>
> Even though I have a conditional set on the client profile exe it 
> always runs this package.  As far as I can tell this is correct syntax.
>
> I also just noticed that in the Add/Remove Programs under winXP SP3 I 
> ended up with .NET 4.0 client profile installed, the Mango.Analyse 
> application AND an entry for this boot strapper ... when I tried to 
> uninstall the bootstrapper it just gave an error saying that it 
> couldn't proceed ...
>
> Would appreciate any pointers as I don't seem to be able to find much 
> documentation for this task.
> --
> *Jammer*
> WWW.JAMMER.BIZ  TWITTER 
>  LINKEDIN
> **
>
> --
> 
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. 
> Create new or port existing apps to sell to consumers worldwide. 
> Explore the Intel AppUpSM program developer opportunity. 
> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex 
infrastructure or vast IT resources to deliver seamless, secure access to 
virtual desktops. With this all-in-one solution, easily deploy virtual desktops 
for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it 
free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
LEGAL NOTICE
This message is intended for the use of the named recipient(s) only and may 
contain confidential and / or privileged information. If you are not the 
intended recipient, please contact the sender and delete this message. Any 
unauthorised use of the information contained in this message is prohibited.
Mango Business Solutions Limited is registered in England under No. 4560258 
with its registered office at Suite 3, Middlesex House, Rutherford Close, 
Stevenage, Herts, SG1 2EF, UK.

PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual 

[WiX-users] Error message when creating an ODBC DataSource

[Wittek Ádám]

Hi,

I keep getting an error message during the installation:
Error configuring ODBC data source: MyDSN, ODBC error 11: Driver's ConfigDSN, 
ConfigDriver, or ConfigTranslator failed. Verify that the file MyDSN exists and 
that you can access it.

There are 3 buttons on the message box: Cancel, Retry, and Ignore. If I select 
Ignore then the installation is finishing successfully. The ODBC DataSource is 
created as well and it can connect to the Database. So everything works fine. 
Then why do I get this error message?

I cannot release the installer with this annoying error to the customers. I 
must get rid of it! Any help would be greatly appreciated!

Details:
The installer creates the ODBC DataSource like the following:







I know that ODBCDataSource/@DriverName is not formatted string, so I also 
update the ODBCDataSource table via a C# CustomAction:

[CustomAction]
private static void UpdateODBCDataSourceTable(Session session)
{
session.Log("Opening view");
View lView = session.Database.OpenView("DELETE FROM ODBCDataSource 
WHERE ODBCDataSource.DataSource='OracleODBCDataSource'");
 lView.Execute();

lView = session.Database.OpenView("SELECT * FROM ODBCDataSource");
lView.Execute();

try
{
Record lRecord = session.Database.CreateRecord(5);
lRecord.SetString(1, 'OracleODBCDataSource');   
 //DataSource
lRecord.SetString(2, 'OracleODBCDataSourceComp');
//Component
lRecord.SetString(3, 'MyDSN');  
   //Description
lRecord.SetString(4, session["ORACLEODBCDRIVER"]); 
//DriverDescription
lRecord.SetInteger(5, 0);   
  //Registration: 0 means System DSN

lView.Modify(ViewModifyMode.InsertTemporary, lRecord);
}
catch (Exception ex)
{
session.Log(ex.Message);
}

lView.Close();

session.Log("Closing view");
lView.Close();
}

The ORACLEODBCDRIVER property is set by the user during the installation.

The related part of the log:
Action 7:21:28: InstallODBC. Installing ODBC components
1: Oracle in OraDb11g_home1 2:  3: 4 4: DSN 5: MyDSN 6: Server 7: MyTNS
Error 1919. Error configuring ODBC data source: MyDSN, ODBC error 11: Driver's 
ConfigDSN, ConfigDriver, or ConfigTranslator failed. Verify that the file MyDSN 
exists and that you can access it.

Thank you in advance.
Regards,
Adam Wittek
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] My First Bundle! :)

[James Green]

Hi,

Thanks for that Rob.  Looked at the logs and solved that particular issue.  The 
only issue I have left now is that the Bundle itself appears in the Add/Remove 
programs.

Is there a way to hide it? Or should I be thinking about "hiding" the 
application and use the bundle as the UnInstaller?

Jammer

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 11 January 2012 05:26
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] My First Bundle! :)

Take a look at the log file that should be created in your %TEMP% directory. 
Hopefully that will show how the condition evaluated and explain why uninstall 
failed.

On Tue, Jan 10, 2012 at 12:00 PM, Jammer  wrote:

> Hi All,
>
> I'm creating my first bootstapper installer and I have a few questions.
>
> My entire script looks like this:
>
> 
> http://schemas.microsoft.com/wix/2006/wi";
> xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
>
>  Version="1.0.0.0"
> Manufacturer="Mango-Solutions"
> UpgradeCode="340fe3b1-b98d-42fc-9a15-d1d36ca83922"
> HelpTelephone="+44 (0)1249 767700"
> HelpUrl="http://www.mango-solutions.com";
> Compressed="yes">
>
>
>  icense"/>
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client"
> Value="Install"
> Variable="DotNetFramework40ClientInstallRegValue"/>
>
>  Root="HKLM"
> Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
> Value="Install"
> Variable="DotNetFramework40FullInstallRegValue"/>
> 
>
>  SourceFile="..\..\lib\net_client_profile\dotNetFx40_Client_x86_x64.exe
> "/>  SourceFile="..\Build\Mango.Analyse.Installer.msi"/>
> 
> 
> 
>
> Even though I have a conditional set on the client profile exe it 
> always runs this package.  As far as I can tell this is correct syntax.
>
> I also just noticed that in the Add/Remove Programs under winXP SP3 I 
> ended up with .NET 4.0 client profile installed, the Mango.Analyse 
> application AND an entry for this boot strapper ... when I tried to 
> uninstall the bootstrapper it just gave an error saying that it 
> couldn't proceed ...
>
> Would appreciate any pointers as I don't seem to be able to find much 
> documentation for this task.
> --
> *Jammer*
> WWW.JAMMER.BIZ  TWITTER 
>  LINKEDIN
> **
>
> --
> 
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. 
> Create new or port existing apps to sell to consumers worldwide. 
> Explore the Intel AppUpSM program developer opportunity. 
> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex 
infrastructure or vast IT resources to deliver seamless, secure access to 
virtual desktops. With this all-in-one solution, easily deploy virtual desktops 
for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it 
free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
LEGAL NOTICE
This message is intended for the use of the named recipient(s) only and may 
contain confidential and / or privileged information. If you are not the 
intended recipient, please contact the sender and delete this message. Any 
unauthorised use of the information contained in this message is prohibited.
Mango Business Solutions Limited is registered in England under No. 4560258 
with its registered office at Suite 3, Middlesex House, Rutherford Close, 
Stevenage, Herts, SG1 2EF, UK.

PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: check for MSI existence and validity

[Kryschan]

Rob Mensching-7 wrote
> 
> The BootstrapperApplication.xml should list all the payloads, so if you
> really want to do this upfront, your BA should be able to it (plus using
> the WixBundleOriginalPath variable).
> 

In the temporary folder I found a file BootstrapperApplicationData.xml. I
guess this is what you mean. Indeed this file contains all my packages but
it does neither contain the relative path of the package nor the package's
SHA1 hash value.

This is an example entry:



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7175564.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

[Ulrich Proeller]

Orca just shows only 2 tables in the patch file: MsiPatchMetadata and 
MsiPatchSequence. Therefore I wonder why the patch is doing anything.

Here are the steps to create the patch:
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe" patch.wxs
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\light.exe" patch.wixobj
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\torch.exe" -p -xi 
..\Releases\V126\SzenariorechnerSetup.wixpdb 
..\Releases\V127\SzenariorechnerSetup.wixpdb -out patch.wixmst
"c:\Program Files (x86)\Windows Installer XML v3.5\bin\pyro.exe" patch.wixmsp 
-out patch.msp -t RTM patch.wixmst -sf

The switch "-sf" in the pyro command was added the get rid of a duplicate key 
error.

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com] 
Gesendet: Mittwoch, 11. Januar 2012 07:08
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

First, you can use Orca to see what the patch is modifying. After that, I 
epxect the WiX v3.6 warnings were that it didn't find anything updated.
Maybe post the set of steps you followed to build the patch?

On Tue, Jan 10, 2012 at 11:01 AM, Ulrich Proeller  wrote:

> Hi All,
>
> I am trying to create a patch (minor upgrade) to my WIX project which 
> is expected to do three things:
>
> 1.   Change the version number of my product (1.2.6.0 => 1.2.7.0)
>
> 2.   Replace an managed exe where just the version number has changed
> (1.2.6.0 => 1.2.7.0)
>
> 3.   Replace a simple text file which simply contains the updated
> version number.
>
> My patch definition file looks as follows:
>
>   xmlns="http://schemas.microsoft.com/wix/2006/wi";>
>   Classification="Update"
> Comments="Patch"
> Description="Patch"
> DisplayName="Patch"
> Manufacturer="..."
> MoreInfoURL="http://...";
> TargetProductName="Szenario Rechner"
> Codepage="1252">
>
>  
>
>
>  
>
>  
> 
>
> First, I tried the official WIX 3.6 Beta but always got warnings about 
> an empty .cab file and the patch file size was just 20 kb.
> After switching to WIX 3.5 the patch creation process was without 
> warnings or errors and I  got a 480 kb patch file.
>
> However, when applying the patch file, which works without problems, 
> only the managed exe file was replaced. The version number is still 
> 1.2.6.0 and the text file still shows the old content (1.2.6).
>
> Can please anybody give me an advice what I am doing wrong. I've 
> already checked every line in the tutorial and in the WIX book and I 
> have googled for any related problem, without success!
>
> Thanks in advance, Ulrich
>
> --
> 
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. 
> Create new or port existing apps to sell to consumers worldwide. 
> Explore the Intel AppUpSM program developer opportunity. 
> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex 
infrastructure or vast IT resources to deliver seamless, secure access to 
virtual desktops. With this all-in-one solution, easily deploy virtual desktops 
for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it 
free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users