Re: [WiX-users] Environment variable that has project name with parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

[Sandi Remar]

Hi Blair!

I have latest stable version of WiX 3.0.

I was playing around with this issue and found a workaround.

If I add a reference to "MyProject", Visual studio Solution Explorer
displays a reference to it as "MyProject (MyProject\MyProject)".
So I edited WiX project file (Setup.wixproj) manually.

Original reference to "MyProject"in WiX project file that did not compile was:

  
  MyProject (MyProject\MyProject)
  {3e483c28-64f3-478b-8297-2fafb426cae3}
  True
   


After change a reference to "MyProject"in WiX project file looked like:

  
  MyProject
  {3e483c28-64f3-478b-8297-2fafb426cae3}
  True
   

After changing the name of a reference Visual studio Solution Explorer
displayed a reference  to "MyProject" properly as "MyProject" 
and everything works OK!

I think this is a problem with Votive and environment variables...

Best regards,
Sandi




From: Blair 
To: General discussion for Windows Installer XML toolset. 

Sent: Fri, November 6, 2009 1:36:48 AM
Subject: Re: [WiX-users] Environment variable that has project name with 
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Attachments usually don't survive the list server.

What version/build of WiX do you have installed?

-Original Message-
From: Sandi Remar [mailto:sandi_re...@yahoo.com] 
Sent: Thursday, November 05, 2009 12:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Hello Blair!

Thank you for your answer.
But I wanted to ask something else.
I will try to explain a little better:

I have a solution named "MySolution" with two solution folders - "MyProject"
and "MySetup".
Solution folder "MyProject" has one library project named "MyProject".
Solution folder "MySetup"has one WiX project named "Setup".
When I add a reference to "MyProject", a reference is added as "MyProject
(MyProject\MyProject)" - see attached pic. "TheSameName.bmp".

If I try to compile
 I get an error : 
"Error1Undefined preprocessor variable
'$(var.MyProject.TargetPath)'.D:\Zacasni\Test VS
Project2\MySolution\Setup\Product.wxs131Setup"

But if I rename a Solution folder "MyProject" to "MyProjectRenamed", and add
a reference to "MyProject", a reference is added properly as "MyProject " -
see attached pic. "DifferentName.bmp"
and everything compiles OK.

I can compile
 with no
errors.

Thank you for your time and patience,
Sandi





From: Blair 
To: General discussion for Windows Installer XML toolset.

Sent: Thu, November 5, 2009 5:20:21 PM
Subject: Re: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

For WiX, the solution isn't considered a project. So, your
MyProject\MyProject is known to the WiX preprocessor as simply MyProject.
Thus, no matter the name of the solution, your references will remain like
$(var.MyProject.TargetFileName).

Accessing the solution itself is via the following preprocessor macros:
$(var.SolutionDir)
$(var.SolutionExt)
$(var.SolutionFileName)
$(var.SolutionName)
$(var.SolutionPath)

-Original Message-
From: Sandi Remar [mailto:sandi_re...@yahoo.com]
Sent: Thursday, November 05, 2009 4:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Hello everybody!

I am new to WiX, so I hope that my question is not too dumb :-)

I use Visual Studio 2008 with Votive and WiX 3.0.
I have a problem using environment variables that have project names with
parentheses.
I stumbled upon this problem when I was adding a file to WiX source.

I have a solution with a Solution folder "MyProject" that contains a project
named "MyProject".

Since a Solution folder name is the same as the name of a project in it,
Visual studio obviously wants to destinguish these two names by changing a
project name.

I see this when I want to add reference to that project in Votive.
When I click References->Add Reference->Project, I see a reference to
"MyProject" listed as "MyProject (MyProject\MyProject)"

Here is the problem - Visual studio sees "MyProject" as "MyProject
(MyProject\MyProject)", but WiX reports an error when I compile this code:



I guess that parentheses in project name disturbs preprocessor.

When I change Solution folder name to some other name, "MyProject" is listed
as "MyProject"
and not "MyProject (MyProject\MyProject)"
and everything is OK, WiX compiles with no errors, when I compile this code:



I tried to put project name in double quotes , like $(var."MyProject
(MyProject\MyProject)".TargetFileName), but this does not work...

Does anybody have any suggestions?

Thanks!
Sandi



  
--

Re: [WiX-users] Windows 2008 server and msxml 4 SP 2 (msxml.msm) issue

[Blair]

MSMs generally don't place anything in the Add or Remove Programs list.

Where did the msxml.msm file you are using come from?

-Original Message-
From: Eschenbacher, Frank [mailto:frank.eschenbac...@voltdelta.net] 
Sent: Thursday, November 05, 2009 6:41 AM
To: wix-us...@lists.sourceforge.net.
Subject: [WiX-users] Windows 2008 server and msxml 4 SP 2 (msxml.msm) issue

Hello all,
 
we use wix 3.0 and have the following phenomenon:
 
Out Application consists of several files and the msxml.msm merge
module. On Windows XP SP 2 I see our Application and the msxml 4 in the
"Add or remove programs" list, everything works fine. So far so good.
 
On Windows 2008 server when installing the same msi package, msxml 4 is
not in the "Add or remove programs" list and does not seem to be
installed at all.
 
Does anyone have the same phenomenon or a solution?
 
Best regards
Frank
 
Go Green - Please consider the environment before printing this email
 

 
Volt Delta International GmbH, Landsberger Str. 110, D-80339 Muenchen 
Sitz: Muenchen, Amtsgericht Muenchen, HRB 156693, VAT-ID DE814437634 
Managing Directors (Geschaeftsfuehrer): Noel Hughes, Hans Pokorny, Yusuf
Bulan
 
 

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


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

Re: [WiX-users] Duplicated primary key in _SummaryInformation table of the transform

[Blair Murri]

There is a way to build an MSI such that it doesn't cab the files at all, which 
produces a layout that is identical to an admin install. I haven't tried it 
myself, but it probably involves some manipulations of the Media element and 
the SourceName attribute of the Directory element(s), as well as removing 
any/all Compressed attributes in File element(s).
I wonder if it would be possible to melt the MSM files and build patches based 
on that.
Looking at the section of the Diff.wixmst file you provided, you may try simply 
removing that from your wixmst file (leaving the rest of the file intact). Both 
MSIs should have that "row" in their summary information, so the fact that the 
wixmst is attempting to add the row indicates that something is up there. That 
type of surgery may be easier than changing your build process all around.
-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Thursday, November 05, 2009 5:34 PM
To: General discussion for Windows Installer XML toolset.
Cc: Jude Nwoko; Anandha Ganesan; Marc; Reyhner; Murugesan Vivekananthan; Clive 
Eastwood
Subject: Re: [WiX-users] Duplicated primary key in _SummaryInformation table of 
the transform
 Blair, all files we patch are part of merge modules. There are no files 
outside of a merge module at all. I guess that rules out the WIXPDB approach. 
Anyway, wixpdb files are introduced in WIX3, isn't it? In that case, we do not 
have any original wixpdb files since we used WIX 2 to generate the MSIs.
Is there any other alternative for admin installations? This process does not 
allow me to explode the MSI and patch it because of file sequencing issues from 
the SP1 MSP.
Thanks,
Sharat Janapareddy
~ 40269

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, November 04, 2009 3:34 PM
To: 'General discussion for Windows Installer XML toolset.'
Cc: Murugesan Vivekananthan; Jude Nwoko; Clive Eastwood; Marc Reyhner; Anandha 
Ganesan
Subject: Re: [WiX-users] Duplicated primary key in _SummaryInformation table of 
the transform
Regarding an alternative to admin installations:
If you aren't trying to patch merge module contents, you could try using the 
wixpdb files instead of the admin images.
If your "original" wixpdb doesn't have access to the older binaries, you can do 
the following in order to force a "bound/binary" wixpdb:
Each time you build an MSI you might patch later, you call light twice. The 
first time you specify the following two arguments: "-bf" and "-xo" and the 
"-o[ut]" argument (if present) should have an extension of ".wixout". The 
second time you call light, you pass it the .wixout as the only "objectFile" 
(along with all the same extensions as the first call). The resulting .wixpdb 
will also contain the files from the corresponding MSI.
You can then move that wixpdb forward in time to any build machine and torch & 
pyro will be able to find the embedded files in the wixpbd.
-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Wednesday, November 04, 2009 2:53 PM
To: General discussion for Windows Installer XML toolset.
Cc: Jude Nwoko; Anandha Ganesan; Marc Reyhner; Murugesan Vivekananthan; Clive 
Eastwood
Subject: [WiX-users] Duplicated primary key in _SummaryInformation table of the 
transform
The only entry I see related to this error is the _SummaryInformation table's 
(from the Diff.wixmst) field '11'. Here's the corresponding row
entry for that. 
 
  11
  2009/11/04 09:36:30
 
It looks like this field 11 is PID_LASTPRINTED property which has the timestamp 
when the admin image is created. Got this info from 
http://msdn.microsoft.com/en-us/library/aa369748(VS.85).aspx. I don't see any 
other row in the table with the same field number which is what the error seems 
to be suggesting.
So, what I would like to understand is - 
1. Since this WIXMST is generated by TORCH.exe, is there a way to skip 
generating this field.
2. Is there a way to apply a patch directly to an MSI instead of its admin 
image? I am currently using something like below to generate the Release --> 
SP1 admin image before generating a DIFF against the updated MSI:
  MSIEXEC -a ReleaseProduct.msi -p SP1_Patch.msp TARGETDIR=C:\Product
Thanks,
Sharat Janapareddy
~ 40269
-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Tuesday, November 03, 2009 7:58 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Error generating MSP for multiple SKUs
I am trying to create an SP1 rollup MSP using these steps - Apply the same SP1 
patch to both the Eval and Select SKUs of Release version separately, and then 
generate the DIFFs by comparing the corresponding updated versions.
I was able to get to the point where we have the transforms (wixmst) but I get 
this error while generating the MSP. The problem here is - the error does not 
say which WIXMST or WIXOBJ or what file is causing this.
1>

Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field

[Blair]

For the test scenario, go to Add/Remove Programs and select "Repair", and
make sure that the registry value doesn't change (test from each of the two
initial states).

Not sure why it doesn't delete, but you could try adding a RemoveRegistryKey
element to the same component.

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Thursday, November 05, 2009 5:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the
component's GUID field

Thanks Blair.


I tried it by using your code example. It works!

But I found a problem, after uninstallation, this registry entry is still in
the registry. Even if I use "createAndRemoveOnUninstall", it's still there.
I checked the uninstall log, it doesn't say if the delete key operation is
okay or not:
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveValue(Name=MyApp
3.0,Value="[INSTALLLOCATION]MyApp30.exe"[RunWhenWindowsStartsArgument],)
MSI (s) (D0:C0) [17:25:45:891]: Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 3: 2 
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveKey()


What can I do to make sure this registry entry is deleted upon uninstalling?

Also, you mentioned "You may need to preserve RUNWHENWINDOWSSTART and
restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair." - we use major upgrade, does it matter for us? If so, what is the
use case or test scenario to verify our install is fine with this restraint?

Thanks.




From: Blair 
To: General discussion for Windows Installer XML toolset.

Sent: Friday, October 30, 2009 5:54:06 PM
Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the
component's GUID field

Identity theft is always such a pain.

compone...@guid='*' is required to generate a "stable" guid. That means that
if the component's keypath didn't change, it is the same component. As a
result, both of your components, which share the exact same keypath, are the
same component as far as Windows Installer is concerned (they share the same
identity). The value isn't part of the keypath, unfortunately.

What you may consider doing instead is (since your components are currently
not transitive and are mutually exclusive) is something like this:








You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair.

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 30, 2009 2:27 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field

We use Wix 3.0.4805.0.

We run into a very strange link error: we have a component that uses "*" as
the GUID. But when we link it, it reports an error:
error LGHT0204 : ICE08: Component: RegistrySpecial has a duplicate GUID:
{A7C1768B-FF73-5DFC-8E76-E810E013F78A}


But I searched all of our source code, there is no GUID
"{A7C1768B-FF73-5DFC-8E76-E810E013F78A}" defined anywhere.

Here is the command line to compile and link it:
candle.exe -dRelease -out <.wixobj file> -arch x86 -ext 
myapp.wxs
light.exe -ext  -cultures:en-us -out myapp.msi -pdbout
 -loc  

Basically, this is what we'd like to do:
there is an option called "Start application when Windows starts". If the
end user select this option, we'll write the application's file path to a
registry entry; if the end user doesn't select this option, we'll also write
the entry with a parameter. The logic is just like this:
if (RUNWHENWINDOWSSTART) {
  write registry with "[PATH_TO_APP]"
} else {
  write registry with "[PATH_TO_APP] -bootload"
}

Here is the code:

RUNWHENWINDOWSSTART = 1












I thought "*" will generate GUID for each component. But how come it reports
that error? And it's always that ID. What is special about that ID? The
interesting thing is, if I delete one of the two components from the code,
the compile/link is fine. So it seems the root of the problem is that I'm
having these two components at the same time. Why I can't have these two
components at the same time? This is really a if-then-else scenario. Maybe I
shouldn't have two components to implement the logic? Is there any other way
to implement this?

Thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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

Re: [WiX-users] Some text on progress dialog

[Blair]

Yes. 1033 = en-US = English (United States). The attribute's value needs to
be the decimal LCID value.

A list of LCIDs are here:
http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Thursday, November 05, 2009 5:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Some text on progress dialog

Thanks Blair. You're a truly expert on Wix.


I added "" in my code. It works!

By the way, how does LCID work? Currently, in my code, I have
"Language='1033'" in my code, is this okay?

Thanks.




From: Blair 
To: General discussion for Windows Installer XML toolset.

Sent: Tuesday, November 3, 2009 10:18:47 PM
Subject: Re: [WiX-users] Some text on progress dialog

If you want to use the WiX-supplied values, you need to have the following
element in your authoring:  and have
"es-es" in your -Cultures parameter for light.exe. Otherwise, you need to
make sure your ProductLanguage is set to some LCID that identifies Spanish
so it will use the strings from the OS (assuming the OS has Spanish language
support installed).

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Tuesday, November 03, 2009 5:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Some text on progress dialog

We use Wix 3.0.


In the progress dialog, there are some text showing during installation such
as "Starting services", "Copying new files" or "Stopping services". I wonder
if these text configurable based on different language?

I found these string IDs and add the translation in each wxl files. But it
doesn't seem working. It still always shows English no matter what language
we choose. For instance, I have these in the WinUI_es-es.wxl:
Iniciando servicios
Copiando archivos nuevos
Deteniendo servicios
Creando accesos directos
Registrando producto
Quitando archivos de copia de
seguridad


But the Spanish installer still shows English. 

I doubt if these strings are from shell? Namely, they can't be customized
based on the language? But I'm not sure.

Let me know if you know it.

Thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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



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



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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


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

Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field

[little.forest]

Thanks Blair.


I tried it by using your code example. It works!

But I found a problem, after uninstallation, this registry entry is still in 
the registry. Even if I use "createAndRemoveOnUninstall", it's still there. I 
checked the uninstall log, it doesn't say if the delete key operation is okay 
or not:
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveValue(Name=MyApp 
3.0,Value="[INSTALLLOCATION]MyApp30.exe"[RunWhenWindowsStartsArgument],)
MSI (s) (D0:C0) [17:25:45:891]: Note: 1: 1402 2: 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 3: 2 
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveKey()


What can I do to make sure this registry entry is deleted upon uninstalling?

Also, you mentioned "You may need to preserve RUNWHENWINDOWSSTART and restore 
it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair." - we use major upgrade, does it matter for us? If so, what is the 
use case or test scenario to verify our install is fine with this restraint?

Thanks.




From: Blair 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 30, 2009 5:54:06 PM
Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the component's 
GUID field

Identity theft is always such a pain.

compone...@guid='*' is required to generate a "stable" guid. That means that
if the component's keypath didn't change, it is the same component. As a
result, both of your components, which share the exact same keypath, are the
same component as far as Windows Installer is concerned (they share the same
identity). The value isn't part of the keypath, unfortunately.

What you may consider doing instead is (since your components are currently
not transitive and are mutually exclusive) is something like this:








You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair.

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 30, 2009 2:27 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field

We use Wix 3.0.4805.0.

We run into a very strange link error: we have a component that uses "*" as
the GUID. But when we link it, it reports an error:
error LGHT0204 : ICE08: Component: RegistrySpecial has a duplicate GUID:
{A7C1768B-FF73-5DFC-8E76-E810E013F78A}


But I searched all of our source code, there is no GUID
"{A7C1768B-FF73-5DFC-8E76-E810E013F78A}" defined anywhere.

Here is the command line to compile and link it:
candle.exe -dRelease -out <.wixobj file> -arch x86 -ext 
myapp.wxs
light.exe -ext  -cultures:en-us -out myapp.msi -pdbout
 -loc  

Basically, this is what we'd like to do:
there is an option called "Start application when Windows starts". If the
end user select this option, we'll write the application's file path to a
registry entry; if the end user doesn't select this option, we'll also write
the entry with a parameter. The logic is just like this:
if (RUNWHENWINDOWSSTART) {
  write registry with "[PATH_TO_APP]"
} else {
  write registry with "[PATH_TO_APP] -bootload"
}

Here is the code:

RUNWHENWINDOWSSTART = 1












I thought "*" will generate GUID for each component. But how come it reports
that error? And it's always that ID. What is special about that ID? The
interesting thing is, if I delete one of the two components from the code,
the compile/link is fine. So it seems the root of the problem is that I'm
having these two components at the same time. Why I can't have these two
components at the same time? This is really a if-then-else scenario. Maybe I
shouldn't have two components to implement the logic? Is there any other way
to implement this?

Thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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


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

Re: [WiX-users] Some text on progress dialog

[little.forest]

Thanks Blair. You're a truly expert on Wix.


I added "" in my code. It works!

By the way, how does LCID work? Currently, in my code, I have "Language='1033'" 
in my code, is this okay?

Thanks.




From: Blair 
To: General discussion for Windows Installer XML toolset. 

Sent: Tuesday, November 3, 2009 10:18:47 PM
Subject: Re: [WiX-users] Some text on progress dialog

If you want to use the WiX-supplied values, you need to have the following
element in your authoring:  and have
"es-es" in your -Cultures parameter for light.exe. Otherwise, you need to
make sure your ProductLanguage is set to some LCID that identifies Spanish
so it will use the strings from the OS (assuming the OS has Spanish language
support installed).

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Tuesday, November 03, 2009 5:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Some text on progress dialog

We use Wix 3.0.


In the progress dialog, there are some text showing during installation such
as "Starting services", "Copying new files" or "Stopping services". I wonder
if these text configurable based on different language?

I found these string IDs and add the translation in each wxl files. But it
doesn't seem working. It still always shows English no matter what language
we choose. For instance, I have these in the WinUI_es-es.wxl:
Iniciando servicios
Copiando archivos nuevos
Deteniendo servicios
Creando accesos directos
Registrando producto
Quitando archivos de copia de
seguridad


But the Spanish installer still shows English. 

I doubt if these strings are from shell? Namely, they can't be customized
based on the language? But I'm not sure.

Let me know if you know it.

Thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

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


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



  __
Looking for the perfect gift? Give the gift of Flickr! 

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

Re: [WiX-users] Duplicated primary key in _SummaryInformation table of the transform

[Sharat Janapareddy]

 Blair, all files we patch are part of merge modules. There are no files 
outside of a merge module at all. I guess that rules out the WIXPDB approach. 
Anyway, wixpdb files are introduced in WIX3, isn't it? In that case, we do not 
have any original wixpdb files since we used WIX 2 to generate the MSIs.

Is there any other alternative for admin installations? This process does not 
allow me to explode the MSI and patch it because of file sequencing issues from 
the SP1 MSP.

Thanks,

Sharat Janapareddy
~ 40269


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Wednesday, November 04, 2009 3:34 PM
To: 'General discussion for Windows Installer XML toolset.'
Cc: Murugesan Vivekananthan; Jude Nwoko; Clive Eastwood; Marc Reyhner; Anandha 
Ganesan
Subject: Re: [WiX-users] Duplicated primary key in _SummaryInformation table of 
the transform

Regarding an alternative to admin installations:
If you aren't trying to patch merge module contents, you could try using the 
wixpdb files instead of the admin images.

If your "original" wixpdb doesn't have access to the older binaries, you can do 
the following in order to force a "bound/binary" wixpdb:

Each time you build an MSI you might patch later, you call light twice. The 
first time you specify the following two arguments: "-bf" and "-xo" and the 
"-o[ut]" argument (if present) should have an extension of ".wixout". The 
second time you call light, you pass it the .wixout as the only "objectFile" 
(along with all the same extensions as the first call). The resulting .wixpdb 
will also contain the files from the corresponding MSI.

You can then move that wixpdb forward in time to any build machine and torch & 
pyro will be able to find the embedded files in the wixpbd.

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Wednesday, November 04, 2009 2:53 PM
To: General discussion for Windows Installer XML toolset.
Cc: Jude Nwoko; Anandha Ganesan; Marc Reyhner; Murugesan Vivekananthan; Clive 
Eastwood
Subject: [WiX-users] Duplicated primary key in _SummaryInformation table of the 
transform

The only entry I see related to this error is the _SummaryInformation table's 
(from the Diff.wixmst) field '11'. Here's the corresponding row
entry for that. 


11
2009/11/04 09:36:30


It looks like this field 11 is PID_LASTPRINTED property which has the timestamp 
when the admin image is created. Got this info from 
http://msdn.microsoft.com/en-us/library/aa369748(VS.85).aspx. I don't see any 
other row in the table with the same field number which is what the error seems 
to be suggesting.

So, what I would like to understand is - 
1.  Since this WIXMST is generated by TORCH.exe, is there a way to skip 
generating this field.
2.  Is there a way to apply a patch directly to an MSI instead of its admin 
image? I am currently using something like below to generate the Release --> 
SP1 admin image before generating a DIFF against the updated MSI:
MSIEXEC -a ReleaseProduct.msi -p SP1_Patch.msp 
TARGETDIR=C:\Product

Thanks,

Sharat Janapareddy
~ 40269

-Original Message-
From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] 
Sent: Tuesday, November 03, 2009 7:58 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Error generating MSP for multiple SKUs

I am trying to create an SP1 rollup MSP using these steps - Apply the same SP1 
patch to both the Eval and Select SKUs of Release version separately, and then 
generate the DIFFs by comparing the corresponding updated versions.

I was able to get to the point where we have the transforms (wixmst) but I get 
this error while generating the MSP. The problem here is - the error does not 
say which WIXMST or WIXOBJ or what file is causing this.
1>errors in directory 
1>d:\enlistments\sp1.qfe_rollup\private\product\setup\wix\patch\server
1>d:\enlistments\sp1.qfe_rollup\private\product\setup\wix\patch\server\pyro.
exe : error PYRO0130 : The primary key '11' is duplicated in table 
'_SummaryInformation'.  Please remove one of the entries or rename a part of 
the primary key to avoid the collision.
1>NMAKE : fatal error U1077: 'd:\enlistments\
sp1.qfe_rollup\public\ext\wix\wix3-binaries\pyro.exe' : return code '0x82' 
BUILD: NMAKE.EXE /nologo BUILDMSG=Stop. LINKONLY=1 NOPASS0=1 NTTEST= UMTEST= 
386=1 failed - rc = 2

Any ideas on what this is talking about? I don't see any "11" in any of the 
WIX* files generated during this process.

Thanks,

Sharat Janapareddy
~ 40269


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

Re: [WiX-users] .wproj supports in VS 2k*

[Blair]

.wproj files are reported to be Wwise project files (from
http://www.audiokinetic.com/).

WiX msbuild (votive) project files have always been .wixproj as far as I
know. I have never seen .wproj used with WiX.

-Original Message-
From: Colin Yu [mailto:coli...@microsoft.com] 
Sent: Thursday, November 05, 2009 1:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] .wproj supports in VS 2k*

Yes, I am using the 64 bits version.

However, I do see the WiX project templates and I can add a new WiX project.

But it is interesting to notice that if I create a new WiX project, the
extension is .wixproj. The existing .wproj projects fail to load because the
project types are not understood. I believe that the project file extension
has changed from .wproj to .wixpro to avoid collision of the Wwise audio
file type. 

I am new to WiX and I am not so sure which toolset support .wproj extension.
I am not supposed to change the file extension to .wixproj. 


-Original Message-
From: John H. Bergman (XPedient Technologies)
[mailto:john.berg...@xpedienttechnologies.com] 
Sent: Thursday, November 05, 2009 1:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] .wproj supports in VS 2k*

Do you see the Wix Project types in the Add New Project?

If not, Votive did not install.  There was a post a while ago on the list
about manually installing the templates that would take care of it.   We had
a similar problem where the 64bit version would not install (3.5.1030) fully
on some of our developers computers, but the 32bit one did just fine.

-Original Message-
From: Colin Yu [mailto:coli...@microsoft.com] 
Sent: Thursday, November 05, 2009 1:16 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] .wproj supports in VS 2k*

I have installed the WiX Toolset but VS 2k8 still fails to load .wproj
projects. Can you give me a help on this?

Thanks

Colin


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


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



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


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

Re: [WiX-users] Is "perMachine" the default?

[Blair]

Not quite. There are two things at play here: the ALLUSERS property and the
"don't elevate" flag.

If you set InstallPrivileges to "elevated" the flag is not set (the
default). If you set InstallPrivileges to "limited" the flag is set. Nothing
is done wrt the property with this attribute.

If instead you set the InstallScope property, then the following happens:
If it is set to "perMachine", the property is set to "1" and the flag is not
set.
If it is set to "perUser", the property is not created and the flag is set.

In perUser packages, you want the flag set and the property not created. In
perMachine packages, you want the property set and the flag not set. Thus,
the InstallScope attribute does it all, and you don't need to worry about
the flag or the property being set correctly (for non Win7-only switching
packages).

-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net] 
Sent: Thursday, November 05, 2009 1:02 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Is "perMachine" the default?

When running my .msi on Vista, I do not see any difference between
InstallScope="perMachine" and not using this attribute at all. Is
"perMachine" the default?


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


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

Re: [WiX-users] InstallScope="perUser" makes only sense on Windows Seven?

[Blair]

If you set InstallScope="perUser" then your MSI will be marked to not prompt
for elevation. As a consequence you cannot set ALLUSERS and all resources
must go into locations that don't require elevation, unless you want to see
the error you are reporting. ProgramFilesFolder always requires elevation
(unless the default permissions have been severely altered) and as a result
your files should not go under ProgramFilesFolder if you set perUser as your
installation scope.

Real perUser installations are very possible under Vista and XP (I have
written several), but they require that you pick a directory to install that
is in the user's profile and not in "Program Files", and that you don't put
anything in HKLM.

In Windows 7 (using MSI 5.0), the ProgramFilesFolder gets remapped to a
profile location when the installation ends up perUser, which is what helps
enable switchable packages, but only when setting the MSIINSTALLPERUSER
property. In downlevel platforms, that folder never changes value and thus
always points to a protected perMachine location.

Also, Windows 7 does not force you to write perUser. You can write
perMachine and get just as good a job as under Vista with the very same MSI.
It simply makes a very old pattern installation pattern that was never very
well supported previously more viable.

Without Windows 7 you generally have to write two MSI files if you wish one
to be perUser and the other perMachine. With Windows 7 you can still use the
exact same MSI files in the same way (there is NO forcing of a new way), or
you can make a single package that can be installed either way using the new
property to enable the new behavior.

-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net] 
Sent: Thursday, November 05, 2009 1:01 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] InstallScope="perUser" makes only sense on Windows
Seven?

This perMachine / perUser discussion really confuses me. ;-)

 

I tried what happens if I set InstallScope="perUser".

 

The result is, that I cannot install the software on Vista, because it says
I do not have sufficient access rights to enter C:\Program
Files\[Manufacturer] (no, it does not ask whether it shall elevate, even if
I set InstallPrivileges="elevated" in addition to InstallScope="perUser").
This is because "real" perUser installs are only possible in Windows 7, but
all other Windows (= 99,9% of all existing installations) will share the
files folder.

 

So if InstallScope="perUser" useless on every OS besides Windows 7?

 

The consequence would be that one must write different .msi for Vista and
Windows 7 -- one that is perMachine (since perUser will not work) and one
that is perUser (since that seems to be what Microsoft wants us to do in
Windows 7).

 

This sounds weird, since everything else besides that flag will be the same!

 

Or did I miss something?

 

Thanks

Markus


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


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

Re: [WiX-users] Environment variable that has project name with parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

[Blair]

Attachments usually don't survive the list server.

What version/build of WiX do you have installed?

-Original Message-
From: Sandi Remar [mailto:sandi_re...@yahoo.com] 
Sent: Thursday, November 05, 2009 12:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Hello Blair!

Thank you for your answer.
But I wanted to ask something else.
I will try to explain a little better:

I have a solution named "MySolution" with two solution folders - "MyProject"
and "MySetup".
Solution folder "MyProject" has one library project named "MyProject".
Solution folder "MySetup"has one WiX project named "Setup".
When I add a reference to "MyProject", a reference is added as "MyProject
(MyProject\MyProject)" - see attached pic. "TheSameName.bmp".

If I try to compile
 I get an error : 
"Error1Undefined preprocessor variable
'$(var.MyProject.TargetPath)'.D:\Zacasni\Test VS
Project2\MySolution\Setup\Product.wxs131Setup"

But if I rename a Solution folder "MyProject" to "MyProjectRenamed", and add
a reference to "MyProject", a reference is added properly as "MyProject " -
see attached pic. "DifferentName.bmp"
and everything compiles OK.

I can compile
 with no
errors.

Thank you for your time and patience,
Sandi





From: Blair 
To: General discussion for Windows Installer XML toolset.

Sent: Thu, November 5, 2009 5:20:21 PM
Subject: Re: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

For WiX, the solution isn't considered a project. So, your
MyProject\MyProject is known to the WiX preprocessor as simply MyProject.
Thus, no matter the name of the solution, your references will remain like
$(var.MyProject.TargetFileName).

Accessing the solution itself is via the following preprocessor macros:
$(var.SolutionDir)
$(var.SolutionExt)
$(var.SolutionFileName)
$(var.SolutionName)
$(var.SolutionPath)

-Original Message-
From: Sandi Remar [mailto:sandi_re...@yahoo.com]
Sent: Thursday, November 05, 2009 4:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Hello everybody!

I am new to WiX, so I hope that my question is not too dumb :-)

I use Visual Studio 2008 with Votive and WiX 3.0.
I have a problem using environment variables that have project names with
parentheses.
I stumbled upon this problem when I was adding a file to WiX source.

I have a solution with a Solution folder "MyProject" that contains a project
named "MyProject".

Since a Solution folder name is the same as the name of a project in it,
Visual studio obviously wants to destinguish these two names by changing a
project name.

I see this when I want to add reference to that project in Votive.
When I click References->Add Reference->Project, I see a reference to
"MyProject" listed as "MyProject (MyProject\MyProject)"

Here is the problem - Visual studio sees "MyProject" as "MyProject
(MyProject\MyProject)", but WiX reports an error when I compile this code:



I guess that parentheses in project name disturbs preprocessor.

When I change Solution folder name to some other name, "MyProject" is listed
as "MyProject"
and not "MyProject (MyProject\MyProject)"
and everything is OK, WiX compiles with no errors, when I compile this code:



I tried to put project name in double quotes , like $(var."MyProject
(MyProject\MyProject)".TargetFileName), but this does not work...

Does anybody have any suggestions?

Thanks!
Sandi



  

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



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



  


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration 

Re: [WiX-users] IIS7 and WiX 3.5.1023.0

[Mike Carlson (DEV DIV)]

It sounds to me like a bug. Please file one - don't forget to copy all the 
helpful information (version information, sample authoring + log failure 
messages) from your mail into the bug.

Thanks,
Mike Carlson

-Original Message-
From: Duncan Kelbie [mailto:duncan.kel...@neuralt.com] 
Sent: Thursday, November 05, 2009 3:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] IIS7 and WiX 3.5.1023.0

Hi,

 

I need to install a virtual dir on IIS 7. When using WiX 3.5.1002.0 it
all worked except the virtual directory names were not getting resolved
so they were being set to my property names e.g.
[WEBPAGEVIRTUALDIRECTORY]. I thought this was fixed in WiX 3.5.1.023.0
so I upgraded but then the installation failed and I got a bunch of
errors. I found that it fails on both IIS7 and IIS6. Is this a bug or am
I doing something wrong? It worked great when installing to IIS6 using
version 3.0 of WiX. The errors I get are (when installing to IIS7):

 

WriteIIS7ConfigChanges:  Error 0x800700b7: Failed add
isapiCgiRestriction element

WriteIIS7ConfigChanges:  Error 0x800700b7: Failed to configure IIS web
svc ext

WriteIIS7ConfigChanges:  Error 0x800700b7: WriteIIS7ConfigChanges Failed

MSI (s) (E0:20) [11:03:54:402]: Error in rollback skipped. Return: 5

 

And the WiX code is:

 



  

  

  

  

  





  





  



  





  



 

Cheers


_
This e-mail has been scanned for viruses by Verizon Business Internet Managed 
Scanning Services - powered by MessageLabs. For further information visit 
http://www.verizonbusiness.com/uk
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] 'downgrading' a file during an upgrade

[John Nannenga]

Regarding "I've tried scripting the installer to remove the file in question 
first before writing the new one in, but only the file remove is running the 
first time the installer is run. If the installer is run a second time, the 
file remove does not run (because the file isn't there and the file is then 
written as expected)."

The concept you'll want to look up here is "transitive components".   
Reference:  http://msdn.microsoft.com/en-us/library/aa372462(VS.85).aspx



-Original Message-
From: John Nannenga 
Sent: Thursday, November 05, 2009 5:00 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] 'downgrading' a file during an upgrade

This might get the job done for you...


  



  
  ?Foo.exe=3 AND NOT PATCH


This would work if your upgrade process will install missing files. 




-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, November 05, 2009 10:40 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] 'downgrading' a file during an upgrade

Except for the fact that both components are "touching" the same file there is 
no relationship in Windows Installer's view-of-the-world between those two 
components apart from being in the same directory (they don't share a keyfile) 
so there is no way for it to know that the one component will cause the other 
to need to be "restored", so that kind of dance won't work within a single 
transaction. The component states are evaluated before any changes occur to the 
box, and are not reevaluated again once the script starts being built.

If the builds with the incorrect file version are all "in-house" you could try 
blocking installation when those builds are present and forcing a manual 
removal before installation. That would probably be the easiest.

The next easiest would be to move to 4.x.x.x or something like that for your 
version numbers (at least for that file).

You could try setting REINSTALLMODE but that affects the entire transaction, 
not just that file, so it could have other consequences you may not be able to 
mitigate.

-Original Message-
From: Plowman, Mark [mailto:mark.plow...@n4s.co.uk]
Sent: Thursday, November 05, 2009 2:51 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 'downgrading' a file during an upgrade

Apologies if this arrives twice. The first one got bounced.

 

Hoping someone can help me with this.

 

We've got a scenario where we've discovered a dll that has a rogue version 
number that is much higher than the rest of the system (due to a missed 
assemblyinfo file) . The system itself is still in development so we want to 
bring the version number back into line with the rest of the system. We've 
corrected the version number but we are currently running in upgrade mode for 
our releases.

Initially the file failed to update due to the version number of the original 
file being higher than the new file.

I've tried scripting the installer to remove the file in question first before 
writing the new one in, but only the file remove is running the first time the 
installer is run. If the installer is run a second time, the file remove does 
not run (because the file isn't there and the file is then written as expected).

 

I suspect this is happening because the installer is deciding what it can and 
can't do up front and is not taking the file removal into account when it 
compares version numbers. Am I correct in this assumption?

 

Second (and most important question) - is there a way around this without 
performing an uninstall? Ideally, I'd like to be able to tell the installer 
allow downgrading just for this one file but I haven't found a way of doing 
that yet. Anyone  have any ideas please?

 

 

The incorrect version number is 3.5.0.

The correct version number is 1.4.2007.

 

Below are excerpts from install logs and the wxs file so you can see what is 
happening.

 

Log:

MSI (s) (C8:E4) [16:08:58:636]: Component: RemoveApp_Code.dll;
Installed: Absent;   Request: Local;   Action: Local

MSI (s) (C8:E4) [16:08:58:636]: Component: App_Code.dll; Installed:
Absent;   Request: Local;   Action: Null

 

Here you can see that no action has been set for adding the file back in. 

 

Wxs script





  

  



  



 



  

 

We know that this method of removing and adding works as we have done the same 
thing for the web.config file with no problems. Of course, this is not a 
versioned file which probably explains why it works when it doesn't for the 
versioned file.

 

Any suggestions gratefully received.

 

Cheers,

Mark

 


This e-mail has come from Experian, the only business to have been twice named 
the UK's 'Business of the Year’ 

===
Information in this e-mail and any attachments is confidential, and may not be 
copied or used b

Re: [WiX-users] 'downgrading' a file during an upgrade

[John Nannenga]

This might get the job done for you...


  



  
  ?Foo.exe=3 AND NOT PATCH


This would work if your upgrade process will install missing files. 




-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, November 05, 2009 10:40 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] 'downgrading' a file during an upgrade

Except for the fact that both components are "touching" the same file there is 
no relationship in Windows Installer's view-of-the-world between those two 
components apart from being in the same directory (they don't share a keyfile) 
so there is no way for it to know that the one component will cause the other 
to need to be "restored", so that kind of dance won't work within a single 
transaction. The component states are evaluated before any changes occur to the 
box, and are not reevaluated again once the script starts being built.

If the builds with the incorrect file version are all "in-house" you could try 
blocking installation when those builds are present and forcing a manual 
removal before installation. That would probably be the easiest.

The next easiest would be to move to 4.x.x.x or something like that for your 
version numbers (at least for that file).

You could try setting REINSTALLMODE but that affects the entire transaction, 
not just that file, so it could have other consequences you may not be able to 
mitigate.

-Original Message-
From: Plowman, Mark [mailto:mark.plow...@n4s.co.uk]
Sent: Thursday, November 05, 2009 2:51 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 'downgrading' a file during an upgrade

Apologies if this arrives twice. The first one got bounced.

 

Hoping someone can help me with this.

 

We've got a scenario where we've discovered a dll that has a rogue version 
number that is much higher than the rest of the system (due to a missed 
assemblyinfo file) . The system itself is still in development so we want to 
bring the version number back into line with the rest of the system. We've 
corrected the version number but we are currently running in upgrade mode for 
our releases.

Initially the file failed to update due to the version number of the original 
file being higher than the new file.

I've tried scripting the installer to remove the file in question first before 
writing the new one in, but only the file remove is running the first time the 
installer is run. If the installer is run a second time, the file remove does 
not run (because the file isn't there and the file is then written as expected).

 

I suspect this is happening because the installer is deciding what it can and 
can't do up front and is not taking the file removal into account when it 
compares version numbers. Am I correct in this assumption?

 

Second (and most important question) - is there a way around this without 
performing an uninstall? Ideally, I'd like to be able to tell the installer 
allow downgrading just for this one file but I haven't found a way of doing 
that yet. Anyone  have any ideas please?

 

 

The incorrect version number is 3.5.0.

The correct version number is 1.4.2007.

 

Below are excerpts from install logs and the wxs file so you can see what is 
happening.

 

Log:

MSI (s) (C8:E4) [16:08:58:636]: Component: RemoveApp_Code.dll;
Installed: Absent;   Request: Local;   Action: Local

MSI (s) (C8:E4) [16:08:58:636]: Component: App_Code.dll; Installed:
Absent;   Request: Local;   Action: Null

 

Here you can see that no action has been set for adding the file back in. 

 

Wxs script





  

  



  



 



  

 

We know that this method of removing and adding works as we have done the same 
thing for the web.config file with no problems. Of course, this is not a 
versioned file which probably explains why it works when it doesn't for the 
versioned file.

 

Any suggestions gratefully received.

 

Cheers,

Mark

 


This e-mail has come from Experian, the only business to have been twice named 
the UK's 'Business of the Year’ 

===
Information in this e-mail and any attachments is confidential, and may not be 
copied or used by anyone other than the addressee, nor disclosed to any third 
party without our permission. There is no intention to create any legally 
binding contract or other binding commitment through the use of this electronic 
communication unless it is issued in accordance with the Experian Limited 
standard terms and conditions of purchase or other express written agreement 
between Experian Limited and the recipient. 
Although Experian has taken reasonable steps to ensure that this communication 
and any attachments are free from computer virus, you are advised to take your 
own steps to ensure that they are actually virus free. 
Companies Act information:
Registered name: Experian Limited
Re

Re: [WiX-users] Read ProductID (PIDKEY) from registry

[Wilson, Phil]

Sascha's point is that you can save this yourself if you really want to get it 
from the registry. ProductID might be the better property to change because 
it's been through any verification that might be done by ValidateProductID. 
However if you've already shipped the original it's too late, which is why 
upgrades need a sanity test before the original actually gets out the door. 

My point is that if you don't want to do that, then a custom action can call 
MsiGetProductInfo. You don't pass parameters anyway.

http://www.wixwiki.com/index.php?title=Simple_Custom_Action_Dll 

and you'll do a MsiGetProperty ("ProductCode" .. ) and then 
MsiGetProductInfo for "ProductID" on that returned product code, then 
MsiSetProperty (handle "MYOLDPIDKEY" ) to set the value into the 
MYOLDPIDKEY property, but there's no reason why you can't set PIDKEY. Since 
you're doing this on an upgrade of some kind you'd condition this CA call on 
the property in the Upgrade table. 

Phil Wilson 


-Original Message-
From: Tim Musschoot [mailto:tim.mussch...@telenet.be] 
Sent: Thursday, November 05, 2009 11:05 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Read ProductID (PIDKEY) from registry

It appears to be a property set by MSI in a location with a strange GUID. In
brief: I cannot find logic between the application and the place MSI puts
this parameter.

I need to make a customaction call to the "MsiGetProductInfo" method in
"msi.dll", passing some params. However, I've still not found how to call a
dll method, passing parameters :-s



-Oorspronkelijk bericht-
Van: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Verzonden: donderdag 5 november 2009 0:53
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Read ProductID (PIDKEY) from registry

Assuming that PIDKEY is just a property you're setting, you'll
probably want to set the property to a default value (e.g. DEMO) and
do a RegistrySearch to overwrite it if you can find an existing PIDKEY
in the registry.


 
  


Sascha


On Wed, Nov 4, 2009 at 6:31 AM, Tim Musschoot 
wrote:
> Hello,
>
> I've found a way of introducing a product serial in the Installer. This
key
> is set in the registry at the default location (as arranged by MSI). Now I
> want to read the key of a previous installation (at upgrade for example)
> into the PIDKEY variable of my WIX script (this is not done
automatically).
> Can someone tell me how this can be arranged?
>
> TIA,
> Tim
>
>
>

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


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


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



*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at Portland House, Bressenden Place, London, 
SW1E 5BF (Registered number 166023). For a list of European legal entities 
within the Invensys Group, please go to 
http://www.invensy

Re: [WiX-users] Per User / Per Machine

[Wilson, Phil]

InstallPrivileges is to do with whether Windows can show the UAC prompt or not. 
 InstallScope sets the ALLUSERS per machine/per user value. I'm not sure what 
you mean by one overriding the other. If you can author a true per-user install 
that you know doesn't require elevation then you do a per-user install and set 
InstallPrivileges to limited and it installs without a UAC prompt. I don't know 
why you can't author a per-user that elevates, unless you're referring to a 
non-admin user. You run it and it asks for a UAC prompt if you're an 
administrator, and that elevates it. If you're not an administrator, of course 
you can't take an MSI and have it run elevated. Elevation isn't in the package 
- it depends on the installing user's privileges. Other scenarios will produce 
the "over the shoulder" dialog where the administrator supplies credentials on 
behalf of the non-admin user.

Phil Wilson


-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
Sent: Thursday, November 05, 2009 1:04 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

But as I just tried out, it is impossible to author a elevated perUSer
installation: InstallScope="perUser" actually does override a manually coded
InstallPrivileges="elevated" attribute! So is that a bug in WiX?

> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
> Sent: Donnerstag, 5. November 2009 21:44
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User / Per Machine
>
> A couple of comments:
>
> 1. It's only since UAC that the per-machine/per-user difficulty has
> been around. It's not been there forever. MSIINSTALLPERUSER is the
> solution in MSI 5.0.
> http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori
> ng-a-single-package-for-per-user-or-per-machine-installation-context-
> in-windows-7.aspx
>
> 2. It's hard to talk about per-user and per-machine without taking
> privilege into account. A lot of people seem to be under the impression
> that you don't need to be elevated to install a per-user MSI, and then
> author it to write to all kinds of restricted locations and wonder why
> they need admin privilege to install it. ALLUSERS=2 produces unexpected
> effects for non-elevated users where you get a per-user install when a
> per-system may have been assumed (some other user logs on and says "I
> can see the files are installed but there's no shortcut").
>
> Phil Wilson
>
> -Original Message-
> From: Markus Karg [mailto:markus.k...@gmx.net]
> Sent: Thursday, November 05, 2009 11:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> Blair,
>
> thank you very much for your detailed answer. :-)
>
> So if I understand correctly, all I have to do is to set ALLUSERS to 1?
> Ok,
> nice. :-)
>
> But actually, after decades of seeing lots of installers asking the
> administrator where the *he* wants the files get copied to, I do not
> understand why it is up to *the .msi author* to decide about this...
> (actually I do not see any sense in deciding this *per .msi file* at
> all, as
> virtually all currently installed products are installed *per machine*
> anyways since no Windows before Seven was able to do a pure per-user
> install, and nobody ever seriously complained about that, and with a
> decision *per .msi file* chaos is likely to come...: "Hey admin, why
> can I
> execute all programs but not this one? Why can everybody but me execute
> this
> program? And why did it work on Vista but on Seven it is just vanished
> from
> my Start menu?"). For me as a MSI starter this reads like: "You can't
> do it
> right. I will fail anyways." ;-)
>
> Regards
> Markus
>
> > -Original Message-
> > From: Blair [mailto:os...@live.com]
> > Sent: Donnerstag, 5. November 2009 12:57
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Some items' ultimate locations depend on the ALLUSERS value. Some
> > examples:
> >
> > HKCR is really a merge of a key under HKLM and a different key under
> > HKCU.
> > If ALLUSERS is set to 1, you get the HKLM registration, otherwise
> (when
> > it
> > is blank) you get the HKCU one.
> >
> > The predefined property StartMenuFolder varies its value based on
> > ALLUSERS
> > as well. See the following table:
> > Type of Install REFKNOWNFOLDERIDCSIDL
> > Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> > Per-userStartMenu   CSIDL_STARTMENU
> >
> > The portion of your authoring for items using those two values are
> > "easy"
> > since the actual authoring doesn't change. However, the location of
> the
> > binary that the verb and the shortcut point to need to be in a
> location
> > that
> > will be correctly identified, and that location should vary based on
> > what
> > value of 

Re: [WiX-users] Patch information

[Scharp, Craig]

Hi Pally,

Perfect!  I'm off and running.  Thank you!

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Thursday, November 05, 2009 9:19 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch information

Unless you're specifically using WiX v2.0 the first link is out-of-date
(it's still pretty good but you do need the Windows SDK installed to use
MSIMSP.exe which it doesn't mention).

Using WiX v3.0 there are 2 different ways to generate patches. See ->
http://wix.sourceforge.net/manual-wix3/patching.htm and the pages it
links to.

Personally I use the first method listed there as I had issues using the
purely-WiX method but I think that may be because I was used to doing it
the PCP way in WiX v2.0. Those pages are also available in the WiX.chm &
are very well written & easy to follow in my humble opinion.

If you have any questions just fire them at the list, there's plenty of
experienced people around who should be able to help you if you get
stuck.

Good luck.

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

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


-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com] 
Sent: 04 November 2009 15:55
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Patch information

Hi WIX users,

 

I have to do a patch for a major upgrade.  I haven't done that yet and
trying to find a good resource that will show me how to.  I have been
using the three links below for information, but they seem to be doing
different things.  Can anyone steer me towards a good recent "how to"
for building a patch?  I only need to replace a few files on the
website.  Here are the links that I'm using for resource:

 

http://wix.sourceforge.net/manual-wix2/patch_building.htm

http://www.tramontana.co.hu/wix/lesson4.php#4.3

http://blogs.technet.com/alexshev/archive/2008/03/08/from-msi-to-wix-par
t-9-patching.aspx

 

Thanks in advance for any ideas or suggestions!


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




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

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

Re: [WiX-users] Edit control & default button

[Dan Giambalvo]

So, is there any way to work around this issue?  Is there something I can do in 
the handler of my button to cause a focus change before I invoke my CA?  

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Wednesday, November 04, 2009 4:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Edit control & default button

Dan Giambalvo wrote:
> I'm running into a strange issue with an interaction between an Edit control 
> and a default button with a custom action on a WiX Dialog.  The Edit is tied 
> to an MSI property, and the button's custom action does some processing to 
> validate the value of that property.   I'm finding when I make the button 
> default (so it responds to Enter), that the CustomAction is not passed the 
> updated value of the control.
>
> Is this a known limitation of Windows Installer UI?
>   

Dunno if it's known, but it makes sense, as default buttons don't 
trigger a loss of focus.

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



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


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

Re: [WiX-users] .wproj supports in VS 2k*

[Colin Yu]

Yes, I am using the 64 bits version.

However, I do see the WiX project templates and I can add a new WiX project.

But it is interesting to notice that if I create a new WiX project, the 
extension is .wixproj. The existing .wproj projects fail to load because the 
project types are not understood. I believe that the project file extension has 
changed from .wproj to .wixpro to avoid collision of the Wwise audio file type. 

I am new to WiX and I am not so sure which toolset support .wproj extension. I 
am not supposed to change the file extension to .wixproj. 


-Original Message-
From: John H. Bergman (XPedient Technologies) 
[mailto:john.berg...@xpedienttechnologies.com] 
Sent: Thursday, November 05, 2009 1:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] .wproj supports in VS 2k*

Do you see the Wix Project types in the Add New Project?

If not, Votive did not install.  There was a post a while ago on the list about 
manually installing the templates that would take care of it.   We had a 
similar problem where the 64bit version would not install (3.5.1030) fully on 
some of our developers computers, but the 32bit one did just fine.

-Original Message-
From: Colin Yu [mailto:coli...@microsoft.com] 
Sent: Thursday, November 05, 2009 1:16 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] .wproj supports in VS 2k*

I have installed the WiX Toolset but VS 2k8 still fails to load .wproj 
projects. Can you give me a help on this?

Thanks

Colin

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

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


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

Re: [WiX-users] Per User / Per Machine

[Markus Karg]

But as I just tried out, it is impossible to author a elevated perUSer
installation: InstallScope="perUser" actually does override a manually coded
InstallPrivileges="elevated" attribute! So is that a bug in WiX?

> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
> Sent: Donnerstag, 5. November 2009 21:44
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> A couple of comments:
> 
> 1. It's only since UAC that the per-machine/per-user difficulty has
> been around. It's not been there forever. MSIINSTALLPERUSER is the
> solution in MSI 5.0.
> http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori
> ng-a-single-package-for-per-user-or-per-machine-installation-context-
> in-windows-7.aspx
> 
> 2. It's hard to talk about per-user and per-machine without taking
> privilege into account. A lot of people seem to be under the impression
> that you don't need to be elevated to install a per-user MSI, and then
> author it to write to all kinds of restricted locations and wonder why
> they need admin privilege to install it. ALLUSERS=2 produces unexpected
> effects for non-elevated users where you get a per-user install when a
> per-system may have been assumed (some other user logs on and says "I
> can see the files are installed but there's no shortcut").
> 
> Phil Wilson
> 
> -Original Message-
> From: Markus Karg [mailto:markus.k...@gmx.net]
> Sent: Thursday, November 05, 2009 11:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> Blair,
> 
> thank you very much for your detailed answer. :-)
> 
> So if I understand correctly, all I have to do is to set ALLUSERS to 1?
> Ok,
> nice. :-)
> 
> But actually, after decades of seeing lots of installers asking the
> administrator where the *he* wants the files get copied to, I do not
> understand why it is up to *the .msi author* to decide about this...
> (actually I do not see any sense in deciding this *per .msi file* at
> all, as
> virtually all currently installed products are installed *per machine*
> anyways since no Windows before Seven was able to do a pure per-user
> install, and nobody ever seriously complained about that, and with a
> decision *per .msi file* chaos is likely to come...: "Hey admin, why
> can I
> execute all programs but not this one? Why can everybody but me execute
> this
> program? And why did it work on Vista but on Seven it is just vanished
> from
> my Start menu?"). For me as a MSI starter this reads like: "You can't
> do it
> right. I will fail anyways." ;-)
> 
> Regards
> Markus
> 
> > -Original Message-
> > From: Blair [mailto:os...@live.com]
> > Sent: Donnerstag, 5. November 2009 12:57
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Some items' ultimate locations depend on the ALLUSERS value. Some
> > examples:
> >
> > HKCR is really a merge of a key under HKLM and a different key under
> > HKCU.
> > If ALLUSERS is set to 1, you get the HKLM registration, otherwise
> (when
> > it
> > is blank) you get the HKCU one.
> >
> > The predefined property StartMenuFolder varies its value based on
> > ALLUSERS
> > as well. See the following table:
> > Type of Install REFKNOWNFOLDERIDCSIDL
> > Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> > Per-userStartMenu   CSIDL_STARTMENU
> >
> > The portion of your authoring for items using those two values are
> > "easy"
> > since the actual authoring doesn't change. However, the location of
> the
> > binary that the verb and the shortcut point to need to be in a
> location
> > that
> > will be correctly identified, and that location should vary based on
> > what
> > value of ALLUSERS you are supporting (if you use ProgramFilesFolder,
> > for
> > instance, the location you get will be in a non-profile location that
> > requires elevation to access, that is, a per-machine location, so you
> > can't
> > really use it in a per-user package.)
> >
> > -Original Message-
> > From: Markus Karg [mailto:markus.k...@gmx.net]
> > Sent: Wednesday, November 04, 2009 10:53 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > But how to do that, "author the package based on your decision"?
> >
> > I mean, I just have two files, one program menu item and one
> extension
> > verb.
> > The .wxs file is more or less a copy of the WiX manual's samples /
> WiX
> > tutorial code snippets.
> >
> > The WiX manual does not say something about "authoring the packaging
> > based
> > on your decision", nor does the WiX tutorial.
> >
> > Is it enough to just set the ALLUSERS property, or how is that to be
> > done
> > "author the package based on your decision"?
> >
> > Sorry for one more silly questions, but I just can't find a H

[WiX-users] Is "perMachine" the default?

[Markus Karg]

When running my .msi on Vista, I do not see any difference between
InstallScope="perMachine" and not using this attribute at all. Is
"perMachine" the default?

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

[WiX-users] InstallScope="perUser" makes only sense on Windows Seven?

[Markus Karg]

This perMachine / perUser discussion really confuses me. ;-)

 

I tried what happens if I set InstallScope="perUser".

 

The result is, that I cannot install the software on Vista, because it says
I do not have sufficient access rights to enter C:\Program
Files\[Manufacturer] (no, it does not ask whether it shall elevate, even if
I set InstallPrivileges="elevated" in addition to InstallScope="perUser").
This is because "real" perUser installs are only possible in Windows 7, but
all other Windows (= 99,9% of all existing installations) will share the
files folder.

 

So if InstallScope="perUser" useless on every OS besides Windows 7?

 

The consequence would be that one must write different .msi for Vista and
Windows 7 -- one that is perMachine (since perUser will not work) and one
that is perUser (since that seems to be what Microsoft wants us to do in
Windows 7).

 

This sounds weird, since everything else besides that flag will be the same!

 

Or did I miss something?

 

Thanks

Markus

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

Re: [WiX-users] .wproj supports in VS 2k*

[John H. Bergman (XPedient Technologies)]

Do you see the Wix Project types in the Add New Project?

If not, Votive did not install.  There was a post a while ago on the list about 
manually installing the templates that would take care of it.   We had a 
similar problem where the 64bit version would not install (3.5.1030) fully on 
some of our developers computers, but the 32bit one did just fine.

-Original Message-
From: Colin Yu [mailto:coli...@microsoft.com] 
Sent: Thursday, November 05, 2009 1:16 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] .wproj supports in VS 2k*

I have installed the WiX Toolset but VS 2k8 still fails to load .wproj 
projects. Can you give me a help on this?

Thanks

Colin

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

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

Re: [WiX-users] Per User / Per Machine

[Wilson, Phil]

A couple of comments: 

1. It's only since UAC that the per-machine/per-user difficulty has been 
around. It's not been there forever. MSIINSTALLPERUSER is the solution in MSI 
5.0. 
http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx
 

2. It's hard to talk about per-user and per-machine without taking privilege 
into account. A lot of people seem to be under the impression that you don't 
need to be elevated to install a per-user MSI, and then author it to write to 
all kinds of restricted locations and wonder why they need admin privilege to 
install it. ALLUSERS=2 produces unexpected effects for non-elevated users where 
you get a per-user install when a per-system may have been assumed (some other 
user logs on and says "I can see the files are installed but there's no 
shortcut"). 

Phil Wilson 

-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net] 
Sent: Thursday, November 05, 2009 11:53 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Blair,

thank you very much for your detailed answer. :-)

So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok,
nice. :-)

But actually, after decades of seeing lots of installers asking the
administrator where the *he* wants the files get copied to, I do not
understand why it is up to *the .msi author* to decide about this...
(actually I do not see any sense in deciding this *per .msi file* at all, as
virtually all currently installed products are installed *per machine*
anyways since no Windows before Seven was able to do a pure per-user
install, and nobody ever seriously complained about that, and with a
decision *per .msi file* chaos is likely to come...: "Hey admin, why can I
execute all programs but not this one? Why can everybody but me execute this
program? And why did it work on Vista but on Seven it is just vanished from
my Start menu?"). For me as a MSI starter this reads like: "You can't do it
right. I will fail anyways." ;-)

Regards
Markus

> -Original Message-
> From: Blair [mailto:os...@live.com]
> Sent: Donnerstag, 5. November 2009 12:57
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> Some items' ultimate locations depend on the ALLUSERS value. Some
> examples:
> 
> HKCR is really a merge of a key under HKLM and a different key under
> HKCU.
> If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when
> it
> is blank) you get the HKCU one.
> 
> The predefined property StartMenuFolder varies its value based on
> ALLUSERS
> as well. See the following table:
> Type of Install   REFKNOWNFOLDERIDCSIDL
> Per-machine   CommonStartMenu CSIDL_COMMON_STARTMENU
> Per-user  StartMenu   CSIDL_STARTMENU
> 
> The portion of your authoring for items using those two values are
> "easy"
> since the actual authoring doesn't change. However, the location of the
> binary that the verb and the shortcut point to need to be in a location
> that
> will be correctly identified, and that location should vary based on
> what
> value of ALLUSERS you are supporting (if you use ProgramFilesFolder,
> for
> instance, the location you get will be in a non-profile location that
> requires elevation to access, that is, a per-machine location, so you
> can't
> really use it in a per-user package.)
> 
> -Original Message-
> From: Markus Karg [mailto:markus.k...@gmx.net]
> Sent: Wednesday, November 04, 2009 10:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> But how to do that, "author the package based on your decision"?
> 
> I mean, I just have two files, one program menu item and one extension
> verb.
> The .wxs file is more or less a copy of the WiX manual's samples / WiX
> tutorial code snippets.
> 
> The WiX manual does not say something about "authoring the packaging
> based
> on your decision", nor does the WiX tutorial.
> 
> Is it enough to just set the ALLUSERS property, or how is that to be
> done
> "author the package based on your decision"?
> 
> Sorry for one more silly questions, but I just can't find a How-To for
> that.
> 
> Thanks
> Markus
> 
> > -Original Message-
> > From: Blair [mailto:os...@live.com]
> > Sent: Mittwoch, 4. November 2009 06:47
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Sorry if I am confusing you.
> >
> > I recommend you decide upfront if your installation will be per-user
> or
> > per-machine. Don't try to make a package that is intended to be
> > switchable.
> >
> > Then author the package based on your decision.
> >
> > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > workable
> > packages that can be switched during insta

Re: [WiX-users] Environment variable that has project name with parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

[Sandi Remar]

Hello Blair!

Thank you for your answer.
But I wanted to ask something else.
I will try to explain a little better:

I have a solution named "MySolution" with two
solution folders - "MyProject" and "MySetup".
Solution folder "MyProject" has one library project named "MyProject".
Solution folder "MySetup"has one WiX project named "Setup".
When I add a reference to "MyProject", a reference is
added as "MyProject (MyProject\MyProject)" - see attached pic. 
"TheSameName.bmp".

If I try to compile

I get an error : 
"Error1Undefined preprocessor variable '$(var.MyProject.TargetPath)'.   
 D:\Zacasni\Test VS Project2\MySolution\Setup\Product.wxs131Setup"

But if I rename a Solution folder "MyProject" to "MyProjectRenamed",
and add a reference to "MyProject", a reference is
added properly as "MyProject " - see attached pic. "DifferentName.bmp"
and everything compiles OK.

I can compile 

with no errors.

Thank you for your time and patience,
Sandi





From: Blair 
To: General discussion for Windows Installer XML toolset. 

Sent: Thu, November 5, 2009 5:20:21 PM
Subject: Re: [WiX-users] Environment variable that has project name with 
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

For WiX, the solution isn't considered a project. So, your
MyProject\MyProject is known to the WiX preprocessor as simply MyProject.
Thus, no matter the name of the solution, your references will remain like
$(var.MyProject.TargetFileName).

Accessing the solution itself is via the following preprocessor macros:
$(var.SolutionDir)
$(var.SolutionExt)
$(var.SolutionFileName)
$(var.SolutionName)
$(var.SolutionPath)

-Original Message-
From: Sandi Remar [mailto:sandi_re...@yahoo.com] 
Sent: Thursday, November 05, 2009 4:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Environment variable that has project name with
parentheses - $(var.MyProject (MyProject\MyProject).TargetFileName)

Hello everybody!

I am new to WiX, so I hope that my question is not too dumb :-)

I use Visual Studio 2008 with Votive and WiX 3.0.
I have a problem using environment variables that have project names with
parentheses.
I stumbled upon this problem when I was adding a file to WiX source.

I have a solution with a Solution folder "MyProject" that contains a project
named "MyProject".

Since a Solution folder name is the same as the name of a project in it,
Visual studio obviously wants to destinguish these two names by changing a
project name.

I see this when I want to add reference to that project in Votive.
When I click References->Add Reference->Project, I see a reference to 
"MyProject" listed as "MyProject (MyProject\MyProject)"

Here is the problem - Visual studio sees "MyProject" as "MyProject
(MyProject\MyProject)",
but WiX reports an error when I compile this code:



I guess that parentheses in project name disturbs preprocessor.

When I change Solution folder name to some other name, "MyProject" is listed
as "MyProject"
and not "MyProject (MyProject\MyProject)"
and everything is OK, WiX compiles with no errors, when I compile this code:



I tried to put project name in double quotes , like
$(var."MyProject (MyProject\MyProject)".TargetFileName), but this does not
work...

Does anybody have any suggestions?

Thanks!
Sandi



  

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


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



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

Re: [WiX-users] Per User / Per Machine

[Markus Karg]

Blair,

thank you very much for your detailed answer. :-)

So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok,
nice. :-)

But actually, after decades of seeing lots of installers asking the
administrator where the *he* wants the files get copied to, I do not
understand why it is up to *the .msi author* to decide about this...
(actually I do not see any sense in deciding this *per .msi file* at all, as
virtually all currently installed products are installed *per machine*
anyways since no Windows before Seven was able to do a pure per-user
install, and nobody ever seriously complained about that, and with a
decision *per .msi file* chaos is likely to come...: "Hey admin, why can I
execute all programs but not this one? Why can everybody but me execute this
program? And why did it work on Vista but on Seven it is just vanished from
my Start menu?"). For me as a MSI starter this reads like: "You can't do it
right. I will fail anyways." ;-)

Regards
Markus

> -Original Message-
> From: Blair [mailto:os...@live.com]
> Sent: Donnerstag, 5. November 2009 12:57
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> Some items' ultimate locations depend on the ALLUSERS value. Some
> examples:
> 
> HKCR is really a merge of a key under HKLM and a different key under
> HKCU.
> If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when
> it
> is blank) you get the HKCU one.
> 
> The predefined property StartMenuFolder varies its value based on
> ALLUSERS
> as well. See the following table:
> Type of Install   REFKNOWNFOLDERIDCSIDL
> Per-machine   CommonStartMenu CSIDL_COMMON_STARTMENU
> Per-user  StartMenu   CSIDL_STARTMENU
> 
> The portion of your authoring for items using those two values are
> "easy"
> since the actual authoring doesn't change. However, the location of the
> binary that the verb and the shortcut point to need to be in a location
> that
> will be correctly identified, and that location should vary based on
> what
> value of ALLUSERS you are supporting (if you use ProgramFilesFolder,
> for
> instance, the location you get will be in a non-profile location that
> requires elevation to access, that is, a per-machine location, so you
> can't
> really use it in a per-user package.)
> 
> -Original Message-
> From: Markus Karg [mailto:markus.k...@gmx.net]
> Sent: Wednesday, November 04, 2009 10:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
> 
> But how to do that, "author the package based on your decision"?
> 
> I mean, I just have two files, one program menu item and one extension
> verb.
> The .wxs file is more or less a copy of the WiX manual's samples / WiX
> tutorial code snippets.
> 
> The WiX manual does not say something about "authoring the packaging
> based
> on your decision", nor does the WiX tutorial.
> 
> Is it enough to just set the ALLUSERS property, or how is that to be
> done
> "author the package based on your decision"?
> 
> Sorry for one more silly questions, but I just can't find a How-To for
> that.
> 
> Thanks
> Markus
> 
> > -Original Message-
> > From: Blair [mailto:os...@live.com]
> > Sent: Mittwoch, 4. November 2009 06:47
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Sorry if I am confusing you.
> >
> > I recommend you decide upfront if your installation will be per-user
> or
> > per-machine. Don't try to make a package that is intended to be
> > switchable.
> >
> > Then author the package based on your decision.
> >
> > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > workable
> > packages that can be switched during installation. However, the
> advice
> > is
> > still: don't do it. Make it one or the other and prevent the one you
> > don't
> > support.
> >
> > -Original Message-
> > From: Markus Karg [mailto:markus.k...@gmx.net]
> > Sent: Tuesday, November 03, 2009 9:28 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Blair,
> >
> > now I am more confused than before. On one hand you say, I shall
> write
> > a
> > .msi that is either perUser OR perMachine, on the other hand you say
> > that it
> > is very hard to do when not using MSI 5 (which is only available on
> > Windows
> > 7). So for me this reads like: "For a MSI beginner it is impossible
> to
> > write
> > a correctly working setup on any OS before W7.";-(
> >
> > Regards
> > Markus
> >
> > > -Original Message-
> > > From: Blair [mailto:os...@live.com]
> > > Sent: Montag, 2. November 2009 21:43
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > All resources (files, registry entries, etc.) can generally be
> > divid

[WiX-users] .wproj supports in VS 2k*

[Colin Yu]

I have installed the WiX Toolset but VS 2k8 still fails to load .wproj 
projects. Can you give me a help on this?

Thanks

Colin

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

Re: [WiX-users] Read ProductID (PIDKEY) from registry

[Tim Musschoot]

It appears to be a property set by MSI in a location with a strange GUID. In
brief: I cannot find logic between the application and the place MSI puts
this parameter.

I need to make a customaction call to the "MsiGetProductInfo" method in
"msi.dll", passing some params. However, I've still not found how to call a
dll method, passing parameters :-s



-Oorspronkelijk bericht-
Van: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Verzonden: donderdag 5 november 2009 0:53
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Read ProductID (PIDKEY) from registry

Assuming that PIDKEY is just a property you're setting, you'll
probably want to set the property to a default value (e.g. DEMO) and
do a RegistrySearch to overwrite it if you can find an existing PIDKEY
in the registry.


 
  


Sascha


On Wed, Nov 4, 2009 at 6:31 AM, Tim Musschoot 
wrote:
> Hello,
>
> I've found a way of introducing a product serial in the Installer. This
key
> is set in the registry at the default location (as arranged by MSI). Now I
> want to read the key of a previous installation (at upgrade for example)
> into the PIDKEY variable of my WIX script (this is not done
automatically).
> Can someone tell me how this can be arranged?
>
> TIA,
> Tim
>
>
>

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


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


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

Re: [WiX-users] Read ProductID (PIDKEY) from registry

[Tim Musschoot]

Thx so far. I tried to do this from within C# code, and this works very
well.

Can someone tell me how I can call a method in "msi.dll" from WIX, passing a
number of parameters to the method?

TIA,
Tim

-Oorspronkelijk bericht-
Van: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
Verzonden: dinsdag 3 november 2009 23:42
Aan: General discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Read ProductID (PIDKEY) from registry

It might be set in the registry (isn't everything?) but that seems to be an
implementation detail. AFAIK the correct way to get this value for an
installed product is to call MsiGetProductInfo(mailto:tim.mussch...@telenet.be] 
Sent: Tuesday, November 03, 2009 11:32 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Read ProductID (PIDKEY) from registry

Hello,

I've found a way of introducing a product serial in the Installer. This key
is set in the registry at the default location (as arranged by MSI). Now I
want to read the key of a previous installation (at upgrade for example)
into the PIDKEY variable of my WIX script (this is not done automatically).
Can someone tell me how this can be arranged? 

TIA,
Tim



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



*** Confidentiality Notice: This e-mail, including any associated or
attached files, is intended solely for the individual or entity to which it
is addressed. This e-mail is confidential and may well also be legally
privileged. If you have received it in error, you are on notice of its
status. Please notify the sender immediately by reply e-mail and then delete
this message from your system. Please do not copy it or use it for any
purposes, or disclose its contents to any other person. This email comes
from a division of the Invensys Group, owned by Invensys plc, which is a
company registered in England and Wales with its registered office at
Portland House, Bressenden Place, London, SW1E 5BF (Registered number
166023). For a list of European legal entities within the Invensys Group,
please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77
. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).




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


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