[WiX-users] Registering a dll in Vista

[Colin Bleckner]

Wow, this has been a long two days in WiX world.  I've been trying to 
register a single DLL with WiX.  I started by using heat to capture all 
the registry keys set by my DLL.  (Feature request: it would be AWESOME 
if heat.exe returned some sort of error message in Vista telling me that 
even though it's generating valid output, it's not actually generating 
the correct set of registry keys.  After a day of beating my head 
against a wall I happened to stumble across a wixwiki page that 
mentioned that heat doesn't work 100% correctly in Vista.  Fantastic.)

Anyway, I ran heat on XP and got a more complete looking set of registry 
keys.  But my installer STILL didn't register my DLL on a fresh Vista 
install correctly.  I just finally discovered that if I turn off Vista's 
UAC first my installer works correctly.  Is that expected?  Is there 
anything I can do to avoid this?  Or at the very least a condition I can 
set to prevent a seemingly valid install happen?

Sorry for sounding a little rantish, it's been a long couple days... :)
Colin

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

[WiX-users] Передайте в бухгалтерию

[Анастасия Гавриловна]

В бухгалтерию:

27 мая с 10.00 до 17.00.

Заработная плата: налоговые, бухгалтерские, правовые.
 Елена Воробьева:к.э.н., ведущий эксперт еженедельника Экономика и жизнь, автор 
книг Зарплата с учетом требований налоговых органов, ЕСН: новейший справочник 
налогоплательщика, НДФЛ: новейший справочник налогоплательщика и др.

Программу вышлем по запросу
Стоимость участия 8900руб. СКИДКА для постоянных клиентов
В стоимость включены:  методические материалы; обед, кофе-брейк.
 Заявки принимаем на сайте, звоните:  8~[495]~744~1~157


Успехов и процветания.



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

[WiX-users] Наша специализация индивидуаль ные и групповые туры

[Цены ниже]

Уникальная ЧЕХИЯ.
Наша специализация индивидуальные и групповые туры.
Цены ниже чем у тур операторов !!!

Забронируем для Вас отель, обеспечим встречу в аэропорту, организуем поездки в 
любую точку Европы.
 Предлагаем экскурсии по уникальным замкам, пещерам, природным паркам, 
загородным резиденциям и костёлам.
Мы предложим Вам уникальные туристические программы на любой вкус и кошелёк.
Экскурсия в замок "Карштейн" у нас стоит 25 Евро.


Предлагаем к сотрудничеству туристические фирмы.

С Уважением Маргарита.
Тел. +8 10  420 775 219 976, 775 097 465
e-mail: [EMAIL PROTECTED]


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

Re: [WiX-users] what is wix_x64?

[Ian Thomas]

On 64-bit operating systems, Windows Installer installs and manages
applications consisting of 32-bit or 64-bit Windows Installer components
(ref  ). It doesn't
work the other way round of course. 

 

  _  

Ian Thomas - Perth, Australia

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, May 16, 2008 11:50 AM
To: Kelly Leahy
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] what is wix_x64?

 

If you want a 64-bit cmd shell to work then you need the x64 MSI installed.
If you always use a 32-bit cmd shell then it doesn't really matter.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 20:36
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] what is wix_x64?

 


OK... I've been installing the x86 version.  If I'm running on the x64 OS
(Vista x64) should I be using the x64 version? 

Kelly 




Rob Mensching <[EMAIL PROTECTED]> 

05/15/2008 08:32 PM 


To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net"
 


cc

 


Subject

RE: [WiX-users] what is wix_x64?

 


 

 




"running WiX on x64".  It should have everything.   
  
The root issue, IIRC, is the Windows Installer doesn't allow you to have a
dual-platform package. so you need two.   
  
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 10:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] what is wix_x64? 
  

What's the difference between wix3_x64.msi and wix3.msi on the weekly
releases? 

Is the x64 for targeting x64, running WiX on x64, or what? 

Does it not include the x86 versions of CAs? 

Just curious, 
Kelly 

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

Re: [WiX-users] Temporary files in WiX?

[Christopher Painter]

I'm not having any luck finding a link to his message but the logic went 
something like this
   
  During a managed/elevated install  an administrator has blessed ( usually /jm 
) a package and a non-priv user invokes the package with /i.  The UI is not 
elevated but the execute / non-impersonated CA's are elevated. When Type1 
CA's execute they are extracted as a random filename tmp file and immeadiatly 
consumed by the sandbox process.   If  that DLL has a dependency MSI doesn't 
support it.   If someone was to extract that file out for the life of the 
install and then consume that file by the Type 1 CA  you could theoretically 
have a situation where the user could tamper with the extracted file and inject 
untrusted code into the elevated process.
   
  I understand what he's saying... but on a security vs usability perspective ( 
and the realty that most packages are never serviced this way even though the 
platform was designed for it ) I choose to support this scenario.   The WiX 
toolset on the other hand chooses not to.
   
  I hope that makes sense.  BTW, you've helped me in the past with MSBuild/TFS. 
 Thankyou for your help.
   
  Chris
  

Neil Enns <[EMAIL PROTECTED]> wrote:
P {   MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px  }  I'm not sure I understand 
the concern. My setup already lays the files down on disk and consumes them. I 
just want to be able to remove them after setup is complete, so they don't 
stick around taking space on the user's machine.
   
  Neil
   

-
  From: Christopher Painter [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 6:30 PM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Temporary files in WiX?


  
  Another reason why I have to use a different tool.Everyone in the WiX 
world has to roll their own equivilant to InstallShield's  ISSetupFile table ( 
actions ISSetupFilesExtract and ISSetupFilesCleanup ). Again, this seems to 
be driven by philosphy as Rob recently posted a whole explanation saying he's 
corncerned about man in the middle style attacks if a file was extracted and 
then consumed by an elevated setup. His preferred solution seems to be that 
the MSI team support companion files in the CA sandbox but it's very unlikely 
that they will ever write that.

Neil Enns <[EMAIL PROTECTED]> wrote: @font-face {   font-family: Cambria 
Math;  }  @font-face {   font-family: Calibri;  }  @page Section1 {size: 
612.0pt 792.0pt; margin: 72.0pt 72.0pt 72.0pt 72.0pt; }  P.MsoNormal {   
FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Calibri","sans-serif"  }  
LI.MsoNormal {   FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 
"Calibri","sans-serif"  }  DIV.MsoNormal {   FONT-SIZE: 11pt; MARGIN: 0cm 0cm 
0pt; FONT-FAMILY: "Calibri","sans-serif"  }  A:link {   COLOR: blue; 
TEXT-DECORATION: underline; mso-style-priority: 99  }  SPAN.MsoHyperlink {   
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99  }  A:visited { 
  COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99  }  
SPAN.MsoHyperlinkFollowed {   COLOR: purple; TEXT-DECORATION: underline; 
mso-style-priority: 99  }  SPAN.EmailStyle17 {   COLOR: windowtext; 
FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-compose  }  
.MsoChpDefault {  
 mso-style-type: export-only  }  DIV.Section1 {   page: Section1  }Is 
there such a thing as temporary files during a wix install? We’re shipping some 
redist installers as part of our installer, and they only need to be on the end 
user’s machine for the duration of install. What’s the right way in WiX to 
indicate they’re temporary and should be cleaned up after install is finished? 
   
  Thanks!
   
  Neil

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

  



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

Re: [WiX-users] really slow using pyro

[Rob Mensching]

“safe” is one way to look at it.  “correct” is another.  

We can look at adding a switch to make it easy, but you can actually get what 
you want right now.  You could implement an extension that overrides the 
default “BinderFileManager” and implement the CompareFiles() method using the 
method you describe.  You can see the default BinderFileManager does a byte by 
byte comparison.

Also, I noticed that you were using .wixouts to build your patch.  I would 
recommend using the .wixpdb instead.  That will actually have all the necessary 
information to get much faster comparison (when the switch is finally 
implemented).

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 20:33
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: RE: [WiX-users] really slow using pyro


I'm a bit suprised that it is doing this comparison for every file.  Is it just 
to be safe?  Could we add a switch that allowed it to do slightly less safe 
comparisons (i.e. I can guarantee that if two files have the same date, size, 
and name, that their contents are the same (or at least I'm willing to take 
that risk)).

Wouldn't that speed up comparisons considerably?

Kelly


Rob Mensching <[EMAIL PROTECTED]>

05/15/2008 08:19 PM

To

Kelly Leahy <[EMAIL PROTECTED]>

cc

"wix-users@lists.sourceforge.net" , "[EMAIL 
PROTECTED]" <[EMAIL PROTECTED]>

Subject

RE: [WiX-users] really slow using pyro







I talked to Peter.  For a product with ~2,000 - 3,000 files 10 minutes is 
reasonable.  Pyro is diffing all of the files in your product looking for 
different ones and that takes time.

I noticed that you are using Includes all over the place.  Instead, you could 
use Fragments and get improvements in the compile steps and also do filtering 
at the Fragment level during patching.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 12:01
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] really slow using pyro


10 minutes running pyro, 2 minutes running the 'light' command line that builds 
the original msi's.

Were you able to get the makefile, or do you want me to paste the command lines 
into an email for you?

Kelly
Rob Mensching <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

05/15/2008 10:04 AM


To

Kelly Leahy <[EMAIL PROTECTED]>

cc

"wix-users@lists.sourceforge.net" 

Subject

Re: [WiX-users] really slow using pyro











One more question:  can you give me an idea of the time spent building MSI vs. 
building MSP?  Basically, I’m looking for a bit more details about what “long 
time” means.  

I’m not the patching expert but Peter is back from vacation and I’ll make sure 
he gets this thread tonight.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro


Sorry, I was braindead last night and it didn't even occur to me that knowing 
the version and what I'm doing might be useful information :(

0. tried that - didn't seem to tell me much of anything.
1. 3.0.3419 - I'll try a newer build today.
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst
 (entire makefile is attached)
3. all files are local

other info:
running Vista x64 Business on a quad-core machine with 4gb RAM and mirrored 
HDDs using hardware RAID.
not much else going on while building (I've been giving it the full machine).

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The wixproj 
contains the RTM folder's contents.  The Update1 folder mentioned in the 
makefile is nearly identical, with only differences being in content and the 
definitions in the defines.wxi (also attached here).


Any recommendations would be greatly appreciated - and if there's anything I 
can do to help repro / debug, I'd be happy to do so, assuming it's within my 
capabilities or relatively close to them.
Kelly
Rob Mensching <[EMAIL PROTECTED]>

05/14/2008 11:52 PM




To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 


cc

Subject

RE: [WiX-users] really slow using pyro














0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not sure 
there is much wired up to it).

1.  What version of WiX v3 are you using?

2.  What is the command line you’re passing pyro?

3.  Are all of your MSIs and files local (not on a network share)?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro


When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While this 
still isn't that long, it's very frustrating when we're trying to build and 
test our installs!

Am I missing something easy that will make the

Re: [WiX-users] what is wix_x64?

[Rob Mensching]

If you want a 64-bit cmd shell to work then you need the x64 MSI installed.  If 
you always use a 32-bit cmd shell then it doesn’t really matter.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 20:36
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] what is wix_x64?


OK... I've been installing the x86 version.  If I'm running on the x64 OS 
(Vista x64) should I be using the x64 version?

Kelly


Rob Mensching <[EMAIL PROTECTED]>

05/15/2008 08:32 PM

To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 


cc

Subject

RE: [WiX-users] what is wix_x64?







“running WiX on x64”.  It should have everything.

The root issue, IIRC, is the Windows Installer doesn’t allow you to have a 
dual-platform package… so you need two.  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 10:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] what is wix_x64?


What's the difference between wix3_x64.msi and wix3.msi on the weekly releases?

Is the x64 for targeting x64, running WiX on x64, or what?

Does it not include the x86 versions of CAs?

Just curious,
Kelly

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**


**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Temporary files in WiX?

[Neil Enns]

I'm not sure I understand the concern. My setup already lays the files down on 
disk and consumes them. I just want to be able to remove them after setup is 
complete, so they don't stick around taking space on the user's machine.

Neil


From: Christopher Painter [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 6:30 PM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Temporary files in WiX?

Another reason why I have to use a different tool.Everyone in the WiX world 
has to roll their own equivilant to InstallShield's  ISSetupFile table ( 
actions ISSetupFilesExtract and ISSetupFilesCleanup ). Again, this seems to 
be driven by philosphy as Rob recently posted a whole explanation saying he's 
corncerned about man in the middle style attacks if a file was extracted and 
then consumed by an elevated setup. His preferred solution seems to be that 
the MSI team support companion files in the CA sandbox but it's very unlikely 
that they will ever write that.

Neil Enns <[EMAIL PROTECTED]> wrote:
Is there such a thing as temporary files during a wix install? We’re shipping 
some redist installers as part of our installer, and they only need to be on 
the end user’s machine for the duration of install. What’s the right way in WiX 
to indicate they’re temporary and should be cleaned up after install is 
finished?

Thanks!

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

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

Re: [WiX-users] what is wix_x64?

[Kelly Leahy]

OK... I've been installing the x86 version.  If I'm running on the x64 OS 
(Vista x64) should I be using the x64 version?

Kelly




Rob Mensching <[EMAIL PROTECTED]>

05/15/2008 08:32 PM

To
Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 

cc

Subject
RE: [WiX-users] what is wix_x64?






“running WiX on x64”.  It should have everything. 
 
The root issue, IIRC, is the Windows Installer doesn’t allow you to have a 
dual-platform package… so you need two.  
 
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 10:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] what is wix_x64?
 

What's the difference between wix3_x64.msi and wix3.msi on the weekly 
releases? 

Is the x64 for targeting x64, running WiX on x64, or what? 

Does it not include the x86 versions of CAs? 

Just curious, 
Kelly 

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries 
guidelines.
**



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] really slow using pyro

[Kelly Leahy]

I'm a bit suprised that it is doing this comparison for every file.  Is it 
just to be safe?  Could we add a switch that allowed it to do slightly 
less safe comparisons (i.e. I can guarantee that if two files have the 
same date, size, and name, that their contents are the same (or at least 
I'm willing to take that risk)).

Wouldn't that speed up comparisons considerably?

Kelly




Rob Mensching <[EMAIL PROTECTED]>

05/15/2008 08:19 PM

To
Kelly Leahy <[EMAIL PROTECTED]>
cc
"wix-users@lists.sourceforge.net" , 
"[EMAIL PROTECTED]" 
<[EMAIL PROTECTED]>
Subject
RE: [WiX-users] really slow using pyro






I talked to Peter.  For a product with ~2,000 - 3,000 files 10 minutes is 
reasonable.  Pyro is diffing all of the files in your product looking for 
different ones and that takes time.  
 
I noticed that you are using Includes all over the place.  Instead, you 
could use Fragments and get improvements in the compile steps and also do 
filtering at the Fragment level during patching.
 
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 12:01
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; 
[EMAIL PROTECTED]
Subject: Re: [WiX-users] really slow using pyro
 

10 minutes running pyro, 2 minutes running the 'light' command line that 
builds the original msi's. 

Were you able to get the makefile, or do you want me to paste the command 
lines into an email for you? 

Kelly 



Rob Mensching <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED] 
05/15/2008 10:04 AM 


To
Kelly Leahy <[EMAIL PROTECTED]> 
cc
"wix-users@lists.sourceforge.net"  
Subject
Re: [WiX-users] really slow using pyro
 








One more question:  can you give me an idea of the time spent building MSI 
vs. building MSP?  Basically, I’m looking for a bit more details about 
what “long time” means.   
  
I’m not the patching expert but Peter is back from vacation and I’ll make 
sure he gets this thread tonight. 
  
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro 
  

Sorry, I was braindead last night and it didn't even occur to me that 
knowing the version and what I'm doing might be useful information :( 

0. tried that - didn't seem to tell me much of anything. 
1. 3.0.3419 - I'll try a newer build today. 
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst 
  (entire makefile is attached) 
3. all files are local 

other info: 
running Vista x64 Business on a quad-core machine with 4gb RAM and 
mirrored HDDs using hardware RAID. 
not much else going on while building (I've been giving it the full 
machine). 

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The 
wixproj contains the RTM folder's contents.  The Update1 folder mentioned 
in the makefile is nearly identical, with only differences being in 
content and the definitions in the defines.wxi (also attached here). 


Any recommendations would be greatly appreciated - and if there's anything 
I can do to help repro / debug, I'd be happy to do so, assuming it's 
within my capabilities or relatively close to them. 
Kelly 

Rob Mensching <[EMAIL PROTECTED]> 
05/14/2008 11:52 PM 
 


To
Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 
 
cc

Subject
RE: [WiX-users] really slow using pyro

 
 









0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not 
sure there is much wired up to it). 
 
1.  What version of WiX v3 are you using? 
 
2.  What is the command line you’re passing pyro? 
 
3.  Are all of your MSIs and files local (not on a network share)? 
 
 
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro 
 

When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While 
this still isn't that long, it's very frustrating when we're trying to 
build and test our installs! 

Am I missing something easy that will make the builds of our patches run 
much faster?  What's actually going on during the 'pyro' processing?  Is 
it the file compares that could be taking that much time?  BTW, the patch 
in question ends up only being about 14K in size, and there's only 1 file 
out of about 960 that is different, and that file is very small (several 
K).  The two installs that are being compared are around 80MB in size when 
built into the MSIs, and are about 150MB uncompressed, I think. 

Is there any way to tell the pyro tool to tell me what steps are taking 
the most time so that I can try to understand if there's some 
optimizations we can do to improve it? 

Kelly 

**
This communication is intended solely for the add

Re: [WiX-users] what is wix_x64?

[Rob Mensching]

"running WiX on x64".  It should have everything.

The root issue, IIRC, is the Windows Installer doesn't allow you to have a 
dual-platform package... so you need two.  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Thursday, May 15, 2008 10:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] what is wix_x64?


What's the difference between wix3_x64.msi and wix3.msi on the weekly releases?

Is the x64 for targeting x64, running WiX on x64, or what?

Does it not include the x86 versions of CAs?

Just curious,
Kelly

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] really slow using pyro

[Rob Mensching]

I talked to Peter.  For a product with ~2,000 - 3,000 files 10 minutes is 
reasonable.  Pyro is diffing all of the files in your product looking for 
different ones and that takes time.

I noticed that you are using Includes all over the place.  Instead, you could 
use Fragments and get improvements in the compile steps and also do filtering 
at the Fragment level during patching.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 12:01
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] really slow using pyro


10 minutes running pyro, 2 minutes running the 'light' command line that builds 
the original msi's.

Were you able to get the makefile, or do you want me to paste the command lines 
into an email for you?

Kelly


Rob Mensching <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

05/15/2008 10:04 AM

To

Kelly Leahy <[EMAIL PROTECTED]>

cc

"wix-users@lists.sourceforge.net" 

Subject

Re: [WiX-users] really slow using pyro







One more question:  can you give me an idea of the time spent building MSI vs. 
building MSP?  Basically, I’m looking for a bit more details about what “long 
time” means.  

I’m not the patching expert but Peter is back from vacation and I’ll make sure 
he gets this thread tonight.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro


Sorry, I was braindead last night and it didn't even occur to me that knowing 
the version and what I'm doing might be useful information :(

0. tried that - didn't seem to tell me much of anything.
1. 3.0.3419 - I'll try a newer build today.
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst
  (entire makefile is attached)
3. all files are local

other info:
running Vista x64 Business on a quad-core machine with 4gb RAM and mirrored 
HDDs using hardware RAID.
not much else going on while building (I've been giving it the full machine).

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The wixproj 
contains the RTM folder's contents.  The Update1 folder mentioned in the 
makefile is nearly identical, with only differences being in content and the 
definitions in the defines.wxi (also attached here).


Any recommendations would be greatly appreciated - and if there's anything I 
can do to help repro / debug, I'd be happy to do so, assuming it's within my 
capabilities or relatively close to them.
Kelly
Rob Mensching <[EMAIL PROTECTED]>

05/14/2008 11:52 PM


To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 


cc

Subject

RE: [WiX-users] really slow using pyro











0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not sure 
there is much wired up to it).

1.  What version of WiX v3 are you using?

2.  What is the command line you’re passing pyro?

3.  Are all of your MSIs and files local (not on a network share)?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro


When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While this 
still isn't that long, it's very frustrating when we're trying to build and 
test our installs!

Am I missing something easy that will make the builds of our patches run much 
faster?  What's actually going on during the 'pyro' processing?  Is it the file 
compares that could be taking that much time?  BTW, the patch in question ends 
up only being about 14K in size, and there's only 1 file out of about 960 that 
is different, and that file is very small (several K).  The two installs that 
are being compared are around 80MB in size when built into the MSIs, and are 
about 150MB uncompressed, I think.

Is there any way to tell the pyro tool to tell me what steps are taking the 
most time so that I can try to understand if there's some optimizations we can 
do to improve it?

Kelly

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**

Re: [WiX-users] Building localized versions of an installer

[Rob Mensching]

Yeah, this is easy but the error message didn't help you (I've given it to 
Peter and he'll try to fix it tonight).  "light" is for creating "MSI/MSM" 
files.  "torch" is for creating "MST" files.  "pyro" is for creating "MSP" 
files.  Armed with that knowledge, hopefully it is clear that your final 
command-line should be "torch en-us.wixmst".  

In the future, the error messages should point you in the right direction.

From: Fairweather, James [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 15:08
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: Building localized versions of an installer

Thank-you , Rob and Josh.  That looks like it should work, but it fails with a 
not-very-helpful error message:

I have produced a ".wixmst" file from torch like so:

Ø  torch.exe -t language -v -p -xi -xo C:\eao neutral.wixout en-us.wixout -out 
en-us.wixmst

Now call light on the wixmst file to create the transform:


Ø  light.exe en-us.wixmst
Microsoft (R) Windows Installer Xml Linker version 3.0.3907.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.

C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w\File.idt : error 
LGHT0136 : There was an error importing table 'File' from this file.
Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local 
Settings\Temp\ail5es2w'.
Validator temporary directory located at 'C:\Documents and 
Settings\jamesf\Local Settings\Temp\ihybiq-8'.

I will debug this further, but before I do, is there something obvious that I'm 
doing wrong?


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 2:01 PM
To: Fairweather, James; wix-users@lists.sourceforge.net
Subject: RE: Building localized versions of an installer

You're right on track.  Last step is to take the .wixout (should have been 
named ".wixmsi" to match the other things but .wixout came first) and feed it 
back into light.exe.  Light will finish processing the .wixout into MSI.  Is 
that detailed enough or am I missing a step?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fairweather, 
James
Sent: Thursday, May 15, 2008 13:12
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building localized versions of an installer

Many of our companies' products are localized into several languages.  To build 
the an installer to handle this, we first build a "neutral" MSI, then for each 
culture, we build an MSI, then use msitran to build a transform, and finally 
msidb to merge the transform back to the neutral MSI.  This works, but it's 
really slow because of all the file copying and cabinet building.  The fileset 
is the same for all cultures, so it would be really handy if there were a way 
to tell light to not build the cabinet file (after the first one).  There is a 
-reusecab option, but it's still pretty slow (I think due to a lot of file 
copying), and it sometimes crashes on large filesets.

The approach we are exploring is to use the XML format (-xo option to light), 
then use the torch tool to build the transform from that.  While this is great 
from a speed point of view, I don't see a way of getting from the XML format 
back to MSI/MST.  Am I missing something, or has that simply not been 
implemented to date?

James Fairweather
Lead developer and support engineer
Core Team
604.456.3911 (x13911)
[cid:image001.jpg@01C8B6C7.A3EAA470]
<>-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[jmcfadyen]

my apologies the link is here.

http://johnmcfadyen.spaces.live.com/



Wheeler, Blaine (DSHS/DCS) wrote:
> 
> I'd like to read your notes but unfortunately this link doesn't work for
> me. http://john.mcfadyen.spaces.live.com
> 
> I concur with your views on Windows Installer and count myself very
> lucky to build installs in a closed environment where we control the OS,
> the installer on has to know 1 language and we don't build or show
> dialogs because we don't give users choices during install.
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of jmcfadyen
> Sent: Wednesday, May 14, 2008 11:51 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] yep - back to being 100% frustrated
> 
> 
> It seems to me reading this from a link via Christopher Painter that you
> guys
> are all missing a few vital points. 
> 
> It looks to me like most of you looking at this as Dev's which is where
> you
> are going wrong. I agree these items should be trivial to fix but there
> is a
> vast number of regions outside of the development sphere which are the
> reason it is not. I feel some of you need to take your blinkers off and
> see
> what is really the big picture here. 
> 
> Windows Installer is complex it is difficult to get decent information
> on
> but there are very valid reasons why its so difficult and most of them
> extend outside the realm of the developer developing a piece of software
> for
> his single little machine. 
> 
> Windows Installer caters for a massive array of issues problems
> operating
> systems, and integrates the entire setup not only for your little
> application but is designed to integrate hundred/thousands of
> applications
> developed by hundreds/thousands of developers onto multiple platforms.
> There
> is a much bigger picture at work here. 
> 
> I think the guys at MS have done a great job. I could say vbscript is a
> great programming language and that C# or F# is crap when the reality is
> my
> understanding of them may not be as good as some of you guys here. Most
> of
> you would look at me like I was mental or something but the reality is
> many
> of you are looking at this with the same mentality. 
> 
> I have been using windows installer since its inception and these days I
> find little that it cant do with a tiny bit of brute force. Don't blame
> the
> tools as there are plenty of people out there using these tools and
> making
> them work seemlessly and quickly on a day to day basis. 
> 
> Each day I integrate around 1,000,000 lines of code into multiple msi's
> within minutes using WiX. (I couldnt care less what its written in, if
> you
> know how to use it as it was designed it works like a charm). 
> 
> If anyone would like some assistance understanding the finer intricacies
> of
> windows installer I have some heavy detail on most of the undocumented
> features here. 
> 
> http://john.mcfadyen.spaces.live.com 
> 
> No offence intended to anyone on these boards, this post is not aimed at
> being nasty and I hope my blog can aid with some of your troubles. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Scott Palmer-3 wrote:
>> 
>> On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[EMAIL PROTECTED]>
>> wrote:
>> 
>>>  
>>>
>>> The moral of the story is that deployment procedures really are part
> of
>>> the source code for an application.  They are also risky, so
> implement
>>> them
>>> first to minimize risk.
>>>
>> 
>> This is the problem.  Deployment SHOULD be trivial.  That it is a
> "risky"
>> part is outrageous.  Shouldn't the hard part be in your application's
>> algorithms rather than how to install it?  (Your statement also
> ignores
>> the
>> fact that there is risk in other parts of the development - should
> those
>> parts also be done first to minimize risk? :-) )
>> 
>> Saying it's risky is fine to justify the point that installers should
> be
>> dealt with sooner in the development process - Given the current state
> of
>> installer technology I must sadly agree.  But it belittles the fact
> that
>> the
>> installer technology sucks so bad and is the root problem that needs
>> fixing.  Am I the only one that thinks it is somewhat pathetic to not
>> consider a certain technology for the development of my application
>> because
>> I wont' be able to write the installer?  Doesn't that just say that A:
> the
>> technology to be installed (e.g. COM+), and B: the installer
> technology
>> itself (e.g. MSI) both suck?
>> 
>> On a Mac you would just drag and drop the application icon. The very
>> existence of an installer is frowned upon for most things.  Why
> doesn't
>> Microsoft rip-off that instead of the desktop eye-candy? :-)
>> 
>> Isn't the goal of WiX to make creating MSI easier without giving up
> any of
>> it's raw abilities?  Should we really have to worry at the WiX level
> about
>> naming icon Ids with extensions that match what shortcuts that use
> them
>> point to?  That is just plain dumb and WiX sh

Re: [WiX-users] Temporary files in WiX?

[Christopher Painter]

Another reason why I have to use a different tool.Everyone in the WiX world 
has to roll their own equivilant to InstallShield's  ISSetupFile table ( 
actions ISSetupFilesExtract and ISSetupFilesCleanup ). Again, this seems to 
be driven by philosphy as Rob recently posted a whole explanation saying he's 
corncerned about man in the middle style attacks if a file was extracted and 
then consumed by an elevated setup. His preferred solution seems to be that 
the MSI team support companion files in the CA sandbox but it's very unlikely 
that they will ever write that.

Neil Enns <[EMAIL PROTECTED]> wrote:Is there such a thing as 
temporary files during a wix install? We’re shipping some redist installers as 
part of our installer, and they only need to be on the end user’s machine for 
the duration of install. What’s the right way in WiX to indicate they’re 
temporary and should be cleaned up after install is finished?
   
  Thanks!
   
  Neil

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


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

Re: [WiX-users] Installing .NET 3.5 redist?

[Christopher Painter]

The WiX `philosophy` seems to be  don't add .NET dependencies to your install 
and don't redist the framework.Just do an AppSearch/Launch Condition and 
tell the user to go do it on their own. Personally this conflicts with my 
needs and results in one of the many reasons why I can't use WiX even though 
I'd like to.

Neil Enns <[EMAIL PROTECTED]> wrote:  That's what I was afraid the answer would 
be :( Thanks.

Neil


  
-
  From: Kelly Leahy <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 4:50 PM
To: Neil Enns <[EMAIL PROTECTED]>
Cc: wix-users@lists.sourceforge.net ; [EMAIL 
PROTECTED] <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] Installing .NET 3.5 redist?

  
You need a bootstrapper for this.  You won't be able to nest the installers in 
any way that works. 


Neil Enns <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED]   05/15/2008 04:45 PM 
To
  "wix-users@lists.sourceforge.net"cc
Subject
  [WiX-users] Installing .NET 3.5 redist?
  



Has anyone had any experience with installing the .NET 3.5 redistributable as 
part of a WiX installer? We are a Vista-only application, and know we’ll need 
to install .NET 3.5 to run. There’s a standalone exe (netfx35_x86.exe) that 
installs the redist, but we’re not sure how to integrate that into our 
installer. Calling it from our installer with a /q flag results in an error 
because there’s already another install (ours) running. 
  
Thanks for any tips or pointers! 
  
Neil-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
 
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] How to let other user can find my program in ARP on Vista?

[Wilson, Phil]

You might not have done the installation with the ALLUSERS setting that does a 
per-machine install, so you did a per-user install that only you (the 
installing account) can see.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akibo
Sent: Thursday, May 15, 2008 5:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to let other user can find my program in ARP on Vista?


Hello,

I install my program with account A, and can see my product name in
"uninstall program" on Vista. But account B cannot see this product name in
his control panel/uninstall program. Both account are in administrators
group.

I check HKLM\\Uninstall. I saw my product key are in HKLM\\Uninstall\\[GID]
but not exist in HKLM\\Uninstall. I saw most other application have a
registry - HKLM\\Uninstall\\[APP] and put product name in this folder.

Is that root cause? Whether yes or no, how to resolve it with wix?

Will be appreciate for your kindly help.


--
View this message in context: 
http://www.nabble.com/How-to-let-other-user-can-find-my-program-in-ARP-on-Vista--tp17252574p17252574.html
Sent from the wix-users mailing list archive at Nabble.com.


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



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

Re: [WiX-users] RFC: File vitality

[Bob Arnson]

The feedback was quick 
 and consistent 
: 
Marking files vital by default is a good thing. So in the next weekly 
release of WiX, files will get the msidbFileAttributesVital attribute 
 by 
default. The FilesVitalByDefault property and -fdvital switch have been 
removed; in their place, SuppressFilesVitalByDefault and -sfdvital turn 
off the default "vital" behavior.


Bob Arnson wrote:
I just posted a request for comments on my blog, to ask about a change 
we're considering to simplify WiX authoring. You can see the post here:


http://www.joyofsetup.com/2008/05/03/rfc-vitality/

The short version is that we're considering marking all files with the 
msidbFileAttributesVital bit set by default. That's a behavior change 
and we wanted to get feedback before deciding either way. Please read 
the whole post and let us know what you think, either via blog post 
comments or mail on this list.
  

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

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

[WiX-users] sqlscript create assembly

[Roberto Almanza]

Can you point me to documentation or an example that shows how to add a
SqlClr stored procedure to a wix install?

I have assemblies and stored procedures that I am able to build and deploy
outside of wix, however, when I try to create the assemblies in the same
order in my wix install it fails.

Specifically the install fails with the following error:
Error -2147217900: Failed to execute SQL string, error detail: Assembly
'xxx, version=1.0.0.0, culture=neutral, publictoken=xxx.' was not found in
the SQL catalog., SQL Key: ...

I am trying to create my assembly by specifying the binary:
CREATE ASSEMBLY [xxx] AUTHORIZATION [dbo] FROM 0x...


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

Re: [WiX-users] Installing .NET 3.5 redist?

[Neil Enns]

That's what I was afraid the answer would be :( Thanks.

Neil



From: Kelly Leahy <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 4:50 PM
To: Neil Enns <[EMAIL PROTECTED]>
Cc: wix-users@lists.sourceforge.net ; [EMAIL 
PROTECTED] <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] Installing .NET 3.5 redist?


You need a bootstrapper for this.  You won't be able to nest the installers in 
any way that works.


Neil Enns <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

05/15/2008 04:45 PM


To
"wix-users@lists.sourceforge.net" 
cc

Subject
[WiX-users] Installing .NET 3.5 redist?







Has anyone had any experience with installing the .NET 3.5 redistributable as 
part of a WiX installer? We are a Vista-only application, and know we’ll need 
to install .NET 3.5 to run. There’s a standalone exe (netfx35_x86.exe) that 
installs the redist, but we’re not sure how to integrate that into our 
installer. Calling it from our installer with a /q flag results in an error 
because there’s already another install (ours) running.

Thanks for any tips or pointers!

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



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing .NET 3.5 redist?

[Kelly Leahy]

You need a bootstrapper for this.  You won't be able to nest the 
installers in any way that works.



Neil Enns <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
05/15/2008 04:45 PM

To
"wix-users@lists.sourceforge.net" 
cc

Subject
[WiX-users] Installing .NET 3.5 redist?






Has anyone had any experience with installing the .NET 3.5 redistributable 
as part of a WiX installer? We are a Vista-only application, and know 
we’ll need to install .NET 3.5 to run. There’s a standalone exe 
(netfx35_x86.exe) that installs the redist, but we’re not sure how to 
integrate that into our installer. Calling it from our installer with a /q 
flag results in an error because there’s already another install (ours) 
running.
 
Thanks for any tips or pointers!
 
Neil
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Installing .NET 3.5 redist?

[Neil Enns]

Has anyone had any experience with installing the .NET 3.5 redistributable as 
part of a WiX installer? We are a Vista-only application, and know we'll need 
to install .NET 3.5 to run. There's a standalone exe (netfx35_x86.exe) that 
installs the redist, but we're not sure how to integrate that into our 
installer. Calling it from our installer with a /q flag results in an error 
because there's already another install (ours) running.

Thanks for any tips or pointers!

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

Re: [WiX-users] is there an attribute setting or ??? way get a iis:WebSite entry to create if not exist, don't touch if it does already exist, and don't remove on uninstall?

[Rob Mensching]

WebSite/@ConfigureIfExists
Component/@Permanent

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, May 15, 2008 15:26
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] is there an attribute setting or ??? way get a iis:WebSite 
entry to create if not exist, don't touch if it does already exist, and don't 
remove on uninstall?

is there an attribute setting or ??? way get a iis:WebSite entry to create if 
not exist, don't touch if it does already exist, and don't remove on uninstall?
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wixunit?

[Richard]

In article <[EMAIL PROTECTED]>,
Rob Mensching <[EMAIL PROTECTED]>  writes:

> To answer your actual question, we don't really have any tools to do testin=
> g on MSIs today in the WiX toolset.  There is the "static analysis stuff" (=
> ICEs, via light.exe or smoke.exe) but nothing that verifies installs work. =
>  Bob had some interesting opinions on it that I thought he wrote on his blo=
> g (http://www.joyofsetup.com)... I'm not seeing it now.

ICEs are a good place to start unit testing your built MSI.  Most
people never even seem to get that far.  I wrote a bunch (~70+) of
ICEs when I worked on a complex install.

For testing whether or not the install itself worked, we hacked
together a VMware machine, vbscript running on the VMware host and
vbscript running on the virtual machine to tie everything together.
We actually had a continuous integration feedback loop that went like
this:

- monitor CVS for changes to install source files
- after a period of quiescence on CVS, build the install
- start/reset the VMware guest machine image
- launch the built install in the VMWare image
- monitor the VMware image for failures
- report back via email to the developers any failures

We wanted to evolve this to doing automated upgrade testing as well,
but didn't get that far.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

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

[WiX-users] Temporary files in WiX?

[Neil Enns]

Is there such a thing as temporary files during a wix install? We're shipping 
some redist installers as part of our installer, and they only need to be on 
the end user's machine for the duration of install. What's the right way in WiX 
to indicate they're temporary and should be cleaned up after install is 
finished?

Thanks!

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

[WiX-users] is there an attribute setting or ??? way get a iis:WebSite entry to create if not exist, don't touch if it does already exist, and don't remove on uninstall?

[Robert O'Brien]

is there an attribute setting or ??? way get a iis:WebSite entry to create if 
not exist, don't touch if it does already exist, and don't remove on uninstall?
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to associate certificate with IIS website without adding certificate to store?

[Robert O'Brien]

Or put another way is the following ENVIRONMENTID public property reference in 
the CertificateRef Id value an option when it comes to defining certs 
associated with a given web site so that I can have the msi use a different 
cert for the web site depending on the service deliverable environment I'm 
deploying the cert to?






From: Robert O'Brien
Sent: Thursday, May 15, 2008 9:57 AM
To: Rob Mensching; 'wix-users@lists.sourceforge.net'
Subject: RE: [WiX-users] How to associate certificate with IIS website without 
adding certificate to store?

I have a service deliverable msi where I need to be able to pass in a public 
property value that defines the name of an existing cert that the msi will 
associate with a new 443 site it creates.

q1 - If I include the ssl certs for each of my service deliverable environments 
where the msi will be run to deploy service bits (e.g. dev, deployment 
verification test, test, perf, beta, pre-production, user acceptance testing, 
production hot standby, production)  then do I have a way of using a public 
property value to define which cert gets used in each case?

q2 - if there currently isn't a way to reference a cert already installed on 
the host (which is the case in beta, pre-production, user acceptance testing, 
production hot standby, production environments where we don't create & manage 
the systems) can I include some type of dummy cert for those cases and flag the 
iis:Certificate entry such that it won't try and install it if it already sees 
a certificate of that name in the local machine store?

From: Rob Mensching
Sent: Wednesday, May 14, 2008 11:38 PM
To: Robert O'Brien; 'wix-users@lists.sourceforge.net'
Subject: RE: [WiX-users] How to associate certificate with IIS website without 
adding certificate to store?

Unfortunately, I don't think the current Certificate code is going to support 
that.  The code could be updated to handle the scenario though.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Wednesday, May 14, 2008 18:51
To: 'wix-users@lists.sourceforge.net'
Subject: Re: [WiX-users] How to associate certificate with IIS website without 
adding certificate to store?

Did this work and if so does there exist a sample of what it means to create a 
permanent component Certificate entry that refers to an ssl certificate already 
known to be present on hosts you are deploying to?  In other words I just want 
my iis site settings to bind to port 443 and use an known in advance ssl 
certificate already present on the target systems.

From: Rob Mensching <[EMAIL PROTECTED]> - 2007-12-21 11:15
Try putting the Certificate element in a permanent Component.

Lin wrote:
> Hi,
>
> I am new to Wix so I hope this is the correct mailing list for such
> questions.
>
> I am using Wix3. I would like to associate a certificate with a IIS
> website. The certificate already exists in machine store, so I don't
> need to add it during installation. I have tried the
> / combination, but
>  not only overwrites the certificate (which is still
> acceptable) but removes it during uninstall (this is not acceptable).
>
> So how do I just set up the IIS website certificate without touching
> the certificate store?
>
> Thanks,
> Dakun

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

Re: [WiX-users] Building localized versions of an installer

[Fairweather, James]

Thank-you , Rob and Josh.  That looks like it should work, but it fails with a 
not-very-helpful error message:

 

I have produced a ".wixmst" file from torch like so:

Ø  torch.exe -t language -v -p -xi -xo C:\eao neutral.wixout en-us.wixout -out 
en-us.wixmst

 

Now call light on the wixmst file to create the transform:

 

Ø  light.exe en-us.wixmst

Microsoft (R) Windows Installer Xml Linker version 3.0.3907.0

Copyright (C) Microsoft Corporation 2003. All rights reserved.

 

C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w\File.idt : error 
LGHT0136 : There was an error importing table 'File' from this file.

Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local 
Settings\Temp\ail5es2w'.

Validator temporary directory located at 'C:\Documents and 
Settings\jamesf\Local Settings\Temp\ihybiq-8'.

 

I will debug this further, but before I do, is there something obvious that I'm 
doing wrong?

 

 

From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 2:01 PM
To: Fairweather, James; wix-users@lists.sourceforge.net
Subject: RE: Building localized versions of an installer

 

You're right on track.  Last step is to take the .wixout (should have been 
named ".wixmsi" to match the other things but .wixout came first) and feed it 
back into light.exe.  Light will finish processing the .wixout into MSI.  Is 
that detailed enough or am I missing a step?

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fairweather, 
James
Sent: Thursday, May 15, 2008 13:12
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building localized versions of an installer

 

Many of our companies' products are localized into several languages.  To build 
the an installer to handle this, we first build a "neutral" MSI, then for each 
culture, we build an MSI, then use msitran to build a transform, and finally 
msidb to merge the transform back to the neutral MSI.  This works, but it's 
really slow because of all the file copying and cabinet building.  The fileset 
is the same for all cultures, so it would be really handy if there were a way 
to tell light to not build the cabinet file (after the first one).  There is a 
-reusecab option, but it's still pretty slow (I think due to a lot of file 
copying), and it sometimes crashes on large filesets.

 

The approach we are exploring is to use the XML format (-xo option to light), 
then use the torch tool to build the transform from that.  While this is great 
from a speed point of view, I don't see a way of getting from the XML format 
back to MSI/MST.  Am I missing something, or has that simply not been 
implemented to date?

 

James Fairweather

Lead developer and support engineer

Core Team

604.456.3911 (x13911)

   

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

Re: [WiX-users] New bee question. 'SQLDatabase' and 'User' tags a re not being resolved.

[Mike Rerick]

You need to add support for the Util and SQL extension namespaces.

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








See the Util and Sql schemas for more information.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Reza Farzin
Sent: Thursday, May 15, 2008 12:18 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] New bee question. 'SQLDatabase' and 'User' tags are not
being resolved.

Hello everyboyd,

 

Could anybody please tell me why I am getting this error. I am trying to
compile the SQL sample from http://www.tramontana.co.hu/wix/lesson7.php .

 

The User and SqlDataBase are documented in chm file. I don't know what I am
doing wrong. Is there anything that I need to add to be able to use these
tags.

 

I am using candle version 3.0.4109.0.

 

 

Here is the error

 

SampleSQL.wxs

C:\dev\WixTest\SQLSample\SampleSQL.wxs(14) : error CNDL0005 : The Product
element contains an unexpected child element 'User'.

C:\dev\WixTest\SQLSample\SampleSQL.wxs(22) : error CNDL0005 : The Component
element contains an unexpected child element 'SqlDatabase'.

 

 





   

 



 





 



 



  



 

  

 



  



  

 



  



 



 



  



 

username

password

server

 

  



 

Thanks 

 

-Reza



The information contained in this transmission contains potentially
privileged, export controlled and/or confidential information of Imageware
Systems, Inc. or its customers or partners.  It is intended only to be read
by the person(s) named above and for no other purpose.  You are hereby
notified that any dissemination, distribution, duplication of this
communication or use of its contents for any purpose not authorized
expressly by Imageware Systems, Inc. is strictly prohibited and could lead
to both civil and/or criminal penalties.  If you are not the intended
recipient, you are prohibited to review the contents herein and please
contact the sender by reply e-mail and destroy all copies of the original
message.  To reply to our e-mail administrator directly, please send an
e-mail to [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wixunit?

[Rob Mensching]

It's a unit test framework for the WiX toolset itself.  It isn't very 
interesting unless you are changing core WiX toolset code and want to make sure 
you haven't regressed.  I also haven't pushed out all of the test data that I 
have internally because I haven't done the necessary scrub to make sure there 
isn't any proprietary Microsoft code in the test data.  I know there is some 
because some early teams at Microsoft contributed their setup code to the test 
harness to bootstrap our testing efforts.

However, I should note that Jordan has been building a fantastic new test 
system for verifying the WiX toolset itself so WiXUnit will be retired in the 
not too distant future.  Jordan says he'll have information in the WiX.chm 
about how to add more tests in the next couple weeks.  I'm just now starting to 
write tests using it (used it last week to run down a bug about the SymbolPath 
element) after Jordan gave me a sneak peek.  It's quite cool...

To answer your actual question, we don't really have any tools to do testing on 
MSIs today in the WiX toolset.  There is the "static analysis stuff" (ICEs, via 
light.exe or smoke.exe) but nothing that verifies installs work.  Bob had some 
interesting opinions on it that I thought he wrote on his blog 
(http://www.joyofsetup.com)... I'm not seeing it now.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Holder 
(Cactus Commerce Inc)
Sent: Thursday, May 15, 2008 13:59
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] wixunit?

Another question that's come up today concerns testing practices around WiX and 
I noticed in the toolset interaction diagram (still shipping in the v3.0 help 
file) a reference to a tool called "wixunit".  There's anecdotal mention of 
this thing in a couple of Google searches, but nothing concrete.  Does it 
exist?  Is it under development?  No specific mention on SourceForge (other 
than the .chm contained with the install); nothing on wixwiki.com

Insight appreciated on this or other pertinent tools for "test" purposes 
generally.
RH

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

Re: [WiX-users] Building localized versions of an installer

[Rob Mensching]

You're right on track.  Last step is to take the .wixout (should have been 
named ".wixmsi" to match the other things but .wixout came first) and feed it 
back into light.exe.  Light will finish processing the .wixout into MSI.  Is 
that detailed enough or am I missing a step?

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fairweather, 
James
Sent: Thursday, May 15, 2008 13:12
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building localized versions of an installer

Many of our companies' products are localized into several languages.  To build 
the an installer to handle this, we first build a "neutral" MSI, then for each 
culture, we build an MSI, then use msitran to build a transform, and finally 
msidb to merge the transform back to the neutral MSI.  This works, but it's 
really slow because of all the file copying and cabinet building.  The fileset 
is the same for all cultures, so it would be really handy if there were a way 
to tell light to not build the cabinet file (after the first one).  There is a 
-reusecab option, but it's still pretty slow (I think due to a lot of file 
copying), and it sometimes crashes on large filesets.

The approach we are exploring is to use the XML format (-xo option to light), 
then use the torch tool to build the transform from that.  While this is great 
from a speed point of view, I don't see a way of getting from the XML format 
back to MSI/MST.  Am I missing something, or has that simply not been 
implemented to date?

James Fairweather
Lead developer and support engineer
Core Team
604.456.3911 (x13911)
[cid:image001.jpg@01C8B694.0C63C7E0]
<>-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] wixunit?

[Ross Holder (Cactus Commerce Inc)]

Another question that's come up today concerns testing practices around WiX and 
I noticed in the toolset interaction diagram (still shipping in the v3.0 help 
file) a reference to a tool called "wixunit".  There's anecdotal mention of 
this thing in a couple of Google searches, but nothing concrete.  Does it 
exist?  Is it under development?  No specific mention on SourceForge (other 
than the .chm contained with the install); nothing on wixwiki.com

Insight appreciated on this or other pertinent tools for "test" purposes 
generally.
RH

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

[WiX-users] Building localized versions of an installer

[Fairweather, James]

Many of our companies' products are localized into several languages.
To build the an installer to handle this, we first build a "neutral"
MSI, then for each culture, we build an MSI, then use msitran to build a
transform, and finally msidb to merge the transform back to the neutral
MSI.  This works, but it's really slow because of all the file copying
and cabinet building.  The fileset is the same for all cultures, so it
would be really handy if there were a way to tell light to not build the
cabinet file (after the first one).  There is a -reusecab option, but
it's still pretty slow (I think due to a lot of file copying), and it
sometimes crashes on large filesets.

 

The approach we are exploring is to use the XML format (-xo option to
light), then use the torch tool to build the transform from that.  While
this is great from a speed point of view, I don't see a way of getting
from the XML format back to MSI/MST.  Am I missing something, or has
that simply not been implemented to date?

 

James Fairweather

Lead developer and support engineer

Core Team

604.456.3911 (x13911)

   

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

[WiX-users] New bee question. 'SQLDatabase' and 'User' tags are not being resolved.

[Reza Farzin]

Hello everyboyd,

 

Could anybody please tell me why I am getting this error. I am trying to
compile the SQL sample from http://www.tramontana.co.hu/wix/lesson7.php
.

 

The User and SqlDataBase are documented in chm file. I don't know what I
am doing wrong. Is there anything that I need to add to be able to use
these tags.

 

I am using candle version 3.0.4109.0.

 

 

Here is the error

 

SampleSQL.wxs

C:\dev\WixTest\SQLSample\SampleSQL.wxs(14) : error CNDL0005 : The
Product element contains an unexpected child element 'User'.

C:\dev\WixTest\SQLSample\SampleSQL.wxs(22) : error CNDL0005 : The
Component element contains an unexpected child element 'SqlDatabase'.

 

 





   

 



 





 



 



  



 

  

 



  



  

 



  



 



 



  



 

username

password

server

 

  



 

Thanks 

 

-Reza

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

Re: [WiX-users] Latest Source

[Rob Mensching]

Sorry.  I'm bad about the CVS updates when I get in crunch mode.  There are 
source drops (.zip) with every build that are part of the automated system and 
thus are up to date (and I get lazy because I know that).  Honestly, near zero 
people have ever asked about the CVS tree so it stays low on my priority 
list... I'll get it updated tonight and up it in my priority list if more 
people are actually going to look at it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garth
Sent: Thursday, May 15, 2008 09:01
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Latest Source

Hi,

I've checked out the latest source of WIX 3.0 from CVS and patched what
I belived to be a problem in the Source.

I loged a bug an was then told this has been fixed.

Is CVS still used?

Where would I checkout the latest source for WIX 3.0?

Cheers

Garth

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

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

Re: [WiX-users] really slow using pyro

[Kelly Leahy]

10 minutes running pyro, 2 minutes running the 'light' command line that 
builds the original msi's.

Were you able to get the makefile, or do you want me to paste the command 
lines into an email for you?

Kelly




Rob Mensching <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
05/15/2008 10:04 AM

To
Kelly Leahy <[EMAIL PROTECTED]>
cc
"wix-users@lists.sourceforge.net" 
Subject
Re: [WiX-users] really slow using pyro






One more question:  can you give me an idea of the time spent building MSI 
vs. building MSP?  Basically, I’m looking for a bit more details about 
what “long time” means.  
 
I’m not the patching expert but Peter is back from vacation and I’ll make 
sure he gets this thread tonight.
 
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro
 

Sorry, I was braindead last night and it didn't even occur to me that 
knowing the version and what I'm doing might be useful information :( 

0. tried that - didn't seem to tell me much of anything. 
1. 3.0.3419 - I'll try a newer build today. 
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst 
   (entire makefile is attached) 
3. all files are local 

other info: 
running Vista x64 Business on a quad-core machine with 4gb RAM and 
mirrored HDDs using hardware RAID. 
not much else going on while building (I've been giving it the full 
machine). 

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The 
wixproj contains the RTM folder's contents.  The Update1 folder mentioned 
in the makefile is nearly identical, with only differences being in 
content and the definitions in the defines.wxi (also attached here). 


Any recommendations would be greatly appreciated - and if there's anything 
I can do to help repro / debug, I'd be happy to do so, assuming it's 
within my capabilities or relatively close to them. 
Kelly 



Rob Mensching <[EMAIL PROTECTED]> 
05/14/2008 11:52 PM 


To
Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 
 
cc

Subject
RE: [WiX-users] really slow using pyro
 








0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not 
sure there is much wired up to it). 
  
1.  What version of WiX v3 are you using? 
  
2.  What is the command line you’re passing pyro? 
  
3.  Are all of your MSIs and files local (not on a network share)? 
  
  
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro 
  

When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While 
this still isn't that long, it's very frustrating when we're trying to 
build and test our installs! 

Am I missing something easy that will make the builds of our patches run 
much faster?  What's actually going on during the 'pyro' processing?  Is 
it the file compares that could be taking that much time?  BTW, the patch 
in question ends up only being about 14K in size, and there's only 1 file 
out of about 960 that is different, and that file is very small (several 
K).  The two installs that are being compared are around 80MB in size when 
built into the MSIs, and are about 150MB uncompressed, I think. 

Is there any way to tell the pyro tool to tell me what steps are taking 
the most time so that I can try to understand if there's some 
optimizations we can do to improve it? 

Kelly 

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries 
guidelines.
**
 



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in p

Re: [WiX-users] really slow using pyro

[Rob Mensching]

One more question:  can you give me an idea of the time spent building MSI vs. 
building MSP?  Basically, I’m looking for a bit more details about what “long 
time” means.  

I’m not the patching expert but Peter is back from vacation and I’ll make sure 
he gets this thread tonight.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro


Sorry, I was braindead last night and it didn't even occur to me that knowing 
the version and what I'm doing might be useful information :(

0. tried that - didn't seem to tell me much of anything.
1. 3.0.3419 - I'll try a newer build today.
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst
   (entire makefile is attached)
3. all files are local

other info:
running Vista x64 Business on a quad-core machine with 4gb RAM and mirrored 
HDDs using hardware RAID.
not much else going on while building (I've been giving it the full machine).

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The wixproj 
contains the RTM folder's contents.  The Update1 folder mentioned in the 
makefile is nearly identical, with only differences being in content and the 
definitions in the defines.wxi (also attached here).


Any recommendations would be greatly appreciated - and if there's anything I 
can do to help repro / debug, I'd be happy to do so, assuming it's within my 
capabilities or relatively close to them.
Kelly


Rob Mensching <[EMAIL PROTECTED]>

05/14/2008 11:52 PM

To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 


cc

Subject

RE: [WiX-users] really slow using pyro







0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not sure 
there is much wired up to it).

1.  What version of WiX v3 are you using?

2.  What is the command line you’re passing pyro?

3.  Are all of your MSIs and files local (not on a network share)?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro


When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While this 
still isn't that long, it's very frustrating when we're trying to build and 
test our installs!

Am I missing something easy that will make the builds of our patches run much 
faster?  What's actually going on during the 'pyro' processing?  Is it the file 
compares that could be taking that much time?  BTW, the patch in question ends 
up only being about 14K in size, and there's only 1 file out of about 960 that 
is different, and that file is very small (several K).  The two installs that 
are being compared are around 80MB in size when built into the MSIs, and are 
about 150MB uncompressed, I think.

Is there any way to tell the pyro tool to tell me what steps are taking the 
most time so that I can try to understand if there's some optimizations we can 
do to improve it?

Kelly

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**


**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012

Re: [WiX-users] Where do WiX Variables Come From?

[Rob Mensching]

Heh, yeah, that sounds like the bug.  Can you make sure a bug gets opened on 
the issue?  I'm not the Votive expert so I'm not sure there is a work around 
but something needs to be fixed.  In the very least, the error message is 
horrible.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Holder
Sent: Thursday, May 15, 2008 08:27
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Where do WiX Variables Come From?

Am having a bit of an issue with WiX  variables this a.m. which I'm hoping 
someone can clue me in on.  In a large Visual Studio solution, there are these 
two projects called "Common.csproj", each referring to logic in different 
namespaces, each in different physical folders.  When setting the File tag's 
Source attribute to a WiX variable, we run into a problem.  The syntax for the 
variable for both projects is as follows:

$(var.Common.TargetDir)

In order to solve this problem, we looked at the .wixproj file's schema, 
wherein we have a series of ProjectReference tags.  Beneath the 
ProjectReference node, there's a Name tag - presumed to contain the string 
referred to by the WiX toolset to identify the project name within the WiX 
variable syntax.   Consequently, we changed our .wixproj as follows (note the 
 tag content):


   58 

   59   ServiceCommon

   60   {7b6ebb1f-3b75-4497-85fb-e524fc9486fc}

   61   True

   62 

   63 

   64   SharedCommon

   65   {13736794-cc44-4834-86a6-9733ba4c2089}

   66   True

   67 

Ordinarily, the  tags would have contained strings like "Common 
(Shared\Common)" and "Common (Service\Common)"; and these strings would have 
appeared within the References node of the WiX project.  Instead "SharedCommon" 
and "ServiceCommon" now appear in the References folder, as they do in the 
listing above.

However, when building the WiX project from within Visual Studio, we're still 
seeing the same original error we had when we'd first started building using 
diplicate $(var.Common.TargetDir) strings in our .wxs file:

candle.exe(0,0): error CNDL0001: Item has already been added. Key in 
dictionary: 'Common.Configuration'  Key being added: 'Common.Configuration'
Done building project "Sonora.wixproj" -- FAILED.

The -d arugments used when candle.exe is run by the build still use the 
"Common" string, suggesting that WiX is actually not looking at the .wixproj 
file's ProjectReference\Name nodes for the strings used as WiX variable names - 
it's simply using the project file name, looks like.

Can anyone verify this?  Further - can anyone suggest an alternative approach 
for handling duplicate project names (if indeed any approaches exist, other 
than telling all your devs to use unique project names in each solution)?

Gratefully,
ross.holder  |
Office  613.727.9898 ext 2018 | Mobile 613.293.7673 | Fax 819.420.0121
[EMAIL PROTECTED]
Application Developer - Product Development
P Before printing this, think about the environment|Avant d'imprimer ceci, 
pensez à l'environnement

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

[WiX-users] what is wix_x64?

[Kelly Leahy]

What's the difference between wix3_x64.msi and wix3.msi on the weekly 
releases?

Is the x64 for targeting x64, running WiX on x64, or what?

Does it not include the x86 versions of CAs?

Just curious,
Kelly


**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[Rob Mensching]

I think we’ve covered the whole gambit of issues on this thread.  I am going 
through all of them and will try to collect all the issues raised here and 
attempt to answer some the open questions over time.

However, this particular comment made me chuckle:

“They solved the 8.3 filename issue in WiX V3.. I believe they 
can do more.”

Heh.  “They” is *us*.  You and you and you and you over there who doesn’t talk 
much.  This mailing list, this place where we talk about what we do with the 
WiX toolset and the Windows Installer, this is where we live.  This is where we 
get work done.  This is where we make the world a better place one line of code 
or one question answered or one piece of feedback at a time.  You may think 
that’s all flowery language or complete and utter bullshit but that is how I 
see what we (all of us) are doing here.  We are a community built around using 
the WiX toolset and making it better.

The WiX toolset isn’t done.  Nobody here is arguing that there isn’t more that 
we can do to make the experience better.  Just look at our bug list and you can 
see literally hundreds of places where we are *clearly* not done.  IMHO, there 
is so much work to do the real question is about what gets done next.

All I ask is that you remember that there are people here.  We work on code, we 
talk about code, but this place is about people.  I understand that the 
technology (both MSI and WiX) can be frustrating.  Trust me, we all know that.  
I also appreciate that sometimes you just have to rant to get it out of your 
system.  It’s fine if you want to do that here (I always read rants about 
actual problems since they almost always point at some pain point we have yet 
to address).  But don’t make it personal.  I can assure you that no one here is 
actively working to make your life harder.  Instead, I encourage you to 
consider yourself a member of this community and frame your feedback such that 
it can help us improve the toolset or the community itself.

Finally, I disagree with the sentiment that this thread was doomed from the 
beginning.  Open (and preferably respectful) debate is one of the best ways to 
explore the spectrum of options and issues available for us to solve.  You 
underestimate the power you have in this community if you think that debates 
like this (that were mostly respectful ) have no impact.


PS:  None of my comments are intended to be directed *at* Scott.  They are 
about *all of us*.  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: Wednesday, May 14, 2008 07:22
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated

We all knew this thread was going nowhere from the first post of course...

My only point was that (in my experience) the original posters frustration is 
shared by the vast majority of developers trying to do installers on Windows. 
(i.e. everyone I know that has ever seen or worked on a WiX project)
Anything that can be done by WiX to ease these pain points is therefore 
justified by the vast payoff in improved productivity around the globe :-)

They solved the 8.3 filename issue in WiX V3.. I believe they can do more.

Regards,

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

Re: [WiX-users] How to associate certificate with IIS website without adding certificate to store?

[Robert O'Brien]

I have a service deliverable msi where I need to be able to pass in a public 
property value that defines the name of an existing cert that the msi will 
associate with a new 443 site it creates.

q1 - If I include the ssl certs for each of my service deliverable environments 
where the msi will be run to deploy service bits (e.g. dev, deployment 
verification test, test, perf, beta, pre-production, user acceptance testing, 
production hot standby, production)  then do I have a way of using a public 
property value to define which cert gets used in each case?

q2 - if there currently isn't a way to reference a cert already installed on 
the host (which is the case in beta, pre-production, user acceptance testing, 
production hot standby, production environments where we don't create & manage 
the systems) can I include some type of dummy cert for those cases and flag the 
iis:Certificate entry such that it won't try and install it if it already sees 
a certificate of that name in the local machine store?

From: Rob Mensching
Sent: Wednesday, May 14, 2008 11:38 PM
To: Robert O'Brien; 'wix-users@lists.sourceforge.net'
Subject: RE: [WiX-users] How to associate certificate with IIS website without 
adding certificate to store?

Unfortunately, I don't think the current Certificate code is going to support 
that.  The code could be updated to handle the scenario though.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Wednesday, May 14, 2008 18:51
To: 'wix-users@lists.sourceforge.net'
Subject: Re: [WiX-users] How to associate certificate with IIS website without 
adding certificate to store?

Did this work and if so does there exist a sample of what it means to create a 
permanent component Certificate entry that refers to an ssl certificate already 
known to be present on hosts you are deploying to?  In other words I just want 
my iis site settings to bind to port 443 and use an known in advance ssl 
certificate already present on the target systems.

From: Rob Mensching <[EMAIL PROTECTED]> - 2007-12-21 11:15
Try putting the Certificate element in a permanent Component.

Lin wrote:
> Hi,
>
> I am new to Wix so I hope this is the correct mailing list for such
> questions.
>
> I am using Wix3. I would like to associate a certificate with a IIS
> website. The certificate already exists in machine store, so I don't
> need to add it during installation. I have tried the
> / combination, but
>  not only overwrites the certificate (which is still
> acceptable) but removes it during uninstall (this is not acceptable).
>
> So how do I just set up the IIS website certificate without touching
> the certificate store?
>
> Thanks,
> Dakun

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

Re: [WiX-users] yep - back to being 100% frustrated

[Wheeler, Blaine (DSHS/DCS)]

I'd like to read your notes but unfortunately this link doesn't work for
me. http://john.mcfadyen.spaces.live.com

I concur with your views on Windows Installer and count myself very
lucky to build installs in a closed environment where we control the OS,
the installer on has to know 1 language and we don't build or show
dialogs because we don't give users choices during install.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jmcfadyen
Sent: Wednesday, May 14, 2008 11:51 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated


It seems to me reading this from a link via Christopher Painter that you
guys
are all missing a few vital points. 

It looks to me like most of you looking at this as Dev's which is where
you
are going wrong. I agree these items should be trivial to fix but there
is a
vast number of regions outside of the development sphere which are the
reason it is not. I feel some of you need to take your blinkers off and
see
what is really the big picture here. 

Windows Installer is complex it is difficult to get decent information
on
but there are very valid reasons why its so difficult and most of them
extend outside the realm of the developer developing a piece of software
for
his single little machine. 

Windows Installer caters for a massive array of issues problems
operating
systems, and integrates the entire setup not only for your little
application but is designed to integrate hundred/thousands of
applications
developed by hundreds/thousands of developers onto multiple platforms.
There
is a much bigger picture at work here. 

I think the guys at MS have done a great job. I could say vbscript is a
great programming language and that C# or F# is crap when the reality is
my
understanding of them may not be as good as some of you guys here. Most
of
you would look at me like I was mental or something but the reality is
many
of you are looking at this with the same mentality. 

I have been using windows installer since its inception and these days I
find little that it cant do with a tiny bit of brute force. Don't blame
the
tools as there are plenty of people out there using these tools and
making
them work seemlessly and quickly on a day to day basis. 

Each day I integrate around 1,000,000 lines of code into multiple msi's
within minutes using WiX. (I couldnt care less what its written in, if
you
know how to use it as it was designed it works like a charm). 

If anyone would like some assistance understanding the finer intricacies
of
windows installer I have some heavy detail on most of the undocumented
features here. 

http://john.mcfadyen.spaces.live.com 

No offence intended to anyone on these boards, this post is not aimed at
being nasty and I hope my blog can aid with some of your troubles. 











Scott Palmer-3 wrote:
> 
> On Tue, May 13, 2008 at 1:26 PM, Josh Rowe <[EMAIL PROTECTED]>
> wrote:
> 
>>  
>>
>> The moral of the story is that deployment procedures really are part
of
>> the source code for an application.  They are also risky, so
implement
>> them
>> first to minimize risk.
>>
> 
> This is the problem.  Deployment SHOULD be trivial.  That it is a
"risky"
> part is outrageous.  Shouldn't the hard part be in your application's
> algorithms rather than how to install it?  (Your statement also
ignores
> the
> fact that there is risk in other parts of the development - should
those
> parts also be done first to minimize risk? :-) )
> 
> Saying it's risky is fine to justify the point that installers should
be
> dealt with sooner in the development process - Given the current state
of
> installer technology I must sadly agree.  But it belittles the fact
that
> the
> installer technology sucks so bad and is the root problem that needs
> fixing.  Am I the only one that thinks it is somewhat pathetic to not
> consider a certain technology for the development of my application
> because
> I wont' be able to write the installer?  Doesn't that just say that A:
the
> technology to be installed (e.g. COM+), and B: the installer
technology
> itself (e.g. MSI) both suck?
> 
> On a Mac you would just drag and drop the application icon. The very
> existence of an installer is frowned upon for most things.  Why
doesn't
> Microsoft rip-off that instead of the desktop eye-candy? :-)
> 
> Isn't the goal of WiX to make creating MSI easier without giving up
any of
> it's raw abilities?  Should we really have to worry at the WiX level
about
> naming icon Ids with extensions that match what shortcuts that use
them
> point to?  That is just plain dumb and WiX should deal with that
behind
> the
> scenes for us.   Just like it deals with the insane requirement for
8.3
> filenames (WiX V3).  Should I have to hack the component keys when I
want
> to
> use shortcuts in a simple install for ALL_USERS? No, WiX should handle
> that
> too.
> 
> Regards,
> 
> Scott
> 
>

[WiX-users] Fw: really slow using pyro

[Kelly Leahy]

I guess the list doesn't like attachments.  Any recommendations of where 
to put them?

- Forwarded by Kelly Leahy/SEAT/MILLIMAN on 05/15/2008 09:23 AM -

Kelly Leahy
 (Seattle)
05/15/2008 09:14 AM

To
Rob Mensching <[EMAIL PROTECTED]>
cc
"wix-users@lists.sourceforge.net" 
Subject
RE: [WiX-users] really slow using pyro





Sorry, I was braindead last night and it didn't even occur to me that 
knowing the version and what I'm doing might be useful information :(

0. tried that - didn't seem to tell me much of anything.
1. 3.0.3419 - I'll try a newer build today.
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst
   (entire makefile is attached)
3. all files are local

other info:
running Vista x64 Business on a quad-core machine with 4gb RAM and 
mirrored HDDs using hardware RAID.
not much else going on while building (I've been giving it the full 
machine).

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The 
wixproj contains the RTM folder's contents.  The Update1 folder mentioned 
in the makefile is nearly identical, with only differences being in 
content and the definitions in the defines.wxi (also attached here).
<>

Any recommendations would be greatly appreciated - and if there's anything 
I can do to help repro / debug, I'd be happy to do so, assuming it's 
within my capabilities or relatively close to them.
Kelly




Rob Mensching <[EMAIL PROTECTED]>

05/14/2008 11:52 PM

To
Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 

cc

Subject
RE: [WiX-users] really slow using pyro






0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not 
sure there is much wired up to it).
 
1.  What version of WiX v3 are you using?
 
2.  What is the command line you’re passing pyro?
 
3.  Are all of your MSIs and files local (not on a network share)?
 
 
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro
 

When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While 
this still isn't that long, it's very frustrating when we're trying to 
build and test our installs! 

Am I missing something easy that will make the builds of our patches run 
much faster?  What's actually going on during the 'pyro' processing?  Is 
it the file compares that could be taking that much time?  BTW, the patch 
in question ends up only being about 14K in size, and there's only 1 file 
out of about 960 that is different, and that file is very small (several 
K).  The two installs that are being compared are around 80MB in size when 
built into the MSIs, and are about 150MB uncompressed, I think. 

Is there any way to tell the pyro tool to tell me what steps are taking 
the most time so that I can try to understand if there's some 
optimizations we can do to improve it? 

Kelly 

**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries 
guidelines.
**



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourcefo

[WiX-users] Latest Source

[Garth]

Hi,

I've checked out the latest source of WIX 3.0 from CVS and patched what 
I belived to be a problem in the Source.

I loged a bug an was then told this has been fixed.

Is CVS still used?

Where would I checkout the latest source for WIX 3.0?

Cheers

Garth

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

[WiX-users] Where do WiX Variables Come From?

[Ross Holder (Cactus Commerce Inc)]

Am having a bit of an issue with WiX  variables this a.m. which I'm hoping 
someone can clue me in on.  In a large Visual Studio solution, there are these 
two projects called "Common.csproj", each referring to logic in different 
namespaces, each in different physical folders.  When setting the File tag's 
Source attribute to a WiX variable, we run into a problem.  The syntax for the 
variable for both projects is as follows:

$(var.Common.TargetDir)

In order to solve this problem, we looked at the .wixproj file's schema, 
wherein we have a series of ProjectReference tags.  Beneath the 
ProjectReference node, there's a Name tag - presumed to contain the string 
referred to by the WiX toolset to identify the project name within the WiX 
variable syntax.   Consequently, we changed our .wixproj as follows (note the 
 tag content):


   58 

   59   ServiceCommon

   60   {7b6ebb1f-3b75-4497-85fb-e524fc9486fc}

   61   True

   62 

   63 

   64   SharedCommon

   65   {13736794-cc44-4834-86a6-9733ba4c2089}

   66   True

   67 

Ordinarily, the  tags would have contained strings like "Common 
(Shared\Common)" and "Common (Service\Common)"; and these strings would have 
appeared within the References node of the WiX project.  Instead "SharedCommon" 
and "ServiceCommon" now appear in the References folder, as they do in the 
listing above.

However, when building the WiX project from within Visual Studio, we're still 
seeing the same original error we had when we'd first started building using 
diplicate $(var.Common.TargetDir) strings in our .wxs file:

candle.exe(0,0): error CNDL0001: Item has already been added. Key in 
dictionary: 'Common.Configuration'  Key being added: 'Common.Configuration'
Done building project "Sonora.wixproj" -- FAILED.

The -d arugments used when candle.exe is run by the build still use the 
"Common" string, suggesting that WiX is actually not looking at the .wixproj 
file's ProjectReference\Name nodes for the strings used as WiX variable names - 
it's simply using the project file name, looks like.

Can anyone verify this?  Further - can anyone suggest an alternative approach 
for handling duplicate project names (if indeed any approaches exist, other 
than telling all your devs to use unique project names in each solution)?

Gratefully,
RH


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

[WiX-users] Where do WiX Variables Come From?

[Ross Holder]

Am having a bit of an issue with WiX  variables this a.m. which I'm hoping
someone can clue me in on.  In a large Visual Studio solution, there are
these two projects called "Common.csproj", each referring to logic in
different namespaces, each in different physical folders.  When setting the
File tag's Source attribute to a WiX variable, we run into a problem.  The
syntax for the variable for *both* projects is as follows:



$(var.Common.TargetDir)



In order to solve this problem, we looked at the .wixproj file's schema,
wherein we have a series of ProjectReference tags.  Beneath the
ProjectReference node, there's a Name tag – presumed to contain the string
referred to by the WiX toolset to identify the project name within the WiX
variable syntax.   Consequently, we changed our .wixproj as follows (note
the  tag content):



   58 

   59   ServiceCommon

   60   {7b6ebb1f-3b75-4497-85fb-e524fc9486fc}

   61   True

   62 

   63 

   64   SharedCommon

   65   {13736794-cc44-4834-86a6-9733ba4c2089}

   66   True

   67 



Ordinarily, the  tags would have contained strings like "Common
(Shared\Common)" and "Common (Service\Common)"; and these strings would have
appeared within the References node of the WiX project.  Instead
"SharedCommon" and "ServiceCommon" now appear in the References folder, as
they do in the listing above.



However, when building the WiX project from within Visual Studio, we're
still seeing the same original error we had when we'd first started building
using diplicate $(var.Common.TargetDir) strings in our .wxs file:



candle.exe(0,0): error CNDL0001: Item has already been added. Key in
dictionary: 'Common.Configuration'  Key being added: 'Common.Configuration'

Done building project "Sonora.wixproj" -- FAILED.



The –d arugments used when candle.exe is run by the build still use the
"Common" string, suggesting that WiX is actually not looking at the .wixproj
file's ProjectReference\Name nodes for the strings used as WiX variable
names – it's simply using the project file name, looks like.



Can anyone verify this?  Further – can anyone suggest an alternative
approach for handling duplicate project names (if indeed any approaches
exist, other than telling all your devs to use unique project names in each
solution)?



Gratefully,

*ross.holder**  | ** *

Office  613.727.9898 ext 2018 | Mobile 613.293.7673 | Fax 819.420.0121

[EMAIL PROTECTED] <[EMAIL PROTECTED]>

Application Developer - Product Development

*P** **Before printing this, think about the environment**|**Avant
d'imprimer ceci, pensez à l'environnement*
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [WiX-Users] Reglocator on 64-bit machine?

[BES Installer]

Hi there, I'm experiencing a strange issue and was wondering if anyone had
some insight into it.

I have an installer package where all the components are 32-bit, but I must
nonetheless interact with 64-bit prerequisite software and install on a 64
bit platform.

Now, all I am trying to do at this point is read from the 64-bit registry
hive with the help of AppSearch and RegLocator, so that I can determine what
folder the prerequisite software is in.  I updated the Reglocator.Type
column for this entry to 16, to indicate misdbLocatorTypeDirectory and
msidbLocatorType64bit.  However, in the subsequent log, I see that the
property linked to this row is not being set, even though this registry
exists.

Now when I change the Reglocator.Type column to 18 (msidbLocatorTypeRawValue
and msidbLocatorTypeDirectory) I see that this is set but then something
called WIN64DUALFOLDERS kicks in and changes the value.  This makes it plain
what happened in the first case; it found the value in the registry, C:\Program
Files\MyFolder\MyProgram.exe and then WIN64DUALFOLDERS changes it to
C:\*Program
Files (x86)*\MyFolder\MyProgram.exe.  Then Windows installer attempts to
confirm that the folder exists and since it doesn't under the new name, it
won't set the property (It really should log the reason it doesn't set it,
but that's something to take up with the MSI folks I guess).

So my question is, how do I stop WIN64DUALFOLDERS from working in this
case?  I'm using MSI 3.1, if that makes any difference?  I've seen people
say that you can select this if the component is marked as 64-bit, but in
this case I'm using reglocator which does not seem to allow for that
distinction.

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

Re: [WiX-users] yep - back to being 100% frustrated

[Christopher Painter]

Last year the MSBuild team had a very interesting blog asking people if they 
had $100 to spend on MSBuild how would they spend it?   They then went on to 
give a list of possible priorities.
   
  I think it would be very beneficial if both the MSI team and the WiX virtual 
team would have similar blog posts. When doing it, be sure to include a 
broad list of features that consumers would want not just things the teams want.
   
  For the MSI team, my wish would be that they put a lot more work into 
properly behaving custom action sandboxes so that consuming EXE's and Managed 
Code DLL's wouldn't be problematic.  

Justin Rockwood <[EMAIL PROTECTED]> wrote:
Interesting discussion so far. I just wanted to chime in a 
little here. I think Mathias is correct here in stating that there are some 
real problems with Windows Installer (and thereby Wix in its current form). I 
work on the dang thing but I still get frustrated at Windows Installer. It's 
just too hard to do simple things. Right now, Wix is a wrapper on top of MSI, 
and while we are trying to make things simpler by bundling in custom actions, 
providing some guidance on how to write "correct" installers, providing a 
development environment via Votive, etc. we still have a long, long way to go 
before it's really easy for devs not conversant in all of the intricacies of 
MSI. We'll get there eventually, but slowly. As always, we are open to 
constructive feedback and will try our best to pass on some of your feedback to 
the Windows Installer group.
   
  Thanks,
  Justin
   
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin 
MacPherson
Sent: Thursday, May 15, 2008 2:14 AM
To: Holmgren Mathias
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated

   
  http://johnmcfadyen.spaces.live.com/
2008/5/15 Holmgren Mathias <[EMAIL PROTECTED]>:
> Don't blame the tools as there are plenty of people out there using 
these tools and making them work seemlessly and quickly on a day to day basis.  
   

  Well, you can't just disregard the large majority of people who are 
struggling a lot with this. And you can't disregard the "developer 
perspective", because developers are the people that have to deal with this.
   
  Sure, one part of the story is about expectations and the learning curve of 
installation. Before building an installation package, you expect it to be 
pretty easy, like a couple of days work. Then when you start doing it you find 
out that the level of investment necessary to complete a working real world 
installer is not 10 but maybe 100 times greater than what you expected, or more 
(yes, for real, I'm not making this up). And we are talking very experienced 
people here, not rookie devs.
   
  Having to invest your time so heavily to get so little tangible result back 
is a shock to most people. And when all the bumps, twists and turns of the 
technology are added on top of that learning process there will be frustration.
   
  Now, I'm not much for nursing cry baby mentality either. It will get you 
nowhere. But I do feel that there is a case to be made here about not putting 
up with things that are overburdening. This is the other part of the story.
   
  If the tools can be improved to make installation simpler, why settle for 
less?
  Or are installer technology and the tools already as good as they can ever 
become?
   
  No. Identify the stuff that can be made easier with better tools. Reduce some 
of the burden of that complexity you are referring to and streamline the more 
common stories to ease the learning curve. That's what should be done.
 
  > http://john.mcfadyen.spaces.live.com 
   

  Domain lookup of that comes up blank. Do you have another link? I sure could 
use some info on those undocumented features.
   
  /Mathias


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

   

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


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

Re: [WiX-users] Did WiX V3 projects break compatibility with earlier builds?

[Justin Rockwood]

That's a pretty good summary of the MPF. J To answer your question more
completely. VB/C#/C++ were all written using the native C++ project system
that was in existence years before MPF even came about. MPF is part of the
Visual Studio SDK and was written originally as a port of the C++ code. The
problem (IMHO) is that the native code project system was flawed in its
design to begin with. It was overly complex and burdensome to work with. The
VS SDK team had a golden opportunity to clean it up and make it so much
easier to use when creating a new SDK for Visual Studio based on managed
code. Unfortunately, I don't think they got it right. Interestingly, in
Votive 2.0 I had written my own SDK that was a lot easier to use than the
MPF (it was before the MPF was around). I think knowing what I do now about
the MPF and the bugs/lack of features, I might not have switched over to it.
At any rate, I don't foresee VB/C#/C++ being rewritten to use the MPF since
it is not up to par (yet).

 

Justin

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don Caton
Sent: Wednesday, May 14, 2008 9:53 PM
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with
earlier builds?

 

Scott:

 

MPF stands for 'Managed Package Framework', an incomplete and buggy
framework for building project systems that integrate into Visual Studio.
It's part of the Visual Studio SDK.  Consider yourself lucky that you don't
have to deal with it.

 

Don

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: Wednesday, May 14, 2008 9:43 PM
To: Justin Rockwood
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with
earlier builds?

 

It seems the real bug then is that there are two code paths... VB/C/C++
should be implemented via the MPF stuff as well... then this never would
have happened.  I say this still not knowing what MPF stands for or anything
about it though.

 

Scott

 

On 14-May-08, at 10:45 AM, Justin Rockwood wrote:

 

No, other projects that are not based on the MPF (which includes VB/C#/C++)
do not lock because they do not have that bug. However, projects that are
based on the MPF (IronPython, if I remember correctly) do exhibit the same
bug that WiX has. This bug, in my mind, is one of the most annoying ones
that should have higher priority (along with the other one that you pointed
out - same line output). Thanks for the bug reports!

 

Justin

 

From: Scott Palmer 
Sent: Wednesday, May 14, 2008 7:14 AM
To: Justin Rockwood
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Did WiX V3 projects break compatibility with
earlier builds?

 

On Tue, May 13, 2008 at 7:05 PM, Justin Rockwood  wrote:

I hate the locking as well. Unfortunately, this is a bug in the MPF (the
Visual Studio SDK) that they have not fixed yet. We will have to just fix it
on our own instead of waiting for a fix from them. Note that it's not a
trivial fix either because it requires a separate thread to do the build.

Are you saying that other tasks like compiling and linking C/C++ code lock
things the same way.. but I assume for short enough periods of time that it
isn't noticeable?  I'm just wondering why I only notice this with WiX
projects.
 ...

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

Re: [WiX-users] yep - back to being 100% frustrated

[Justin Rockwood]

Interesting discussion so far. I just wanted to chime in a little here. I
think Mathias is correct here in stating that there are some real problems
with Windows Installer (and thereby Wix in its current form). I work on the
dang thing but I still get frustrated at Windows Installer. It's just too
hard to do simple things. Right now, Wix is a wrapper on top of MSI, and
while we are trying to make things simpler by bundling in custom actions,
providing some guidance on how to write "correct" installers, providing a
development environment via Votive, etc. we still have a long, long way to
go before it's really easy for devs not conversant in all of the intricacies
of MSI. We'll get there eventually, but slowly. As always, we are open to
constructive feedback and will try our best to pass on some of your feedback
to the Windows Installer group.

 

Thanks,

Justin

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin
MacPherson
Sent: Thursday, May 15, 2008 2:14 AM
To: Holmgren Mathias
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated

 

http://johnmcfadyen.spaces.live.com/

2008/5/15 Holmgren Mathias <[EMAIL PROTECTED]>:

> Don't blame the tools as there are plenty of people out there using these
tools and making them work seemlessly and quickly on a day to day basis.  

 

Well, you can't just disregard the large majority of people who are
struggling a lot with this. And you can't disregard the "developer
perspective", because developers are the people that have to deal with this.

 

Sure, one part of the story is about expectations and the learning curve of
installation. Before building an installation package, you expect it to be
pretty easy, like a couple of days work. Then when you start doing it you
find out that the level of investment necessary to complete a working real
world installer is not 10 but maybe 100 times greater than what you
expected, or more (yes, for real, I'm not making this up). And we are
talking very experienced people here, not rookie devs.

 

Having to invest your time so heavily to get so little tangible result back
is a shock to most people. And when all the bumps, twists and turns of the
technology are added on top of that learning process there will be
frustration.

 

Now, I'm not much for nursing cry baby mentality either. It will get you
nowhere. But I do feel that there is a case to be made here about not
putting up with things that are overburdening. This is the other part of the
story.

 

If the tools can be improved to make installation simpler, why settle for
less?

Or are installer technology and the tools already as good as they can ever
become?

 

No. Identify the stuff that can be made easier with better tools. Reduce
some of the burden of that complexity you are referring to and streamline
the more common stories to ease the learning curve. That's what should be
done.

 

> http://john.mcfadyen.spaces.live.com
  

 

Domain lookup of that comes up blank. Do you have another link? I sure could
use some info on those undocumented features.

 

/Mathias


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

 

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

Re: [WiX-users] Install a mysql 5 database

[Tobias Bengtsson]

I doubt that the mailto:[EMAIL PROTECTED] On Behalf Of Norbert Haedler
Sent: den 14 maj 2008 22:35
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install a mysql 5 database

hello,

i had some problems to install an mysql database with a wix 2.0
installer. i had installed mysql 5.0 server on an win xp system and
tried it like this: http://www.tramontana.co.hu/wix/lesson7.php
the installer does the necessary steppes without an error but afterwards
there is no database created. I also tried it with an custom action
(cmd.exe) but it isn't possible to do two steppes (login and create the
database).
I don't know what i can do now to create a database with some tables. Is
there an other possibility? or did i something wrong?

thanks for your help norbert

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


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

[WiX-users] WiX under Mono

[Ruslan Hristov]

Hello,

Is it possible to run WiX under Mono (and Linux)? I found a blog from  
2004 that claimed it was possible, but I tried running and then  
compiling the latest version but there seems to be quite a few issues.

Any information would be appreciated.

Thanks,
 >>ruslan

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

[WiX-users] Installing third-party app from msi installer

[Fredrik Oja]

Hi all,

I'm new to wix and need some advice on how to have my app's installer to
install another third-party app if necessary. I need to bundle the install
files (one setup.exe and a couple of other files) into my msi and on
install, copy the files to a temporary directory, run the setup.exe and
finally remove the install files from the temporary directory.

Any hints about how this could be done would be greatly appreciated,

Thanks,

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

[WiX-users] property in custom action

[Norbert Haedler]

hello again,...

i'd "write" a custom action to create an mysql database on an server:



this workes fine. but i want to use a relative path in the execommand, 
something like [INSTALLDIR]MySQLDB.sql but this didn't work. does 
anybody know why? e.g. [SQLUSER] workes fine to.

thanks norbert

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

[WiX-users] How to let other user can find my program in ARP on Vista?

[Akibo]

Hello,

I install my program with account A, and can see my product name in
"uninstall program" on Vista. But account B cannot see this product name in
his control panel/uninstall program. Both account are in administrators
group.

I check HKLM\\Uninstall. I saw my product key are in HKLM\\Uninstall\\[GID]
but not exist in HKLM\\Uninstall. I saw most other application have a
registry - HKLM\\Uninstall\\[APP] and put product name in this folder. 

Is that root cause? Whether yes or no, how to resolve it with wix? 

Will be appreciate for your kindly help.


-- 
View this message in context: 
http://www.nabble.com/How-to-let-other-user-can-find-my-program-in-ARP-on-Vista--tp17252574p17252574.html
Sent from the wix-users mailing list archive at Nabble.com.


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

[WiX-users] Делигирование

[Распределение ресурсов]

Новейшие технологии 
тайм-менеджмента 
27 мая 2008 г. Москва

 Наши 
телефоны:
(495)509-2139 и 509-2161
 


  

 
 


Целевая аудитория:
 

руководители всех уровней
 

Цель семинара:
 

Формирование у 
участников представления об эффективных способах учета и распределения 
временных ресурсов (time-managements) с учетом индивидуальных особенностей 
восприятия; формирование и развитие практических навыков самоменеджмента 
(планирования, целеполагания, минимизации временных потерь).


 

Об авторе: 
 

профессиональный 
бизнес-тренер. В ходе тренингов активно использует такие интерактивные 
методики, как: ролевые игры, групповая дискуссия; упражнения в минигруппах на 
отработку и закрепление тренируемых навыков; анализ видео-метафор и т.д.

 

В программе:  
 


Понятие "Управление временем"   
 Технический инструментарий эффективного планирования 
времениИндивидуальные возможности 
оптимизации расхода времени (как в области профессиональной деятельности, так и 
вне ее) 

 

Стоимость участия в семинаре:
 

7500 руб., 
НДС не облагается согласно главы 26.2 
Налогового кодекса РФ.

 

Выдаваемый документ
 

Сертификат о повышении квалификации установленного 
образца

 
  
 

 
   

[WiX-users] desktop icon and program meun item not remove.

[sanjayjadam]

I have created two individual setups in wix for my two projects. Its get
install in same parent directory (c:\apps\firstapp and c:\apps\secondapp).
When i install one of my setup and Uninstall the same , the unistallation
process is working fine(with both the setups). but when i try to install
both the setups and try to uninstall both the setups one by one, the
uninstallation process do not remove desktop icon and program menu item.

if anybody could help me it will be great help

thanks in advance

Sanjay Jadam




-- 
View this message in context: 
http://www.nabble.com/desktop-icon-and-program-meun-item-not-remove.-tp17250191p17250191.html
Sent from the wix-users mailing list archive at Nabble.com.


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

[WiX-users] Регистрация и защита интеллект уальной собственности

[andrus geoff]

  Регистрация и   защита интеллектуальной собственности:
  Регистрация товарных знаков Регистрация патентов на 
полезные модели Регистрация патентов на промышленные образцы 
Регистрация патентов на изобретения Депонирование авторских прав
 Регистрация программ для ЭВМ и БД Лицензионные договора на патенты и 
товарные знаки Договора уступки прав на патенты и товарные знаки
 Судебная защита  Сложные задачи- наша   работа!
  Тел. / 495 / 629 9 611
  Тел. / 499 / 408 9 683
  Приносим свои извинения, если данная рассылка Вам   не нужна.

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

[WiX-users] Новинка!

[gerold demeter]

   Новейшие базы данных. 
 Внешнеэкономическая деятельность 1999-2008 гг РФ и Украины . 
 Юридические лица и предприятия Москвы и РФ по 2008 г . ( регистрационные и 
фактические данные ) 3000 руб . 
 Банковские переводы ( данные РКЦ ЦБ )  6000 руб . 
 Физические лица Москвы и Московской области ( телефоны , прописка , 
собственность , паспорта ) по 2007 г  2000  руб . 
 ГАИ Москвы и Московской области ( данные по автомобилям и владельцам , 
водительским удостоверениям , ДТП , ПДД и др .) по 2007 г  2000  руб . 
 Пенсионный фонд ( данные о работодателе , месте работы , месте жительства , 
доходе ) 2000  руб . 
 Антикриминал ( полный сборник по криминальной тематике ) по 2007 г . 3 000 руб 
. 
 Регионы России ( физ . лица , ГАИ городов России ).  4000 руб .
 Стоимость полного комплекта  - 15000руб. 
 Наш телефон для связи: /495/ 961 5 867 
   
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[Martin MacPherson]

http://johnmcfadyen.spaces.live.com/

2008/5/15 Holmgren Mathias <[EMAIL PROTECTED]>:

>  > Don't blame the tools as there are plenty of people out there using
> these tools and making them work seemlessly and quickly on a day to day
> basis.
>
>
>
> Well, you can't just disregard the large majority of people who are
> struggling a lot with this. And you can't disregard the "developer
> perspective", because developers are the people that have to deal with this.
>
>
>
> Sure, one part of the story is about expectations and the learning curve of
> installation. Before building an installation package, you expect it to be
> pretty easy, like a couple of days work. Then when you start doing it you
> find out that the level of investment necessary to complete a working real
> world installer is not 10 but maybe 100 times greater than what you
> expected, or more (yes, for real, I'm not making this up). And we are
> talking very experienced people here, not rookie devs.
>
>
>
> Having to invest your time so heavily to get so little tangible result back
> is a shock to most people. And when all the bumps, twists and turns of the
> technology are added on top of that learning process there will be
> frustration.
>
>
>
> Now, I'm not much for nursing cry baby mentality either. It will get you
> nowhere. But I do feel that there is a case to be made here about not
> putting up with things that are overburdening. This is the other part of the
> story.
>
>
>
> If the tools can be improved to make installation simpler, why settle for
> less?
>
> Or are installer technology and the tools already as good as they can ever
> become?
>
>
>
> No. Identify the stuff that can be made easier with better tools. Reduce
> some of the burden of that complexity you are referring to and streamline
> the more common stories to ease the learning curve. That's what should be
> done.
>
>
>
> > http://john.mcfadyen.spaces.live.com
>
>
>
> Domain lookup of that comes up blank. Do you have another link? I sure
> could use some info on those undocumented features.
>
>
>
> /Mathias
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[Holmgren Mathias]

> Don't blame the tools as there are plenty of people out there using
these tools and making them work seemlessly and quickly on a day to day
basis.  

 

Well, you can't just disregard the large majority of people who are
struggling a lot with this. And you can't disregard the "developer
perspective", because developers are the people that have to deal with
this.

 

Sure, one part of the story is about expectations and the learning curve
of installation. Before building an installation package, you expect it
to be pretty easy, like a couple of days work. Then when you start doing
it you find out that the level of investment necessary to complete a
working real world installer is not 10 but maybe 100 times greater than
what you expected, or more (yes, for real, I'm not making this up). And
we are talking very experienced people here, not rookie devs.

 

Having to invest your time so heavily to get so little tangible result
back is a shock to most people. And when all the bumps, twists and turns
of the technology are added on top of that learning process there will
be frustration.

 

Now, I'm not much for nursing cry baby mentality either. It will get you
nowhere. But I do feel that there is a case to be made here about not
putting up with things that are overburdening. This is the other part of
the story.

 

If the tools can be improved to make installation simpler, why settle
for less?

Or are installer technology and the tools already as good as they can
ever become?

 

No. Identify the stuff that can be made easier with better tools. Reduce
some of the burden of that complexity you are referring to and
streamline the more common stories to ease the learning curve. That's
what should be done.

 

> http://john.mcfadyen.spaces.live.com
  

 

Domain lookup of that comes up blank. Do you have another link? I sure
could use some info on those undocumented features.

 

/Mathias

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

[WiX-users] Минимизация временных потерь

[Распределение ресурсов]

Новейшие технологии 
тайм-менеджмента 
27 мая 2008 г. Москва

 Наши 
телефоны:
(495)509-2139 и 509-2161
 


  

 
 


Целевая аудитория:
 

руководители всех уровней
 

Цель семинара:
 

Формирование у 
участников представления об эффективных способах учета и распределения 
временных ресурсов (time-managements) с учетом индивидуальных особенностей 
восприятия; формирование и развитие практических навыков самоменеджмента 
(планирования, целеполагания, минимизации временных потерь).


 

Об авторе: 
 

профессиональный 
бизнес-тренер. В ходе тренингов активно использует такие интерактивные 
методики, как: ролевые игры, групповая дискуссия; упражнения в минигруппах на 
отработку и закрепление тренируемых навыков; анализ видео-метафор и т.д.

 

В программе:  
 


Понятие "Управление временем"   
 Технический инструментарий эффективного планирования 
времениИндивидуальные возможности 
оптимизации расхода времени (как в области профессиональной деятельности, так и 
вне ее) 

 

Стоимость участия в семинаре:
 

7500 руб., 
НДС не облагается согласно главы 26.2 
Налогового кодекса РФ.

 

Выдаваемый документ
 

Сертификат о повышении квалификации установленного 
образца