[WiX-users] Wix Product LaunchCondition if no RegistryValue or RegistryValue is Below 1.3.44

2012-07-22 Thread Kristjan Laane

Dear WiX Gurus

[ I need to get this to work for the Product / .msi directly, not by using
Bundle / Burn ]
[ Using WiX 3.6 ]


Fragment that Puts Registry Value into a Variable


?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
  ?include $(sys.CURRENTDIR)Deployment\Data\Statics.wxi ?
  Fragment
util:RegistrySearch Root=HKCU Key=$(var.Line.Reg.Path)
Value=Version Variable=AppAlreadyInstalled /
  /Fragment
/Wix


Main Product with Non-Working Condition

Product Name=$(var.App.Title) Manufacturer=!(loc.Company)
Language=!(loc.Lang) Id=* Version=$(var.VersionNumber)
UpgradeCode=$(var.App.UpgradeCode)   
Package Id=* InstallerVersion=300 Compressed=yes
InstallScope=$(var.App.Elevation) InstallPrivileges=limited /
DirectoryRef Id=TARGETDIR /
MajorUpgrade Schedule=afterInstallValidate
DowngradeErrorMessage=!(loc.Msi.NewerVersionInstalled) /
Property Id='DiskPrompt' Value=$(var.App.Title) Installation Media /
Media Id=1 Cabinet=Media.cab EmbedCab=yes DiskPrompt=#1 /
Icon Id=AppIcon SourceFile=$(var.Icon.Path) /

Condition Message=Newer version already installed.
![CDATA[Installed OR AppAlreadyInstalled]]
/Condition

Feature Id=ProductFeature Level=1
 ...
/Feature
/Product



Issues


I believe AppAlreadyInstalled is never set at the moment because it is
in a fragement in a different file?
Then I actually want the installation to proceed if the registry value
is NOT found at all / does not exist ?
But if it does it exist, I would like the installation to proceed only
if the registry value is below a certain value e.g. proceed with
installation only if AppAlreadyInstalled  1.3.44; this sounds hard to
achieve because the registry value is stored as a string with two full-stops
/ periods?
Note the registry check is not of the app to-be-installed, which is
already taken care of by DowngradeErrorMessage


Ta, 
Kristjan


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Pass data into localization wxl file

2012-05-02 Thread Kristjan Laane
Thanks again Bob. 

I looked at the docs for the Product element and it is not clear to me from
this URL whether the Name property, for instance, is formatted or not:
Product Element
http://wix.sourceforge.net/manual-wix3/wix_xsd_product.htm

If you know what marks a field as formatted please let me know, or if im
looking at the wrong documentation, please let me know as well. 

Ta, 
Kristjan


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: 02 May 2012 03:50
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Pass data into localization wxl file

On 28-Apr-12 17:03, Kristjan Laane wrote:
 Thanks for the info Bob - but what determines whether a localized 
 string is formatted or not?
Whether it appears in a field that's documented as being formatted. Many
fields are but some are required to be string literals and aren't formatted,
so properties aren't evaluated.

 I just tried $(sys.CURRENTDIR) and that is not evaluated either!
That is a preprocessor variable; localization strings are processed much
later than the preprocessor.

--
sig://boB
http://joyofsetup.com/



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Protect installed msi files

2012-04-30 Thread Kristjan Laane
Thanks for the info Rob! Below is what I found in the decompiled old msi, is
any of it relevant? And im afraid even if you point out what is relevant I
would not know what to do with that in Wix, do you know what I would need to
specify in Wix to make the self-healing happen for a File, Component or a
Feature? ... assuming I do not have to toggle self-healing at Product level
/ assuming self-healing is not all or nothing per msi.



CustomAction Id=ERRCA_UIANDADVERTISED Error=[VSDUIANDADVERTISED] /

Custom Action=ERRCA_UIANDADVERTISED Sequence=5ProductState=1/Custom

AdvertiseExecuteSequence
CostInitialize Sequence=800 /
CostFinalize Sequence=1000 /
Custom Action=DIRCA_TARGETDIR
Sequence=750TARGETDIR=/Custom
InstallValidate Sequence=1400 /
InstallInitialize Sequence=1500 /
CreateShortcuts Sequence=4500 /
RegisterClassInfo Sequence=4600 /
RegisterExtensionInfo Sequence=4700 /
RegisterMIMEInfo Sequence=4900 /
RegisterProgIdInfo Sequence=4800 /
PublishComponents Sequence=6200 /
PublishFeatures Sequence=6300 /
PublishProduct Sequence=6400 /
InstallFinalize Sequence=6600 /
MsiPublishAssemblies Sequence=6250 /
/AdvertiseExecuteSequence



-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 30 April 2012 01:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Protect installed msi files

Self-healing is a feature of the Windows Installer. There are several ways
to get it to kick in. The most common is through Advertised entry points.

You might decompile your old VS setup/deployment project and see if it has
things Advertised or otherwise organized differently.

You could also get a verbose log file from the repair operations and see
what was used in the past to kick off the self-healing.

On Sun, Apr 29, 2012 at 2:01 PM, Kristjan Laane
kristjan.la...@gmail.comwrote:


 Hello again

 When I used to create my msis through Visual Studio Setup and 
 Deployment projects then these installers protected the files that got
installed i.e.
 if I installed the application and then manually deleted a file (such 
 as an included image content file) then when the next time the main 
 executable was run this deleted file got restored i.e. the msi was 
 found in the Windows store and it repaired my installation.

 With Wix this protection is not present any more. I think that is 
 better for some of the (optional) files that are installed, but I 
 would like to protect some of my dll's as before - do you know how I 
 could do that in Wix?

 Atb,
 Kristjan

 P.S. My msi's were always per machine, but now are per user, so this 
 may be the difference that is actually causing the lack of protection? 
 If that is the case, is it still possible to protect certain File / 
 Component / Feature elements when deploying per user msi's ?





 --
 
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. 
 Discussions will include endpoint security, mobile security and the 
 latest in malware threats. 
 http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
virtually, Rob Mensching - http://RobMensching.com LLC

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Protect installed msi files

2012-04-30 Thread Kristjan Laane
Or perhaps something in here?:

InstallExecuteSequence
Custom Action=DIRCA_CheckFX Sequence=1 /
Custom Action=ERRCA_CANCELNEWERVERSION
Sequence=201NEWERPRODUCTFOUND AND NOT Installed/Custom
Custom Action=VSDCA_VsdLaunchConditions Sequence=399NOT
Installed/Custom
Custom Action=DIRCA_TARGETDIR
Sequence=750TARGETDIR=/Custom
LaunchConditions Sequence=400NOT
Installed/LaunchConditions
FindRelatedProducts Sequence=200 /
AppSearch Sequence=100 /
CCPSearch Sequence=500NOT Installed/CCPSearch
RMCCPSearch Sequence=600NOT Installed/RMCCPSearch
ValidateProductID Sequence=700 /
CostInitialize Sequence=800 /
FileCost Sequence=900 /
IsolateComponents
Sequence=950RedirectedDllSupport/IsolateComponents
CostFinalize Sequence=1000 /
SetODBCFolders Sequence=1100NOT Installed/SetODBCFolders
InstallValidate Sequence=1400 /
InstallInitialize Sequence=1500 /
AllocateRegistrySpace Sequence=1550NOT
Installed/AllocateRegistrySpace
ProcessComponents Sequence=1600 /
UnpublishComponents Sequence=1700 /
UnpublishFeatures Sequence=1800 /
StopServices Sequence=1900VersionNT/StopServices
DeleteServices Sequence=2000VersionNT/DeleteServices
UnregisterComPlus Sequence=2100 /
SelfUnregModules Sequence=2200 /
UnregisterTypeLibraries Sequence=2300 /
RemoveODBC Sequence=2400 /
UnregisterFonts Sequence=2500 /
RemoveRegistryValues Sequence=2600 /
UnregisterClassInfo Sequence=2700 /
UnregisterExtensionInfo Sequence=2800 /
UnregisterProgIdInfo Sequence=2900 /
UnregisterMIMEInfo Sequence=3000 /
RemoveIniValues Sequence=3100 /
RemoveShortcuts Sequence=3200 /
RemoveEnvironmentStrings Sequence=3300 /
RemoveDuplicateFiles Sequence=3400 /
RemoveFiles Sequence=3500 /
RemoveFolders Sequence=3600 /
CreateFolders Sequence=3700 /
MoveFiles Sequence=3800 /
InstallFiles Sequence=4000 /
DuplicateFiles Sequence=4210 /
PatchFiles Sequence=4090 /
BindImage Sequence=4300 /
CreateShortcuts Sequence=4500 /
RegisterClassInfo Sequence=4600 /
RegisterExtensionInfo Sequence=4700 /
RegisterProgIdInfo Sequence=4800 /
RegisterMIMEInfo Sequence=4900 /
WriteRegistryValues Sequence=5000 /
WriteIniValues Sequence=5100 /
WriteEnvironmentStrings Sequence=5200 /
RegisterFonts Sequence=5300 /
InstallODBC Sequence=5400 /
RegisterTypeLibraries Sequence=5500 /
SelfRegModules Sequence=5600 /
RegisterComPlus Sequence=5700 /
InstallServices Sequence=5800VersionNT/InstallServices
StartServices Sequence=5900VersionNT/StartServices
RegisterUser Sequence=6000 /
RegisterProduct Sequence=6100 /
PublishComponents Sequence=6200 /
PublishFeatures Sequence=6300 /
PublishProduct Sequence=6400 /
InstallFinalize Sequence=6600 /
RemoveExistingProducts Sequence=6550 /
InstallExecute Sequence=6500 /
MsiPublishAssemblies Sequence=6250 /
MsiUnpublishAssemblies Sequence=1650 /
/InstallExecuteSequence


-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 30 April 2012 01:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Protect installed msi files

Self-healing is a feature of the Windows Installer. There are several ways
to get it to kick in. The most common is through Advertised entry points.

You might decompile your old VS setup/deployment project and see if it has
things Advertised or otherwise organized differently.

You could also get a verbose log file from the repair operations and see
what was used in the past to kick off the self-healing.

On Sun, Apr 29, 2012 at 2:01 PM, Kristjan Laane
kristjan.la...@gmail.comwrote:


 Hello again

 When I used to create my msis through Visual Studio Setup and 
 Deployment projects then these installers protected the files that got
installed i.e.
 if I installed the application and then manually deleted a file (such 
 as an included image content file) then when the next time the main 
 executable was run this deleted file got restored i.e. the msi was 
 found in the Windows store and it repaired my installation.

 With Wix this protection is not present any more. I think that is 
 better for some of the (optional) files that are installed, but I 
 would like to protect some of my dll's as before - do you know how I 
 could do that in Wix?

 Atb,
 Kristjan

[WiX-users] Random GUID generation

2012-04-30 Thread Kristjan Laane
There are a couple of components that I need to generate a random GUID for
on each build, but Wix does not allow me to use asterisk for them, because
im using per user install that requires registry key (path) and file in same
component. 

Any way to make asterisk work in this case?

Also, if I use asterisk for a Component is it true that it will not generate
a new GUID every build? i.e. Component/@Guid=* calculates a GUID that
stays the same as long as your file path stays the same
(http://stackoverflow.com/questions/5832315/wix-autogenerate-guid ) Does
that mean Wix keeps some kind of database of builds past and compares the
file paths of current and past builds to determine whether asterisk should
generate a new GUID or stay same as last build?

In any case, I need to also generate a random GUID for UPGRADECODE every
build, because im trying to deploy an installation strategy with changing
upgrade codes every version so that I can create parallel installs of
different versions of the same app, in different target folders, the
component files in which I would like to max out on reference count 1
(each). 

If * does not equal random guid every time, I was wondering if there already
exist any Wix extension that I could call upon to generate random GUIDs for
me, rather than burdening myself to semi-manually generate them every time ?


Thank you for your expertise, 
Kristjan



Error   12  The Component/@Guid attribute's value '*' is not valid for
this component because it does not meet the criteria for having an
automatically generated guid. Components with registry keypaths and files
cannot use an automatically generated guid. Create multiple components, each
with one file and/or one registry value keypath, to use automatically
generated guids.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Protect installed msi files

2012-04-29 Thread Kristjan Laane

Hello again

When I used to create my msis through Visual Studio Setup and Deployment
projects then these installers protected the files that got installed i.e.
if I installed the application and then manually deleted a file (such as an
included image content file) then when the next time the main executable was
run this deleted file got restored i.e. the msi was found in the Windows
store and it repaired my installation.

With Wix this protection is not present any more. I think that is better for
some of the (optional) files that are installed, but I would like to protect
some of my dll's as before - do you know how I could do that in Wix? 

Atb, 
Kristjan

P.S. My msi's were always per machine, but now are per user, so this may be
the difference that is actually causing the lack of protection? If that is
the case, is it still possible to protect certain File / Component / Feature
elements when deploying per user msi's ?




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Pass data into localization wxl file

2012-04-28 Thread Kristjan Laane
Dear Experts

 

After failing to use $(var.x) in my localization file, I tried to use
utilize properties as suggested here
http://stackoverflow.com/questions/6827931/is-it-possible-to-pass-variable-t
o-wix-localization-file

 

But I could not get the property to work as well: !(loc.Message_Foo) still
returns the static unevaluated string for me, being literally Foo blah blah
[Property1]. 

 

Where exactly do you define the property?, it was in the main wxs file after
the Package element in my case?

 

Or is there another way to pass constants into multiple localization files?

 

 

Thanks ahead, 

Atb, 

Kristjan

 

 

 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn support for 32bit and 64bit .NET Framework 4 pre-requisite

2012-04-28 Thread Kristjan Laane
Dear fellow developers, 

-- 1 --

I am using the Wix setup bundle as a guide for my own bootstrapper, but it
seems to me that the official Wix installer does not work support installing
.NET 4 Full on 64bit properly?:
I.e. as far as I can tell the DetectCondition is incorrect, because it only
targets 32 bit, and there will be no installation happening on 64bit?

Fragment
   WixVariable Id=WixMbaPrereqPackageId Value=Netfx4Full /
   WixVariable Id=WixMbaPrereqLicenseUrl Value=NetfxLicense.rtf /

   util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net
Framework Setup\NDP\v4\Full Value=Version Variable=Netfx4FullVersion /
   util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net
Framework Setup\NDP\v4\Full Value=Version Variable=Netfx4x64FullVersion
Win64=yes /

   PackageGroup Id=Netfx4Full
   ExePackage Id=Netfx4Full Cache=no Compressed=no
PerMachine=yes Permanent=yes Vital=yes
SourceFile=dotNetFx40_Full_x86_x64.exe
 
DownloadUrl=http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6
-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe
   DetectCondition=Netfx4FullVersion AND (NOT
VersionNT64 OR Netfx4x64FullVersion) /

   !-- ExePackage Id=Netfx4x86
DownloadUrl=http://download.microsoft.com/download/5/6/4/5641DA81-E6FA-4550
-9F80-A1D862D9CFAA/dotNetFx40_Full_x86.exe Compressed=no PerMachine=yes
Permanent=yes SourceFile=dotNetFx40_Full_x86.exe / --
   /PackageGroup
   /Fragment

From:
http://wix.codeplex.com/SourceControl/changeset/view/a782416c7fbc#src%2fSetu
p%2fBundle%2fNetfx.wxs 

i.e. should it be changed to just DetectCondition=Netfx4FullVersion OR
Netfx4x64FullVersion, because the source is dotNetFx40_Full_x86_x64.exe ?

-- 2 --

Also, I am going to try to point to the newest version of .NET 4 - currently
4.0.3 at http://www.microsoft.com/en-us/download/details.aspx?id=29053
Do you think this is better, and will it work?
i.e. 
 SourceFile=NDP40-KB2600211-x86-x64.exe
 
DownloadUrl=http://download.microsoft.com/download/3/3/9/3396A3CA-BFE8-4C9B
-83D3-CADAE72C17BE/NDP40-KB2600211-x86-x64.exe  


Atb, 
Kristjan


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Pass data into localization wxl file

2012-04-28 Thread Kristjan Laane
Thanks for the info Bob - but what determines whether a localized string is
formatted or not? 

I just tried $(sys.CURRENTDIR) and that is not evaluated either! Is there
any way to get outside information into localization files? I cannot have
any language-independent static parts otherwise, which seems like a rather
large limitation to me. 


Atb, 
Kristjan


-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: 28 April 2012 21:19
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Pass data into localization wxl file

On 28-Apr-12 07:20, Kristjan Laane wrote:
 But I could not get the property to work as well: !(loc.Message_Foo) 
 still returns the static unevaluated string for me, being literally 
 Foo blah blah [Property1].
That means you're trying to use properties in a string that isn't formatted.

--
sig://boB
http://joyofsetup.com/



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users