date:20100924

Re: [WiX-users] BadImageFormatException, Microsoft.Deployment.WindowsInstaller

2010-09-24 Thread Gary Gocek

An update to my original post to say that I reproduced my error by creating
a small solution with a .NET 4 code project and a .NET 4 CA project, and I
built it on a 32-bit build server with WIX 3.5.2110. The error seems to say
that the installer was built via a newer runtime than is available at
installation time, and it's true that the build PC is different than the PCs
where I try to install. But I have tried installing on a PC with VS 2010 and
.NET 4, so I don't see how my installation PC can be at an earlier runtime
than the build PC. Unless msiexec is doing something funny with the runtime.
Any help would be appreciated.

-Original Message-
From: Gary Gocek [mailto:g...@gocek.org] 
Sent: Thursday, September 23, 2010 7:26 PM
To: 'wix-users@lists.sourceforge.net'
Subject: BadImageFormatException, Microsoft.Deployment.WindowsInstaller


I'm building a project on Win 2008 Server 64-bit, using TFS 2010 build
services and Visual Studio 2010. All projects in the solution are for VS
2010 and .NET Framework 4 (recently converted from VS 2008 and .NET 3.5).
The projects are set for "Any CPU" (so the Platform property in the .csproj
files is 'x86'). WiX 3.5.2110 is installed. The solution builds and
candle/light run to create the MSI.

But when I try to run the MSI, it fails and I see an error in the MSI log
referring to Microsoft.Deployment.WindowsInstaller. I have tried installing
in 32-bit and 64-bit environments, always with msiexec 4.5 (5.0 under Win
7), and .NET 4 is installed and up to date.

Any suggestions? Thanks, here's the error:

System.BadImageFormatException: Could not load file or assembly
'XyzInstaller' or one of its dependencies. This assembly is built by a
runtime newer than the currently loaded runtime and cannot be loaded. File
name: 'XyzInstaller'
   at System.Reflection.Assembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark&
stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection)
   at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark&
stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection)
   at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
   at System.Reflection.Assembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
   at System.AppDomain.Load(String assemblyString)
   at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionM
ethod(Session session, String assemblyName, String className, String
methodName)



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread Christopher Painter

Right, sorry if it wasn't clear when I first said that.  PackageCode is more 
for 
MSI's and not really important to MSM's.
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: John Fry 
To: General discussion for Windows Installer XML toolset. 

Sent: Fri, September 24, 2010 6:26:27 PM
Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Thanks! I replaced the Package ID with the old Module GUID and deleted
the Module GUID, and Wix seems to have kept the same module signature.
It looks like the Package ID wasn't being used anywhere as long as
there was a Module GUID so it doesn't matter that the Package ID
changed.

Thanks again!
John

On Fri, Sep 24, 2010 at 4:01 PM, Christopher Painter
 wrote:
> Checkout an example at:
>
> http://iswix.codeplex.com/SourceControl/changeset/view/53668#841593
>
> This module ends up having a signature of:
>
> IsWiXAddInMM.68061036_B1D9_4092_AD3B_DC569F3DD183 1033 1.0.0.0
>
> and a package code of:  {68061036-B1D9-4092-AD3B-DC569F3DD183} every time it
> builds.   This has no adverse side effects.
>
>
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: Christopher Painter 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Fri, September 24, 2010 5:53:28 PM
> Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Yes, what I was trying to say is  that WiX v3 uses the Module Id along with 
the
> Package Id to create the Module.GUID you see in the ModuleSignature table.
> Just build your old, tweak it up and build the new and you'll see they are the
> same in Orca if you did it right.
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: John Fry 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Fri, September 24, 2010 5:26:22 PM
> Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Won't removing the module GUID change the module signature?
>
> If we have the following lines:
>
> 
> 
>
> then the ModuleID field in the ModuleSignature table ends up as:
> OurModuleName.OLD_MODULE_GUID
>
> If we remove the module GUID so it looks like:
>
>  
> 
>
> then the ModuleID field in the ModuleSignature table ends up as
> OurModuleName.PACKAGE_GUID.
>
> Since older versions of our product are already installed with the
> ModuleID of OurModuleName.OLD_MODULE_GUID, if a customer installs a
> new version of our product that has a ModuleID of
> OurModuleName.PACKAGE_GUID, won't the installer think it's a
> different, new module (rather than upgrading the old module)?
>
> A potential solution seems to be changing the Package ID to the old
> Module GUID so that the ModuleID ends up the same in newer versions,
> but I'm not sure where else the Package ID gets used (i.e. if doing
> this would cause even more problems).
>
> Thanks!
> John
>
> On Fri, Sep 24, 2010 at 3:02 PM, Christopher Painter
>  wrote:
>> Merge modules are recognized by their Module Signature.  I know of no purpose
>> for the Summary Information Package Code other then it must have one becaues
>> it's an MSI database.  I  know of no harm in changing it and this is probably
>> the reason why the schema no longer requires it.
>>
>> Christopher Painter, Author of Deployment Engineering Blog
>> Have a hot tip, know a secret or read a really good thread that deserves
>> attention? E-Mail Me
>>
>>
>>
>> - Original Message 
>> From: John Fry 
>> To: wix-users@lists.sourceforge.net
>> Sent: Fri, September 24, 2010 4:25:47 PM
>> Subject: [WiX-users] Wix 3.5 Module GUID Deprecated
>>
>> Hello,
>>
>> We’re upgrading our build system from Wix 2.0 to 3.5 and are now
>> getting the following warning:
>>
>> warning CNDL1088 : The Module/@Guid attribute is deprecated merge
>> modules use their package code as the modularization guid.  Use the
>> Package/@Id attribute instead.
>>
>> We currently specify both a module GUID and a package ID – can we just
>> remove the module GUID in future releases? Our “finished product” is a
>> merge module that gets included in several different products, and we
>> want to ensure that it’s recognized properly e.g. if a user installs a
>> new product with an upgraded version of our service packaged in.
>>
>> Also, we’re currently hardcoding a GUID as the package ID and keeping
>> it the same from release to release, is this correct? I didn’t see any
>> other ID that was staying constant between releases that would
>> associate a new version of our module with an older one.
>>
>> Any advice would be appreciated.
>>
>> Thanks!
>> John Fry
>>
>> 
---

[WiX-users] Square brackets in variable value

2010-09-24 Thread John Fry

Hi,

As part of an upgrade from Wix 2 to 3.5 the following is no longer working:




as it gives: error LGHT0204 : ICE03: Invalid format string; Table:
Environment, Column: Value, Key(s): OURPROD_TGT_PATH.GUID_HERE

I found posts online saying to escape the brackets so [ becomes [\[]
and ] becomes [\]]. Doing so got rid of the error, but then the value
ends up being escaped in the MSI; if you view it in orca you see the
value is "[\[]%CommonProgramFiles[\]]\path\to\folder;[~]" which
includes the escaping. The value we want is
"[%CommonProgramFiles]\path\to\folder;[~]" but if we don't escape it
we get the above error.

Interestingly, it works fine if the value is hardcoded rather than
being a variable, so the following:



produces the correct value in the MSI:

[%CommonProgramFiles]\path\to\folder;[~]

Does anyone know why this doesn't work if the value comes from a
variable? Do we need to escape the variable somehow so that Wix just
puts the exact text of the variable into the environment table? We use
this variable in a couple other places and it's set conditionally
based on build parameters so it would be nice to not have to hardcode
it everywhere.

Thanks!
John Fry

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread John Fry

Thanks! I replaced the Package ID with the old Module GUID and deleted
the Module GUID, and Wix seems to have kept the same module signature.
It looks like the Package ID wasn't being used anywhere as long as
there was a Module GUID so it doesn't matter that the Package ID
changed.

Thanks again!
John

On Fri, Sep 24, 2010 at 4:01 PM, Christopher Painter
 wrote:
> Checkout an example at:
>
> http://iswix.codeplex.com/SourceControl/changeset/view/53668#841593
>
> This module ends up having a signature of:
>
> IsWiXAddInMM.68061036_B1D9_4092_AD3B_DC569F3DD183 1033 1.0.0.0
>
> and a package code of:  {68061036-B1D9-4092-AD3B-DC569F3DD183} every time it
> builds.   This has no adverse side effects.
>
>
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: Christopher Painter 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Fri, September 24, 2010 5:53:28 PM
> Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Yes, what I was trying to say is  that WiX v3 uses the Module Id along with 
> the
> Package Id to create the Module.GUID you see in the ModuleSignature table.
> Just build your old, tweak it up and build the new and you'll see they are the
> same in Orca if you did it right.
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: John Fry 
> To: General discussion for Windows Installer XML toolset.
> 
> Sent: Fri, September 24, 2010 5:26:22 PM
> Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Won't removing the module GUID change the module signature?
>
> If we have the following lines:
>
> 
> 
>
> then the ModuleID field in the ModuleSignature table ends up as:
> OurModuleName.OLD_MODULE_GUID
>
> If we remove the module GUID so it looks like:
>
>  
> 
>
> then the ModuleID field in the ModuleSignature table ends up as
> OurModuleName.PACKAGE_GUID.
>
> Since older versions of our product are already installed with the
> ModuleID of OurModuleName.OLD_MODULE_GUID, if a customer installs a
> new version of our product that has a ModuleID of
> OurModuleName.PACKAGE_GUID, won't the installer think it's a
> different, new module (rather than upgrading the old module)?
>
> A potential solution seems to be changing the Package ID to the old
> Module GUID so that the ModuleID ends up the same in newer versions,
> but I'm not sure where else the Package ID gets used (i.e. if doing
> this would cause even more problems).
>
> Thanks!
> John
>
> On Fri, Sep 24, 2010 at 3:02 PM, Christopher Painter
>  wrote:
>> Merge modules are recognized by their Module Signature.  I know of no purpose
>> for the Summary Information Package Code other then it must have one becaues
>> it's an MSI database.  I  know of no harm in changing it and this is probably
>> the reason why the schema no longer requires it.
>>
>> Christopher Painter, Author of Deployment Engineering Blog
>> Have a hot tip, know a secret or read a really good thread that deserves
>> attention? E-Mail Me
>>
>>
>>
>> - Original Message 
>> From: John Fry 
>> To: wix-users@lists.sourceforge.net
>> Sent: Fri, September 24, 2010 4:25:47 PM
>> Subject: [WiX-users] Wix 3.5 Module GUID Deprecated
>>
>> Hello,
>>
>> We’re upgrading our build system from Wix 2.0 to 3.5 and are now
>> getting the following warning:
>>
>> warning CNDL1088 : The Module/@Guid attribute is deprecated merge
>> modules use their package code as the modularization guid.  Use the
>> Package/@Id attribute instead.
>>
>> We currently specify both a module GUID and a package ID – can we just
>> remove the module GUID in future releases? Our “finished product” is a
>> merge module that gets included in several different products, and we
>> want to ensure that it’s recognized properly e.g. if a user installs a
>> new product with an upgraded version of our service packaged in.
>>
>> Also, we’re currently hardcoding a GUID as the package ID and keeping
>> it the same from release to release, is this correct? I didn’t see any
>> other ID that was staying constant between releases that would
>> associate a new version of our module with an older one.
>>
>> Any advice would be appreciated.
>>
>> Thanks!
>> John Fry
>>
>> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>>
>>
>> --

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread Christopher Painter

Checkout an example at:

http://iswix.codeplex.com/SourceControl/changeset/view/53668#841593

This module ends up having a signature of:

IsWiXAddInMM.68061036_B1D9_4092_AD3B_DC569F3DD183 1033 1.0.0.0

and a package code of:  {68061036-B1D9-4092-AD3B-DC569F3DD183} every time it 
builds.   This has no adverse side effects.


 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: Christopher Painter 
To: General discussion for Windows Installer XML toolset. 

Sent: Fri, September 24, 2010 5:53:28 PM
Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Yes, what I was trying to say is  that WiX v3 uses the Module Id along with the 
Package Id to create the Module.GUID you see in the ModuleSignature table.   
Just build your old, tweak it up and build the new and you'll see they are the 
same in Orca if you did it right. 
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: John Fry 
To: General discussion for Windows Installer XML toolset. 

Sent: Fri, September 24, 2010 5:26:22 PM
Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Won't removing the module GUID change the module signature?

If we have the following lines:




then the ModuleID field in the ModuleSignature table ends up as:
OurModuleName.OLD_MODULE_GUID

If we remove the module GUID so it looks like:

 


then the ModuleID field in the ModuleSignature table ends up as
OurModuleName.PACKAGE_GUID.

Since older versions of our product are already installed with the
ModuleID of OurModuleName.OLD_MODULE_GUID, if a customer installs a
new version of our product that has a ModuleID of
OurModuleName.PACKAGE_GUID, won't the installer think it's a
different, new module (rather than upgrading the old module)?

A potential solution seems to be changing the Package ID to the old
Module GUID so that the ModuleID ends up the same in newer versions,
but I'm not sure where else the Package ID gets used (i.e. if doing
this would cause even more problems).

Thanks!
John

On Fri, Sep 24, 2010 at 3:02 PM, Christopher Painter
 wrote:
> Merge modules are recognized by their Module Signature.  I know of no purpose
> for the Summary Information Package Code other then it must have one becaues
> it's an MSI database.  I  know of no harm in changing it and this is probably
> the reason why the schema no longer requires it.
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: John Fry 
> To: wix-users@lists.sourceforge.net
> Sent: Fri, September 24, 2010 4:25:47 PM
> Subject: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Hello,
>
> We’re upgrading our build system from Wix 2.0 to 3.5 and are now
> getting the following warning:
>
> warning CNDL1088 : The Module/@Guid attribute is deprecated merge
> modules use their package code as the modularization guid.  Use the
> Package/@Id attribute instead.
>
> We currently specify both a module GUID and a package ID – can we just
> remove the module GUID in future releases? Our “finished product” is a
> merge module that gets included in several different products, and we
> want to ensure that it’s recognized properly e.g. if a user installs a
> new product with an upgraded version of our service packaged in.
>
> Also, we’re currently hardcoding a GUID as the package ID and keeping
> it the same from release to release, is this correct? I didn’t see any
> other ID that was staying constant between releases that would
> associate a new version of our module with an older one.
>
> Any advice would be appreciated.
>
> Thanks!
> John Fry
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Start uncovering the many advantages of virtual appliances
and start using them to

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread Christopher Painter

Yes, what I was trying to say is  that WiX v3 uses the Module Id along with the 
Package Id to create the Module.GUID you see in the ModuleSignature table.   
Just build your old, tweak it up and build the new and you'll see they are the 
same in Orca if you did it right. 
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: John Fry 
To: General discussion for Windows Installer XML toolset. 

Sent: Fri, September 24, 2010 5:26:22 PM
Subject: Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Won't removing the module GUID change the module signature?

If we have the following lines:




then the ModuleID field in the ModuleSignature table ends up as:
OurModuleName.OLD_MODULE_GUID

If we remove the module GUID so it looks like:

 


then the ModuleID field in the ModuleSignature table ends up as
OurModuleName.PACKAGE_GUID.

Since older versions of our product are already installed with the
ModuleID of OurModuleName.OLD_MODULE_GUID, if a customer installs a
new version of our product that has a ModuleID of
OurModuleName.PACKAGE_GUID, won't the installer think it's a
different, new module (rather than upgrading the old module)?

A potential solution seems to be changing the Package ID to the old
Module GUID so that the ModuleID ends up the same in newer versions,
but I'm not sure where else the Package ID gets used (i.e. if doing
this would cause even more problems).

Thanks!
John

On Fri, Sep 24, 2010 at 3:02 PM, Christopher Painter
 wrote:
> Merge modules are recognized by their Module Signature.  I know of no purpose
> for the Summary Information Package Code other then it must have one becaues
> it's an MSI database.  I  know of no harm in changing it and this is probably
> the reason why the schema no longer requires it.
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: John Fry 
> To: wix-users@lists.sourceforge.net
> Sent: Fri, September 24, 2010 4:25:47 PM
> Subject: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Hello,
>
> We’re upgrading our build system from Wix 2.0 to 3.5 and are now
> getting the following warning:
>
> warning CNDL1088 : The Module/@Guid attribute is deprecated merge
> modules use their package code as the modularization guid.  Use the
> Package/@Id attribute instead.
>
> We currently specify both a module GUID and a package ID – can we just
> remove the module GUID in future releases? Our “finished product” is a
> merge module that gets included in several different products, and we
> want to ensure that it’s recognized properly e.g. if a user installs a
> new product with an upgraded version of our service packaged in.
>
> Also, we’re currently hardcoding a GUID as the package ID and keeping
> it the same from release to release, is this correct? I didn’t see any
> other ID that was staying constant between releases that would
> associate a new version of our module with an older one.
>
> Any advice would be appreciated.
>
> Thanks!
> John Fry
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/list

[WiX-users] Checking for other products

2010-09-24 Thread ldykes

Hi all,

I want to terminate the installation of a product unless 
there is a recent version of a different product already 
installed, so I defined an Upgrade element and a 
Condition thus:


 



.
.

  

.
.   

   REQUIREDBINARIES

.
.

This didn't work; the install always aborts, whether the 
required product and version are installed or not.

I thought it might be a sequencing problem, so I got rid 
of the Condition and defined a CustomAction and 
sequenced it sequenced it so it should come some time 
after FindRelatedProducts, i.e.,


.
.

.
.
  
 (NOT REQUIREDBINARIES)
  
.
.

Same result.

I'm kind of fuzzy about the evaluation of strings as 
conditions, but something analagous has worked for me 
when the Upgrade is the product currently being 
installed.

Assisistance appreciated.

Regards,
Lee


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] custom action to delete file on uninstallation

2010-09-24 Thread dB .

If everything else fails, there's a Win32_DeleteFile CA in 
http://msiext.codeplex.com/. 

dB. @ dblock.org 
Moscow|Geneva|Seattle|New York


-Original Message-
From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] 
Sent: Friday, September 24, 2010 8:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] custom action to delete file on uninstallation

Hi:
Is there a custom action supplied with WIX to delete files on uninstallation 
that weren't included in components. I carn't delete the whole directory as 
some files in the directory aren't of my creating.
Any help appreciated.
Regards
Sean.
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest 
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing 
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread John Fry

Won't removing the module GUID change the module signature?

If we have the following lines:




then the ModuleID field in the ModuleSignature table ends up as:
OurModuleName.OLD_MODULE_GUID

If we remove the module GUID so it looks like:

 


then the ModuleID field in the ModuleSignature table ends up as
OurModuleName.PACKAGE_GUID.

Since older versions of our product are already installed with the
ModuleID of OurModuleName.OLD_MODULE_GUID, if a customer installs a
new version of our product that has a ModuleID of
OurModuleName.PACKAGE_GUID, won't the installer think it's a
different, new module (rather than upgrading the old module)?

A potential solution seems to be changing the Package ID to the old
Module GUID so that the ModuleID ends up the same in newer versions,
but I'm not sure where else the Package ID gets used (i.e. if doing
this would cause even more problems).

Thanks!
John

On Fri, Sep 24, 2010 at 3:02 PM, Christopher Painter
 wrote:
> Merge modules are recognized by their Module Signature.  I know of no purpose
> for the Summary Information Package Code other then it must have one becaues
> it's an MSI database.  I  know of no harm in changing it and this is probably
> the reason why the schema no longer requires it.
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
>
> - Original Message 
> From: John Fry 
> To: wix-users@lists.sourceforge.net
> Sent: Fri, September 24, 2010 4:25:47 PM
> Subject: [WiX-users] Wix 3.5 Module GUID Deprecated
>
> Hello,
>
> We’re upgrading our build system from Wix 2.0 to 3.5 and are now
> getting the following warning:
>
> warning CNDL1088 : The Module/@Guid attribute is deprecated merge
> modules use their package code as the modularization guid.  Use the
> Package/@Id attribute instead.
>
> We currently specify both a module GUID and a package ID – can we just
> remove the module GUID in future releases? Our “finished product” is a
> merge module that gets included in several different products, and we
> want to ensure that it’s recognized properly e.g. if a user installs a
> new product with an upgraded version of our service packaged in.
>
> Also, we’re currently hardcoding a GUID as the package ID and keeping
> it the same from release to release, is this correct? I didn’t see any
> other ID that was staying constant between releases that would
> associate a new version of our module with an older one.
>
> Any advice would be appreciated.
>
> Thanks!
> John Fry
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread Christopher Painter

Merge modules are recognized by their Module Signature.  I know of no purpose 
for the Summary Information Package Code other then it must have one becaues 
it's an MSI database.  I  know of no harm in changing it and this is probably 
the reason why the schema no longer requires it.
 
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me



- Original Message 
From: John Fry 
To: wix-users@lists.sourceforge.net
Sent: Fri, September 24, 2010 4:25:47 PM
Subject: [WiX-users] Wix 3.5 Module GUID Deprecated

Hello,

We’re upgrading our build system from Wix 2.0 to 3.5 and are now
getting the following warning:

warning CNDL1088 : The Module/@Guid attribute is deprecated merge
modules use their package code as the modularization guid.  Use the
Package/@Id attribute instead.

We currently specify both a module GUID and a package ID – can we just
remove the module GUID in future releases? Our “finished product” is a
merge module that gets included in several different products, and we
want to ensure that it’s recognized properly e.g. if a user installs a
new product with an upgraded version of our service packaged in.

Also, we’re currently hardcoding a GUID as the package ID and keeping
it the same from release to release, is this correct? I didn’t see any
other ID that was staying constant between releases that would
associate a new version of our module with an older one.

Any advice would be appreciated.

Thanks!
John Fry

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix 3.5 Module GUID Deprecated

2010-09-24 Thread John Fry

Hello,

We’re upgrading our build system from Wix 2.0 to 3.5 and are now
getting the following warning:

warning CNDL1088 : The Module/@Guid attribute is deprecated merge
modules use their package code as the modularization guid.  Use the
Package/@Id attribute instead.

We currently specify both a module GUID and a package ID – can we just
remove the module GUID in future releases? Our “finished product” is a
merge module that gets included in several different products, and we
want to ensure that it’s recognized properly e.g. if a user installs a
new product with an upgraded version of our service packaged in.

Also, we’re currently hardcoding a GUID as the package ID and keeping
it the same from release to release, is this correct? I didn’t see any
other ID that was staying constant between releases that would
associate a new version of our module with an older one.

Any advice would be appreciated.

Thanks!
John Fry

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Per-user installation with elevation prompt

2010-09-24 Thread Bruce Cran

Hi,

I'm trying to do a major upgrade of a product which was installed
per-user but which installed files into ProgramFilesFolder. The
previous installer was authored using the Visual Studio Deployment
project and defaulted to a perUser installation (with the option of
installing perMachine) - but when Windows Installer tries to copy
files, an elevation prompt is displayed and installation allowed to
continue. I've tried to do something similar with the new installer
which is written using WiX 3.5 but I just get a permission denied error
if I try and do a perUser installation which installs to
ProgramFilesFolder - as I know I should do!  As far as I know I can't
make the new MSI perMachine because FindRelatedProducts doesn't work
between perUser and perMachine packages.

In case it matters I'm scheduling the upgrade after InstallExecute so
that certain files aren't deleted, which would happen if the previous
installation was uninstalled first. 
Is there a way to make the upgrade work?

-- 
Bruce Cran

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action

2010-09-24 Thread Wilson, Phil

Setting MigrateFeatureStates means that you want to do an upgrade where the 
features that get installed are exactly the same as the features that are 
already installed. It usually doesn't make sense to set that and then set 
features in a UI dialog. 

Phil Wilson 

-Original Message-
From: fiordean dacian [mailto:dfiord...@yahoo.com] 
Sent: Friday, September 24, 2010 8:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action

Hi

I made a mistake when I copied the "FindRelatedProducts" in my initial email. 
Here is the correct text from the verbose log (we see the property 
WIX_UPGRADE_DETECTED being correctly set to my initial installed product GUID)

Action start 16:44:52: FindRelatedProducts.
FindRelatedProducts: Found application: {C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}
MSI (c) (38:4C) [16:44:52:289]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED 
property. Its value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
MSI (c) (38:4C) [16:44:52:289]: PROPERTY CHANGE: Adding MIGRATE property. Its 
value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
Action ended 16:44:52: FindRelatedProducts. Return value 1.


Thanks.




--- On Fri, 9/24/10, fiordean dacian  wrote:

From: fiordean dacian 
Subject: Major upgrade, MigrateFeatureStates & custom action
To: wix-users@lists.sourceforge.net
Date: Friday, September 24, 2010, 5:39 PM

Hello

I have a couple of problems with my installer on a major upgrade. I'm using Wix 
3.5.

My installer has 2 features and I use the MajorUpgrade element available with 
Wix 3.5 to do my major upgrade. 

Here is what I did:

Product Code and version changed within the new installer.
As I use "MajorUpgrade" element, I removed my explicit declaration of 
RemovedExistingProducts as "MajorUpgrade" seems it schedules it. From the 
documentation, I understand "MajorUpgrade" schedules also MigrateFeatureStates 
and this is good as I want to take advantage of this MSI feature (more below).
ALLUSERS property is set to 1 in both installers.

Here is what I get:

Install the first version of the product which installs fine; then launch the 
installer for the newer version to perform an upgrade.
I do a verbose log and I get a
 couple of strange things:

Action 15:29:09: FindRelatedProducts. Searching for related applications
Action start 15:29:09: FindRelatedProducts.
FindRelatedProducts: Found application: {C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}
MSI (c) (C8:A0) [15:29:09:708]: PROPERTY CHANGE: Adding PREVFOUND property. Its 
value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
Action ended 15:29:09: FindRelatedProducts. Return value 1.

...

MSI (c) (C8:A0) [15:29:09:817]: Doing action: MigrateFeatureStates
Action 15:29:09: MigrateFeatureStates. Migrating feature states from related 
applications
Action start 15:29:09: MigrateFeatureStates.
Action ended 15:29:09: MigrateFeatureStates. Return value 0.

...

Plenty of 

Disallowing installation of component: {83D1BFA5-5703-43F2-AB56-BB0630B8E921} 
since the same component with higher versioned keyfile exists

...

My 2 features are absent from the installation
 

MSI (s) (5C:FC) [15:29:23:721]: Feature: FullInstallation; Installed: Absent;   
Request: Null;   Action: Null

MSI (s) (5C:FC) [15:29:23:721]: Feature: DcServer; Installed: Absent;   
Request: Null;   Action: Null



This explains why no upgrade is done, the question is why they are absent? I 
select them through a UI which changed like below compared to the previous 
version of my installer:

Old version:


    


New version:


    



Nothing is removed like for a major upgrade (and it says this is maintainance 
or uninstall):

MSI (s) (5C:FC) [15:29:23:736]: Doing action: RemoveExistingProducts
Action 15:29:23: RemoveExistingProducts. Removing applications
Action start 15:29:23: RemoveExistingProducts.
MSI (s) (5C:FC) [15:29:23:736]: Skipping RemoveExistingProducts action: current 
configuration
 is maintenance mode or an uninstall
Action ended 15:29:23: RemoveExistingProducts. Return value 0.

So it looks like MigrateFeatureStates doesn't detect the feature state of the 
current installation to set it for the new version of the installer.

Here is the Upgrade table for the initial installer:

Upgrade code   Version 
Attributes   ActionProperty
{CB09E96B-19D6-439C-9A40-68143559032A} 6.6.0         258      
 NEWERFOUND
{64EF24E1-8FC8-44C0-B9AD-981D638B4596}    6.5.0    6.6.0  256       
PREVFOUND

And here is the Upgrade table for the new installer:

{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   1 WIX_UPGRADE_DETECTED
{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   2 WIX_DOWNGRADE_DETECTED

Anyone has an idea what am I doing wrong?

Thanks!











  


  
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify ap

Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action

2010-09-24 Thread fiordean dacian

Hi

I made a mistake when I copied the "FindRelatedProducts" in my initial email. 
Here is the correct text from the verbose log (we see the property 
WIX_UPGRADE_DETECTED being correctly set to my initial installed product GUID)

Action start 16:44:52: FindRelatedProducts.
FindRelatedProducts: Found application: {C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}
MSI (c) (38:4C) [16:44:52:289]: PROPERTY CHANGE: Adding WIX_UPGRADE_DETECTED 
property. Its value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
MSI (c) (38:4C) [16:44:52:289]: PROPERTY CHANGE: Adding MIGRATE property. Its 
value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
Action ended 16:44:52: FindRelatedProducts. Return value 1.


Thanks.




--- On Fri, 9/24/10, fiordean dacian  wrote:

From: fiordean dacian 
Subject: Major upgrade, MigrateFeatureStates & custom action
To: wix-users@lists.sourceforge.net
Date: Friday, September 24, 2010, 5:39 PM

Hello

I have a couple of problems with my installer on a major upgrade. I'm using Wix 
3.5.

My installer has 2 features and I use the MajorUpgrade element available with 
Wix 3.5 to do my major upgrade. 

Here is what I did:

Product Code and version changed within the new installer.
As I use "MajorUpgrade" element, I removed my explicit declaration of 
RemovedExistingProducts as "MajorUpgrade" seems it schedules it. From the 
documentation, I understand "MajorUpgrade" schedules also MigrateFeatureStates 
and this is good as I want to take advantage of this MSI feature (more below).
ALLUSERS property is set to 1 in both installers.

Here is what I get:

Install the first version of the product which installs fine; then launch the 
installer for the newer version to perform an upgrade.
I do a verbose log and I get a
 couple of strange things:

Action 15:29:09: FindRelatedProducts. Searching for related applications
Action start 15:29:09: FindRelatedProducts.
FindRelatedProducts: Found application: {C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}
MSI (c) (C8:A0) [15:29:09:708]: PROPERTY CHANGE: Adding PREVFOUND property. Its 
value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
Action ended 15:29:09: FindRelatedProducts. Return value 1.

...

MSI (c) (C8:A0) [15:29:09:817]: Doing action: MigrateFeatureStates
Action 15:29:09: MigrateFeatureStates. Migrating feature states from related 
applications
Action start 15:29:09: MigrateFeatureStates.
Action ended 15:29:09: MigrateFeatureStates. Return value 0.

...

Plenty of 

Disallowing installation of component: {83D1BFA5-5703-43F2-AB56-BB0630B8E921} 
since the same component with higher versioned keyfile exists

...

My 2 features are absent from the installation
 

MSI (s) (5C:FC) [15:29:23:721]: Feature: FullInstallation; Installed: Absent;   
Request: Null;   Action: Null

MSI (s) (5C:FC) [15:29:23:721]: Feature: DcServer; Installed: Absent;   
Request: Null;   Action: Null



This explains why no upgrade is done, the question is why they are absent? I 
select them through a UI which changed like below compared to the previous 
version of my installer:

Old version:


    


New version:


    



Nothing is removed like for a major upgrade (and it says this is maintainance 
or uninstall):

MSI (s) (5C:FC) [15:29:23:736]: Doing action: RemoveExistingProducts
Action 15:29:23: RemoveExistingProducts. Removing applications
Action start 15:29:23: RemoveExistingProducts.
MSI (s) (5C:FC) [15:29:23:736]: Skipping RemoveExistingProducts action: current 
configuration
 is maintenance mode or an uninstall
Action ended 15:29:23: RemoveExistingProducts. Return value 0.

So it looks like MigrateFeatureStates doesn't detect the feature state of the 
current installation to set it for the new version of the installer.

Here is the Upgrade table for the initial installer:

Upgrade code   Version 
Attributes   ActionProperty
{CB09E96B-19D6-439C-9A40-68143559032A} 6.6.0         258      
 NEWERFOUND
{64EF24E1-8FC8-44C0-B9AD-981D638B4596}    6.5.0    6.6.0  256       
PREVFOUND

And here is the Upgrade table for the new installer:

{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   1 WIX_UPGRADE_DETECTED
{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   2 WIX_DOWNGRADE_DETECTED

Anyone has an idea what am I doing wrong?

Thanks!











  


  
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat.exe

2010-09-24 Thread Castro, Edwin G. (Hillsboro)

No. But you can specify the variable in the *.wixproj file. Set the 
DefineConstants element (or add to it). You'll need something like the 
following:

VariableName=Path\To\SourceDir

Please note that the debug configuration will likely have Debug defined in 
DefineConstants:

Debug;VariableName=Path\To\SourceDir

Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

> -Original Message-
> From: David Amey [mailto:da...@creative-engine.co.uk]
> Sent: Thursday, September 23, 2010 2:27 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Heat.exe
> 
> Thankyou Bob,
> 
> This now works fine!
> 
> Is it possible to set the variable within the main.wxs file so that candle 
> picks
> up the value though? Sorry if this is a stupid question!
> 
> 
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: 23 September 2010 01:32
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Heat.exe
> 
>   On 22-Sep-10 18:11, David Amey wrote:
> > Basically I'm using heat to harvest a folder, simples. However I'm
> using the "-var" property in the command line (to replace the "sourceDir" in
> the output component's source attribute), using a variable declared in the
> main.wxs. This replaces the "sourceDir" as expected, but when it comes to
> candle to compile , it flags an error as if the variable isn't populated.
> 
> You have to define the values for any preprocessor variables you use in your
> source code. How you do that depends on how you run the compiler (e.g., -d
> on the command line or DefineConstants in MSBuild) but both are
> documented in WiX.chm.
> 
> --
> sig://boB
> http://joyofsetup.com/
> 
> 
> 
> --
> Start uncovering the many advantages of virtual appliances and start using
> them to simplify application deployment and accelerate your shift to cloud
> computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> --
> Start uncovering the many advantages of virtual appliances and start using
> them to simplify application deployment and accelerate your shift to cloud
> computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Major upgrade, MigrateFeatureStates & custom action

2010-09-24 Thread fiordean dacian

Hello

I have a couple of problems with my installer on a major upgrade. I'm using Wix 
3.5.

My installer has 2 features and I use the MajorUpgrade element available with 
Wix 3.5 to do my major upgrade. 

Here is what I did:

Product Code and version changed within the new installer.
As I use "MajorUpgrade" element, I removed my explicit declaration of 
RemovedExistingProducts as "MajorUpgrade" seems it schedules it. From the 
documentation, I understand "MajorUpgrade" schedules also MigrateFeatureStates 
and this is good as I want to take advantage of this MSI feature (more below).
ALLUSERS property is set to 1 in both installers.

Here is what I get:

Install the first version of the product which installs fine; then launch the 
installer for the newer version to perform an upgrade.
I do a verbose log and I get a couple of strange things:

Action 15:29:09: FindRelatedProducts. Searching for related applications
Action start 15:29:09: FindRelatedProducts.
FindRelatedProducts: Found application: {C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}
MSI (c) (C8:A0) [15:29:09:708]: PROPERTY CHANGE: Adding PREVFOUND property. Its 
value is '{C0C6FEAB-9024-481E-BB4F-7A54EC0BA765}'.
Action ended 15:29:09: FindRelatedProducts. Return value 1.

...

MSI (c) (C8:A0) [15:29:09:817]: Doing action: MigrateFeatureStates
Action 15:29:09: MigrateFeatureStates. Migrating feature states from related 
applications
Action start 15:29:09: MigrateFeatureStates.
Action ended 15:29:09: MigrateFeatureStates. Return value 0.

...

Plenty of 

Disallowing installation of component: {83D1BFA5-5703-43F2-AB56-BB0630B8E921} 
since the same component with higher versioned keyfile exists

...

My 2 features are absent from the installation 

MSI (s) (5C:FC) [15:29:23:721]: Feature: FullInstallation; Installed: Absent;   
Request: Null;   Action: Null

MSI (s) (5C:FC) [15:29:23:721]: Feature: DcServer; Installed: Absent;   
Request: Null;   Action: Null



This explains why no upgrade is done, the question is why they are absent? I 
select them through a UI which changed like below compared to the previous 
version of my installer:

Old version:


    


New version:


    



Nothing is removed like for a major upgrade (and it says this is maintainance 
or uninstall):

MSI (s) (5C:FC) [15:29:23:736]: Doing action: RemoveExistingProducts
Action 15:29:23: RemoveExistingProducts. Removing applications
Action start 15:29:23: RemoveExistingProducts.
MSI (s) (5C:FC) [15:29:23:736]: Skipping RemoveExistingProducts action: current 
configuration is maintenance mode or an uninstall
Action ended 15:29:23: RemoveExistingProducts. Return value 0.

So it looks like MigrateFeatureStates doesn't detect the feature state of the 
current installation to set it for the new version of the installer.

Here is the Upgrade table for the initial installer:

Upgrade code   Version 
Attributes   ActionProperty
{CB09E96B-19D6-439C-9A40-68143559032A} 6.6.0         258       
NEWERFOUND
{64EF24E1-8FC8-44C0-B9AD-981D638B4596}    6.5.0    6.6.0  256       
PREVFOUND

And here is the Upgrade table for the new installer:

{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   1 WIX_UPGRADE_DETECTED
{CB09E96B-19D6-439C-9A40-68143559032A}    6.7.0   2 WIX_DOWNGRADE_DETECTED

Anyone has an idea what am I doing wrong?

Thanks!





  
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error in Custom Action

2010-09-24 Thread Alexander Kozlenko

Hello Yan, thanks for suggestion. I don't use Return attribute at all. As
described in documentation "check" value is default. For this moment I use
defined in WiX source file custom action with Type 19:

and invoke it from my custom action if some error occurred with
Session.DoAction method. This helps me to block installation on error in
current action.

-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net] 
Sent: Friday, September 24, 2010 4:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Error in Custom Action

Can this be the case that you have Return='ignore' in the custom action
definition? I suppose in this case returning ActionResult.Failure will be
ignored.

-- Yan

-Original Message-
From: Alexander Kozlenko [mailto:alexander.kozle...@hotmail.com]
Sent: Thursday, September 23, 2010 01:50
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Error in Custom Action

What is the best way to block installation on error in Custom Action? I used
ActionResult.Failure result value but installation continues to install.
Only throwing an exception of type InstallerException helps me to block
installation. Thanks.

Alexander Kozlenko


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error in Custom Action

2010-09-24 Thread Yan Sklyarenko

Can this be the case that you have Return='ignore' in the custom action
definition? I suppose in this case returning ActionResult.Failure will
be ignored.

-- Yan

-Original Message-
From: Alexander Kozlenko [mailto:alexander.kozle...@hotmail.com] 
Sent: Thursday, September 23, 2010 01:50
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Error in Custom Action

What is the best way to block installation on error in Custom Action? I
used
ActionResult.Failure result value but installation continues to install.
Only throwing an exception of type InstallerException helps me to block
installation. Thanks.

 

Alexander Kozlenko


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] call custom action after another custom action is finished

2010-09-24 Thread bryan rasmussen

Actually, Just found a compiler for Ruby so I suppose I will try with
that to see if I can get the full application installed.

Thanks,
Bryan Rasmussen

On Fri, Sep 24, 2010 at 2:36 PM, bryan rasmussen
 wrote:
> "Pally Sandher"  wrote:
>
>> Use a bootstrapper to install Ruby before your installer runs.
>> Concurrent installations are highly dangerous & just as unsupported.
>
> Ok, but Ruby's 'installer' is an .exe, not an MSI,  should I still try
> to run a bootstrapper (never tried before) or can I get by with
> running first the exe, waiting till it exits and then running my
> script which will just check that the system has ruby and then run
> some various  gem installs.
>
> Thanks,
> Bryan Rasmussen
>
>> -Original Message-
>> From: bryan rasmussen [mailto:rasmussen.br...@gmail.com]
>> Sent: 24 September 2010 12:46
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] call custom action after another custom action
>> isfinished
>>
>> Hi,
>>
>> I am running a custom action that is an exe saved in my installed
>> directory. That custom action action should allow the user to install
>> Ruby. When the Installer is finished I want to run a custom action that
>> is a jscript
>>
>> How do I do that? I am supposing something like
>>
>>  >      Action="JS_I_Run"
>>      After="ID_OF_RUBY_INSTALLER" />
>>
>> where Action is the id of the javascirpt and After is the id of the
>> installer. Does this make sense or would you recommend another way to do
>> it?
>>
>> Thanks,
>> Bryan Rasmussen
>

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 3.6 Bootstrapper Visual Studio Project

2010-09-24 Thread juergstaub


Anyone? 
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-6-Bootstrapper-Visual-Studio-Project-tp5548437p5566641.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] call custom action after another custom action is finished

2010-09-24 Thread bryan rasmussen

"Pally Sandher"  wrote:

> Use a bootstrapper to install Ruby before your installer runs.
> Concurrent installations are highly dangerous & just as unsupported.

Ok, but Ruby's 'installer' is an .exe, not an MSI,  should I still try
to run a bootstrapper (never tried before) or can I get by with
running first the exe, waiting till it exits and then running my
script which will just check that the system has ruby and then run
some various  gem installs.

Thanks,
Bryan Rasmussen

> -Original Message-
> From: bryan rasmussen [mailto:rasmussen.br...@gmail.com]
> Sent: 24 September 2010 12:46
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] call custom action after another custom action
> isfinished
>
> Hi,
>
> I am running a custom action that is an exe saved in my installed
> directory. That custom action action should allow the user to install
> Ruby. When the Installer is finished I want to run a custom action that
> is a jscript
>
> How do I do that? I am supposing something like
>
>        Action="JS_I_Run"
>      After="ID_OF_RUBY_INSTALLER" />
>
> where Action is the id of the javascirpt and After is the id of the
> installer. Does this make sense or would you recommend another way to do
> it?
>
> Thanks,
> Bryan Rasmussen

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] custom action to delete file on uninstallation

2010-09-24 Thread Theo Landman

  I would suggest the use of the   wix 
element provided you know the (partial) name of the file(s) that you 
want to have removed. The On="uninstall" will ensure that the remove 
only happens if the parent component is removed.
Theo

Op 24-9-2010 14:03, Sean Farrow schreef:
> Hi:
> Is there a custom action supplied with WIX to delete files on uninstallation 
> that weren't included in components. I carn't delete the whole directory as 
> some files in the directory aren't of my creating.
> Any help appreciated.
> Regards
> Sean.
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps&  games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


-- 

Never argue with idiots. They drag you down to their level, and then
beat you with experience. — Dilbert 


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] handling the existance of multiple versions in an installation

2010-09-24 Thread Sean Farrow

Hi:
I am writing an installation that requires a product to be installed before 
installing my product.
There can be multiple versions of the product installed on a system. There are 
multiple paths involved in detecting the product. How would people handle this 
for best practices given the following:
The registry contains the path to the main executable and all other required 
paths for each version.
Would people have version specific properties pointing to the individual paths, 
or is it better to write a table and have one property to tell me whether the 
version of the product is installed.
Any help appreciated.
Sean.
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] custom action to delete file on uninstallation

2010-09-24 Thread Sean Farrow

Hi:
Is there a custom action supplied with WIX to delete files on uninstallation 
that weren't included in components. I carn't delete the whole directory as 
some files in the directory aren't of my creating.
Any help appreciated.
Regards
Sean.
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Concatinating properties and string literals

2010-09-24 Thread Sean Farrow

Hi:
I am in the process of writing a custom action to run an executable, can I 
concatenate a property name with a string literal of my executable?
Regards
Sean.
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] call custom action after another custom action isfinished

2010-09-24 Thread Pally Sandher

Use a bootstrapper to install Ruby before your installer runs.
Concurrent installations are highly dangerous & just as unsupported.

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: bryan rasmussen [mailto:rasmussen.br...@gmail.com] 
Sent: 24 September 2010 12:46
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] call custom action after another custom action
isfinished

Hi,

I am running a custom action that is an exe saved in my installed
directory. That custom action action should allow the user to install
Ruby. When the Installer is finished I want to run a custom action that
is a jscript

How do I do that? I am supposing something like

  

where Action is the id of the javascirpt and After is the id of the
installer. Does this make sense or would you recommend another way to do
it?

Thanks,
Bryan Rasmussen


--
Nokia and AT&T present the 2010 Calling All Innovators-North America
contest Create new apps & games for the Nokia N8 for consumers in  U.S.
and Canada $10 million total in prizes - $4M cash, 500 devices, nearly
$6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and
Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] call custom action after another custom action is finished

2010-09-24 Thread bryan rasmussen

Hi,

I am running a custom action that is an exe saved in my installed
directory. That custom action action should allow the user to install
Ruby. When the Installer is finished I want to run a custom action
that is a jscript

How do I do that? I am supposing something like

  

where Action is the id of the javascirpt and After is the id of the
installer. Does this make sense or would you recommend another way to
do it?

Thanks,
Bryan Rasmussen

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to handle run from source

2010-09-24 Thread Theo Landman

  Hello,
I have all kinds of problems with a run from source installation. The 
biggest problem is the fact that the installation directory is not 
standard adjusted to the source location.


   
  
 
   
   
   
 
  
   


So for example, trying to set the ARPINSTALLLOCATION is incorrect when 
the user does a run from source:



Is there some kind of standard guideline to handle such a case? Note: I 
have been mucking around with custom actions and trying to avoid relying 
on INSTALLLOCATION as having the correct value, but things started to 
become rather complex and fragile.

Thanks,
Theo
-- 

Never argue with idiots. They drag you down to their level, and then
beat you with experience. — Dilbert 


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component installation status not affectedby condition?

2010-09-24 Thread Pally Sandher

That code looks perfectly fine so the problem must lie elsewhere.
Without being able to see your UI & Property code the only thing I can
think of is your Property is being set from one value to another value
when the checkbox is checked or unchecked. Your code is checking whether
the value is set or not so when the checkbox is unchecked it should be
unset (set it to "") if you want that Condition to evaluate to false. If
you're setting it to TRUE or FALSE you'll have to change your Condition
to test for that as Windows Installer knows nothing of boolean
variables, all Properties are just text as far as it's concerned, it's
how you use them that makes them something else.

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Mark Simonetti [mailto:ma...@opalsoftware.co.uk] 
Sent: 23 September 2010 15:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Component installation status not affectedby
condition?

  Thanks Pally.
It doesn't seem to be working for some reason, whether the initial
install has them turned off or on, I never seem to be able to change it.
Everything I've read seems to indicate that it should work so I'll look
over it all again - but in the meantime, here is what I have:



INSTALLDESKTOPSHORTCUT


 

And in the feature:


   ..
   ..
 

I must be missing something.

Thanks,
Mark.
--

On 23/09/2010 12:19, Pally Sandher wrote:
> Set Transitive="yes" on those Components -> 
> http://wix.sourceforge.net/manual-wix3/wix_xsd_component.htm
>
> Palbinder Sandher
> Software Deployment&  IT Administrator
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
>
> http://www.iesve.com
> **Design, Simulate + Innovate with the** 
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, 
> Glasgow G20 0SP Email Disclaimer
>
> -Original Message-
> From: Mark Simonetti [mailto:ma...@opalsoftware.co.uk]
> Sent: 23 September 2010 12:01
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Component installation status not affected by 
> condition?
>
>Hi,
> I have a custom dialog box that contains checkboxes to allow the user 
> to select what shortcuts they want installing.  I then have a 
> component for each shortcut with a condition inside it.
>
> 
>  
> INSTALLDESKTOPSHORTCUT
>  Name="MyApp"
> Description="My app."
> Target="[APPLICATIONFOLDER]myapp.exe"
> WorkingDirectory="APPLICATIONFOLDER" /> 
>  Name="desktopshortcut" Type="integer" Value="1" KeyPath="yes" /> 
>   
>
> The problem is if I run the setup again and change these conditions 
> (via the checkboxes) the component installation status does not 
> change.  Is their a way I can make this work or will I have to have 
> them as "features" instead?
>
> Thanks,
> Mark.
>
>
> --
> --
> --
> Start uncovering the many advantages of virtual appliances and start 
> using them to simplify application deployment and accelerate your 
> shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
>  Start uncovering the many advantages of virtual appliances 
> and start using them to simplify application deployment and accelerate

> your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>



--
Nokia and AT&T present the 2010 Calling All Innovators-North America
contest Create new apps & games for the Nokia N8 for consumers in  U.S.
and Canada $10 million total in prizes - $4M cash, 500 devices, nearly
$6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and
Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S.

Re: [WiX-users] How to author a type 50 custom action that targets abinary stream

2010-09-24 Thread Pally Sandher

What you actually want is a Type 2 Custom Action as there's no other
type which can target an executable in a Binary Stream such as

This is covered in the tutorial at
http://www.tramontana.co.hu/wix/lesson3.php#3.2

[#Foo.bin] refers to a File Id. If you're not installing Foo.bin you
can't use it.

Also you may want to fix the spelling of 'Action' in 
NOT
REMOVE="ALL" 

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com] 
Sent: 23 September 2010 19:18
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to author a type 50 custom action that targets
abinary stream

Hi

I'm trying to author a custom action that executes a command and uses a
file that's carried as a binary stream as input to the command.
Basically, I want my MSI to just execute a custom action on this file.
It won't install anything physically to disk.

I keep running into ICE03 - "Not a valid foreign key" when trying to
author the custom action

Basically what I would like to do is the following:






  NOT
REMOVE="ALL" 

My understanding is that Binary can only be used as the source, not the
target of a custom action. Is this assumuption correct?

Thanks,
Jacques

--
Nokia and AT&T present the 2010 Calling All Innovators-North America
contest Create new apps & games for the Nokia N8 for consumers in  U.S.
and Canada $10 million total in prizes - $4M cash, 500 devices, nearly
$6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and
Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] AUTO: Kenneth L Resler is out of the office. (returning 09/27/2010)

2010-09-24 Thread Kenneth . Resler


I am out of the office until 09/27/2010.

I will respond to your message when I return. If you need immeadiate assistance 
call the Sheriff's helpdesk at 612-348-7279


Note: This is an automated response to your message  "Re: [WiX-users] gui" sent 
on 9/24/2010 2:48:23 AM.

This is the only notification you will receive while this person is away.

Disclaimer: Information in this message or an attachment may be government data 
and thereby subject to the Minnesota Government Data Practices Act, Minnesota 
Statutes, Chapter 13, may be subject to attorney-client or work product 
privilege, may be confidential, privileged, proprietary, or otherwise 
protected, and the unauthorized review, copying, retransmission, or other use 
or disclosure of the information is strictly prohibited. If you are not the 
intended recipient of this message, please immediately notify the sender of the 
transmission error and then promptly delete this message from your computer 
system.   
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] gui

2010-09-24 Thread David Amey

Thankyou for this, but it's not quite the solution I need. I need the
option of the language selection, as the client needs different
languages on different machines.

Thankyou for your time!

David

-Original Message-
From: Dave Brotherstone [mailto:dav...@pobox.com] 
Sent: 23 September 2010 17:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] gui

>
> "David Amey"  wrote:
>
> > Does anyone know how I could create a drop down selection for 
> > languages, used to localise an install?
>
>
Depending on your requirements, MSI can do this for you, selecting the
language from the OS language settings - it involves embedding a
transform named .mst in your MSI - see
http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm
for details.
Note that it is (AFAIK) officially "undocumented", but is used
internally by instmsi.exe, so it's not quite so dangerous to use it.

--
Nokia and AT&T present the 2010 Calling All Innovators-North America
contest Create new apps & games for the Nokia N8 for consumers in  U.S.
and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to
Ovi Store http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] BadImageFormatException, Microsoft.Deployment.WindowsInstaller

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

[WiX-users] Square brackets in variable value

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

[WiX-users] Checking for other products

Re: [WiX-users] custom action to delete file on uninstallation

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

Re: [WiX-users] Wix 3.5 Module GUID Deprecated

[WiX-users] Wix 3.5 Module GUID Deprecated

[WiX-users] Per-user installation with elevation prompt

Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action

Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action

Re: [WiX-users] Heat.exe

[WiX-users] Major upgrade, MigrateFeatureStates & custom action

Re: [WiX-users] Error in Custom Action

Re: [WiX-users] Error in Custom Action

Re: [WiX-users] call custom action after another custom action is finished

Re: [WiX-users] Wix 3.6 Bootstrapper Visual Studio Project

Re: [WiX-users] call custom action after another custom action is finished

Re: [WiX-users] custom action to delete file on uninstallation

[WiX-users] handling the existance of multiple versions in an installation

[WiX-users] custom action to delete file on uninstallation

[WiX-users] Concatinating properties and string literals

Re: [WiX-users] call custom action after another custom action isfinished

[WiX-users] call custom action after another custom action is finished

[WiX-users] How to handle run from source

Re: [WiX-users] Component installation status not affectedby condition?

Re: [WiX-users] How to author a type 50 custom action that targets abinary stream

[WiX-users] AUTO: Kenneth L Resler is out of the office. (returning 09/27/2010)

Re: [WiX-users] gui

32 matches

Site Navigation

Mail list logo

Footer information