Re: [WiX-users] RegistrySearch on click

[Joseph L. Casale]

> I think you’d have to write your own VB script/DLL custom action to:
> 1. Read the user’s input from a property
> 2. Read the existing value from the registry - 
> http://stackoverflow.com/questions/34065/how-to-read-a-value-from-the-windows-registry
> 3. Write a property (or don’t) if the user’s input matches what’s currently 
> in the registry
> 4. Use the newly created property to condition whether or not to allow the 
> ‘Next’ button to proceed to the next dialog

Hi Joel,
It turned out to be rather simple to do this with a C# DLL.

Thanks for the pointer,
jlc
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch on click

[Joel Budreau]

I think you’d have to write your own VB script/DLL custom action to:
1. Read the user’s input from a property
2. Read the existing value from the registry - 
http://stackoverflow.com/questions/34065/how-to-read-a-value-from-the-windows-registry
3. Write a property (or don’t) if the user’s input matches what’s currently in 
the registry
4. Use the newly created property to condition whether or not to allow the 
‘Next’ button to proceed to the next dialog
 
> On Mar 6, 2015, at 12:36 PM, Joseph L. Casale  
> wrote:
> 
> Trying that again...
> 
> I have been searching around for a while without luck on the approach
> used to initiate a RegistrySearch using a value entered in a text field
> when the user presses next in a dialog.
> 
> The best I could come up with was publishing a DoAction event in the
> next button control. However, I cant seem to find an indication that
> you can actually create a CustomAction that performs a registry search?
> 
> Ultimately I need to return an error if the value is not found.
> 
> Thanks,
> jlc
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch on click

[Joseph L. Casale]

Trying that again...

I have been searching around for a while without luck on the approach
used to initiate a RegistrySearch using a value entered in a text field
when the user presses next in a dialog.

The best I could come up with was publishing a DoAction event in the
next button control. However, I cant seem to find an indication that
you can actually create a CustomAction that performs a registry search?

Ultimately I need to return an error if the value is not found.

Thanks,
jlc
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch problem

[vorsichtdiekurve]

Well, it's a little bit embarrasing, but i've already found what was the
issue. There was a typo in the registry path.
Anyway, thank's for your effort.
Mateusz



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

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch problem

[Bevan Weiss]

Is this a 64/32bit registry type issue?
And is the burn package being run with elevated privileges? (just to rule
out issues with registry permissions)


Regards,
Bevan

Date: Wed, 23 Jul 2014 00:38:22 -0700 (PDT)
From: vorsichtdiekurve 
Subject: [WiX-users] RegistrySearch problem

Hi,
I'm trying to determine what if a version of PostgreSQL is installed on a
windows 8.1 64 bit machine, using the following code:
**
But when running the bootstrapper, i get this in the install log:
*Registry key not found. Key =
'SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3'*
Actually the key exists, it can be found using regedit.
Thank you in advance for any answer.
Mateusz

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch problem

[Chaitanya]

On 7/23/2014 8:51 PM, vorsichtdiekurve wrote:
> Unfortunately, it didn't.
> My problem is that the registry key is not being found, not that the
> registry search is not being executed.
> Here is my bootsrapper code:
>UpgradeCode="3731eedd-c21c-40e2-bf03-653ea4a186e2">
>Id="WixStandardBootstrapperApplication.RtfLicense" />
>   Result="exists" Key="SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3"
> Value="Version" Variable="PostgreVersion" />
>  
> Compressed="yes" PerMachine="yes" Permanent="yes" Vital="yes"
> InstallCommand="/q"
>  SourceFile="postgresql-9.3.4-4-windows-x64.exe"
>  DetectCondition="PostgreVersion" />
>
> DisplayInternalUI="yes"/>
>  
>   
>
>
>
>
> --
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-problem-tp7596055p7596062.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> .
>
when you win64=yes it might will check in wow6432node

just give path 'SOFTWARE\wow6432node\PostgreSQL'


-- 
Thanks & Regards,
Chaitanya.


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch problem

[vorsichtdiekurve]

Unfortunately, it didn't.
My problem is that the registry key is not being found, not that the
registry search is not being executed.
Here is my bootsrapper code:




  
  
  






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

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch problem

[Carter Young]

Are you having the same problem as the Poster here:

http://stackoverflow.com/questions/19227335/wix-burn-3-7-and-postgresql-registry-search-fail

Did the answer help?

Carter

Quoting vorsichtdiekurve :

> Hi,
> I'm trying to determine what if a version of PostgreSQL is installed on a
> windows 8.1 64 bit machine, using the following code:
> * Key="SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3" Value="Version"
> Variable="PostgreVersion" />*
> But when running the bootstrapper, i get this in the install log:
> *Registry key not found. Key =
> 'SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3'*
> Actually the key exists, it can be found using regedit.
> Thank you in advance for any answer.
> Mateusz
>
>
>
> --
> View this message in context:  
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-problem-tp7596055.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>




--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch doesn't find Key

[Michael Turner]

Try adding Secure="yes" on the Property.  This means that "the Property can
be passed to the server side when doing a managed installation with elevated
privileges".  I don't fully understand what "the server side" is, but I
think it has something to do with the "transactional" part of the
installation, and I think it's where deferred custom actions happen.

If you turn on logging, you'll see it list out property values with "(c)",
which is "the client side", and later with "(s)", which is "the server
side".  If you see that this property has the correct value with a "(c)" and
has no value with "(s)", then you need to mark it as "secure".

Related:
-
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Property-Secure-when-to-use-td4982590.html
-
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Simple-question-about-properties-tp4974905p4980963.html


Another possibility is that you are looking for the wrong thing. 
[HKLM\Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER] does
not normally have a value named "test" on it.  If you are looking for a SQL
Server 2008 R2 SSRS installation path, that's usually on the key
[HKLM\Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Setup]
on the value "SQLPath" or "SqlProgramDir".

Regards,
Mike


-----Original Message-
From: Brett Faurot [mailto:Brett.Faurot@]
Sent: Tuesday, June 10, 2014 12:51 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

Thank you Phil and Pavan,
I have tried explicitly calling out 64-bit and specifying type="directory"
but it still fails to find it. The only difference I can tell between this
use and others in the installer are the . and _ in the key. I was wondering
if that was throwing the registrysearch off.  It's frustrating when such a
simple thing causes a dead stop in work.

-Original Message-
From: Phil Wilson [mailto:phildgwilson@] 
Sent: Saturday, June 07, 2014 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

..and also don't forget there are 64-bit and 32-bit registries so you may
need to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru <Pavan.Konduru@> wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:Brett.Faurot@]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@.sourceforge
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install
> location of MS SQL Reporting Services by checking the registry; but, my
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer. 
> Also, I can successfully populate the property looking for a value when
> the Key="Software\Microsoft\Microsoft SQL Server". It seems to be only
> once I introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and
> the property fails to populate.  Any ideas?
>
> Thanks,
> Brett




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-doesn-t-find-Key-tp7595091p7595175.html
Sent from the wix-users mailing list archive at Nabble.com.

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

Re: [WiX-users] RegistrySearch doesn't find Key

[Pavan Konduru]

Hi Brett,

This worked for me. I created a dummy registry key with the same name as yours. 
Since the dummy key was not in wow64node, I put win64=yes.
I put a value in the key as "VERSION" and put the value as some directory," 
C:\backup"


  



This is from the logs:

AppSearch: Property: REPORTINGSERVICESPROP, Signature: SQLSEARCH
MSI (c) (D4:6C) [13:18:20:995]: Note: 1: 2262 2: Signature 3: -2147287038 
MSI (c) (D4:6C) [13:18:20:995]: PROPERTY CHANGE: Adding REPORTINGSERVICESPROP 
property. Its value is 'C:\backup'.


--Pavan

-Original Message-
From: Brett Faurot [mailto:brett.fau...@dh.com] 
Sent: Tuesday, June 10, 2014 12:51 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

Thank you Phil and Pavan,
I have tried explicitly calling out 64-bit and specifying type="directory" but 
it still fails to find it. The only difference I can tell between this use and 
others in the installer are the . and _ in the key. I was wondering if that was 
throwing the registrysearch off.  It's frustrating when such a simple thing 
causes a dead stop in work.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Saturday, June 07, 2014 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

..and also don't forget there are 64-bit and 32-bit registries so you may need 
to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru  
wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:brett.fau...@dh.com]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install 
> location of MS SQL Reporting Services by checking the registry; but, my 
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer.  
> Also, I can successfully populate the property looking for a value when the 
> Key="Software\Microsoft\Microsoft SQL Server". It seems to be only once I 
> introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and the 
> property fails to populate.  Any ideas?
>
> Thanks,
> Brett
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this first 
> edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this 
> first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

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



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



-

Re: [WiX-users] RegistrySearch doesn't find Key

[Pavan Konduru]

Hi Brett,

Can you post the code of how you are using this property in your code?

--Pavan

-Original Message-
From: Brett Faurot [mailto:brett.fau...@dh.com] 
Sent: Tuesday, June 10, 2014 12:51 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

Thank you Phil and Pavan,
I have tried explicitly calling out 64-bit and specifying type="directory" but 
it still fails to find it. The only difference I can tell between this use and 
others in the installer are the . and _ in the key. I was wondering if that was 
throwing the registrysearch off.  It's frustrating when such a simple thing 
causes a dead stop in work.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Saturday, June 07, 2014 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

..and also don't forget there are 64-bit and 32-bit registries so you may need 
to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru  
wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:brett.fau...@dh.com]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install 
> location of MS SQL Reporting Services by checking the registry; but, my 
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer.  
> Also, I can successfully populate the property looking for a value when the 
> Key="Software\Microsoft\Microsoft SQL Server". It seems to be only once I 
> introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and the 
> property fails to populate.  Any ideas?
>
> Thanks,
> Brett
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this first 
> edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this 
> first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

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



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



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

Re: [WiX-users] RegistrySearch doesn't find Key

[Brett Faurot]

Thank you Phil and Pavan,
I have tried explicitly calling out 64-bit and specifying type="directory" but 
it still fails to find it. The only difference I can tell between this use and 
others in the installer are the . and _ in the key. I was wondering if that was 
throwing the registrysearch off.  It's frustrating when such a simple thing 
causes a dead stop in work.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Saturday, June 07, 2014 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

..and also don't forget there are 64-bit and 32-bit registries so you may need 
to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru  
wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:brett.fau...@dh.com]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install 
> location of MS SQL Reporting Services by checking the registry; but, my 
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer.  
> Also, I can successfully populate the property looking for a value when the 
> Key="Software\Microsoft\Microsoft SQL Server". It seems to be only once I 
> introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and the 
> property fails to populate.  Any ideas?
>
> Thanks,
> Brett
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this first 
> edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
>  Learn Graph Databases - Download FREE O'Reilly Book "Graph 
> Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, this 
> first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

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



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

Re: [WiX-users] RegistrySearch doesn't find Key

[Phil Wilson]

..and also don't forget there are 64-bit and 32-bit registries so you
may need to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru
 wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:brett.fau...@dh.com]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install 
> location of MS SQL Reporting Services by checking the registry; but, my 
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer.  
> Also, I can successfully populate the property looking for a value when the 
> Key="Software\Microsoft\Microsoft SQL Server". It seems to be only once I 
> introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and the 
> property fails to populate.  Any ideas?
>
> Thanks,
> Brett
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the 
> definitive new guide to graph databases and their applications. Written by 
> three acclaimed leaders in the field, this first edition is now available. 
> Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

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

Re: [WiX-users] RegistrySearch doesn't find Key

[Pavan Konduru]

Try putting type ="directory"

-Original Message-
From: Brett Faurot [mailto:brett.fau...@dh.com] 
Sent: Friday, June 06, 2014 12:32 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch doesn't find Key

I'm having problems using a registrysearch. I'm trying to get the install 
location of MS SQL Reporting Services by checking the registry; but, my 
installer is failing the find the key.



This same method is used successfully many other times in this installer.  
Also, I can successfully populate the property looking for a value when the 
Key="Software\Microsoft\Microsoft SQL Server". It seems to be only once I 
introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and the property 
fails to populate.  Any ideas?

Thanks,
Brett


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



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

Re: [WiX-users] RegistrySearch/@Win64 bug?

[Igor Solodovnikov]

Thank you Blair,

I reported this bug at http://wixtoolset.org/issues/4215/

Igor


On Thu, Nov 28, 2013 at 10:33 AM, Blair Murri  wrote:

> The -arch command-line argument is what sets the default value of @Win64
> on things like the RegistrySearch and Component elements, not the
> Package/@Platform attribute.
>
> That is a doc bug. Please file it so we get it corrected.
>
> -Blair
>
> > Date: Wed, 27 Nov 2013 19:46:10 +0200
> > From: igor@gmail.com
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch/@Win64 bug?
> >
> > Hello,
> >
> > RegistrySearch/@Win64 documentation at
> >
> http://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html
> >  says:
> >
> > The default value depends on the value of the Package/@Platform
> attribute:
> > if the @Platform attribute value is 'x86', the default @Win64 attribute
> > value is 'no'; otherwise, the default value is 'yes'.
> >
> > But my tests with WIX 3.6.3303 showed that default is always 'no'
> > regardless of Package/@Platform attribute value. For example I have
> > Package/@Platform
> > value 'x64' and RegistrySearch element without @Win64 attribute. I
> compile
> > msi and check its content with Orca. RegLocator table contains record
> > corresponding to my RegistrySearch element but its Type does
> > not contain msidbLocatorType64bit set.
> >
> > Is this bug in WiX or bug in the schema reference? Or maybe I missing
> > something?
> >
> > Thanks,
> > Igor
> >
> --
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch/@Win64 bug?

[Blair Murri]

The -arch command-line argument is what sets the default value of @Win64 on 
things like the RegistrySearch and Component elements, not the 
Package/@Platform attribute.
 
That is a doc bug. Please file it so we get it corrected.
 
-Blair
 
> Date: Wed, 27 Nov 2013 19:46:10 +0200
> From: igor@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch/@Win64 bug?
> 
> Hello,
> 
> RegistrySearch/@Win64 documentation at
> http://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html
>  says:
> 
> The default value depends on the value of the Package/@Platform attribute:
> if the @Platform attribute value is 'x86', the default @Win64 attribute
> value is 'no'; otherwise, the default value is 'yes'.
> 
> But my tests with WIX 3.6.3303 showed that default is always 'no'
> regardless of Package/@Platform attribute value. For example I have
> Package/@Platform
> value 'x64' and RegistrySearch element without @Win64 attribute. I compile
> msi and check its content with Orca. RegLocator table contains record
> corresponding to my RegistrySearch element but its Type does
> not contain msidbLocatorType64bit set.
> 
> Is this bug in WiX or bug in the schema reference? Or maybe I missing
> something?
> 
> Thanks,
> Igor
> --
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch example in tutorial

[Blair Murri]

An MSI itself can be either 32-bit or 64-bit package, and it targets installing 
for that bitness (a 64-bit package cannot be used on a 32-bit platform, while a 
32-bit package cannot access 64-bit sections of the filesystem).
Typically your build settings set the bitness of the packages you create using 
the WiX toolset.

> From: rob...@softdev.net
> To: wix-users@lists.sourceforge.net
> Date: Wed, 28 Aug 2013 07:33:17 +
> Subject: Re: [WiX-users] RegistrySearch example in tutorial
> 
> Hi Phil/Blair,
> 
> I'm just trying to get through the tutorial on a x64 machine. The problem was 
> resolved by creating the key in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. I 
> removed the key I had created in HKEY_LOCAL_MACHINE\SOFTWARE. It now works.
> 
> I don't understand "Do you have a 32-bit MSI" or "if you have an x86 platform 
> install". Are you referring to the WiX install? I don't remember being 
> offered a selection between x86 and x64 during the install - in fact there 
> wasn't one.
> 
> Regards,
> Robert Clancy
> 
> -Original Message-
> From: Phil Wilson [mailto:phildgwil...@gmail.com] 
> Sent: Wednesday, 28 August 2013 3:26 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch example in tutorial
> 
> The original registry search you posted doesn't have Win64="yes" so it will 
> be a 32-bit registry search if you have an x86 platform install (and it looks 
> like you do).
> 
> Phil Wilson
> 
> 
> On Tue, Aug 27, 2013 at 2:29 AM, Blair Murri  wrote:
> 
> > If you are intending to use the 32-bit registry in a 64-bit platform 
> > in RegEdit, you need to start from the 
> > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
> > (which is the 32-bit HKEY_LOCAL_MACHINE\SOFTWARE key).
> > You make TARGETDIR conditional by setting a property by that name to 
> > the full path (hopefully with a backslash ('\') at the end) before 
> > costing starts in whatever sequence starts first. Same with INSTALLDIR.
> > Subdirectories will automatically use the path set for their parents 
> > if a path is not presupplied. During costing, properties will be 
> > created for all directories that didn't already have properties (and 
> > each one will be set to the full path of that directory).
> > AppSearch, et. al. will set the property you specify. So will the 
> > command-line. By default, the *Search actions will override the 
> > command-line.
> >
> > > From: rob...@softdev.net
> > > To: wix-users@lists.sourceforge.net
> > > Date: Mon, 26 Aug 2013 23:52:18 +
> > > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> > >
> > > Thanks for both replies. I am indeed on a x64 machine and have no 
> > > idea
> > how to distinguish between x86/x64 registries. I've probably created 
> > the key in the wrong one. Any pointers? To open the editor, I type in 
> > "regedit"
> > >
> > > If not that, then how should I make this conditional:
> > >
> > > > > 
> > > > >   
> > > > > 
> > > > >   
> > >
> > > -Original Message-
> > > From: Phil Wilson [mailto:phildgwil...@gmail.com]
> > > Sent: Tuesday, 27 August 2013 4:49 AM
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> > >
> > > What often happens is that there is a custom action to set the 
> > > default
> > INSTALLDIR location to the program files folder, and people forget to 
> > make it conditional, with a condition like NOT INSTALDIR.  You may 
> > find that if you set INSTALLDIR on an msiexec command line it would 
> > also get overwritten. The NOT INSTALLDIR condition just means "don't 
> > set it to default if it's already set".
> > >
> > > Phil Wilson
> > >
> > >
> > > On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:
> > >
> > > > "Adding" is not overridding, it is creating.
> > > > That would suggest that there is no InstallDir value at 
> > > > HKLM\Software\Acme\Foobar 1.0 Do you have a 32-bit MSI and are 
> > > > trying to read a 64-bit registry location, per chance? Or vice versa?
> > > >
> > > > > From: rob...@softdev.net
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Date: Mon, 26 Aug 2013 06:31:51 +
> > > > > Subject: [WiX-

Re: [WiX-users] RegistrySearch example in tutorial

[Robert Clancy]

Hi Phil/Blair,

I'm just trying to get through the tutorial on a x64 machine. The problem was 
resolved by creating the key in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. I 
removed the key I had created in HKEY_LOCAL_MACHINE\SOFTWARE. It now works.

I don't understand "Do you have a 32-bit MSI" or "if you have an x86 platform 
install". Are you referring to the WiX install? I don't remember being offered 
a selection between x86 and x64 during the install - in fact there wasn't one.

Regards,
Robert Clancy

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Wednesday, 28 August 2013 3:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch example in tutorial

The original registry search you posted doesn't have Win64="yes" so it will be 
a 32-bit registry search if you have an x86 platform install (and it looks like 
you do).

Phil Wilson


On Tue, Aug 27, 2013 at 2:29 AM, Blair Murri  wrote:

> If you are intending to use the 32-bit registry in a 64-bit platform 
> in RegEdit, you need to start from the 
> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
> (which is the 32-bit HKEY_LOCAL_MACHINE\SOFTWARE key).
> You make TARGETDIR conditional by setting a property by that name to 
> the full path (hopefully with a backslash ('\') at the end) before 
> costing starts in whatever sequence starts first. Same with INSTALLDIR.
> Subdirectories will automatically use the path set for their parents 
> if a path is not presupplied. During costing, properties will be 
> created for all directories that didn't already have properties (and 
> each one will be set to the full path of that directory).
> AppSearch, et. al. will set the property you specify. So will the 
> command-line. By default, the *Search actions will override the 
> command-line.
>
> > From: rob...@softdev.net
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 26 Aug 2013 23:52:18 +
> > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> >
> > Thanks for both replies. I am indeed on a x64 machine and have no 
> > idea
> how to distinguish between x86/x64 registries. I've probably created 
> the key in the wrong one. Any pointers? To open the editor, I type in 
> "regedit"
> >
> > If not that, then how should I make this conditional:
> >
> > > > 
> > > >   
> > > >         
> > > >   
> >
> > -Original Message-
> > From: Phil Wilson [mailto:phildgwil...@gmail.com]
> > Sent: Tuesday, 27 August 2013 4:49 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> >
> > What often happens is that there is a custom action to set the 
> > default
> INSTALLDIR location to the program files folder, and people forget to 
> make it conditional, with a condition like NOT INSTALDIR.  You may 
> find that if you set INSTALLDIR on an msiexec command line it would 
> also get overwritten. The NOT INSTALLDIR condition just means "don't 
> set it to default if it's already set".
> >
> > Phil Wilson
> >
> >
> > On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:
> >
> > > "Adding" is not overridding, it is creating.
> > > That would suggest that there is no InstallDir value at 
> > > HKLM\Software\Acme\Foobar 1.0 Do you have a 32-bit MSI and are 
> > > trying to read a 64-bit registry location, per chance? Or vice versa?
> > >
> > > > From: rob...@softdev.net
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Mon, 26 Aug 2013 06:31:51 +
> > > > Subject: [WiX-users] RegistrySearch example in tutorial
> > > >
> > > > I'm a novice user, going through Getting Started. I cannot get 
> > > > the
> > > RegistrySearch to work, or FILEEXISTS - both from "Where to Install?"
> > > page in your tutorial.
> > > >
> > > > I suspect it is because this element:
> > > > 
> > > >> > Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> > > > 
> > > >
> > > > is overridden by the subsequent
> > > >
> > > > 
> > > >   
> > > > 
> > > >   
> > > >
> > > > Meaning that if the registry sets a directory outside of program 
> > > > files,
> > > then it seems to not work because later in the wxs file it is 
> > >

Re: [WiX-users] RegistrySearch example in tutorial

[Phil Wilson]

The original registry search you posted doesn't have Win64="yes" so it
will be a 32-bit registry search if you have an x86 platform install (and
it looks like you do).

Phil Wilson


On Tue, Aug 27, 2013 at 2:29 AM, Blair Murri  wrote:

> If you are intending to use the 32-bit registry in a 64-bit platform in
> RegEdit, you need to start from the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
> (which is the 32-bit HKEY_LOCAL_MACHINE\SOFTWARE key).
> You make TARGETDIR conditional by setting a property by that name to the
> full path (hopefully with a backslash ('\') at the end) before costing
> starts in whatever sequence starts first. Same with INSTALLDIR.
> Subdirectories will automatically use the path set for their parents if a
> path is not presupplied. During costing, properties will be created for all
> directories that didn't already have properties (and each one will be set
> to the full path of that directory).
> AppSearch, et. al. will set the property you specify. So will the
> command-line. By default, the *Search actions will override the
> command-line.
>
> > From: rob...@softdev.net
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 26 Aug 2013 23:52:18 +
> > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> >
> > Thanks for both replies. I am indeed on a x64 machine and have no idea
> how to distinguish between x86/x64 registries. I've probably created the
> key in the wrong one. Any pointers? To open the editor, I type in "regedit"
> >
> > If not that, then how should I make this conditional:
> >
> > > > 
> > > >   
> > > > 
> > > >   
> >
> > -Original Message-
> > From: Phil Wilson [mailto:phildgwil...@gmail.com]
> > Sent: Tuesday, 27 August 2013 4:49 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] RegistrySearch example in tutorial
> >
> > What often happens is that there is a custom action to set the default
> INSTALLDIR location to the program files folder, and people forget to make
> it conditional, with a condition like NOT INSTALDIR.  You may find that if
> you set INSTALLDIR on an msiexec command line it would also get
> overwritten. The NOT INSTALLDIR condition just means "don't set it to
> default if it's already set".
> >
> > Phil Wilson
> >
> >
> > On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:
> >
> > > "Adding" is not overridding, it is creating.
> > > That would suggest that there is no InstallDir value at
> > > HKLM\Software\Acme\Foobar 1.0 Do you have a 32-bit MSI and are trying
> > > to read a 64-bit registry location, per chance? Or vice versa?
> > >
> > > > From: rob...@softdev.net
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Mon, 26 Aug 2013 06:31:51 +
> > > > Subject: [WiX-users] RegistrySearch example in tutorial
> > > >
> > > > I'm a novice user, going through Getting Started. I cannot get the
> > > RegistrySearch to work, or FILEEXISTS - both from "Where to Install?"
> > > page in your tutorial.
> > > >
> > > > I suspect it is because this element:
> > > > 
> > > >> > Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> > > > 
> > > >
> > > > is overridden by the subsequent
> > > >
> > > > 
> > > >   
> > > > 
> > > >   
> > > >
> > > > Meaning that if the registry sets a directory outside of program
> > > > files,
> > > then it seems to not work because later in the wxs file it is
> > > contained within ProgramFilesFolder. Logging reveals it is overridden:
> > > >
> > > > MSI (c) (50:AC) [16:21:36:966]: PROPERTY CHANGE: Adding INSTALLDIR
> > > property. Its value is 'C:\Program Files (x86)\... etc
> > > >
> > > > I realise the file is not read sequentially.
> > > >
> > > > Regards,
> > > > Robert
> > > >
> > > --
> > > 
> > > > Introducing Performance Central, a new site from SourceForge and
> > > > AppDynamics. Performance Central is your source for news, insights,
> > > > analysis and resources for efficient Application Performance
> Management.
> > > > Visit us today!
> > &

Re: [WiX-users] RegistrySearch example in tutorial

[Blair Murri]

If you are intending to use the 32-bit registry in a 64-bit platform in 
RegEdit, you need to start from the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node 
(which is the 32-bit HKEY_LOCAL_MACHINE\SOFTWARE key).
You make TARGETDIR conditional by setting a property by that name to the full 
path (hopefully with a backslash ('\') at the end) before costing starts in 
whatever sequence starts first. Same with INSTALLDIR. Subdirectories will 
automatically use the path set for their parents if a path is not presupplied. 
During costing, properties will be created for all directories that didn't 
already have properties (and each one will be set to the full path of that 
directory).
AppSearch, et. al. will set the property you specify. So will the command-line. 
By default, the *Search actions will override the command-line.

> From: rob...@softdev.net
> To: wix-users@lists.sourceforge.net
> Date: Mon, 26 Aug 2013 23:52:18 +0000
> Subject: Re: [WiX-users] RegistrySearch example in tutorial
> 
> Thanks for both replies. I am indeed on a x64 machine and have no idea how to 
> distinguish between x86/x64 registries. I've probably created the key in the 
> wrong one. Any pointers? To open the editor, I type in "regedit"
> 
> If not that, then how should I make this conditional:
> 
> > > 
> > >   
> > > 
> > >   
> 
> -Original Message-
> From: Phil Wilson [mailto:phildgwil...@gmail.com] 
> Sent: Tuesday, 27 August 2013 4:49 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch example in tutorial
> 
> What often happens is that there is a custom action to set the default 
> INSTALLDIR location to the program files folder, and people forget to make it 
> conditional, with a condition like NOT INSTALDIR.  You may find that if you 
> set INSTALLDIR on an msiexec command line it would also get overwritten. The 
> NOT INSTALLDIR condition just means "don't set it to default if it's already 
> set".
> 
> Phil Wilson
> 
> 
> On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:
> 
> > "Adding" is not overridding, it is creating.
> > That would suggest that there is no InstallDir value at 
> > HKLM\Software\Acme\Foobar 1.0 Do you have a 32-bit MSI and are trying 
> > to read a 64-bit registry location, per chance? Or vice versa?
> >
> > > From: rob...@softdev.net
> > > To: wix-users@lists.sourceforge.net
> > > Date: Mon, 26 Aug 2013 06:31:51 +
> > > Subject: [WiX-users] RegistrySearch example in tutorial
> > >
> > > I'm a novice user, going through Getting Started. I cannot get the
> > RegistrySearch to work, or FILEEXISTS - both from "Where to Install?" 
> > page in your tutorial.
> > >
> > > I suspect it is because this element:
> > > 
> > >> Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> > > 
> > >
> > > is overridden by the subsequent
> > >
> > > 
> > >   
> > > 
> > >   
> > >
> > > Meaning that if the registry sets a directory outside of program 
> > > files,
> > then it seems to not work because later in the wxs file it is 
> > contained within ProgramFilesFolder. Logging reveals it is overridden:
> > >
> > > MSI (c) (50:AC) [16:21:36:966]: PROPERTY CHANGE: Adding INSTALLDIR
> > property. Its value is 'C:\Program Files (x86)\... etc
> > >
> > > I realise the file is not read sequentially.
> > >
> > > Regards,
> > > Robert
> > >
> > --
> > 
> > > Introducing Performance Central, a new site from SourceForge and 
> > > AppDynamics. Performance Central is your source for news, insights, 
> > > analysis and resources for efficient Application Performance Management.
> > > Visit us today!
> > >
> > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> > lktrk
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > --
> >  Introducing Performance Central, a new site from SourceForge 
> > and AppDynamics. Performance Central is your source for news, 
> > insights, analysis and resources for efficient Application P

Re: [WiX-users] RegistrySearch example in tutorial

[Robert Clancy]

Thanks for both replies. I am indeed on a x64 machine and have no idea how to 
distinguish between x86/x64 registries. I've probably created the key in the 
wrong one. Any pointers? To open the editor, I type in "regedit"

If not that, then how should I make this conditional:

> > 
> >   
> > 
> >   

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Tuesday, 27 August 2013 4:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch example in tutorial

What often happens is that there is a custom action to set the default 
INSTALLDIR location to the program files folder, and people forget to make it 
conditional, with a condition like NOT INSTALDIR.  You may find that if you set 
INSTALLDIR on an msiexec command line it would also get overwritten. The NOT 
INSTALLDIR condition just means "don't set it to default if it's already set".

Phil Wilson


On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:

> "Adding" is not overridding, it is creating.
> That would suggest that there is no InstallDir value at 
> HKLM\Software\Acme\Foobar 1.0 Do you have a 32-bit MSI and are trying 
> to read a 64-bit registry location, per chance? Or vice versa?
>
> > From: rob...@softdev.net
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 26 Aug 2013 06:31:51 +
> > Subject: [WiX-users] RegistrySearch example in tutorial
> >
> > I'm a novice user, going through Getting Started. I cannot get the
> RegistrySearch to work, or FILEEXISTS - both from "Where to Install?" 
> page in your tutorial.
> >
> > I suspect it is because this element:
> > 
> >Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> > 
> >
> > is overridden by the subsequent
> >
> > 
> >   
> > 
> >   
> >
> > Meaning that if the registry sets a directory outside of program 
> > files,
> then it seems to not work because later in the wxs file it is 
> contained within ProgramFilesFolder. Logging reveals it is overridden:
> >
> > MSI (c) (50:AC) [16:21:36:966]: PROPERTY CHANGE: Adding INSTALLDIR
> property. Its value is 'C:\Program Files (x86)\... etc
> >
> > I realise the file is not read sequentially.
> >
> > Regards,
> > Robert
> >
> --
> 
> > Introducing Performance Central, a new site from SourceForge and 
> > AppDynamics. Performance Central is your source for news, insights, 
> > analysis and resources for efficient Application Performance Management.
> > Visit us today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> lktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>  Introducing Performance Central, a new site from SourceForge 
> and AppDynamics. Performance Central is your source for news, 
> insights, analysis and resources for efficient Application Performance 
> Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.c
> lktrk ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Introducing Performance Central, a new site from SourceForge and AppDynamics. 
Performance Central is your source for news, insights, analysis and resources 
for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch example in tutorial

[Phil Wilson]

What often happens is that there is a custom action to set the default
INSTALLDIR location to the program files folder, and people forget to make
it conditional, with a condition like NOT INSTALDIR.  You may find that if
you set INSTALLDIR on an msiexec command line it would also get
overwritten. The NOT INSTALLDIR condition just means "don't set it to
default if it's already set".

Phil Wilson


On Mon, Aug 26, 2013 at 3:42 AM, Blair Murri  wrote:

> "Adding" is not overridding, it is creating.
> That would suggest that there is no InstallDir value at
> HKLM\Software\Acme\Foobar 1.0
> Do you have a 32-bit MSI and are trying to read a 64-bit registry
> location, per chance? Or vice versa?
>
> > From: rob...@softdev.net
> > To: wix-users@lists.sourceforge.net
> > Date: Mon, 26 Aug 2013 06:31:51 +
> > Subject: [WiX-users] RegistrySearch example in tutorial
> >
> > I'm a novice user, going through Getting Started. I cannot get the
> RegistrySearch to work, or FILEEXISTS - both from "Where to Install?" page
> in your tutorial.
> >
> > I suspect it is because this element:
> > 
> >Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> > 
> >
> > is overridden by the subsequent
> >
> > 
> >   
> > 
> >   
> >
> > Meaning that if the registry sets a directory outside of program files,
> then it seems to not work because later in the wxs file it is contained
> within ProgramFilesFolder. Logging reveals it is overridden:
> >
> > MSI (c) (50:AC) [16:21:36:966]: PROPERTY CHANGE: Adding INSTALLDIR
> property. Its value is 'C:\Program Files (x86)\... etc
> >
> > I realise the file is not read sequentially.
> >
> > Regards,
> > Robert
> >
> --
> > Introducing Performance Central, a new site from SourceForge and
> > AppDynamics. Performance Central is your source for news, insights,
> > analysis and resources for efficient Application Performance Management.
> > Visit us today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch example in tutorial

[Blair Murri]

"Adding" is not overridding, it is creating.
That would suggest that there is no InstallDir value at 
HKLM\Software\Acme\Foobar 1.0
Do you have a 32-bit MSI and are trying to read a 64-bit registry location, per 
chance? Or vice versa?

> From: rob...@softdev.net
> To: wix-users@lists.sourceforge.net
> Date: Mon, 26 Aug 2013 06:31:51 +
> Subject: [WiX-users] RegistrySearch example in tutorial
> 
> I'm a novice user, going through Getting Started. I cannot get the 
> RegistrySearch to work, or FILEEXISTS - both from "Where to Install?" page in 
> your tutorial.
> 
> I suspect it is because this element:
> 
>Key='Software\Acme\Foobar 1.0' Name='InstallDir' />
> 
> 
> is overridden by the subsequent
> 
> 
>   
> 
>   
> 
> Meaning that if the registry sets a directory outside of program files, then 
> it seems to not work because later in the wxs file it is contained within 
> ProgramFilesFolder. Logging reveals it is overridden:
> 
> MSI (c) (50:AC) [16:21:36:966]: PROPERTY CHANGE: Adding INSTALLDIR property. 
> Its value is 'C:\Program Files (x86)\... etc
> 
> I realise the file is not read sequentially.
> 
> Regards,
> Robert
> --
> Introducing Performance Central, a new site from SourceForge and 
> AppDynamics. Performance Central is your source for news, insights, 
> analysis and resources for efficient Application Performance Management. 
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[Natalie Carr]

Hi, Yes I finally found an answer, im now using this:


  



  
  

It seems to work ok(I think) :)

Thanks

-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com] 
Sent: 16 August 2012 14:19
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch

That looks ok but you don't normally reference WOW6432Node as that
redirection happens automatically if your msi is 32bit.

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com]
Sent: 16 August 2012 2:08 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch

Can anyone tell me if I have done anything wrong here, it does not seem to
be working. And also do I have to call a custom action to run this search?
Whats my best way for testing it?

 

  

  

  

 

 

Kind Regards,

 

Natalie Carr

 


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


--
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] RegistrySearch

[Neil Sleightholm]

That looks ok but you don't normally reference WOW6432Node as that redirection 
happens automatically if your msi is 32bit.

Neil

-Original Message-
From: Natalie Carr [mailto:natalie.c...@measuresoft.com] 
Sent: 16 August 2012 2:08 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch

Can anyone tell me if I have done anything wrong here, it does not seem to be 
working. And also do I have to call a custom action to run this search?
Whats my best way for testing it?

 

  

  

  

 

 

Kind Regards,

 

Natalie Carr

 

--
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] RegistrySearch value created by first msi as input to second msi in chain

[Bob Arnson]

On 01-May-12 16:34, Brian C wrote:
>I have what appears to be a simple chained install using burn, where I 
> would like to do a RegistrySearch to read a key created by the first msi, and 
> use that to install the second msi to a subfolder of that location.
Burn doesn't support that today. All searches are done before beginning 
the apply phase.

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

Re: [WiX-users] RegistrySearch

[loyalty Reddy]

thank you all very much. I am able to get it working

On Mon, Jan 30, 2012 at 3:17 PM, Pally Sandher wrote:

> 
>  NOT ISPRESENT
> 
>
>
> Palbinder Sandher
> Software Platform Engineer
> 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: loyalty Reddy [mailto:reddy.loya...@gmail.com]
>  Sent: 30 January 2012 14:57
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch
>
> I did remove Wow6432Node and also Win64 element. I just want to know at the
> end if ISPRESENT is empty ot not. HOw do I check that? If ISPRESENT is
> empty, I want to enable a control.
>
> On Mon, Jan 30, 2012 at 2:29 PM, Pally Sandher  >wrote:
>
> > You're trying to search WoW6432Node from a 32-bit process. It doesn't
> > exist in that context. Remove it from your Key & it'll magically* work.
> >
> > *Note: no actual magic is involved as it's a fictional concept which
> > doesn't exist. The Windows-on-Windows subsystem does all the clever stuff
> > redirecting 32-bit processes to the correct places on a 64-bit operating
> > system behind the scenes.
> >
> > Palbinder Sandher
> > Software Platform Engineer
> > 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: loyalty Reddy [mailto:reddy.loya...@gmail.com]
> > Sent: 30 January 2012 12:37
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch
> >
> > Hi,
> >
> > I am using Windows 7, 64 bit.
> > I ma having trouble reading if a key exists in registry. The key that I
> am
> > using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.
> >
> > I am using the following code:
> >
> >  
> >   >  Root="HKLM"
> >  Type="raw"
> >  Key="Software\Wow6432Node\MyApplication\MyApp"
> >  Name="DbPath"
> >  Win64="yes" />
> >  
> >
> > Whether or not DbPath exists, the ISPRESENT is not set. I compared the
> > ISPRESENT value with 1 and #1, nothing works.
> > I also tried not using Wow6432Node, still it fails.
> >
> > what am I doing wrong?
> >
> > Thanks,
> > Reddy
> >
> >
> --
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> >
> --
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _

Re: [WiX-users] RegistrySearch

[Pally Sandher]

  NOT ISPRESENT



Palbinder Sandher 
Software Platform Engineer 
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: loyalty Reddy [mailto:reddy.loya...@gmail.com] 
Sent: 30 January 2012 14:57
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch

I did remove Wow6432Node and also Win64 element. I just want to know at the
end if ISPRESENT is empty ot not. HOw do I check that? If ISPRESENT is
empty, I want to enable a control.

On Mon, Jan 30, 2012 at 2:29 PM, Pally Sandher wrote:

> You're trying to search WoW6432Node from a 32-bit process. It doesn't
> exist in that context. Remove it from your Key & it'll magically* work.
>
> *Note: no actual magic is involved as it's a fictional concept which
> doesn't exist. The Windows-on-Windows subsystem does all the clever stuff
> redirecting 32-bit processes to the correct places on a 64-bit operating
> system behind the scenes.
>
> Palbinder Sandher
> Software Platform Engineer
> 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: loyalty Reddy [mailto:reddy.loya...@gmail.com]
> Sent: 30 January 2012 12:37
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch
>
> Hi,
>
> I am using Windows 7, 64 bit.
> I ma having trouble reading if a key exists in registry. The key that I am
> using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.
>
> I am using the following code:
>
>  
>Root="HKLM"
>  Type="raw"
>  Key="Software\Wow6432Node\MyApplication\MyApp"
>  Name="DbPath"
>  Win64="yes" />
>  
>
> Whether or not DbPath exists, the ISPRESENT is not set. I compared the
> ISPRESENT value with 1 and #1, nothing works.
> I also tried not using Wow6432Node, still it fails.
>
> what am I doing wrong?
>
> Thanks,
> Reddy
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[Albert van Peppen]

You can use ISPRESENT in a condition wherever you like; for example in enabling 
a button in your UI.
Read the tutorial on how to use condition on the appropriate place :)

Best regards,


Albert van Peppen
Senior System Engineer
Insad Grafisch b.v.

-Oorspronkelijk bericht-
Van: loyalty Reddy [mailto:reddy.loya...@gmail.com] 
Verzonden: 30 January 2012 15:51
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] RegistrySearch

And how can I check if ISPRESENT is empty or not?

On Mon, Jan 30, 2012 at 2:16 PM, Albert van Peppen  wrote:

> For a x64 MSI this should work, for a Win32 MSI you should use 
> "Software\MyApplication\MyApp" and let the MSI engine handle the 
> WOW6432 stuff :)
>
> Best regards,
>
>
> Albert van Peppen
> Senior System Engineer
> Insad Grafisch b.v.
>
> -Oorspronkelijk bericht-
> Van: loyalty Reddy [mailto:reddy.loya...@gmail.com]
> Verzonden: 30 January 2012 13:34
> Aan: wix-users@lists.sourceforge.net
> Onderwerp: [WiX-users] RegistrySearch
>
> Hi,
>
> I am using Windows 7, 64 bit.
> I ma having trouble reading if a key exists in registry. The key that 
> I am using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.
>
> I am using the following code:
>
>  
>Root="HKLM"
>  Type="raw"
>  Key="Software\Wow6432Node\MyApplication\MyApp"
>  Name="DbPath"
>  Win64="yes" />
>  
>
> Whether or not DbPath exists, the ISPRESENT is not set. I compared the 
> ISPRESENT value with 1 and #1, nothing works.
> I also tried not using Wow6432Node, still it fails.
>
> what am I doing wrong?
>
> Thanks,
> Reddy
>
> --
>  Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft 
> developers is just $99.99! Visual Studio, SharePoint, SQL - plus 
> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you 
> subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>  Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft 
> developers is just $99.99! Visual Studio, SharePoint, SQL - plus 
> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you 
> subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[loyalty Reddy]

I did remove Wow6432Node and also Win64 element. I just want to know at the
end if ISPRESENT is empty ot not. HOw do I check that? If ISPRESENT is
empty, I want to enable a control.

On Mon, Jan 30, 2012 at 2:29 PM, Pally Sandher wrote:

> You're trying to search WoW6432Node from a 32-bit process. It doesn't
> exist in that context. Remove it from your Key & it'll magically* work.
>
> *Note: no actual magic is involved as it's a fictional concept which
> doesn't exist. The Windows-on-Windows subsystem does all the clever stuff
> redirecting 32-bit processes to the correct places on a 64-bit operating
> system behind the scenes.
>
> Palbinder Sandher
> Software Platform Engineer
> 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: loyalty Reddy [mailto:reddy.loya...@gmail.com]
> Sent: 30 January 2012 12:37
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch
>
> Hi,
>
> I am using Windows 7, 64 bit.
> I ma having trouble reading if a key exists in registry. The key that I am
> using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.
>
> I am using the following code:
>
>  
>Root="HKLM"
>  Type="raw"
>  Key="Software\Wow6432Node\MyApplication\MyApp"
>  Name="DbPath"
>  Win64="yes" />
>  
>
> Whether or not DbPath exists, the ISPRESENT is not set. I compared the
> ISPRESENT value with 1 and #1, nothing works.
> I also tried not using Wow6432Node, still it fails.
>
> what am I doing wrong?
>
> Thanks,
> Reddy
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[loyalty Reddy]

And how can I check if ISPRESENT is empty or not?

On Mon, Jan 30, 2012 at 2:16 PM, Albert van Peppen  wrote:

> For a x64 MSI this should work, for a Win32 MSI you should use
> "Software\MyApplication\MyApp" and let the MSI engine handle the WOW6432
> stuff :)
>
> Best regards,
>
>
> Albert van Peppen
> Senior System Engineer
> Insad Grafisch b.v.
>
> -Oorspronkelijk bericht-
> Van: loyalty Reddy [mailto:reddy.loya...@gmail.com]
> Verzonden: 30 January 2012 13:34
> Aan: wix-users@lists.sourceforge.net
> Onderwerp: [WiX-users] RegistrySearch
>
> Hi,
>
> I am using Windows 7, 64 bit.
> I ma having trouble reading if a key exists in registry. The key that I am
> using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.
>
> I am using the following code:
>
>  
>Root="HKLM"
>  Type="raw"
>  Key="Software\Wow6432Node\MyApplication\MyApp"
>  Name="DbPath"
>  Win64="yes" />
>  
>
> Whether or not DbPath exists, the ISPRESENT is not set. I compared the
> ISPRESENT value with 1 and #1, nothing works.
> I also tried not using Wow6432Node, still it fails.
>
> what am I doing wrong?
>
> Thanks,
> Reddy
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[Pally Sandher]

You're trying to search WoW6432Node from a 32-bit process. It doesn't exist in 
that context. Remove it from your Key & it'll magically* work.

*Note: no actual magic is involved as it's a fictional concept which doesn't 
exist. The Windows-on-Windows subsystem does all the clever stuff redirecting 
32-bit processes to the correct places on a 64-bit operating system behind the 
scenes.

Palbinder Sandher 
Software Platform Engineer 
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: loyalty Reddy [mailto:reddy.loya...@gmail.com] 
Sent: 30 January 2012 12:37
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch

Hi,

I am using Windows 7, 64 bit.
I ma having trouble reading if a key exists in registry. The key that I am
using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.

I am using the following code:

 
  
 

Whether or not DbPath exists, the ISPRESENT is not set. I compared the
ISPRESENT value with 1 and #1, nothing works.
I also tried not using Wow6432Node, still it fails.

what am I doing wrong?

Thanks,
Reddy
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch

[Albert van Peppen]

For a x64 MSI this should work, for a Win32 MSI you should use 
"Software\MyApplication\MyApp" and let the MSI engine handle the WOW6432 stuff 
:)

Best regards,


Albert van Peppen
Senior System Engineer
Insad Grafisch b.v.

-Oorspronkelijk bericht-
Van: loyalty Reddy [mailto:reddy.loya...@gmail.com] 
Verzonden: 30 January 2012 13:34
Aan: wix-users@lists.sourceforge.net
Onderwerp: [WiX-users] RegistrySearch

Hi,

I am using Windows 7, 64 bit.
I ma having trouble reading if a key exists in registry. The key that I am 
using for is in HKLM\Software\Wow6432Node\MyApplication\MyApp.

I am using the following code:

 
  
 

Whether or not DbPath exists, the ISPRESENT is not set. I compared the 
ISPRESENT value with 1 and #1, nothing works.
I also tried not using Wow6432Node, still it fails.

what am I doing wrong?

Thanks,
Reddy
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers is just 
$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style 
Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails, returns C: or Empty

[Leo Koivuniemi]

Hi again,

I believe I solved it (haven't done enough testing yet though!)!
It seems that the property had to be set as "Secure=yes" since otherwise UAC
will not allow it.

Will get back to you if I find that it is not solved. But I just tried an
installation that earlier did not work and now it did!

Thanks for all help so far anyway!
Leo

2011/10/25 Leo Koivuniemi 

> Hi,
> thanks for fast reply!
>
> In the MSI log I can see that it actually finds the correct SETUPFOLDER
> path from registry, but then there are some rows saying:
> Ignoring disallowed property SETUPFOLDER
>
> But I can see that it finds the correct path because further down in the
> log I have something like
>
> AppSearch: Property: SETUPFOLDER, Signature: SETUPFOLDER
> MSI (c) (F0:80) [17:32:47:087]: Note: 1: 2262 2: Signature 3: -2147287038
> MSI (c) (F0:80) [17:32:47:087]: PROPERTY CHANGE: Adding SETUPFOLDER
> property. Its value is '\\rrdb\xxx\xxx\Setup'.
>
> And then an .ini file is written and it now the log (almost at the very
> end) says:
>
> MSI (s) (3C:44) [17:34:07:697]: Executing op:
> IniWriteRemoveValue(Section=INSTANCE,Key=SetupFolder,,Mode=0)
> WriteIniValues: File: xxx.ini,  Section: INSTANCE,  Key: SetupFolder,
> Value:
>
> Note that the value: is empty.
>
> And then at the very very end of the log file it states the properties:
>
> Property(C): SETUPFOLDER = \\rrdb\xxx\xxx\Setup
>
> So again it has the correct value but it does not want to use it when
> specifying the target of the shortcut.
>
> Hope this gives you some idea...
>
> Thankful for help!
>
> 2011/10/25 Rob Mensching 
>
>> What does the verbose log file show?
>>
>> On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi <
>> universalserial...@gmail.com> wrote:
>>
>> > Hello all,
>> >
>> > I am having some problems with an installation using Wix v3
>> > During install of application I run
>> >
>> > 
>> > > > Key="SOFTWARE\$(var.Company)\$(var.Product)\Common" Name="SetupFolder"
>> > Type="raw" />
>> > 
>> >
>> > SETUPFOLDER is later used for setting the target of a shortcut in the
>> start
>> > menu. This works when I install or reinstall by running my bootstrapper
>> > setup.exe which then starts the MSI package. But when applying patches
>> for
>> > instance or bypassig the setup.exe and running the MSI directly, then
>> the
>> > registry search returns C: or is just empty. When I check that path in
>> > registry using regedit then I do find the correct value there but for
>> some
>> > reason the RegistrySearch fails and I can't figure out why.
>> >
>> > Notable is that this error does not exist in Windows XP, but now as I
>> have
>> > been porting it to Windows 7 I noticed this problem. So basically the
>> code
>> > should work, but it doesn't do that in Win7 (only works if I go through
>> the
>> > bootstrapper exe)
>> >
>> > Any suggestions?
>> >
>> > Thanks!
>> >
>> > Leo
>> >
>> >
>> --
>> > The demand for IT networking professionals continues to grow, and the
>> > demand for specialized networking skills is growing even more rapidly.
>> > Take a complimentary Learning@Cisco Self-Assessment and learn
>> > about Cisco certifications, training, and career opportunities.
>> > http://p.sf.net/sfu/cisco-dev2dev
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>> >
>>
>>
>> --
>> virtually, Rob Mensching - http://RobMensching.com LLC
>>
>> --
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails, returns C: or Empty

[Leo Koivuniemi]

Hi,
thanks for fast reply!

In the MSI log I can see that it actually finds the correct SETUPFOLDER path
from registry, but then there are some rows saying:
Ignoring disallowed property SETUPFOLDER

But I can see that it finds the correct path because further down in the log
I have something like

AppSearch: Property: SETUPFOLDER, Signature: SETUPFOLDER
MSI (c) (F0:80) [17:32:47:087]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (c) (F0:80) [17:32:47:087]: PROPERTY CHANGE: Adding SETUPFOLDER
property. Its value is '\\rrdb\xxx\xxx\Setup'.

And then an .ini file is written and it now the log (almost at the very end)
says:

MSI (s) (3C:44) [17:34:07:697]: Executing op:
IniWriteRemoveValue(Section=INSTANCE,Key=SetupFolder,,Mode=0)
WriteIniValues: File: xxx.ini,  Section: INSTANCE,  Key: SetupFolder,
Value:

Note that the value: is empty.

And then at the very very end of the log file it states the properties:

Property(C): SETUPFOLDER = \\rrdb\xxx\xxx\Setup

So again it has the correct value but it does not want to use it when
specifying the target of the shortcut.

Hope this gives you some idea...

Thankful for help!

2011/10/25 Rob Mensching 

> What does the verbose log file show?
>
> On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi <
> universalserial...@gmail.com> wrote:
>
> > Hello all,
> >
> > I am having some problems with an installation using Wix v3
> > During install of application I run
> >
> > 
> >  > Key="SOFTWARE\$(var.Company)\$(var.Product)\Common" Name="SetupFolder"
> > Type="raw" />
> > 
> >
> > SETUPFOLDER is later used for setting the target of a shortcut in the
> start
> > menu. This works when I install or reinstall by running my bootstrapper
> > setup.exe which then starts the MSI package. But when applying patches
> for
> > instance or bypassig the setup.exe and running the MSI directly, then the
> > registry search returns C: or is just empty. When I check that path in
> > registry using regedit then I do find the correct value there but for
> some
> > reason the RegistrySearch fails and I can't figure out why.
> >
> > Notable is that this error does not exist in Windows XP, but now as I
> have
> > been porting it to Windows 7 I noticed this problem. So basically the
> code
> > should work, but it doesn't do that in Win7 (only works if I go through
> the
> > bootstrapper exe)
> >
> > Any suggestions?
> >
> > Thanks!
> >
> > Leo
> >
> >
> --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
>
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails, returns C: or Empty

[Rob Mensching]

What does the verbose log file show?

On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi <
universalserial...@gmail.com> wrote:

> Hello all,
>
> I am having some problems with an installation using Wix v3
> During install of application I run
>
> 
>  Key="SOFTWARE\$(var.Company)\$(var.Product)\Common" Name="SetupFolder"
> Type="raw" />
> 
>
> SETUPFOLDER is later used for setting the target of a shortcut in the start
> menu. This works when I install or reinstall by running my bootstrapper
> setup.exe which then starts the MSI package. But when applying patches for
> instance or bypassig the setup.exe and running the MSI directly, then the
> registry search returns C: or is just empty. When I check that path in
> registry using regedit then I do find the correct value there but for some
> reason the RegistrySearch fails and I can't figure out why.
>
> Notable is that this error does not exist in Windows XP, but now as I have
> been porting it to Windows 7 I noticed this problem. So basically the code
> should work, but it doesn't do that in Win7 (only works if I go through the
> bootstrapper exe)
>
> Any suggestions?
>
> Thanks!
>
> Leo
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch under Wow6432Node

[Sharad Patel]

We had a similar requirement. This is what we ended up using...

---

http://schemas.microsoft.com/wix/2006/wi"; >
  
  
  

  
  

  

  

  

---

Cheers
Sharad Patel
Winscribe NZ

-Original Message-
From: Deepika Gakhar [mailto:deepi...@microsoft.com] 
Sent: Wednesday, 16 February 2011 8:24 a.m.
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch under Wow6432Node

Hi,

I'm trying to set a property based on the registry key search. The
registry key as seen in reg editor is
"HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\VC\VCRedist\x64"

I tried 2 combinations -

1.   Set win64="no" and specify path without explicit Wow6432Node.



  


2.  Set win64="no" and specify path with explicit Wow6432Node in the
path.

 

  
But none of them work and the property never gets set. Could someone
please guide me as to how I could correctly search the reg key.

Thanks in advance.

Best Regards,
Deepika

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch for REG_DWORD handling using WiX Installer

[Rob Mensching]

PS: Burn's RegistrySearch returns the value expect. 

On Mon, Nov 22, 2010 at 9:57 AM, Neil Sleightholm wrote:

> As Rob said it is not supported in Windows Installer but it quite a
> simple custom action in DTF. I had a similar problem reading the SQL
> port my instance was using, here is an example:
>
>public static ActionResult ReadSqlTcpPort(Session session)
>{
>session.Log("Begin ReadSqlTcpPort");
>
>using (RegistryKey reg =
> Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Microsoft SQL
> Server\MYINSTANCE\MSSQLServer\SuperSocketNetLib\Tcp"))
>{
>// If key is found, look for value
>if (null != reg)
>{
>session["SqlTcpPort"] = reg.GetValue("TcpPort",
> string.Empty).ToString();
>}
>else
>{
>session["SqlTcpPort"] = string.Empty;
>}
>}
>
>return ActionResult.Success;
>}
>
> Neil
>
> -Original Message-
> From: Brian Pang [mailto:bria...@yahoo.com]
> Sent: 19 November 2010 22:16
> To: WiX-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch for REG_DWORD handling using WiX
> Installer
>
> Hi,
>
> RegistrySearch for REG_DWORD handling using WiX Installer.
>
> After the RegistrySearch it returns REG_SZ with "#1".
> How do you resolve this issue so it will set the return type to an
> REG_DWORD and
> value of 1?
>
> Thanks in advance!
>  Id="idPORT"
> Key="SOFTWARE\Company\Product"  Name="Port" Root="HKLM"
> Type="raw" />
>Key="SOFTWARE\Company\Product"  Action="create">
>  Name="Port" Value="#[PORT]" Type="integer" /> 
> 
>
>
>
>
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
>  ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch for REG_DWORD handling using WiX Installer

[Neil Sleightholm]

As Rob said it is not supported in Windows Installer but it quite a
simple custom action in DTF. I had a similar problem reading the SQL
port my instance was using, here is an example:

public static ActionResult ReadSqlTcpPort(Session session)
{
session.Log("Begin ReadSqlTcpPort");

using (RegistryKey reg =
Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Microsoft SQL
Server\MYINSTANCE\MSSQLServer\SuperSocketNetLib\Tcp"))
{
// If key is found, look for value 
if (null != reg)
{
session["SqlTcpPort"] = reg.GetValue("TcpPort",
string.Empty).ToString();
}
else
{
session["SqlTcpPort"] = string.Empty;
}
}

return ActionResult.Success;
}

Neil

-Original Message-
From: Brian Pang [mailto:bria...@yahoo.com] 
Sent: 19 November 2010 22:16
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch for REG_DWORD handling using WiX
Installer

Hi,

RegistrySearch for REG_DWORD handling using WiX Installer.  

After the RegistrySearch it returns REG_SZ with "#1". 
How do you resolve this issue so it will set the return type to an
REG_DWORD and 
value of 1?

Thanks in advance!
  
  
 




  

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

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch for REG_DWORD handling using WiX Installer

[Rob Mensching]

Sadly, the Windows Installer doesn't support that.

On Fri, Nov 19, 2010 at 2:16 PM, Brian Pang  wrote:

> Hi,
>
> RegistrySearch for REG_DWORD handling using WiX Installer.
>
> After the RegistrySearch it returns REG_SZ with "#1".
> How do you resolve this issue so it will set the return type to an
> REG_DWORD and
> value of 1?
>
> Thanks in advance!
>  Key="SOFTWARE\Company\Product"  Name="Port" Root="HKLM"
> Type="raw" />
>Key="SOFTWARE\Company\Product"  Action="create">
>Name="Port" Value="#[PORT]" Type="integer" /> 
> 
>
>
>
>
>
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


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

Re: [WiX-users] RegistrySearch element

[Rob Hamflett]

You could set the property's initial value to something like MY_DUMMY_VALUE and 
then check to see if 
the property is still equal to it after the registry searching.

Rob

On 26/09/2010 18:39, Sean Farrow wrote:
> Hi:
> I need to use the RegistrySearch element in a property. I need to look a key 
> who's default key has no default value (regedit show "value not set"). What 
> will the property be set to? I'll need to use this property in a launch 
> condition.  Should I do this or could I use a custom action to set the 
> property, and do the registry look up myself.
> Any help appreciated.
> Sean.
> --
> 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


--
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] RegistrySearch element

[Bob Arnson]

  On 26-Sep-10 13:39, Sean Farrow wrote:
> I need to use the RegistrySearch element in a property. I need to look a key 
> who's default key has no default value (regedit show "value not set"). What 
> will the property be set to?

Nothing. See the RegLocator doc.

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

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

Ok, so I thought that I provide the solution of how to use the
StringTools.dll contained in the msiext found
http://msiext.codeplex.com/releases/view/39468 as I myself spend to much
time to get it to work!! and maybe this could help someone else..
Put the StringTools.dll in the same folder as the .wxs file.
Finally put those tags into your .wxs file. The String_Replace documentation
can be found here..
http://code.dblock.org/Source/msiext/1.2/Docs/_string_tools_impl_8h.html#a4e624060174da1bf53aea402c2e29d7a
STRING_VALUE_FROM = "C:\Program Files (x86)\Microsoft Help
Viewer\v1.0\HelpLibManager.exe" .. this is the string faulty converted when
read from registry containing the " (x86)" string we want to remove.
*STRING_REPLACE_FROM = '"(x86)\" ... this is what should be replaced
**STRING_REPLACE_TO = "\" ... this is what we should replace with*
STRING_VALUE_TO = ... this will be filled with the replaced string after the
String_Replace CustomAction have been run...




  












...
  STRING_VALUE_FROM=""
  String_Replace=""
...
  $MainDll
= 2
  $MainDll >
2


I think thats all... glhf..

/Jimmie

2010/5/14 Matt Johnson 

> Not sure why.  I had the same problem.  I used the StringTools custom
> action from the msiext project to take the " (x86) back out.  If there's an
> easier way, I'd be glad to know.
>
> BTW - I checked that specific key, and it is indeed just "Program Files",
> in both the regular x64 root and the wow x86 key - so it's not that it's
> pulling from the wrong place.
>
> Perhaps there's a property to set to tell MSI not to do this replacement?
>
> Matt Johnson MCPD, MCTS, MCSD, MCDBA
> Director of Application Development
> Time America, Inc.
> ma...@timeamerica.com | www.timeamerica.com
>
>
> -Original Message-
> From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Friday, May 14, 2010 7:42 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch converts value data
>
> Hi
>
> Anyone who can tell me why my RegistrySearch converts the value contained
> in
> the registry?
>
>
>   Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>
>
> The actual value in registry is...
> AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>
> But according to the log file upon installation C:\Program Files\Microsoft
> Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft Help
> Viewer\v1.0\
> when using it in a custom action
>
> Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
>
> from log..
> MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> property. Its value is 'C:\Program Files (x86)\Microsoft Help
> Viewer\v1.0\HelpLibManager.exe'
>
> The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>
> So this seems like a bug where all strings containing Program Files found
> in
> registry converts to Program Files (x86)
>
> /Jimmie
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[Castro, Edwin G. (Hillsboro)]

Total Commander must be executing the 32-bit version of cmd.exe. Most likely 
that is happening because Total Commander is a 32-bit app.

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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Tuesday, May 18, 2010 8:52 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch converts value data
> 
> ok, now I know what happend... When I start a cmd prompt from inside
> Total
> Commander... the %ProgramFiles% folder maps to C:\Program Files (x86)
> ...
> but when the cmd prompt is started from Windows ... everything is
> correct..
> Total Commander is a 32-bit program ... maybe thats why?!? ... weired
> though...
> 
> /Jimmie
> 
> 2010/5/18 Jimmie Eriksson 
> 
> > Jesus, I just check my coworkers computers and all of them map
> > %ProgramFiles% to C:\Program Files ... I was wrong... I wonder how
> this
> > happend!?
> > I can't remember ever changing this system variable... which seems
> like a
> > very bad idéa..
> >
> > 2010/5/18 Jimmie Eriksson 
> >
> > %PROGRAMFILES% maps to C:\Program Files (x86) on a 64-bit system.
> >> On my system the variable %ProgramW6432% maps to C:\Program Files.
> But
> >> that variable ain't existing on a 32-bit system.
> >>
> >> /Jimmie
> >>
> >> 2010/5/16 Kristoffer Danielsson 
> >>
> >>
> >>> What happens if you specify %PROGRAMFILES%? It always maps to
> C:\Program
> >>> Files.
> >>>
> >>> > Date: Sun, 16 May 2010 19:07:32 +0200
> >>> > From: eriksson.jim...@gmail.com
> >>> > To: wix-users@lists.sourceforge.net
> >>> > Subject: Re: [WiX-users] RegistrySearch converts value data
> >>> >
> >>> > Can you explain the StringTools solution?
> >>> >
> >>> > 2010/5/14 Matt Johnson 
> >>> >
> >>> > > Not sure why. I had the same problem. I used the StringTools
> custom
> >>> > > action from the msiext project to take the " (x86) back out. If
> >>> there's an
> >>> > > easier way, I'd be glad to know.
> >>> > >
> >>> > > BTW - I checked that specific key, and it is indeed just
> "Program
> >>> Files",
> >>> > > in both the regular x64 root and the wow x86 key - so it's not
> that
> >>> it's
> >>> > > pulling from the wrong place.
> >>> > >
> >>> > > Perhaps there's a property to set to tell MSI not to do this
> >>> replacement?
> >>> > >
> >>> > > Matt Johnson MCPD, MCTS, MCSD, MCDBA
> >>> > > Director of Application Development
> >>> > > Time America, Inc.
> >>> > > ma...@timeamerica.com | www.timeamerica.com
> >>> > >
> >>> > >
> >>> > > -Original Message-
> >>> > > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> >>> > > Sent: Friday, May 14, 2010 7:42 AM
> >>> > > To: wix-users@lists.sourceforge.net
> >>> > > Subject: [WiX-users] RegistrySearch converts value data
> >>> > >
> >>> > > Hi
> >>> > >
> >>> > > Anyone who can tell me why my RegistrySearch converts the value
> >>> contained
> >>> > > in
> >>> > > the registry?
> >>> > >
> >>> > > 
> >>> > >  >>> > > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> >>> > > 
> >>> > >
> >>> > > The actual value in registry is...
> >>> > > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> >>> > >
> >>> > > But according to the log file upon installation C:\Program
> >>> Files\Microsoft
> >>> > > Help Viewer\v1.0\ converts into C:\Program Files
> *(x86)*\Microsoft
> >>> Help
> >>> > > Viewer\v1.0\
> >>> > > when using it in a custom action
> >>> > >
>

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

ok, now I know what happend... When I start a cmd prompt from inside Total
Commander... the %ProgramFiles% folder maps to C:\Program Files (x86) ...
but when the cmd prompt is started from Windows ... everything is correct..
Total Commander is a 32-bit program ... maybe thats why?!? ... weired
though...

/Jimmie

2010/5/18 Jimmie Eriksson 

> Jesus, I just check my coworkers computers and all of them map
> %ProgramFiles% to C:\Program Files ... I was wrong... I wonder how this
> happend!?
> I can't remember ever changing this system variable... which seems like a
> very bad idéa..
>
> 2010/5/18 Jimmie Eriksson 
>
> %PROGRAMFILES% maps to C:\Program Files (x86) on a 64-bit system.
>> On my system the variable %ProgramW6432% maps to C:\Program Files. But
>> that variable ain't existing on a 32-bit system.
>>
>> /Jimmie
>>
>> 2010/5/16 Kristoffer Danielsson 
>>
>>
>>> What happens if you specify %PROGRAMFILES%? It always maps to C:\Program
>>> Files.
>>>
>>> > Date: Sun, 16 May 2010 19:07:32 +0200
>>> > From: eriksson.jim...@gmail.com
>>> > To: wix-users@lists.sourceforge.net
>>> > Subject: Re: [WiX-users] RegistrySearch converts value data
>>> >
>>> > Can you explain the StringTools solution?
>>> >
>>> > 2010/5/14 Matt Johnson 
>>> >
>>> > > Not sure why. I had the same problem. I used the StringTools custom
>>> > > action from the msiext project to take the " (x86) back out. If
>>> there's an
>>> > > easier way, I'd be glad to know.
>>> > >
>>> > > BTW - I checked that specific key, and it is indeed just "Program
>>> Files",
>>> > > in both the regular x64 root and the wow x86 key - so it's not that
>>> it's
>>> > > pulling from the wrong place.
>>> > >
>>> > > Perhaps there's a property to set to tell MSI not to do this
>>> replacement?
>>> > >
>>> > > Matt Johnson MCPD, MCTS, MCSD, MCDBA
>>> > > Director of Application Development
>>> > > Time America, Inc.
>>> > > ma...@timeamerica.com | www.timeamerica.com
>>> > >
>>> > >
>>> > > -Original Message-
>>> > > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
>>> > > Sent: Friday, May 14, 2010 7:42 AM
>>> > > To: wix-users@lists.sourceforge.net
>>> > > Subject: [WiX-users] RegistrySearch converts value data
>>> > >
>>> > > Hi
>>> > >
>>> > > Anyone who can tell me why my RegistrySearch converts the value
>>> contained
>>> > > in
>>> > > the registry?
>>> > >
>>> > > 
>>> > > >> > > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>>> > > 
>>> > >
>>> > > The actual value in registry is...
>>> > > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>>> > >
>>> > > But according to the log file upon installation C:\Program
>>> Files\Microsoft
>>> > > Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft
>>> Help
>>> > > Viewer\v1.0\
>>> > > when using it in a custom action
>>> > >
>>> > > >> Execute="immediate"
>>> > > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe"
>>> />
>>> > >
>>> > > from log..
>>> > > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
>>> > > property. Its value is 'C:\Program Files (x86)\Microsoft Help
>>> > > Viewer\v1.0\HelpLibManager.exe'
>>> > >
>>> > > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>>> > >
>>> > > So this seems like a bug where all strings containing Program Files
>>> found
>>> > > in
>>> > > registry converts to Program Files (x86)
>>> > >
>>> > > /Jimmie
>>> > >
>>> > >
>>> --
>>> > >
>>> > > ___
>>> > > WiX-users mailing list
>>> > > WiX-users@lists.sourceforge.net
>>> > > https://lists.sourceforge.net/lists/listinfo/wix-users
>>> > >
>>> > >
>>> > >
>>> --
>>> > >
>>> > > ___
>>> > > WiX-users mailing list
>>> > > WiX-users@lists.sourceforge.net
>>> > > https://lists.sourceforge.net/lists/listinfo/wix-users
>>> > >
>>> >
>>> --
>>> >
>>> > ___
>>> > WiX-users mailing list
>>> > WiX-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>> _
>>> Hotmail i mobilen på 5 sekunder!
>>>
>>> http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx
>>>
>>> --
>>>
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>
>>
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

Jesus, I just check my coworkers computers and all of them map
%ProgramFiles% to C:\Program Files ... I was wrong... I wonder how this
happend!?
I can't remember ever changing this system variable... which seems like a
very bad idéa..

2010/5/18 Jimmie Eriksson 

> %PROGRAMFILES% maps to C:\Program Files (x86) on a 64-bit system.
> On my system the variable %ProgramW6432% maps to C:\Program Files. But that
> variable ain't existing on a 32-bit system.
>
> /Jimmie
>
> 2010/5/16 Kristoffer Danielsson 
>
>
>> What happens if you specify %PROGRAMFILES%? It always maps to C:\Program
>> Files.
>>
>> > Date: Sun, 16 May 2010 19:07:32 +0200
>> > From: eriksson.jim...@gmail.com
>> > To: wix-users@lists.sourceforge.net
>> > Subject: Re: [WiX-users] RegistrySearch converts value data
>> >
>> > Can you explain the StringTools solution?
>> >
>> > 2010/5/14 Matt Johnson 
>> >
>> > > Not sure why. I had the same problem. I used the StringTools custom
>> > > action from the msiext project to take the " (x86) back out. If
>> there's an
>> > > easier way, I'd be glad to know.
>> > >
>> > > BTW - I checked that specific key, and it is indeed just "Program
>> Files",
>> > > in both the regular x64 root and the wow x86 key - so it's not that
>> it's
>> > > pulling from the wrong place.
>> > >
>> > > Perhaps there's a property to set to tell MSI not to do this
>> replacement?
>> > >
>> > > Matt Johnson MCPD, MCTS, MCSD, MCDBA
>> > > Director of Application Development
>> > > Time America, Inc.
>> > > ma...@timeamerica.com | www.timeamerica.com
>> > >
>> > >
>> > > -Original Message-
>> > > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
>> > > Sent: Friday, May 14, 2010 7:42 AM
>> > > To: wix-users@lists.sourceforge.net
>> > > Subject: [WiX-users] RegistrySearch converts value data
>> > >
>> > > Hi
>> > >
>> > > Anyone who can tell me why my RegistrySearch converts the value
>> contained
>> > > in
>> > > the registry?
>> > >
>> > > 
>> > > > > > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>> > > 
>> > >
>> > > The actual value in registry is...
>> > > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>> > >
>> > > But according to the log file upon installation C:\Program
>> Files\Microsoft
>> > > Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft
>> Help
>> > > Viewer\v1.0\
>> > > when using it in a custom action
>> > >
>> > > > > > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
>> > >
>> > > from log..
>> > > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
>> > > property. Its value is 'C:\Program Files (x86)\Microsoft Help
>> > > Viewer\v1.0\HelpLibManager.exe'
>> > >
>> > > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>> > >
>> > > So this seems like a bug where all strings containing Program Files
>> found
>> > > in
>> > > registry converts to Program Files (x86)
>> > >
>> > > /Jimmie
>> > >
>> > >
>> --
>> > >
>> > > ___
>> > > WiX-users mailing list
>> > > WiX-users@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/wix-users
>> > >
>> > >
>> > >
>> --
>> > >
>> > > ___
>> > > WiX-users mailing list
>> > > WiX-users@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/wix-users
>> > >
>> >
>> --
>> >
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> _
>> Hotmail i mobilen på 5 sekunder!
>>
>> http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx
>>
>> --
>>
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[Pally Sandher]

I fully suspect WIN64DUALFOLDERS would still get in your way if you tried to 
use %ProgramFiles (which on the XP64 machine I'm on right now maps to 
C:\Program Files\ while %ProgramFiles(x86) maps to C:\Program Files (x86)\ FYI) 
in a x86 package on an x64 system.

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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: 18 May 2010 15:13
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch converts value data

%PROGRAMFILES% maps to C:\Program Files (x86) on a 64-bit system.
On my system the variable %ProgramW6432% maps to C:\Program Files. But that 
variable ain't existing on a 32-bit system.

/Jimmie

2010/5/16 Kristoffer Danielsson 

>
> What happens if you specify %PROGRAMFILES%? It always maps to 
> C:\Program Files.
>
> > Date: Sun, 16 May 2010 19:07:32 +0200
> > From: eriksson.jim...@gmail.com
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] RegistrySearch converts value data
> >
> > Can you explain the StringTools solution?
> >
> > 2010/5/14 Matt Johnson 
> >
> > > Not sure why. I had the same problem. I used the StringTools 
> > > custom action from the msiext project to take the " (x86) back 
> > > out. If there's
> an
> > > easier way, I'd be glad to know.
> > >
> > > BTW - I checked that specific key, and it is indeed just "Program
> Files",
> > > in both the regular x64 root and the wow x86 key - so it's not 
> > > that
> it's
> > > pulling from the wrong place.
> > >
> > > Perhaps there's a property to set to tell MSI not to do this
> replacement?
> > >
> > > Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application 
> > > Development Time America, Inc.
> > > ma...@timeamerica.com | www.timeamerica.com
> > >
> > >
> > > -Original Message-
> > > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > > Sent: Friday, May 14, 2010 7:42 AM
> > > To: wix-users@lists.sourceforge.net
> > > Subject: [WiX-users] RegistrySearch converts value data
> > >
> > > Hi
> > >
> > > Anyone who can tell me why my RegistrySearch converts the value
> contained
> > > in
> > > the registry?
> > >
> > > 
> > >  > > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' /> 
> > >
> > > The actual value in registry is...
> > > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> > >
> > > But according to the log file upon installation C:\Program
> Files\Microsoft
> > > Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft 
> > > Help Viewer\v1.0\ when using it in a custom action
> > >
> > >  > > Property="HELPInstaller" 
> > > Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> > >
> > > from log..
> > > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding 
> > > HELPInstaller property. Its value is 'C:\Program Files 
> > > (x86)\Microsoft Help Viewer\v1.0\HelpLibManager.exe'
> > >
> > > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
> > >
> > > So this seems like a bug where all strings containing Program 
> > > Files
> found
> > > in
> > > registry converts to Program Files (x86)
> > >
> > > /Jimmie
> > >
> > >
> --
> 
> > >
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> --
> 
> > >
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> --
&g

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

%PROGRAMFILES% maps to C:\Program Files (x86) on a 64-bit system.
On my system the variable %ProgramW6432% maps to C:\Program Files. But that
variable ain't existing on a 32-bit system.

/Jimmie

2010/5/16 Kristoffer Danielsson 

>
> What happens if you specify %PROGRAMFILES%? It always maps to C:\Program
> Files.
>
> > Date: Sun, 16 May 2010 19:07:32 +0200
> > From: eriksson.jim...@gmail.com
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] RegistrySearch converts value data
> >
> > Can you explain the StringTools solution?
> >
> > 2010/5/14 Matt Johnson 
> >
> > > Not sure why. I had the same problem. I used the StringTools custom
> > > action from the msiext project to take the " (x86) back out. If there's
> an
> > > easier way, I'd be glad to know.
> > >
> > > BTW - I checked that specific key, and it is indeed just "Program
> Files",
> > > in both the regular x64 root and the wow x86 key - so it's not that
> it's
> > > pulling from the wrong place.
> > >
> > > Perhaps there's a property to set to tell MSI not to do this
> replacement?
> > >
> > > Matt Johnson MCPD, MCTS, MCSD, MCDBA
> > > Director of Application Development
> > > Time America, Inc.
> > > ma...@timeamerica.com | www.timeamerica.com
> > >
> > >
> > > -Original Message-
> > > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > > Sent: Friday, May 14, 2010 7:42 AM
> > > To: wix-users@lists.sourceforge.net
> > > Subject: [WiX-users] RegistrySearch converts value data
> > >
> > > Hi
> > >
> > > Anyone who can tell me why my RegistrySearch converts the value
> contained
> > > in
> > > the registry?
> > >
> > > 
> > >  > > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> > > 
> > >
> > > The actual value in registry is...
> > > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> > >
> > > But according to the log file upon installation C:\Program
> Files\Microsoft
> > > Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft Help
> > > Viewer\v1.0\
> > > when using it in a custom action
> > >
> > >  > > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> > >
> > > from log..
> > > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> > > property. Its value is 'C:\Program Files (x86)\Microsoft Help
> > > Viewer\v1.0\HelpLibManager.exe'
> > >
> > > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
> > >
> > > So this seems like a bug where all strings containing Program Files
> found
> > > in
> > > registry converts to Program Files (x86)
> > >
> > > /Jimmie
> > >
> > >
> --
> > >
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> --
> > >
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> --
> >
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
> _
> Hotmail i mobilen på 5 sekunder!
>
> http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[dB .]

Maybe you can achieve what you want by retrieving one of the "special" folder 
paths. MsiExt 1.2 has a new CA called Win32_GetSpecialFolderPath that wraps 
SHGetSpecialFolder.

http://msiext.codeplex.com/releases/view/39468 

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



-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, May 17, 2010 3:08 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] RegistrySearch converts value data

What are you doing with HELPINSTALLERDIR? How are you consuming it?

-Original Message-
From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: Sunday, May 16, 2010 3:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch converts value data

No, but I do a registry search to find out where microsoft have their
HelpLibManager.exe installed.


  


Then my thought was that the variable HELPINSTALLDIR after the registry
search should map to "C:\Program Files\Microsoft Help Viewer\v1.0\" where it
seems to be located both on win32 systems like WinXP and Win64 systems like
Windows Vista 64-bit and Windows 7 64-bit. So in this case microsoft have
both a 32-bit and a 64-bit version of their HelpLibManager.exe which they
install depending on the target system and They tell me where on my disk it
is installed by putting it in the registry which I then extract but then
this WIN64DUALFOLDERS thingie overrides the value extracted from registry
beliving to know better... Thats my problem...

2010/5/15 Blair 

> Do you have a directory named HELPINSTALLDIR?
>
> -Original Message-
> From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Friday, May 14, 2010 9:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch converts value data
>
> Ok, so you're right about the win64dualfolders thingie..
>
> WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters
> in
> 'C:\Program Files\Microsoft Help Viewer\v1.0\' folder path. (mask argument
> =
> 0, the folder pair's iSwapAttrib member = 0).
>
> But isn't it odd, depending on target system, it overrides my wish to
> simply
> read the registry value... I'm not intressted in getting overriden by the
> system who thinks it knows better.
> Can I again override the behavior.. I'm not intressted to support one
> 32-bit
> and another 64-bit installer. One installer is problem enough...
>
> The folder always seems to be
> C:\Program Files\Microsoft Help Viewer\v1.0\
> on both 64- and 32-bit os
> /Jimmie
>
> 2010/5/14 Pally Sandher 
>
> > Not a bug, not even close to a bug. You're using an x86 package on an
> > x64 system.
> >
> > Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
> > what's changing the property.
> >
> > If you want to access x64 specific locations like C:\Program
> > Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
> > x64 package. Your code will give you what you're expecting on an x86
> > system without a problem but WOW64 is intercepting it on x64 systems.
> >
> > 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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > Sent: 14 May 2010 15:42
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch converts value data
> >
> > Hi
> >
> > Anyone who can tell me why my RegistrySearch converts the value
> > contained in the registry?
> >
> >
> >   > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> >
> >
> > The actual value in registry is...
> > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > But according to the log file upon installation C:\Program
> > Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
> > *(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action
> >
> > > Execute="immediate"
> > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> >
> > from log..
> > MSI 

Re: [WiX-users] RegistrySearch converts value data

[Blair]

What are you doing with HELPINSTALLERDIR? How are you consuming it?

-Original Message-
From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: Sunday, May 16, 2010 3:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch converts value data

No, but I do a registry search to find out where microsoft have their
HelpLibManager.exe installed.


  


Then my thought was that the variable HELPINSTALLDIR after the registry
search should map to "C:\Program Files\Microsoft Help Viewer\v1.0\" where it
seems to be located both on win32 systems like WinXP and Win64 systems like
Windows Vista 64-bit and Windows 7 64-bit. So in this case microsoft have
both a 32-bit and a 64-bit version of their HelpLibManager.exe which they
install depending on the target system and They tell me where on my disk it
is installed by putting it in the registry which I then extract but then
this WIN64DUALFOLDERS thingie overrides the value extracted from registry
beliving to know better... Thats my problem...

2010/5/15 Blair 

> Do you have a directory named HELPINSTALLDIR?
>
> -Original Message-
> From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Friday, May 14, 2010 9:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch converts value data
>
> Ok, so you're right about the win64dualfolders thingie..
>
> WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters
> in
> 'C:\Program Files\Microsoft Help Viewer\v1.0\' folder path. (mask argument
> =
> 0, the folder pair's iSwapAttrib member = 0).
>
> But isn't it odd, depending on target system, it overrides my wish to
> simply
> read the registry value... I'm not intressted in getting overriden by the
> system who thinks it knows better.
> Can I again override the behavior.. I'm not intressted to support one
> 32-bit
> and another 64-bit installer. One installer is problem enough...
>
> The folder always seems to be
> C:\Program Files\Microsoft Help Viewer\v1.0\
> on both 64- and 32-bit os
> /Jimmie
>
> 2010/5/14 Pally Sandher 
>
> > Not a bug, not even close to a bug. You're using an x86 package on an
> > x64 system.
> >
> > Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
> > what's changing the property.
> >
> > If you want to access x64 specific locations like C:\Program
> > Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
> > x64 package. Your code will give you what you're expecting on an x86
> > system without a problem but WOW64 is intercepting it on x64 systems.
> >
> > 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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > Sent: 14 May 2010 15:42
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch converts value data
> >
> > Hi
> >
> > Anyone who can tell me why my RegistrySearch converts the value
> > contained in the registry?
> >
> >
> >   > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> >
> >
> > The actual value in registry is...
> > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > But according to the log file upon installation C:\Program
> > Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
> > *(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action
> >
> > > Execute="immediate"
> > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> >
> > from log..
> > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> > property. Its value is 'C:\Program Files (x86)\Microsoft Help
> > Viewer\v1.0\HelpLibManager.exe'
> >
> > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > So this seems like a bug where all strings containing Program Files
> > found in reg

Re: [WiX-users] RegistrySearch converts value data

[Kristoffer Danielsson]

What happens if you specify %PROGRAMFILES%? It always maps to C:\Program Files.
 
> Date: Sun, 16 May 2010 19:07:32 +0200
> From: eriksson.jim...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] RegistrySearch converts value data
> 
> Can you explain the StringTools solution?
> 
> 2010/5/14 Matt Johnson 
> 
> > Not sure why. I had the same problem. I used the StringTools custom
> > action from the msiext project to take the " (x86) back out. If there's an
> > easier way, I'd be glad to know.
> >
> > BTW - I checked that specific key, and it is indeed just "Program Files",
> > in both the regular x64 root and the wow x86 key - so it's not that it's
> > pulling from the wrong place.
> >
> > Perhaps there's a property to set to tell MSI not to do this replacement?
> >
> > Matt Johnson MCPD, MCTS, MCSD, MCDBA
> > Director of Application Development
> > Time America, Inc.
> > ma...@timeamerica.com | www.timeamerica.com
> >
> >
> > -Original Message-
> > From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > Sent: Friday, May 14, 2010 7:42 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch converts value data
> >
> > Hi
> >
> > Anyone who can tell me why my RegistrySearch converts the value contained
> > in
> > the registry?
> >
> > 
> >  > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> > 
> >
> > The actual value in registry is...
> > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > But according to the log file upon installation C:\Program Files\Microsoft
> > Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft Help
> > Viewer\v1.0\
> > when using it in a custom action
> >
> >  > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> >
> > from log..
> > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> > property. Its value is 'C:\Program Files (x86)\Microsoft Help
> > Viewer\v1.0\HelpLibManager.exe'
> >
> > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > So this seems like a bug where all strings containing Program Files found
> > in
> > registry converts to Program Files (x86)
> >
> > /Jimmie
> >
> > --
> >
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > --
> >
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> --
> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
  
_
Hotmail i mobilen på 5 sekunder!
http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx
--

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

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

Can you explain the StringTools solution?

2010/5/14 Matt Johnson 

> Not sure why.  I had the same problem.  I used the StringTools custom
> action from the msiext project to take the " (x86) back out.  If there's an
> easier way, I'd be glad to know.
>
> BTW - I checked that specific key, and it is indeed just "Program Files",
> in both the regular x64 root and the wow x86 key - so it's not that it's
> pulling from the wrong place.
>
> Perhaps there's a property to set to tell MSI not to do this replacement?
>
> Matt Johnson MCPD, MCTS, MCSD, MCDBA
> Director of Application Development
> Time America, Inc.
> ma...@timeamerica.com | www.timeamerica.com
>
>
> -Original Message-
> From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Friday, May 14, 2010 7:42 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch converts value data
>
> Hi
>
> Anyone who can tell me why my RegistrySearch converts the value contained
> in
> the registry?
>
>
>   Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>
>
> The actual value in registry is...
> AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>
> But according to the log file upon installation C:\Program Files\Microsoft
> Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft Help
> Viewer\v1.0\
> when using it in a custom action
>
> Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
>
> from log..
> MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> property. Its value is 'C:\Program Files (x86)\Microsoft Help
> Viewer\v1.0\HelpLibManager.exe'
>
> The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>
> So this seems like a bug where all strings containing Program Files found
> in
> registry converts to Program Files (x86)
>
> /Jimmie
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

No, but I do a registry search to find out where microsoft have their
HelpLibManager.exe installed.


  


Then my thought was that the variable HELPINSTALLDIR after the registry
search should map to "C:\Program Files\Microsoft Help Viewer\v1.0\" where it
seems to be located both on win32 systems like WinXP and Win64 systems like
Windows Vista 64-bit and Windows 7 64-bit. So in this case microsoft have
both a 32-bit and a 64-bit version of their HelpLibManager.exe which they
install depending on the target system and They tell me where on my disk it
is installed by putting it in the registry which I then extract but then
this WIN64DUALFOLDERS thingie overrides the value extracted from registry
beliving to know better... Thats my problem...

2010/5/15 Blair 

> Do you have a directory named HELPINSTALLDIR?
>
> -Original Message-
> From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: Friday, May 14, 2010 9:22 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch converts value data
>
> Ok, so you're right about the win64dualfolders thingie..
>
> WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters
> in
> 'C:\Program Files\Microsoft Help Viewer\v1.0\' folder path. (mask argument
> =
> 0, the folder pair's iSwapAttrib member = 0).
>
> But isn't it odd, depending on target system, it overrides my wish to
> simply
> read the registry value... I'm not intressted in getting overriden by the
> system who thinks it knows better.
> Can I again override the behavior.. I'm not intressted to support one
> 32-bit
> and another 64-bit installer. One installer is problem enough...
>
> The folder always seems to be
> C:\Program Files\Microsoft Help Viewer\v1.0\
> on both 64- and 32-bit os
> /Jimmie
>
> 2010/5/14 Pally Sandher 
>
> > Not a bug, not even close to a bug. You're using an x86 package on an
> > x64 system.
> >
> > Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
> > what's changing the property.
> >
> > If you want to access x64 specific locations like C:\Program
> > Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
> > x64 package. Your code will give you what you're expecting on an x86
> > system without a problem but WOW64 is intercepting it on x64 systems.
> >
> > 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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> > Sent: 14 May 2010 15:42
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] RegistrySearch converts value data
> >
> > Hi
> >
> > Anyone who can tell me why my RegistrySearch converts the value
> > contained in the registry?
> >
> >
> >   > Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
> >
> >
> > The actual value in registry is...
> > AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > But according to the log file upon installation C:\Program
> > Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
> > *(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action
> >
> > > Execute="immediate"
> > Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
> >
> > from log..
> > MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> > property. Its value is 'C:\Program Files (x86)\Microsoft Help
> > Viewer\v1.0\HelpLibManager.exe'
> >
> > The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
> >
> > So this seems like a bug where all strings containing Program Files
> > found in registry converts to Program Files (x86)
> >
> > /Jimmie
> > 
> > --
> >
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> >
>
> 

Re: [WiX-users] RegistrySearch converts value data

[Blair]

Do you have a directory named HELPINSTALLDIR?

-Original Message-
From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: Friday, May 14, 2010 9:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch converts value data

Ok, so you're right about the win64dualfolders thingie..

WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in
'C:\Program Files\Microsoft Help Viewer\v1.0\' folder path. (mask argument =
0, the folder pair's iSwapAttrib member = 0).

But isn't it odd, depending on target system, it overrides my wish to simply
read the registry value... I'm not intressted in getting overriden by the
system who thinks it knows better.
Can I again override the behavior.. I'm not intressted to support one 32-bit
and another 64-bit installer. One installer is problem enough...

The folder always seems to be
C:\Program Files\Microsoft Help Viewer\v1.0\
on both 64- and 32-bit os
/Jimmie

2010/5/14 Pally Sandher 

> Not a bug, not even close to a bug. You're using an x86 package on an
> x64 system.
>
> Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
> what's changing the property.
>
> If you want to access x64 specific locations like C:\Program
> Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
> x64 package. Your code will give you what you're expecting on an x86
> system without a problem but WOW64 is intercepting it on x64 systems.
>
> 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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: 14 May 2010 15:42
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch converts value data
>
> Hi
>
> Anyone who can tell me why my RegistrySearch converts the value
> contained in the registry?
>
>
>   Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>
>
> The actual value in registry is...
> AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>
> But according to the log file upon installation C:\Program
> Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
> *(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action
>
> Execute="immediate"
> Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
>
> from log..
> MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> property. Its value is 'C:\Program Files (x86)\Microsoft Help
> Viewer\v1.0\HelpLibManager.exe'
>
> The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>
> So this seems like a bug where all strings containing Program Files
> found in registry converts to Program Files (x86)
>
> /Jimmie
> 
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
>

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

--

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


--

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

Re: [WiX-users] RegistrySearch converts value data

[Jimmie Eriksson]

Ok, so you're right about the win64dualfolders thingie..

WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in
'C:\Program Files\Microsoft Help Viewer\v1.0\' folder path. (mask argument =
0, the folder pair's iSwapAttrib member = 0).

But isn't it odd, depending on target system, it overrides my wish to simply
read the registry value... I'm not intressted in getting overriden by the
system who thinks it knows better.
Can I again override the behavior.. I'm not intressted to support one 32-bit
and another 64-bit installer. One installer is problem enough...

The folder always seems to be
C:\Program Files\Microsoft Help Viewer\v1.0\
on both 64- and 32-bit os
/Jimmie

2010/5/14 Pally Sandher 

> Not a bug, not even close to a bug. You're using an x86 package on an
> x64 system.
>
> Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
> what's changing the property.
>
> If you want to access x64 specific locations like C:\Program
> Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
> x64 package. Your code will give you what you're expecting on an x86
> system without a problem but WOW64 is intercepting it on x64 systems.
>
> 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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com]
> Sent: 14 May 2010 15:42
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] RegistrySearch converts value data
>
> Hi
>
> Anyone who can tell me why my RegistrySearch converts the value
> contained in the registry?
>
>
>   Key='SOFTWARE\Microsoft\Help\v1.0' Name='AppRoot' />
>
>
> The actual value in registry is...
> AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\
>
> But according to the log file upon installation C:\Program
> Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
> *(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action
>
> Execute="immediate"
> Property="HELPInstaller" Value="[HELPINSTALLDIR]HelpLibManager.exe" />
>
> from log..
> MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
> property. Its value is 'C:\Program Files (x86)\Microsoft Help
> Viewer\v1.0\HelpLibManager.exe'
>
> The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\
>
> So this seems like a bug where all strings containing Program Files
> found in registry converts to Program Files (x86)
>
> /Jimmie
> 
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--

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

Re: [WiX-users] RegistrySearch converts value data

[Pally Sandher]

Not a bug, not even close to a bug. You're using an x86 package on an
x64 system.

Look for WIN64DUALFOLDERS in a verbose log (/l*vx). You'll see that's
what's changing the property.

If you want to access x64 specific locations like C:\Program
Files\Microsoft Help Viewer\v1.0\ on x64 systems you need to build an
x64 package. Your code will give you what you're expecting on an x86
system without a problem but WOW64 is intercepting it on x64 systems.

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: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: 14 May 2010 15:42
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch converts value data

Hi

Anyone who can tell me why my RegistrySearch converts the value
contained in the registry?


  


The actual value in registry is...
AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\

But according to the log file upon installation C:\Program
Files\Microsoft Help Viewer\v1.0\ converts into C:\Program Files
*(x86)*\Microsoft Help Viewer\v1.0\ when using it in a custom action



from log..
MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
property. Its value is 'C:\Program Files (x86)\Microsoft Help
Viewer\v1.0\HelpLibManager.exe'

The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\

So this seems like a bug where all strings containing Program Files
found in registry converts to Program Files (x86)

/Jimmie

--

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



--

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

Re: [WiX-users] RegistrySearch converts value data

[Matt Johnson]

Not sure why.  I had the same problem.  I used the StringTools custom action 
from the msiext project to take the " (x86) back out.  If there's an easier 
way, I'd be glad to know.

BTW - I checked that specific key, and it is indeed just "Program Files", in 
both the regular x64 root and the wow x86 key - so it's not that it's pulling 
from the wrong place.

Perhaps there's a property to set to tell MSI not to do this replacement?

Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.com | www.timeamerica.com


-Original Message-
From: Jimmie Eriksson [mailto:eriksson.jim...@gmail.com] 
Sent: Friday, May 14, 2010 7:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch converts value data

Hi

Anyone who can tell me why my RegistrySearch converts the value contained in
the registry?


  


The actual value in registry is...
AppRoot = C:\Program Files\Microsoft Help Viewer\v1.0\

But according to the log file upon installation C:\Program Files\Microsoft
Help Viewer\v1.0\ converts into C:\Program Files *(x86)*\Microsoft Help
Viewer\v1.0\
when using it in a custom action



from log..
MSI (s) (08:78) [16:20:59:102]: PROPERTY CHANGE: Adding HELPInstaller
property. Its value is 'C:\Program Files (x86)\Microsoft Help
Viewer\v1.0\HelpLibManager.exe'

The folder on disk: C:\Program Files\Microsoft Help Viewer\v1.0\

So this seems like a bug where all strings containing Program Files found in
registry converts to Program Files (x86)

/Jimmie
--

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

--

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

Re: [WiX-users] RegistrySearch on two properties

[Bob Arnson]

On 4/13/2010 10:38 AM, Rodney Schuler wrote:
> Key="Software\TheirCompany\TheirProduct\[THEIRCURVER]\[THEIRCURLANG]"
> Name="ProductName" Type="raw">
>

You can't rely on using the results of one AppSearch in another like 
that because there's no guaranteed order to how the rows in the 
AppSearch table are processed. Some AppSearches can be chained together 
but not registry. I believe an immediate custom action would be required.

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


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

Re: [WiX-users] registrysearch

[Bob Arnson]

On 3/16/2010 6:08 AM, Yu, Brian wrote:
> How do I check if a registry directory exists or not using
> registrysearch?
>

AppSearch doesn't have that functionality.

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


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

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

[mtoews]

Absolutely.  Upgrading resolved the issue.  Thank you.
-- 
View this message in context: 
http://n2.nabble.com/RegistrySearch-Type-raw-causes-a-1-to-be-written-in-RegLocater-table-should-be-a-2-tp4468104p4476425.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

[Jeremy Farrell]

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

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

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

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

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

[Blair]

For the 2.0 release, the latest is 2.0.5805.0 from August 2008. Your version
is way old. Please upgrade.

Even 3.0 has been released (no longer in beta). 2.0 is now considered
legacy.

-Original Message-
From: Toews, Margaret [mailto:margaret.to...@wolterskluwer.com] 
Sent: Thursday, January 28, 2010 7:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch Type raw causes a '1' to be
writtenin RegLocater table - should be a '2'

Wix version 2.0.1605.0

Margaret Toews
Programmer Analyst
ProSystem fx Engagement
CCH, a Wolters Kluwer business
 
Phone: 316.612.5148
Fax: 316.612.3406
E-Mail: margaret.to...@wolterskluwer.com
-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, January 27, 2010 11:20 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] RegistrySearch Type raw causes a '1' to be
writtenin RegLocater table - should be a '2'

Which build of the WiX toolset?

-Original Message-
From: mtoews [mailto:margaret.to...@wolterskluwer.com] 
Sent: Wednesday, January 27, 2010 8:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch Type raw causes a '1' to be written
in
RegLocater table - should be a '2'


>From a Wix newby: When I use the registrysearch element as below 
 
   
 

the search fails unless I edit the msi package and change the value in
the
Type column of the RegLocator table from 1 to 2.  From reading it seems
to
me that when 'raw' is specified as a type the RegLocator table Type
column
should be populated with a 2.  If I edit the package and change it to a
2
the search is successful.  Any assistance is appreciated. 
-- 
View this message in context:
http://n2.nabble.com/RegistrySearch-Type-raw-causes-a-1-to-be-written-in
-Reg
Locater-table-should-be-a-2-tp4468104p4468104.html
Sent from the wix-users mailing list archive at Nabble.com.



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



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


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


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

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

[Toews, Margaret]

Wix version 2.0.1605.0

Margaret Toews
Programmer Analyst
ProSystem fx Engagement
CCH, a Wolters Kluwer business
 
Phone: 316.612.5148
Fax: 316.612.3406
E-Mail: margaret.to...@wolterskluwer.com
-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, January 27, 2010 11:20 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] RegistrySearch Type raw causes a '1' to be
writtenin RegLocater table - should be a '2'

Which build of the WiX toolset?

-Original Message-
From: mtoews [mailto:margaret.to...@wolterskluwer.com] 
Sent: Wednesday, January 27, 2010 8:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch Type raw causes a '1' to be written
in
RegLocater table - should be a '2'


>From a Wix newby: When I use the registrysearch element as below 
 
   
 

the search fails unless I edit the msi package and change the value in
the
Type column of the RegLocator table from 1 to 2.  From reading it seems
to
me that when 'raw' is specified as a type the RegLocator table Type
column
should be populated with a 2.  If I edit the package and change it to a
2
the search is successful.  Any assistance is appreciated. 
-- 
View this message in context:
http://n2.nabble.com/RegistrySearch-Type-raw-causes-a-1-to-be-written-in
-Reg
Locater-table-should-be-a-2-tp4468104p4468104.html
Sent from the wix-users mailing list archive at Nabble.com.



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



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

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

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

[Blair]

Which build of the WiX toolset?

-Original Message-
From: mtoews [mailto:margaret.to...@wolterskluwer.com] 
Sent: Wednesday, January 27, 2010 8:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch Type raw causes a '1' to be written in
RegLocater table - should be a '2'


>From a Wix newby: When I use the registrysearch element as below 
 
   
 

the search fails unless I edit the msi package and change the value in the
Type column of the RegLocator table from 1 to 2.  From reading it seems to
me that when 'raw' is specified as a type the RegLocator table Type column
should be populated with a 2.  If I edit the package and change it to a 2
the search is successful.  Any assistance is appreciated. 
-- 
View this message in context:
http://n2.nabble.com/RegistrySearch-Type-raw-causes-a-1-to-be-written-in-Reg
Locater-table-should-be-a-2-tp4468104p4468104.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] RegistrySearch execution

[Kevin Garman]

G
reat, thanks.


-- 
Thanks,

Kevin Garman, Project Engineer

SCADAware, Inc.
www.scadaware.com




On Tue, 2009-12-22 at 10:12 +1100, Sascha Beaumont wrote: 

> The documentation indicates that it happens during AppSearch
> (http://msdn.microsoft.com/en-us/library/aa367578(VS.85).aspx) -
> RegistrySearch elements map to the RegLocator table in the MSI.
> 
> > The AppSearch action searches for signatures using the CompLocator table
> > first, the RegLocator table second, the IniLocator table third, and finally 
> > the
> > DrLocator table. File signatures are listed in the Signature table. A 
> > signature
> > that is not in the Signature table denotes a directory and the action sets 
> > the
> > property to the directory path for that signature.
> 
> 
> Sascha
> 
> On Tue, Dec 22, 2009 at 10:01 AM, Kevin Garman  wrote:
> > Hi,
> >
> > Can anyone tell me when the RegistrySearches are evaluated in terms of
> > InstallUISequence and InstallExecuteSequence actions?  For some reason I
> > was thinking it happens during AppSearch but now I can find evidence of
> > that.
> >
> > Thanks,
> > Kevin
> > --
> > This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support
> > A streamlined, 14 day to market process makes app distribution fast and easy
> > Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> 
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch execution

[Sascha Beaumont]

The documentation indicates that it happens during AppSearch
(http://msdn.microsoft.com/en-us/library/aa367578(VS.85).aspx) -
RegistrySearch elements map to the RegLocator table in the MSI.

> The AppSearch action searches for signatures using the CompLocator table
> first, the RegLocator table second, the IniLocator table third, and finally 
> the
> DrLocator table. File signatures are listed in the Signature table. A 
> signature
> that is not in the Signature table denotes a directory and the action sets the
> property to the directory path for that signature.


Sascha

On Tue, Dec 22, 2009 at 10:01 AM, Kevin Garman  wrote:
> Hi,
>
> Can anyone tell me when the RegistrySearches are evaluated in terms of
> InstallUISequence and InstallExecuteSequence actions?  For some reason I
> was thinking it happens during AppSearch but now I can find evidence of
> that.
>
> Thanks,
> Kevin
> --
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

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

Re: [WiX-users] RegistrySearch and RegistryValue

[Alex Shevchuk]

>And how about QWORD value?

Looks like Registry table
(http://msdn.microsoft.com/en-us/library/aa371168(VS.85).aspx) supports
only:

- REG_SZ
- REG_MULTI_SZ
- REG_EXPAND_SZ
- REG_BINARY
- REG_DWORD

No REG_QWORD and XXX_LITTLE_ENDIAN (or REG_LINK) support, I think.


Alex



--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch and RegistryValue

[Alex Ivanoff]

And how about QWORD value?


-Original Message-
From: Alex Shevchuk [mailto:shevc...@live.com] 
Sent: Tuesday, May 12, 2009 01:04
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] RegistrySearch and RegistryValue

Hi Alex,

Short answer: Yes, maybe, no.  :-)
Detailed answer:
http://blogs.technet.com/alexshev/archive/2009/05/11/is-it-possible-to-u
se-registrysearch-result-in-registryvalue.aspx

Regards,
Alex




-Original Message-
From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com]
Sent: Monday, May 11, 2009 10:56 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] RegistrySearch and RegistryValue

Is it possible to use RegistrySearch result in RegistryValue? Something
like this:





...





--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks
to Kodak, there's a perfect scanner to get the job done! With the NEW
KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all
image processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks
to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch and RegistryValue

[Alex Shevchuk]

Hi Alex,

Short answer: Yes, maybe, no.  :-)
Detailed answer:
http://blogs.technet.com/alexshev/archive/2009/05/11/is-it-possible-to-use-r
egistrysearch-result-in-registryvalue.aspx

Regards,
Alex




-Original Message-
From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] 
Sent: Monday, May 11, 2009 10:56 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] RegistrySearch and RegistryValue

Is it possible to use RegistrySearch result in RegistryValue? Something
like this:





...




--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch: remove #

[Neil Sleightholm]

I thought that would be the case. It does seem odd to me that Windows
Installer doesn't support this natively, it does make RegistrySearch a
bit restrictive.

Neil

-Original Message-
From: Richard [mailto:[EMAIL PROTECTED] 
Sent: 22 November 2008 14:33
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch: remove #


In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> Actually it is much simpler than that, I want to read the SQL port
> number from the registry and then open it in the firewall but to do
the
> write I need the number without the hash.

Then you'll need to write a CA to strip the "#"; windows installer
doesn't provide any sort of mechanism to remove parts of the property
text when setting properties.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
  <http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch: remove #

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> Actually it is much simpler than that, I want to read the SQL port
> number from the registry and then open it in the firewall but to do the
> write I need the number without the hash.

Then you'll need to write a CA to strip the "#"; windows installer
doesn't provide any sort of mechanism to remove parts of the property
text when setting properties.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch: remove #

[Neil Sleightholm]

Actually it is much simpler than that, I want to read the SQL port
number from the registry and then open it in the firewall but to do the
write I need the number without the hash.

Neil

-Original Message-
From: Richard [mailto:[EMAIL PROTECTED] 
Sent: 21 November 2008 19:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch: remove #


In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> It there anyway to remove the hash (#) from the start of a
> RegistrySearch if the value is a DWORD?

I'm guessing the reason you want this is so that you can do numeric
comparisons on a DWORD value in a condition?

You could write a CA to adjust the property, but what I did when I
wanted to write conditions on a DWORD read out of the registry is to
just treat it as a string comparison.  This may or may not be feasible
in your case; in my case I only had to do equality comparisons for a
small number of values.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
  <http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>


-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch: remove #

[Richard]

In article <[EMAIL PROTECTED]>,
"Neil Sleightholm" <[EMAIL PROTECTED]>  writes:

> It there anyway to remove the hash (#) from the start of a
> RegistrySearch if the value is a DWORD?

I'm guessing the reason you want this is so that you can do numeric
comparisons on a DWORD value in a condition?

You could write a CA to adjust the property, but what I did when I
wanted to write conditions on a DWORD read out of the registry is to
just treat it as a string comparison.  This may or may not be feasible
in your case; in my case I only had to do equality comparisons for a
small number of values.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch Problem

[Adam Nicol]

 

I tried that but for some reason it just allways shows the hard coded
value and not the registry value.


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: 30 October 2008 16:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch Problem

Don't things work if you just put the defaults in the Property/@Value
and nest the RegistrySearch elements under there?

-Original Message-
From: Adam Nicol [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 08:56
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch Problem


Hi, I have several custom dialogs in my installer allowing the user to
enter SQL Server connection details and active directory settings.

I don't want the user to have to re-enter this information each time
they install a new version/reinstall, so I have made it so that during
the install, each of the entered values are stored in the registry. Then
when the user runs a new version of the installer their previous
settings are loaded from the registry and displayed in the dialog.

This all works perfectly, but now I want to be able to have some default
values in the fields the first time that the installer is run when there
is nothing in the registry. Somehow I need to check the registry to see
if the keys exist and read them if they do, otherwise show the user
default values in the fields.

Is this possible, and if so how would I go about doing this?

Thanks in advance,
Adam

TWI Ltd
Registered Number: 3859442 England
Registered Office: Granta Park, Great Abington, Cambridge, CB21 6AL, UK

___
The information in this e-mail is confidential, and may be legally
privileged.  It is intended only for the person(s) specified in the
above address.  Access to this e-mail by anyone else is unauthorised,
and any disclosure, copying, distribution or other use of this e-mail is
prohibited and may be unlawful.  We will not under any circumstances
have any responsibility or liability arising out of or in connection
with any unauthorised use of this e-mail.  Please inform us if this
message has gone astray before deleting it.

Please note that all e-mail is monitored.

When sending e-mails to TWI, please help us by including your name,
company, and details in your e-mail signature.

Seeking Technical Information? Industrial Members can access data as
JoinIT registrants on http://www.twi.co.uk
___




-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

TWI Ltd
Registered Number: 3859442 England
Registered Office: Granta Park, Great Abington, Cambridge, CB21 6AL, UK

___
The information in this e-mail is confidential, and may be legally 
privileged.  It is intended only for the person(s) specified in the 
above address.  Access to this e-mail by anyone else is unauthorised, 
and any disclosure, copying, distribution or other use of this e-mail 
is prohibited and may be unlawful.  We will not under any circumstances 
have any responsibility or liability arising out of or in connection 
with any unauthorised use of this e-mail.  Please inform us if this 
message has gone astray before deleting it.

Please note that all e-mail is monitored.

When sending e-mails to TWI, please help us by including your name, 
company, and details in your e-mail signature.

Seeking Technical Information? Industrial Members can access data as 
JoinIT registrants on http://www.twi.co.uk
___



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a tri

Re: [WiX-users] RegistrySearch Problem

[Rob Mensching]

Don't things work if you just put the defaults in the Property/@Value and nest 
the RegistrySearch elements under there?

-Original Message-
From: Adam Nicol [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 08:56
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch Problem


Hi, I have several custom dialogs in my installer allowing the user to
enter SQL Server connection details and active directory settings.

I don't want the user to have to re-enter this information each time
they install a new version/reinstall, so I have made it so that during
the install, each of the entered values are stored in the registry. Then
when the user runs a new version of the installer their previous
settings are loaded from the registry and displayed in the dialog.

This all works perfectly, but now I want to be able to have some default
values in the fields the first time that the installer is run when there
is nothing in the registry. Somehow I need to check the registry to see
if the keys exist and read them if they do, otherwise show the user
default values in the fields.

Is this possible, and if so how would I go about doing this?

Thanks in advance,
Adam

TWI Ltd
Registered Number: 3859442 England
Registered Office: Granta Park, Great Abington, Cambridge, CB21 6AL, UK

___
The information in this e-mail is confidential, and may be legally
privileged.  It is intended only for the person(s) specified in the
above address.  Access to this e-mail by anyone else is unauthorised,
and any disclosure, copying, distribution or other use of this e-mail
is prohibited and may be unlawful.  We will not under any circumstances
have any responsibility or liability arising out of or in connection
with any unauthorised use of this e-mail.  Please inform us if this
message has gone astray before deleting it.

Please note that all e-mail is monitored.

When sending e-mails to TWI, please help us by including your name,
company, and details in your e-mail signature.

Seeking Technical Information? Industrial Members can access data as
JoinIT registrants on http://www.twi.co.uk
___



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch question

[Albert At School]

Check out my SQL browser source code for a nice solution for enumerating SQL 
instances in a C++ CA

(http://madbutcher.dyndns.org/snippets/)

Albert

- Original Message - 
From: "Mike Rerick" <[EMAIL PROTECTED]>
To: "General discussion for Windows Installer XML toolset." 

Sent: Thursday, August 21, 2008 1:37 AM
Subject: [WiX-users] RegistrySearch question


>I am trying to read a Registry setting to get the installed instances of 
>SQL
> Server. The InstalledInstances entry is a REG_MULTI_SZ data type. There is 
> a
> value entered in this entry but the property INSTALLEDINSTANCES does not
> contain a value. I'm using version 3.0.4401.
>
>
>
> Any ideas?
>
>
>
>
>
>
>
>Key='SOFTWARE\Microsoft\Microsoft SQL Server' Name="InstalledInstances"
> Type="raw"/>
>
>
>
>
>
>
>
> Thanks!
>
>
>
> Mike Rerick
>
> Sr. Software Engineer - Professional Services
>
>  http://www.iwsinc.com/>
>
>
>
> 9200 S.E. Sunnybrook Blvd., Suite 170
>
> Clackamas, OR   97015
>
> Phone: (503) 353-8068Fax: (503) 353-8065
>
>
>
>
>
> The information contained in this transmission contains potentially
> privileged, export controlled and/or confidential information of Imageware
> Systems, Inc. or its customers or partners.  It is intended only to be 
> read
> by the person(s) named above and for no other purpose.  You are hereby
> notified that any dissemination, distribution, duplication of this
> communication or use of its contents for any purpose not authorized
> expressly by Imageware Systems, Inc. is strictly prohibited and could lead
> to both civil and/or criminal penalties.  If you are not the intended
> recipient, you are prohibited to review the contents herein and please
> contact the sender by reply e-mail and destroy all copies of the original
> message.  To reply to our e-mail administrator directly, please send an
> e-mail to [EMAIL PROTECTED]
>
>





> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/





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


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch question

[Mike Rerick]

Thanks Alex. I'll put together a CA to do what I need.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexander
Shevchuk
Sent: Wednesday, August 20, 2008 6:40 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch question

Hi Mike,

REG_MULTI_SZ in AppSearch has lots of problems (here is one of them:
http://support.microsoft.com/kb/897026).
Consensus here is - use custom action of your choice to get that value.

Alex



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Rerick
Sent: Wednesday, August 20, 2008 4:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] RegistrySearch question

I am trying to read a Registry setting to get the installed instances of SQL
Server. The InstalledInstances entry is a REG_MULTI_SZ data type. There is a
value entered in this entry but the property INSTALLEDINSTANCES does not
contain a value. I'm using version 3.0.4401.



Any ideas?







   







Thanks!



Mike Rerick

Sr. Software Engineer - Professional Services

  http://www.iwsinc.com/>



9200 S.E. Sunnybrook Blvd., Suite 170

Clackamas, OR   97015

Phone: (503) 353-8068Fax: (503) 353-8065





The information contained in this transmission contains potentially
privileged, export controlled and/or confidential information of Imageware
Systems, Inc. or its customers or partners.  It is intended only to be read
by the person(s) named above and for no other purpose.  You are hereby
notified that any dissemination, distribution, duplication of this
communication or use of its contents for any purpose not authorized
expressly by Imageware Systems, Inc. is strictly prohibited and could lead
to both civil and/or criminal penalties.  If you are not the intended
recipient, you are prohibited to review the contents herein and please
contact the sender by reply e-mail and destroy all copies of the original
message.  To reply to our e-mail administrator directly, please send an
e-mail to [EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


The information contained in this transmission contains potentially
privileged, export controlled and/or confidential information of Imageware
Systems, Inc. or its customers or partners.  It is intended only to be read
by the person(s) named above and for no other purpose.  You are hereby
notified that any dissemination, distribution, duplication of this
communication or use of its contents for any purpose not authorized
expressly by Imageware Systems, Inc. is strictly prohibited and could lead
to both civil and/or criminal penalties.  If you are not the intended
recipient, you are prohibited to review the contents herein and please
contact the sender by reply e-mail and destroy all copies of the original
message.  To reply to our e-mail administrator directly, please send an
e-mail to [EMAIL PROTECTED]
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch question

[Alexander Shevchuk]

Hi Mike,

REG_MULTI_SZ in AppSearch has lots of problems (here is one of them: 
http://support.microsoft.com/kb/897026).
Consensus here is - use custom action of your choice to get that value.

Alex



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rerick
Sent: Wednesday, August 20, 2008 4:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] RegistrySearch question

I am trying to read a Registry setting to get the installed instances of SQL 
Server. The InstalledInstances entry is a REG_MULTI_SZ data type. There is a 
value entered in this entry but the property INSTALLEDINSTANCES does not 
contain a value. I'm using version 3.0.4401.



Any ideas?







   







Thanks!



Mike Rerick

Sr. Software Engineer - Professional Services

  http://www.iwsinc.com/>



9200 S.E. Sunnybrook Blvd., Suite 170

Clackamas, OR   97015

Phone: (503) 353-8068Fax: (503) 353-8065





The information contained in this transmission contains potentially privileged, 
export controlled and/or confidential information of Imageware Systems, Inc. or 
its customers or partners.  It is intended only to be read by the person(s) 
named above and for no other purpose.  You are hereby notified that any 
dissemination, distribution, duplication of this communication or use of its 
contents for any purpose not authorized expressly by Imageware Systems, Inc. is 
strictly prohibited and could lead to both civil and/or criminal penalties.  If 
you are not the intended recipient, you are prohibited to review the contents 
herein and please contact the sender by reply e-mail and destroy all copies of 
the original message.  To reply to our e-mail administrator directly, please 
send an e-mail to [EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch on a REG_MULTI_SZ

[Dana Gutride]

I'm not sure if you can do this in vbscript, you can definitely do what you
are asking in c++.



On Thu, Jul 31, 2008 at 12:18 PM, Zane Zeeh <[EMAIL PROTECTED]> wrote:

> Ok, so by custom action do you mean one that would call a vb script to
> retrieve these values and set the properties or is there some other sort of
> CA that I can use?
>
> Thank you for responding
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Dana Gutride
> Sent: Thursday, July 31, 2008 11:52 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] RegistrySearch on a REG_MULTI_SZ
>
> Looks like retrieving a reg_multi_sz using the RegLocator table during
> AppSearch is not a great way of doing this.  Plenty of places on the web
> document this oddity.  I think you might just want to use a custom action
> instead of a registry search to retrieve this value and write it to a
> property.
>
> dana
>
> On Thu, Jul 31, 2008 at 11:02 AM, Zane Zeeh <[EMAIL PROTECTED]> wrote:
>
> > I'm trying to get the default SQL Server Instance using the following:
> >  > Root="HKLM"Key="SOFTWARE\Microsoft\Microsoft SQL Server"
> > Name="InstalledInstances" Type="raw"/>
> > This SHOULD return one or more values in the format
> > ~InstanceName1~InstanceName2~InstanceName3. Mine however returns nothing,
> > even though there is a value there. If I use this same Property against a
> > string registry value it returns the single text string without a
> problem.
> > I'd like to be able to return the first value from this mutli string
> > registry entry. How do I do that?
> > Thanks,
> > Zane
> >
> > -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch on a REG_MULTI_SZ

[Zane Zeeh]

Ok, so by custom action do you mean one that would call a vb script to retrieve 
these values and set the properties or is there some other sort of CA that I 
can use?

Thank you for responding

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dana Gutride
Sent: Thursday, July 31, 2008 11:52 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] RegistrySearch on a REG_MULTI_SZ

Looks like retrieving a reg_multi_sz using the RegLocator table during
AppSearch is not a great way of doing this.  Plenty of places on the web
document this oddity.  I think you might just want to use a custom action
instead of a registry search to retrieve this value and write it to a
property.

dana

On Thu, Jul 31, 2008 at 11:02 AM, Zane Zeeh <[EMAIL PROTECTED]> wrote:

> I'm trying to get the default SQL Server Instance using the following:
>  Root="HKLM"Key="SOFTWARE\Microsoft\Microsoft SQL Server"
> Name="InstalledInstances" Type="raw"/>
> This SHOULD return one or more values in the format
> ~InstanceName1~InstanceName2~InstanceName3. Mine however returns nothing,
> even though there is a value there. If I use this same Property against a
> string registry value it returns the single text string without a problem.
> I'd like to be able to return the first value from this mutli string
> registry entry. How do I do that?
> Thanks,
> Zane
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch on a REG_MULTI_SZ

[Dana Gutride]

Looks like retrieving a reg_multi_sz using the RegLocator table during
AppSearch is not a great way of doing this.  Plenty of places on the web
document this oddity.  I think you might just want to use a custom action
instead of a registry search to retrieve this value and write it to a
property.

dana

On Thu, Jul 31, 2008 at 11:02 AM, Zane Zeeh <[EMAIL PROTECTED]> wrote:

> I'm trying to get the default SQL Server Instance using the following:
>  Root="HKLM"Key="SOFTWARE\Microsoft\Microsoft SQL Server"
> Name="InstalledInstances" Type="raw"/>
> This SHOULD return one or more values in the format
> ~InstanceName1~InstanceName2~InstanceName3. Mine however returns nothing,
> even though there is a value there. If I use this same Property against a
> string registry value it returns the single text string without a problem.
> I'd like to be able to return the first value from this mutli string
> registry entry. How do I do that?
> Thanks,
> Zane
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch more than once?

[Michal Peled]

Tris,

What you're looking for is, as far as I know, impossible. The registry
search for properties is done once in the "AppSearch" action, if I'm not
mistaken.

However, there are other ways to achieve your goal: 

1. If the user enters a text that describes a value of a constant
registry key, you can registrysearch that key, and then just ask if the
user's text is equal to the registry searched property.

2.  If the user enters a registry key NAME and you want to look for that
key and get its value, you'll probably have to use a custom action, in
DLL or VBScript, both are pretty simple to accomplish.

 

Regards,

 

MP.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tris
Hodges
Sent: Monday, February 04, 2008 1:53 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch more than once?

 

Is it possible to do a RegistrySearch more than once for a property? 
 
The user can enter some text which I then want to search for in the
registry but the RegistrySearch seems to be only getting called the
first time and return that value for all subsequent calls. Thanks Tris



Everything in one place. All new Windows Live!
 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch with empty registrykeys

[Sebastian Brand]

The MSI Help for the RegLocator table states:
"Note that it is not possible to use the RegLocator table to check  
only for the presence of the key. However, you can search for the  
default value of a key and retrieve its value if it is not empty."

-> http://msdn2.microsoft.com/en-us/library/Aa371171.aspx


Best regards,
Sebastian Brand

Instyler Software - http://www.instyler.com


On Oct 18, 2007, at 9:22 AM, Nitin Chaudhari wrote:

> Hi,
>
>
>
> I want to check if a Key exists, it may or may not have any values  
> or subkeys in it, so I tried the following
>
>
>
>  Key="SOFTWARE\Microsoft\Office\Excel\">
>
>
>
> I am including the Name attribute since I don’t want to check for  
> anything.. I just want to confirm that the path SOFTWARE\Microsoft 
> \Office\Excel\ exists, how can I do that?
>
>
>
> I tried Name=”(Default)” it does not work
>
>
>
> Thanks,
>
> Nitin.
>
>
>
> DISCLAIMER == This e-mail may contain privileged and  
> confidential information which is the property of Persistent  
> Systems Ltd. It is intended only for the use of the individual or  
> entity to which it is addressed. If you are not the intended  
> recipient, you are not authorized to read, retain, copy, print,  
> distribute or use this message. If you have received this  
> communication in error, please notify the sender and delete all  
> copies of this message. Persistent Systems Ltd. does not accept any  
> liability for virus infected mails.
>
> -- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/ 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch??

[Rob Mensching]

[please keep the wix-users mailing list on the thread]

You would have to create a DLL CustomAction to do the registry reading 
yourself, yes.  The CustomAction can search and set a Property.  Again, when 
you think about the reorganization, you're going to find there is a lot of work 
when you want to handle rollback.  I would recommend changing the application 
design so you don't have to do this in the install.

From: Nitin Chaudhari [mailto:[EMAIL PROTECTED]
Sent: Monday, April 02, 2007 6:45 AM
To: Rob Mensching
Subject: Re: [WiX-users] RegistrySearch??

okay, so what should be the workaround?

should I have a dll which does this work and have a custom action fill in the 
registry. In this case... The dll will just lie there and it wont have any 
other use - I would need that to reorganise the value names while uninstalling.

Any better idea?

- Nitin


On 4/2/07, Rob Mensching <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:

You can't do that with anything built into the Windows Installer.  That pattern 
isn't really great for really robust installation behavior either.  It can be 
very hard to correctly repair, patch and sometimes uninstall the data.



From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> [mailto:[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>] On Behalf Of Nitin Chaudhari
Sent: Monday, April 02, 2007 1:42 AM
To: wix-users@lists.sourceforge.net<mailto:wix-users@lists.sourceforge.net>
Subject: [WiX-users] RegistrySearch??



In one of my registry keys the system has following strings



OPEN REG_SZvalue

OPEN1REG_SZvalue1

OPEN2REG_SZvalue 2



now how do i find out that the next name should be OPEN3?

On target machine, there may be OPENn (n could be any number) how can i derive 
OPENn+1



Thanks,

Nitin

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch??

[Rob Mensching]

You can't do that with anything built into the Windows Installer.  That pattern 
isn't really great for really robust installation behavior either.  It can be 
very hard to correctly repair, patch and sometimes uninstall the data.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari
Sent: Monday, April 02, 2007 1:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch??

In one of my registry keys the system has following strings

OPEN REG_SZvalue
OPEN1REG_SZvalue1
OPEN2REG_SZvalue 2

now how do i find out that the next name should be OPEN3?
On target machine, there may be OPENn (n could be any number) how can i derive 
OPENn+1

Thanks,
Nitin
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails in Wix 3.0

[Stefan Krueger [MVP]]

You cannot search for the existance of a registry KEY (folder icon in 
regedit), only for a value. Type "Directory" means that this value should be 
treated as a directory (with trailing backslash).

-- 
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)

"Erich Buhler" <[EMAIL PROTECTED]> schrieb im Newsbeitrag 
news:[EMAIL PROTECTED]
>
> Hi guys,
> I have the following line, but even the folder exists on the registry, Wix
> says the opposite.
>
>
>   Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727" />
>
>
> Is it possible that Wix 3.0 doesn't like the spaces in "NET Framework
> Setup"?
> Do you know how to solve it?
>
> Thank,
> Erich.
> -- 
> View this message in context: 
> http://www.nabble.com/RegistrySearch-fails-in-Wix-3.0-tf3409533.html#a9498749
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV 




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails in Wix 3.0

[Erich Buhler]

Yes, you're 100% right. if the default value is empty, then the answer is
that the folder doesn't exist even if it does. I changed the example to ask
for a value inside it, and it worked. I copy the new version for the sake of
the community :-)


 


Thanks,
Erich.


Levi Wilson wrote:
> 
> Doesn't the  require that the @Name attribute be
> defined?
> Maybe you'll want to set the @Name equal to one of the registry values
> found
> in that key, such as the Install or something.  Then, if SEARCHFORNET20 is
> set to anything, it exists.  If not, then it doesn't.
> 
> On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hi guys,
>> I have the following line, but even the folder exists on the registry,
>> Wix
>> says the opposite.
>>
>> 
>>   > Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727" />
>> 
>>
>> Is it possible that Wix 3.0 doesn't like the spaces in "NET Framework
>> Setup"?
>> Do you know how to solve it?
>>
>> Thank,
>> Erich.
>> --
>> View this message in context:
>> http://www.nabble.com/RegistrySearch-fails-in-Wix-3.0-tf3409533.html#a9498749
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>>
>> -
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/RegistrySearch-fails-in-Wix-3.0-tf3409533.html#a9499274
Sent from the wix-users mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch fails in Wix 3.0

[Levi Wilson]

Doesn't the  require that the @Name attribute be defined?
Maybe you'll want to set the @Name equal to one of the registry values found
in that key, such as the Install or something.  Then, if SEARCHFORNET20 is
set to anything, it exists.  If not, then it doesn't.

On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:



Hi guys,
I have the following line, but even the folder exists on the registry, Wix
says the opposite.


  


Is it possible that Wix 3.0 doesn't like the spaces in "NET Framework
Setup"?
Do you know how to solve it?

Thank,
Erich.
--
View this message in context:
http://www.nabble.com/RegistrySearch-fails-in-Wix-3.0-tf3409533.html#a9498749
Sent from the wix-users mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch Type=Registry

[Brian Patton]

If you ever intend to re-write a registry value looked up with
RegistrySearch, it looks like writing it as a "string" (even if it's really
a DWORD) will work, because the property is stored in a string-writeable
format (i.e. DWORDs are written by RegistrySearch as #value, and Registry
nodes will write "string"s of formate #value as DWORD:value).

On 12/20/06, Stefan Pavlik <[EMAIL PROTECTED]> wrote:


Hi...

Type='registry' is not supported (it was deprecated for a long time...)

You should replace it with Type='raw' probably.

Here is actual help for Type attribute:

This attribute's value should be one of the following:
directory
Sets a directory path from the registry value.
file
Sets a file path from the registry value.
raw
Sets the raw value from the registry value. Please note that this
value will contain a prefix as follows:
DWORD: Starts with '#' optionally followed by '+' or '-'.
REG_BINARY: Starts with '#x' and the installer converts and saves
each hexadecimal digit (nibble) as an ASCII character prefixed by '#x'.
REG_EXPAND_SZ: Starts with '#%'.
REG_MULTI_SZ: Starts with '[~]' and ends with '[~]'.
REG_SZ: No prefix, but if the first character of the registry value
is '#', the installer escapes the character by prefixing it with
another '#'.


Regards Stefan

Steve Bennett wrote:
> Hi all,
>
>   I'm trying to maintain an old .wxs file generated a while ago by
> decompiling a Visual Studio-generated .msi. It contains a
>  node which doesn't appear to be
> supported any more. (2.0.4611 doesn't like it; 2.0.2613 does). Could
> anyone tell me what it did, and what I should update it to? The full
> context is as follows:
>
>
>
> 
>
>Root="HKLM"
> Key="Software\[Manufacturer]\[PfxBaseName]\[PfxMajorVersion]"
> Name="InstallRoot" Type="registry" />
>
> 
>
>
>
> Steve
>
>
>
> Steve Bennett
>
> [POWERflex Corporation ]
>
> [Tel: +61-3-9548-9006  Fax: +61-3-9548-9003]
>
> [Email: spb @ pfxcorp.com  Web: www.pfxcorp.com]
>
>
>
>
> 
>
>
-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> 
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users





--
===
Brian Patton
http://people.bu.edu/bjp/
http://people.bu.edu/reallife/ourstories.html
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch Type=Registry

[Stefan Pavlik]

Hi...

Type='registry' is not supported (it was deprecated for a long time...)

You should replace it with Type='raw' probably.

Here is actual help for Type attribute:

This attribute's value should be one of the following:
directory
Sets a directory path from the registry value.
file
Sets a file path from the registry value.
raw
Sets the raw value from the registry value. Please note that this
value will contain a prefix as follows:
DWORD: Starts with '#' optionally followed by '+' or '-'.
REG_BINARY: Starts with '#x' and the installer converts and saves
each hexadecimal digit (nibble) as an ASCII character prefixed by '#x'.
REG_EXPAND_SZ: Starts with '#%'.
REG_MULTI_SZ: Starts with '[~]' and ends with '[~]'.
REG_SZ: No prefix, but if the first character of the registry value
is '#', the installer escapes the character by prefixing it with
another '#'.


Regards Stefan

Steve Bennett wrote:
> Hi all,
> 
>   I’m trying to maintain an old .wxs file generated a while ago by
> decompiling a Visual Studio-generated .msi. It contains a
>  node which doesn’t appear to be
> supported any more. (2.0.4611 doesn’t like it; 2.0.2613 does). Could
> anyone tell me what it did, and what I should update it to? The full
> context is as follows:
> 
>  
> 
> 
> 
>Root="HKLM"
> Key="Software\[Manufacturer]\[PfxBaseName]\[PfxMajorVersion]"
> Name="InstallRoot" Type="registry" />
> 
> 
> 
>  
> 
> Steve
> 
>  
> 
> Steve Bennett
> 
> [POWERflex Corporation ]
> 
> [Tel: +61-3-9548-9006  Fax: +61-3-9548-9003]
> 
> [Email: spb @ pfxcorp.com  Web: www.pfxcorp.com]
> 
>  
> 
> 
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> 
> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch key exists

[Bob Arnson]

Alexander Gnauck wrote:
> is is possible to check with RegistrySearch if a specified RegKey 
> exists? 
No. The underlying RegLocator table in MSI supports registry values, not 
just keys.
> I want to check if the .NET 1.1 Framework is installed. It should be 
> installed if the Key 
> HKLM\Software\Microsoft\Windows\.NETFramework\policy\v1.1 exists.
>   
The NetFxExtension in WiX v3 already supports that via a registry search 
on HKLM\Software\Microsoft\NET Framework Setup\NDP\v1.1.4322\Install.

-- 
sig://boB
http://bobs.org


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch key exists

[Alexander Gnauck]

> is is possible to check with RegistrySearch if a specified RegKey 
> exists? All my tests failed yet.
> 
> I want to check if the .NET 1.1 Framework is installed. It should be 
> installed if the Key 
> HKLM\Software\Microsoft\Windows\.NETFramework\policy\v1.1 exists.

i figured out the .NET Framework stuff with some other postings on the list.
But still have to check if some keys exist, and can't use the Name 
attrib for that.

Alex



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users