Re: [WiX-users] C# .dll

[Joe Kaplan]

Hi Rob,

Would you care to elaborate on this part a bit?  If you already blogged it, 
I apologize.  I've followed the evolution of this issue for a while now and 
I am always curious to learn more about it.  To my knowledge, I don't 
remember you or anyone else discussing any specific issues regarding loaded 
the CLR into the installer process.

I'm definitely of the opinion that these things are best avoided for now due 
to the lack of support for it at the WI level.  On the other hand, I also 
believe it is just a matter of time before this needs to happen in a fully 
supported way.  Basically, I'm trying to understand what the solution might 
look like in order to overcome some of the more subtle issues.  What's so 
"neat"?  :)

Thanks!

Joe K.

- Original Message - 
From: "Rob Mensching" <[EMAIL PROTECTED]>
To: "Levi Wilson" <[EMAIL PROTECTED]>; "Dhaval Patel" 
<[EMAIL PROTECTED]>
Cc: 
Sent: Friday, March 16, 2007 12:43 PM
Subject: Re: [WiX-users] C# .dll


More importantly, the Windows Installer doesn't support it today.  There are 
actually "neat" problems you can introduce by loading the .NET Framework 
into the Windows Installer process.

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson
Sent: Friday, March 16, 2007 10:40 AM
To: Dhaval Patel
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# .dll

I don't know for certain, but my guess would be that there's no guarantee 
that the .NET Framework has been installed on the client.
On 3/16/07, Dhaval Patel 
<[EMAIL PROTECTED]> wrote:
Will WIX 3.0 be adding the capability to call C# .dll files? If not, 
WHY? :)

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







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





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


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

Re: [WiX-users] C# .dll

[Dhaval Patel]

I guess, I see your point, Rob. But making this functionality available
would open all kinds of doors for folks like me - I get to govern 'what,
how, and when' my clients install currently; our company is a 90% MS shop,
and most of our server deployments have .NET installed just for that reason
alone.

Of course, this may mean more issues for you :)


On 3/16/07, Rob Mensching <[EMAIL PROTECTED]> wrote:


 More importantly, the Windows Installer doesn't support it today.  There
are actually "neat" problems you can introduce by loading the .NET Framework
into the Windows Installer process.



*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Levi Wilson
*Sent:* Friday, March 16, 2007 10:40 AM
*To:* Dhaval Patel
*Cc:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] C# .dll



I don't know for certain, but my guess would be that there's no guarantee
that the .NET Framework has been installed on the client.

On 3/16/07, *Dhaval Patel *<[EMAIL PROTECTED]> wrote:

Will WIX 3.0 be adding the capability to call C# .dll files? If not,
WHY? :)

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



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

[WiX-users] Disabling a Feature

[Geoff Finger]

I have a feature that can only installed if .net 1.1 or higher is also
installed. The description for the feature indicates this requirement
but I don't want to trust to the users' good sense, some of them will
either not read the message or ignore it and get into trouble.

Searching through the archives showed several posts about disabling a
feature by using a Condition to set the Level to 0. I tried this and
it worked fine except that the feature wasn't just disabled, it was
entirely removed.

I'd like the feature to be visible but unchangeable from the "won't be
installed" state so the users can select it and see the requirement in
the description and then go install .net if necessary. Is there any
way to do this?

Thanks!

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

Re: [WiX-users] Intercepting SQL errors and displaying custom error

[Rob Mensching]

Take a look at wix\src\ext\SqlExtension\wixlib\en-us.wxl.  You'll see 
everything there is overridable.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta
Sent: Friday, March 16, 2007 2:13 PM
To: Don Tasanasanta; Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom error

I'm searching the wixlib's for the sql error strings and only found them in the 
sca.wixlib

None of the tuple's defined in the sql section has localization variables and I 
haven't found associating fields in the wixui.wixlib

Does that mean that the sql errors have not been localized? In which case, does 
that mean that a wxl file won't do the trick in intercepting sql errors and 
substituting my own custom errors?


From: Don Tasanasanta
Sent: Friday, March 16, 2007 1:06 PM
To: Don Tasanasanta; Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Intercepting SQL errors and displaying custom error

Ok maybe I don't understand .wxl files that well...

I found the identifier in the error table, created a .wxl file and used light 
with a -loc to my wxl file and a reference to my rsp file.

When all was said and done I checked the error table but the error identifier I 
tried to replace wasn't changed.

Here is my wxl file:



   1033
   la la la la la


I'm trying to replace the string 26201 in the error table.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta
Sent: Thursday, March 15, 2007 5:35 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom error

I think I understand the use of .wxl files and I've found the sql errors within 
the sca.wixlib.

How do I identify the sql errors within my personal .wxl? Do I simply copy from 
 to  of the sql errors into my own .wxl, 
substitute my own error msgs, and then link it?

Is it that easy?


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 4:46 PM
To: Don Tasanasanta; wix-users@lists.sourceforge.net
Subject: RE: Intercepting SQL errors and displaying custom error

Yes.  Provide a .wxl file for the localization identifiers defined the .wixlib.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta
Sent: Wednesday, March 14, 2007 3:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intercepting SQL errors and displaying custom error

Is there a way to intercept SQL install errors and display my own custom 
error(s)?

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

Re: [WiX-users] CAB not being written to _Streams table

[Matt Coill]

I found the problem:


Setting this to "yes" fixed it. Suddenly my MSI was 4meg and it worked.

I did read that _Streams was a temporary table in MSDN, but the instructions 
for embedding a CAB (http://msdn2.microsoft.com/en-us/library/aa369279.aspx) 
tell you to add it to the _Streams table in step 8.

About the disk ID, the table got screwed up with cut and paste:
DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source

i2

i4

L64

S255

S32

S72

1

7



#XUSB21.cab






This means that every file with sequence number 7 or below will be in the 
cabinet.

Thanks,
 - Matt


From: Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 2:30 PM
To: Matt Coill; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] CAB not being written to _Streams table

_Streams is not a real table. The documentation states "This is a temporary 
table, created only when referenced by a SQL statement." The CABs are actually 
stored as separate streams in the OLE Structured Storage file. You can see them 
with the DocFile Viewer (dfview.exe) from Visual Studio 6.0 (it may be included 
in later versions but I can't see it) but that's not really very helpful as the 
names of the streams are mangled.

If you want to change the compression level, change the CompressionLevel 
attribute. However, here, I think that you've misunderstood DiskId. Only the 
files marked with the same DiskId are included in the specified CAB file. I'm 
not sure if there's any point making multiple embedded CABs, although it is 
possible to request light.exe to reuse existing CAB files.

--
Mike Dimmick


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Coill
Sent: 16 March 2007 20:37
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CAB not being written to _Streams table

Embeddding the cab:


Opening the msi with ORCA:
I see that the cab is listed as embedded in the media table -

DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source

i2

i4

L64

S255

S32

S72

Media

DiskId









1

7



#XUSB21.cab






The files that should be embedded in it are all the ones sequence of seven or 
less
File

Component_

FileName

FileSize

Version

Language

Attributes

Sequence

s72

s72

l255

i4

S72

S20

I2

i4

File

File













wdf_dll_x64

wdf_dll_x64

wdfx64.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

6

wdf_dll_x86

wdf_dll_x86

wdfx86.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

3

wdf_update_x64

wdf_update_x64

wdfupx64.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

7

wdf_update_x86

wdf_update_x86

wdfupx86.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

4

xusb21_inf

xusb21_inf

xusb21.inf

8400





512

1

xusb21_sys_x64

xusb21_sys_x64

xusb21.sys

347904

6.0.6000.16386

1033

512

5

xusb21_sys_x86

xusb21_sys_x86

xusb21.sys

284544

6.0.6000.16386

1033

512

2


But there is no _Streams table and the file size is only 70K which is 
essentially the same size as without compression.

Does WIX2.0 not support this, or am I missing something?

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

Re: [WiX-users] CAB not being written to _Streams table

[Mike Dimmick]

_Streams is not a real table. The documentation states "This is a temporary
table, created only when referenced by a SQL statement." The CABs are
actually stored as separate streams in the OLE Structured Storage file. You
can see them with the DocFile Viewer (dfview.exe) from Visual Studio 6.0 (it
may be included in later versions but I can't see it) but that's not really
very helpful as the names of the streams are mangled.

 

If you want to change the compression level, change the CompressionLevel
attribute. However, here, I think that you've misunderstood DiskId. Only the
files marked with the same DiskId are included in the specified CAB file.
I'm not sure if there's any point making multiple embedded CABs, although it
is possible to request light.exe to reuse existing CAB files.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Coill
Sent: 16 March 2007 20:37
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CAB not being written to _Streams table

 

Embeddding the cab:



 

Opening the msi with ORCA:

I see that the cab is listed as embedded in the media table -




DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source


i2

i4

L64

S255

S32

S72


Media

DiskId

 

 

 

 


1

7

 

#XUSB21.cab

 

 

 

The files that should be embedded in it are all the ones sequence of seven
or less


File

Component_

FileName

FileSize

Version

Language

Attributes

Sequence


s72

s72

l255

i4

S72

S20

I2

i4


File

File

 

 

 

 

 

 


wdf_dll_x64

wdf_dll_x64

wdfx64.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

6


wdf_dll_x86

wdf_dll_x86

wdfx86.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

3


wdf_update_x64

wdf_update_x64

wdfupx64.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

7


wdf_update_x86

wdf_update_x86

wdfupx86.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

4


xusb21_inf

xusb21_inf

xusb21.inf

8400

 

 

512

1


xusb21_sys_x64

xusb21_sys_x64

xusb21.sys

347904

6.0.6000.16386

1033

512

5


xusb21_sys_x86

xusb21_sys_x86

xusb21.sys

284544

6.0.6000.16386

1033

512

2

 

But there is no _Streams table and the file size is only 70K which is
essentially the same size as without compression.

 

Does WIX2.0 not support this, or am I missing something?

 

Thanks,

- Matt

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

Re: [WiX-users] CAB not being written to _Streams table

[Matt Coill]

Doesn't install unless the files are shipped along with the MSI.

Am I using a recent enough version of Candle\Light:
Microsoft (R) Windows Installer Xml Compiler version 2.0.3620.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.

Thanks,
- Matt

From: Rob Mensching
Sent: Friday, March 16, 2007 2:18 PM
To: Matt Coill; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] CAB not being written to _Streams table

Never heard of anyone having a problem with it where there wasn't a build 
failure somewhere else.  Does it install correctly?

Also, I don't remember if the cabinet shows up in the _Streams table... it may 
just be stored as a stream with the name.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Coill
Sent: Friday, March 16, 2007 1:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CAB not being written to _Streams table

Embeddding the cab:


Opening the msi with ORCA:
I see that the cab is listed as embedded in the media table -

DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source

i2

i4

L64

S255

S32

S72

Media

DiskId









1

7



#XUSB21.cab






The files that should be embedded in it are all the ones sequence of seven or 
less
File

Component_

FileName

FileSize

Version

Language

Attributes

Sequence

s72

s72

l255

i4

S72

S20

I2

i4

File

File













wdf_dll_x64

wdf_dll_x64

wdfx64.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

6

wdf_dll_x86

wdf_dll_x86

wdfx86.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

3

wdf_update_x64

wdf_update_x64

wdfupx64.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

7

wdf_update_x86

wdf_update_x86

wdfupx86.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

4

xusb21_inf

xusb21_inf

xusb21.inf

8400





512

1

xusb21_sys_x64

xusb21_sys_x64

xusb21.sys

347904

6.0.6000.16386

1033

512

5

xusb21_sys_x86

xusb21_sys_x86

xusb21.sys

284544

6.0.6000.16386

1033

512

2


But there is no _Streams table and the file size is only 70K which is 
essentially the same size as without compression.

Does WIX2.0 not support this, or am I missing something?

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

Re: [WiX-users] CAB not being written to _Streams table

[Rob Mensching]

Never heard of anyone having a problem with it where there wasn't a build 
failure somewhere else.  Does it install correctly?

Also, I don't remember if the cabinet shows up in the _Streams table... it may 
just be stored as a stream with the name.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Coill
Sent: Friday, March 16, 2007 1:37 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CAB not being written to _Streams table

Embeddding the cab:


Opening the msi with ORCA:
I see that the cab is listed as embedded in the media table -

DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source

i2

i4

L64

S255

S32

S72

Media

DiskId









1

7



#XUSB21.cab






The files that should be embedded in it are all the ones sequence of seven or 
less
File

Component_

FileName

FileSize

Version

Language

Attributes

Sequence

s72

s72

l255

i4

S72

S20

I2

i4

File

File













wdf_dll_x64

wdf_dll_x64

wdfx64.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

6

wdf_dll_x86

wdf_dll_x86

wdfx86.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

3

wdf_update_x64

wdf_update_x64

wdfupx64.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

7

wdf_update_x86

wdf_update_x86

wdfupx86.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

4

xusb21_inf

xusb21_inf

xusb21.inf

8400





512

1

xusb21_sys_x64

xusb21_sys_x64

xusb21.sys

347904

6.0.6000.16386

1033

512

5

xusb21_sys_x86

xusb21_sys_x86

xusb21.sys

284544

6.0.6000.16386

1033

512

2


But there is no _Streams table and the file size is only 70K which is 
essentially the same size as without compression.

Does WIX2.0 not support this, or am I missing something?

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

Re: [WiX-users] Set All Users desktop

[Mike Dimmick]

Well, unless running an elevated advertised installation, of course. I'm
coming to the conclusion that that's what per-user installs are for.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 15 March 2007 02:57
To: Brett Kapilik
Cc: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Set All Users desktop

 

Brett Kapilik wrote: 

I guess I just thought that 2 was more appropriate as a general setting
because it doesn't cause an error during installation if the user is not
running as an admin. If sending the shortcut to the all-users desktop is
critical to the installation, than ALLUSERS=1 would indeed be better. I
guess I should have made my answer more specific.


It takes a great deal of extra logic to properly support falling back to a
true per-user setup. Non-admins can't install to Program Files, for example.
It's more than just the profile directories.



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

Re: [WiX-users] Intercepting SQL errors and displaying custom error

[Don Tasanasanta]

I'm searching the wixlib's for the sql error strings and only found them
in the sca.wixlib

 

None of the tuple's defined in the sql section has localization
variables and I haven't found associating fields in the wixui.wixlib

 

Does that mean that the sql errors have not been localized? In which
case, does that mean that a wxl file won't do the trick in intercepting
sql errors and substituting my own custom errors? 

 



From: Don Tasanasanta 
Sent: Friday, March 16, 2007 1:06 PM
To: Don Tasanasanta; Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Intercepting SQL errors and displaying custom
error

 

Ok maybe I don't understand .wxl files that well... 

 

I found the identifier in the error table, created a .wxl file and used
light with a -loc to my wxl file and a reference to my rsp file. 

 

When all was said and done I checked the error table but the error
identifier I tried to replace wasn't changed. 

 

Here is my wxl file:

 

 



   1033

   la la la la la



 

I'm trying to replace the string 26201 in the error table.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta
Sent: Thursday, March 15, 2007 5:35 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom
error

 

I think I understand the use of .wxl files and I've found the sql errors
within the sca.wixlib.

 

How do I identify the sql errors within my personal .wxl? Do I simply
copy from  to  of the sql errors into
my own .wxl, substitute my own error msgs, and then link it?

 

Is it that easy?

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 4:46 PM
To: Don Tasanasanta; wix-users@lists.sourceforge.net
Subject: RE: Intercepting SQL errors and displaying custom error

 

Yes.  Provide a .wxl file for the localization identifiers defined the
.wixlib.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta
Sent: Wednesday, March 14, 2007 3:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intercepting SQL errors and displaying custom error

 

Is there a way to intercept SQL install errors and display my own custom
error(s)? 

 

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

Re: [WiX-users] VB6 msm

[Mike Dimmick]

I believe vb6fr.dll is a resource-only DLL containing translations of the
VB6 error message strings into French.

 

It looks like there is no merge module for this. The download page says that
the merge modules are localized into English, German and Japanese, but not
into French.

 

That being said, I think the best thing to do is to add the DLL as its own
component, to be installed into System32 (you should of course use the
[WindowsFolder] property to ensure that the right drive and directory name
are used). You should set the Component/@SharedDllRefCount property to 'yes'
to ensure that multiple applications installing this file won't have a
problem on uninstall.

 

SharedDllRefCount is the last resort for a shared file for which you don't
have a component GUID or for which legacy installers exist.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian
Sent: 15 March 2007 15:22
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] VB6 msm

 

Hi,

 

I use the MSVBVM60.msm to deploy an application made in VB6

 

In the log file of the installation, I can see this

C:\WINDOWS\system32\MSVBVM60.DLL

 

But when I run my program, it say it need vb6fr.dll

If I copy this dll in the system32 directory it's ok, but it's not really
clean.

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

Re: [WiX-users] heat errors scanning files

[Mike Dimmick]

The popup box is coming from the DLL's DllRegisterServer function. Fix your
self-registration code, or write the script manually.

 

You should not run heat on every build. It is intended for creating an
initial script. Generating new GUIDs on every build can cause component rule
violations, and generating new keys causes problems with patching (see
http://blogs.msdn.com/windows_installer_team/archive/2007/03/07/arbitrary-la
bels-used-as-primary-keys-must-not-be-changed-between-versions.aspx).

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Bandy
Sent: 15 March 2007 16:24
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] heat errors scanning files

 

I'm using heat with the -scom flag to generate a file with all of the
registry settings directly. This is being used as the first step in an
automated build script that's external to the dev environment. The problem
is heat keeps generating a popup error when it tries to scan certain files
and it pauses the entire script until you click ok, is there any way to
suppress this popup box either with heat or within the perl script I'm using
to run the build? 

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

Re: [WiX-users] Overide a file version to force upgrade

[Mike Dimmick]

I believe InstallShield lies in the Version column of the File table if this
option is set (setting it to something huge like 65535.65535.65535.65535,
which is the maximum supported value). I don't think this is a particularly
good idea, however. You can't do it with WiX - the linker takes the
information directly from the file's resources.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: 15 March 2007 16:21
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Overide a file version to force upgrade

 

On to an upgrade question-I have an installer that just installs a single
EXE right now, and I'd like to be able to create an upgrade path for it.
The trick is, I'd like to be able to have a package that will upgrade within
the same file version.  If I change only the package code (small upgrade),
and set the condition to upgrade minimum version 1.0.0.0 inclusive, the
upgrade still seems to run from the command line, but no files are actually
changed unless their versions have been modified (e.g. changing the exe's
version to 1.0.0.1 from 1.0.0.0).  I'd like to be able to leave the exe as
version 1.0.0.0, and then publish an installer that will replace the version
on the target machine.  In Installshield, I was able to do this by setting a
property that overrode the file version for upgrade checks-is there a way to
do the same in Wix?  All I want to do is update components where the version
is less than or equal to the version in the package-not just less than.
This comes up a lot in our development/QA builds.  

 

I'd also rather not mess with the version numbers by incorporating a build
number at the end (i.e. 1.0.0.X).  All four segments are meaningful to our
apps, and you can't seem to add a fifth, so we're sort of stuck.  

 

Any suggestions?

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

Re: [WiX-users] problem with exe COM server and heat

[Mike Dimmick]

Heat cannot handle COM server EXEs. You'll have to write the appropriate
registry entries yourself. See the , , , 
elements. You should strongly consider using non-advertised entries - see
Rob's blog entry at
http://robmensching.com/blog/archive/2007/03/12/RobMens-Recommendation-Do-no
t-advertise-COM-information-in-MSI.aspx.

 

If it's a C++ EXE, you should be able to work out what's needed from the
code. If it's a VB6 'ActiveX EXE' you'll need to find out the GUIDs it's
using, for which you can use OleView from the SDK.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: 15 March 2007 21:17
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] problem with exe COM server and heat

 

I'm working with an installer that registers an exe COM server, but the
catch is that the main application is .net.  This means that I have a COM
exe, a Proxy stub DLL, and an interop DLL to contend with.  I ran heat on
all three elements, and put the registry settings in the wix source.  After
I install though, the .net application can't create the COM component.  When
I manually run the exe with the /regserver flag after installing though,
everything works.  Is there something else I need to know about extracting
registry data using heat besides just running "heat.exe file filename -out
source.wxs" on the exe, proxy stub, and interop DLLs?  

 

Thanks again for all the help-I think I might be starting to get a handle on
at least bits of the framework :)

 

Chris

 

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

[WiX-users] CAB not being written to _Streams table

[Matt Coill]

Embeddding the cab:


Opening the msi with ORCA:
I see that the cab is listed as embedded in the media table -

DiskId

LastSequence

DiskPrompt

Cabinet

VolumeLabel

Source

i2

i4

L64

S255

S32

S72

Media

DiskId









1

7



#XUSB21.cab






The files that should be embedded in it are all the ones sequence of seven or 
less
File

Component_

FileName

FileSize

Version

Language

Attributes

Sequence

s72

s72

l255

i4

S72

S20

I2

i4

File

File













wdf_dll_x64

wdf_dll_x64

wdfx64.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

6

wdf_dll_x86

wdf_dll_x86

wdfx86.DLL|wdfcoinstaller01005.dll

1419232

1.5.6000.0

0

512

3

wdf_update_x64

wdf_update_x64

wdfupx64.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

7

wdf_update_x86

wdf_update_x86

wdfupx86.DLL|WUDFUpdate_01005.dll

831096

6.0.6000.16386

1033

512

4

xusb21_inf

xusb21_inf

xusb21.inf

8400





512

1

xusb21_sys_x64

xusb21_sys_x64

xusb21.sys

347904

6.0.6000.16386

1033

512

5

xusb21_sys_x86

xusb21_sys_x86

xusb21.sys

284544

6.0.6000.16386

1033

512

2


But there is no _Streams table and the file size is only 70K which is 
essentially the same size as without compression.

Does WIX2.0 not support this, or am I missing something?

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

Re: [WiX-users] How to create folders and shortcuts in the Start Menu? (Wix 3.0)

[Mike Dimmick]

An advertised shortcut is one which actually invokes Windows Installer when
activated. If the product feature that the shortcut points to is not
installed at that point, Windows Installer will install it, then invoke the
feature. This is how the 'install on demand' and 'advertised product'
features work.

If you've never worked on a Windows domain, I should say that it's possible
to configure products in Active Directory Group Policy so that the shortcuts
appear on a user's start menu (or elsewhere), but the product itself is not
installed until the user clicks one of these shortcuts. This is referred to
as an advertised product.

The  required by the ICE error is there to tidy up folders
containing advertised shortcuts when an advertised product is removed from
Group Policy by an administrator. I think. This isn't too clear.

There are many entry points that can be advertised, such as ProgIDs,
Extensions, TypeLibs and COM classes. However, it's generally not
recommended to advertise COM classes or type libraries, though, as this can
have a surprising effect for the end user (see Rob's blog at
http://robmensching.com/blog/archive/2007/03/12/RobMens-Recommendation-Do-no
t-advertise-COM-information-in-MSI.aspx)

The target of an advertised shortcut is the key file of the component it
belongs to. If your component has multiple files, you may need to specify
the @KeyPath attribute on the file you want the shortcut to launch. Best
practice is one file per component.

ALLUSERS=1 creates a per-machine, not per-user, install. This means that
instead of placing shortcuts in the installing user's start menu, it places
them in \Documents and Settings\All Users\Start Menu. This means they appear
for all users. However, in a shared-computer (hot-desking) scenario, an
administrator might want to only advertise the product to some users and not
others; your install should ideally work in this scenario and therefore
support per-user installs. The validation does not process ALLUSERS=1.

The WiX tutorial at http://www.tramontana.co.hu/wix/ has working shortcuts,
but they're not advertised. The syntax is currently correct for WiX 2.0 but
wixcop should be able to translate it.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DE
Sent: 15 March 2007 23:56
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to create folders and shortcuts in the Start
Menu? (Wix 3.0)


I'd just like to ask some questions relating to this area, because I cannot
find much meaningful documentation about it.
All we want to do is create shortcuts to some of the files we are
installaing. We are using the latest Votive. Assume we are happy to install
to all users.

1) What exactly does it mean to "advertise" a short cut? 

2) Using "advertised shortcuts" and the  tip you made earlier,
we have managed to create a shortcut that is visible within a sub directory
of Start Menu. But it doesn't actually link correctly; on inspection the
target name is set to the name of the product. Why is this?

3) Should I set ALLUSERS = 1 as well? How does it manifest? Would it effect
the previous point? From what I cans see, the ICE errors are not fixed by
ALLUSERS=1.

4) Are icons required to get the Start menu shortcut working correctly?

5) Does there exist a working example in Wix 3.0? Should we perhaps not be
using Wix 3.0?








Levi Wilson wrote:
> 
> Someone correct me if I'm wrong, but I think that if you want the shortcut
> installed for All Users, you need to define this property:
> 
> 
> 
> If you don't, inside that  you can have this:
> 
>  On="uninstall"
> />
> 
> On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:
>>
>>
>> Yes, the installation runs fine but doesn't create the folders in the
>> Start
>> Menu at all. I manage now to change the source to the following:
>>
>> > Source="$(var.TrunkComponentRelease)\Dot Net SDK Release Notes.doc" >
>> > Directory="ProgramMenuFolder1"
>> LongName="NewShortcut3" Name="NewShort"  Advertise="yes" Show="normal"/>
>> 
>>   
>> 
>>   
>> 
>>
>> but I received the following error:
>>
>> Error   17  ICE64: The directory ProgramMenuFolder1 is in the user
>> profile but
>> is not listed in the RemoveFile table.
>> D:\BlackDeath\SuperSolution\WixDotNetSDK\WixDotNetSDKRelease.wxs   
>> 240
>> 1
>> WixDotNetSDKRelease
>>
>>
>> Thanks,
>> Erich.
>>
>>
>> Levi Wilson wrote:
>> >
>> > What didn't work?  Can you post your WiX fragment for us to look
>> at?  Only
>> > the portion of the wxs file that has the shortcut that you're trying to
>> > create.  Did the installation go through, but your start menu folder
>> not
>> > get
>> > created?  What happened?
>> >
>> > On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> Hi Levi,
>> >> I tried the example you included, but it didn't work in Wix 3.0. Could
>> >> you
>> >> provide me a whole example please?
>> >>
>> >>

[WiX-users] DSL Designers

[Clint Chapman]

Has anyone considered using DSL designers as an interface for creating wix 
installers?  On the surface, it seems like a good fit.

Thanks,
ClintBEGIN:VCARD
VERSION:2.1
N:Chapman;Clint
FN:Clint Chapman
ORG:Luminos Industries
TITLE:Software Developer
TEL;WORK;VOICE:(613) 225-7661
TEL;WORK;FAX:(613) 225-3391
ADR;WORK:;;8-58 Antares Drive;Ottawa;Otario;K2E 7W6;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:8-58 Antares Drive=0D=0AOttawa, Otario K2E 7W6=0D=0ACanada
URL;WORK:http://www.luminosindustries.com
EMAIL;INTERNET:[EMAIL PROTECTED]
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20070316T201804Z
END:VCARD
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Intercepting SQL errors and displaying custom error

[Don Tasanasanta]

Ok maybe I don't understand .wxl files that well... 

 

I found the identifier in the error table, created a .wxl file and used
light with a -loc to my wxl file and a reference to my rsp file. 

 

When all was said and done I checked the error table but the error
identifier I tried to replace wasn't changed. 

 

Here is my wxl file:

 

 



   1033

   la la la la la



 

I'm trying to replace the string 26201 in the error table.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta
Sent: Thursday, March 15, 2007 5:35 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Intercepting SQL errors and displaying custom
error

 

I think I understand the use of .wxl files and I've found the sql errors
within the sca.wixlib.

 

How do I identify the sql errors within my personal .wxl? Do I simply
copy from  to  of the sql errors into
my own .wxl, substitute my own error msgs, and then link it?

 

Is it that easy?

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 4:46 PM
To: Don Tasanasanta; wix-users@lists.sourceforge.net
Subject: RE: Intercepting SQL errors and displaying custom error

 

Yes.  Provide a .wxl file for the localization identifiers defined the
.wixlib.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Don
Tasanasanta
Sent: Wednesday, March 14, 2007 3:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intercepting SQL errors and displaying custom error

 

Is there a way to intercept SQL install errors and display my own custom
error(s)? 

 

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

Re: [WiX-users] Consensus about CRT/MCF merge modules?

[Mike Dimmick]

However, with static linking you have the servicing problem - if there's a
security issue in the CRT (not unknown) or in MFC, you will have to rebuild
your application to pick up the fix, then rerelease your application. By
contrast, if using the WinSxS versions, Microsoft can ship an update
directly to end-users (either as an updated assembly with the same version
number, but different file version number, or as an additional assembly with
a newer version number plus a policy binding).

 

I have to admit looking at how the VS2005 CRT merge modules work and being a
bit confused as to why they're configured to do something different on Vista
(not just using MsiAssembly/MsiAssemblyName tables) especially as they were
released over a year before Vista was.

 

Using a private copy of the DLLs in your application directory is also a
possibility but I don't think this is recommended (or even permitted?) for a
final distribution. It still has the servicing problem but not the problem
of having to rebuild the application or having the large binaries.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: 16 March 2007 16:35
To: Chris Bardon; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Consensus about CRT/MCF merge modules?

 

I'm not quite yet ready to make this a "recommendation" but I'm currently
leaning towards statically linking the libraries directly.  I'm seeing hints
that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some
seriously bad repercussions when it comes to patching and some possibly
strange behavior on Vista.  It's a research project I'm doing slowly.

 

For the WiX toolset, we statically link to the CRT (MFC, haven't done that
since I wrote Orca ) to minimize our dependencies on the machine.
That makes the binaries a bit bigger but it is worth it to not have to worry
about "Is the WinSxS store updated at X point in time in my install?"

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: Friday, March 16, 2007 9:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Consensus about CRT/MCF merge modules?

 

Looking through the archives, there appear to be a couple of ways to include
things like the CRT and MFC redistributables in an installer.  Some have
advocated including the DLLs directly, which seems to go against the concept
of having a redistributable MSM to link against.  I tried building with the
Microsoft CRT msm that comes with VS 2005, and got a long list of warnings
from light.  

 

Is there a "recommended" method for dealing with these kinds of
dependencies?  

 

Chris

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

Re: [WiX-users] C# .dll

[Rob Mensching]

More importantly, the Windows Installer doesn't support it today.  There are 
actually "neat" problems you can introduce by loading the .NET Framework into 
the Windows Installer process.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson
Sent: Friday, March 16, 2007 10:40 AM
To: Dhaval Patel
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# .dll

I don't know for certain, but my guess would be that there's no guarantee that 
the .NET Framework has been installed on the client.
On 3/16/07, Dhaval Patel <[EMAIL PROTECTED]> wrote:
Will WIX 3.0 be adding the capability to call C# .dll files? If not, WHY? :)

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

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

Re: [WiX-users] C# .dll

[Levi Wilson]

I don't know for certain, but my guess would be that there's no guarantee
that the .NET Framework has been installed on the client.

On 3/16/07, Dhaval Patel <[EMAIL PROTECTED]> wrote:


Will WIX 3.0 be adding the capability to call C# .dll files? If not,
WHY? :)

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


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

[WiX-users] C# .dll

[Dhaval Patel]

Will WIX 3.0 be adding the capability to call C# .dll files? If not,
WHY? :)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module references in other Merge Modules

[Rob Mensching]

Are you shipping these Merge Modules to customers?  If not, I would highly 
recommend moving to .wixlibs to share the logic across your Products.

If you are shipping to customers and need the dependency between Merge Modules, 
check out the Dependency element.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rory Clark
Sent: Friday, March 16, 2007 9:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Merge Module references in other Merge Modules

Does someone have a sample of a merge module referencing another merge module?

Specifically, we have a merge module that contains a DLL for custom actions.  I 
did not see anything like this on the WiX tutorial site.  Of course, I may have 
missed it.

Thanks!
Rory

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

[WiX-users] Merge Module references in other Merge Modules

[Rory Clark]

Does someone have a sample of a merge module referencing another merge
module?
 
Specifically, we have a merge module that contains a DLL for custom
actions.  I did not see anything like this on the WiX tutorial site.  Of
course, I may have missed it.
 
Thanks!
Rory
 
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Consensus about CRT/MCF merge modules?

[Rob Mensching]

I'm not quite yet ready to make this a "recommendation" but I'm currently 
leaning towards statically linking the libraries directly.  I'm seeing hints 
that the WinSxS/Fusion stuff they did for these libraries in VS2005 has some 
seriously bad repercussions when it comes to patching and some possibly strange 
behavior on Vista.  It's a research project I'm doing slowly...

For the WiX toolset, we statically link to the CRT (MFC, haven't done that 
since I wrote Orca ) to minimize our dependencies on the machine.  That 
makes the binaries a bit bigger but it is worth it to not have to worry about 
"Is the WinSxS store updated at X point in time in my install?"

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: Friday, March 16, 2007 9:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Consensus about CRT/MCF merge modules?

Looking through the archives, there appear to be a couple of ways to include 
things like the CRT and MFC redistributables in an installer.  Some have 
advocated including the DLLs directly, which seems to go against the concept of 
having a redistributable MSM to link against.  I tried building with the 
Microsoft CRT msm that comes with VS 2005, and got a long list of warnings from 
light.

Is there a "recommended" method for dealing with these kinds of dependencies?

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

Re: [WiX-users] pass variable during compile time

[cosmo51]

Richard,
That was exactly the problem.  Thank you for your help.
Shayla
-- Original message -- 
From: <[EMAIL PROTECTED]> 

Shayla,
 
An example from our own build process is as follows:
 
Candle  -dMajorRev=1 -dMinorRev=2 -dPatchRev=3 –dBuildRev=4
 
Within the script, we use (for example)
 

 
I’m not sure if you are actually including the ( and ) characters in the 
command line. If so, that’s where you’re going wrong since they would then need 
to be referenced as $(var.(assemblyVersion)) etc.
 
I should probably also mention that we are using WiX v2, because we are 
currently shipping the product and the official word is that WiX v3 should not 
be used for externally shipping installations at this time. If you are using 
WiX V3 you may find the syntax has changed.
 
Hope this helps,
Regards,
Richard
 
P.S. you can also find an example of preprocessor variable usage in the WiX 
tutorial – see http://www.tramontana.co.hu/wix/lesson9.php
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 16, 2007 11:17 AM
To: Foster, Richard - PAL
Subject: RE: [WiX-users] pass variable during compile time
 
Thank you for your reply.  I added -d(assemblyVersion)=(1.0.42.0) to the candle 
command line but how do I access the varible inside the wix project?  I have 
tries $(var.assemblyVersion).  But this doesn't seem to work.  I have tried 
searching everywhere for an example, but I have had no luck.
TIA,
Shayla
 



* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or 
entity to whom it is addressed. If you have received this communication in 
error, be aware that forwarding it, copying it, or in any way disclosing its 
content to any other person, is strictly prohibited. Peek Traffic Corporation 
is neither liable for the contents, nor for the proper, complete and timely 
transmission of (the information contained in) this communication. If you have 
received this communication in error, please notify the author by replying to 
this e-mail immediately and delete the material from any computer.-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Installer 4.0 msi schema

[Rob Mensching]

There is an easier way.  Go look at wix\src\wix\Data\tables.xml.  That's the 
Windows Installer schema in a format WiX can quickly digest.

From: Thomas Svare [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 5:25 AM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: Re: [WiX-users] Windows Installer 4.0 msi schema

Hello,

Mostly for informational/research purposes.  I know it's documented but I'd 
like to get a look at things.

Thanks,
Tom


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:48 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: Re: [WiX-users] Windows Installer 4.0 msi schema

Why do you want all MSI tables?  EnsureTable will get the table you specify.  
It isn't intended to add all tables though.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Thursday, March 15, 2007 2:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

Hello,

I looked at the command line options and I hope I didn't overlook the 
obvious.

Is there a way to have Wix create an msi with all the tables in the schema even 
though they may be empty?

Thanks,
Tom


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 14, 2007 5:09 PM
To: Mike Dimmick; Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Windows Installer 4.0 msi schema

Although, if it is a standard MSI table you shouldn't need CustomTable at all 
(if you do, it's a bug in the WiX toolset ).

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick
Sent: Wednesday, March 14, 2007 2:48 PM
To: 'Thomas Svare'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

The PatchCertificates element is supported in WiX v3.0, which generates 
MsiPatchCertificate table entries.

If you need a table that isn't supported by WiX, you can use the  
element.

--
Mike Dimmick


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: 14 March 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.0 msi schema

Hello,

I'm not sure if I'm phrasing this correctly but I'll throw it out there 
anyway...

Is there any way with Wix to pick up new tables in the Windows Installer 4.0 
msi schema?  I'm particularly interested in the MSIPatchCertificate table.

Thanks,
Tom

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

[WiX-users] Consensus about CRT/MCF merge modules?

[Chris Bardon]

Looking through the archives, there appear to be a couple of ways to
include things like the CRT and MFC redistributables in an installer.
Some have advocated including the DLLs directly, which seems to go
against the concept of having a redistributable MSM to link against.  I
tried building with the Microsoft CRT msm that comes with VS 2005, and
got a long list of warnings from light.  
 
Is there a "recommended" method for dealing with these kinds of
dependencies?  
 
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] pass variable during compile time

[Richard.Foster]

Shayla,

 

An example from our own build process is as follows:

 

Candle  -dMajorRev=1 -dMinorRev=2 -dPatchRev=3
-dBuildRev=4

 

Within the script, we use (for example)

 



 

I'm not sure if you are actually including the ( and ) characters in the
command line. If so, that's where you're going wrong since they would
then need to be referenced as $(var.(assemblyVersion)) etc.

 

I should probably also mention that we are using WiX v2, because we are
currently shipping the product and the official word is that WiX v3
should not be used for externally shipping installations at this time.
If you are using WiX V3 you may find the syntax has changed.

 

Hope this helps,

Regards,

Richard

 

P.S. you can also find an example of preprocessor variable usage in the
WiX tutorial - see http://www.tramontana.co.hu/wix/lesson9.php

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 16, 2007 11:17 AM
To: Foster, Richard - PAL
Subject: RE: [WiX-users] pass variable during compile time

 

Thank you for your reply.  I added -d(assemblyVersion)=(1.0.42.0) to the
candle command line but how do I access the varible inside the wix
project?  I have tries $(var.assemblyVersion).  But this doesn't seem to
work.  I have tried searching everywhere for an example, but I have had
no luck.

TIA,

Shayla

 




* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or 
entity to whom it is addressed. If you have received this communication in 
error, be aware that forwarding it, copying it, or in any way disclosing its 
content to any other person, is strictly prohibited. Peek Traffic Corporation 
is neither liable for the contents, nor for the proper, complete and timely 
transmission of (the information contained in) this communication. If you have 
received this communication in error, please notify the author by replying to 
this e-mail immediately and delete the material from any computer.


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

Re: [WiX-users] pass variable during compile time

[Richard.Foster]

[Oops... resending to the list so it is present for future reference.]

 

Use the command line parameter -d=

 

For this and other helpful information on available options run the
appropriate tool (e.g. candle, or light) with the "-?" command line
option.

 

Regards,

Richard



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 9:43 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] pass variable during compile time

 

How can I pass a variable to the wix project during compile time? 

TIA

Shayla




* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or 
entity to whom it is addressed. If you have received this communication in 
error, be aware that forwarding it, copying it, or in any way disclosing its 
content to any other person, is strictly prohibited. Peek Traffic Corporation 
is neither liable for the contents, nor for the proper, complete and timely 
transmission of (the information contained in) this communication. If you have 
received this communication in error, please notify the author by replying to 
this e-mail immediately and delete the material from any computer.


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

[WiX-users] pass variable during compile time

[cosmo51]

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

Re: [WiX-users] verify file existance custom action

[Chris.Rowland]

Thanks Levi, I'll give that a shot as soon as I get access to my
development box back.

 



From: Levi Wilson [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 16, 2007 8:56 AM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action

 

Sorry, prematurely sent it.  Here is what I was getting at:

extern "C" UINT __stdcall LocateFile(MSIHANDLE hInstall)
{
  char* pDirPath = NULL;
  DWORD dw = 0;
  if( ERROR_MORE_DATA!=MsiGetProperty(hInstall,"MYFOLDER",NULL,&dw) ) 
return ERROR_INSTALL_FAILURE;

  dw += strlen("requiredfile.txt") + 1 /* term. NULL */;
  pDirPath = new char[dw];
  pDirPath[0] = '\0';
   
  if( ERROR_SUCCESS!=MsiGetProperty(hInstall,"MYFOLDER",pDirPath,&dw) )
{ 
delete[] pDirPath;
return ERROR_INSTALL_FAILURE;
  }

  _ASSERTE( 0!=strlen(pDirPath) );

  if( PathFileExists(pDirPath) ) {
MsiSetProperty(hInstall,"MYFILEEXISTS",pDirPath);  // Dr. Evil
assumption 
  }

  delete[] pDirPath;
  return ERROR_SUCCESS;
}

I believe that something like this would work.



On 3/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

If I look at the log after a completed installation, I can see the
following property values.

 

Property(S): MYFOLDER = C:\FTP\#This is the folder I
selected in the dialog

...

Property(S): MYFILEEXISTS = C:\requiredfile.txt  #this is
where the file was found (MYFOLDER was initialized to 'c:\')

 

So MYFOLDER did get set, but it seems to happen after the directory
search took place.  Would it be possible to have AppSearch happen
sometime in the UI sequence, or would that break something else?  It
looks like by default It happens very early on.

 

 



From: Levi Wilson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 4:36 PM


To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action

 

Hmmm, I've never used a directory search like that.  So you're saying
that your MYFOLDER property isn't getting set when the directory search
is performed?  I think you probably will need to maybe use a custom
action then since I don't think you can dynamically manipulate a
directory search, or tell it when to perform it as I think file searches
get executed during the AppSearch sequence?  I could be wrong, but I
don't think you can use the FileSearch like this. 

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

That actually looks like exactly what I want... much cleaner than my C++
hackjob.

 

 

That gives me a followup question, however.  I plugged your suggestion
(with Depth="0") into my dialog I use to browse to the directory that
contains the file.

It appears that the property I'm trying to set to the browsed-to
directory doesn't contain the browsed-to directory when the
DirectorySearch is performed.

 

  





   





 

  

  NOT
MYFILEEXISTS

  MYFILEEXISTS



 

 

I initialized MYFOLDER with 

This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)

It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )

 

Thanks for the help so far, this feels like a much better way than what
I was previously attempting.



From: Levi Wilson [mailto: [EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 3:50 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action

 

Can you post your CA C++ code?  Also, you don't need to have a DLL
custom action to check for the existence of a file.  You can do
something like this in your WiX source:

 
  

   



If the file has been found, then the MyFileExists property will be set
to the full path of your file.  Is this what you're looking for?

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

I read that "managed code" in a custom action is a no-no (please forgive
me if I use the wrong terminology) so I am attempting to write my custom
action without using managed code.  Most examples I find seem to use it,
however, so I'm doing the best I can.

 

I wrote a simple VC++ app (.exe) that will determine if some files
exist.  I probably did it badly, but it worked in that context. 

I took the same code, and cut& paste into a VC++ file I had setup to
create my dll.

The code was previously a working snippet that would simply set a msi
property to "true" and return ERROR_SUCCESS.

I am now trying to make it do something useful.

 

After the cut& paste I got some build errors and followed (somewhat) the
steps listed here to resolve them.
http://support.microsoft.com/?kbid=814472 

The dll built successfully, but when I run the installer I ge

Re: [WiX-users] verify file existance custom action

[Levi Wilson]

Sorry, prematurely sent it.  Here is what I was getting at:

extern "C" UINT __stdcall LocateFile(MSIHANDLE hInstall)
{
 char* pDirPath = NULL;
 DWORD dw = 0;
 if( ERROR_MORE_DATA!=MsiGetProperty(hInstall,"MYFOLDER",NULL,&dw) )
   return ERROR_INSTALL_FAILURE;

 dw += strlen("requiredfile.txt") + 1 /* term. NULL */;
 pDirPath = new char[dw];
 pDirPath[0] = '\0';

 if( ERROR_SUCCESS!=MsiGetProperty(hInstall,"MYFOLDER",pDirPath,&dw) ) {
   delete[] pDirPath;
   return ERROR_INSTALL_FAILURE;
 }

 _ASSERTE( 0!=strlen(pDirPath) );

 if( PathFileExists(pDirPath) ) {
   MsiSetProperty(hInstall,"MYFILEEXISTS",pDirPath);  // Dr. Evil
assumption
 }

 delete[] pDirPath;
 return ERROR_SUCCESS;
}

I believe that something like this would work.


On 3/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


 If I look at the log after a completed installation, I can see the
following property values.



Property(S): MYFOLDER = C:\FTP\#This is the folder I selected
in the dialog

…

Property(S): MYFILEEXISTS = C:\requiredfile.txt  #this is
where the file was found (MYFOLDER was initialized to 'c:\')



So MYFOLDER did get set, but it seems to happen after the directory search
took place.  Would it be possible to have AppSearch happen sometime in the
UI sequence, or would that break something else?  It looks like by default
It happens very early on.




 --

*From:* Levi Wilson [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 4:36 PM
*To:* Rowland, Chris
*Cc:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] verify file existance custom action



Hmmm, I've never used a directory search like that.  So you're saying that
your MYFOLDER property isn't getting set when the directory search is
performed?  I think you probably *will* need to maybe use a custom action
then since I don't think you can dynamically manipulate a directory search,
or tell it when to perform it as I think file searches get executed during
the AppSearch sequence?  I could be wrong, but I don't think you can use the
FileSearch like this.

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

That actually looks like exactly what I want… much cleaner than my C++
hackjob.





That gives me a followup question, however.  I plugged your suggestion
(with Depth="0") into my dialog I use to browse to the directory that
contains the file.

It appears that the property I'm trying to set to the browsed-to directory
doesn't contain the browsed-to directory when the DirectorySearch is
performed.



  





  







  

  NOT
MYFILEEXISTS

  MYFILEEXISTS







I initialized MYFOLDER with 

This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)

It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )



Thanks for the help so far, this feels like a much better way than what I
was previously attempting.
 --

*From:* Levi Wilson [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 3:50 PM
*To:* Rowland, Chris
*Cc:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] verify file existance custom action



Can you post your CA C++ code?  Also, you don't need to have a DLL custom
action to check for the existence of a file.  You can do something like this
in your WiX source:


  

  



If the file has been found, then the MyFileExists property will be set to
the full path of your file.  Is this what you're looking for?

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

I read that "managed code" in a custom action is a no-no (please forgive
me if I use the wrong terminology) so I am attempting to write my custom
action without using managed code.  Most examples I find seem to use it,
however, so I'm doing the best I can.



I wrote a simple VC++ app (.exe) that will determine if some files exist.
I probably did it badly, but it worked in that context.

I took the same code, and cut& paste into a VC++ file I had setup to
create my dll.

The code was previously a working snippet that would simply set a msi
property to "true" and return ERROR_SUCCESS.

I am now trying to make it do something useful.



After the cut& paste I got some build errors and followed (somewhat) the
steps listed here to resolve them. http://support.microsoft.com/?kbid=814472


The dll built successfully, but when I run the installer I get error 2896,
"Executing action [2] failed."  That doesn't tell me too much.



I stepped backwards until I had one line that I could comment/uncomment to
make the dll work(return "true")/not work(error 2896)



The one line that causes it to fail (and concequently causes the dll to
double in size) is:



ifstream fin1(filename);



Down the road I was doing 'if (fin1.good())' to see i

Re: [WiX-users] verify file existance custom action

[Levi Wilson]

Yeah, that's what I was trying to say.  I believe this happens in the
AppSearch sequence.  You probably will need to use a CA for this to happen.
I can try to help you with this as well, but it might look something like
the following:

extern "C" UINT __stdcall LocateFile(MSIHANDLE hInstall)
{
 char* pDirPath = NULL;

}


On 3/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


 If I look at the log after a completed installation, I can see the
following property values.



Property(S): MYFOLDER = C:\FTP\#This is the folder I selected
in the dialog

…

Property(S): MYFILEEXISTS = C:\requiredfile.txt  #this is
where the file was found (MYFOLDER was initialized to 'c:\')



So MYFOLDER did get set, but it seems to happen after the directory search
took place.  Would it be possible to have AppSearch happen sometime in the
UI sequence, or would that break something else?  It looks like by default
It happens very early on.




 --

*From:* Levi Wilson [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 4:36 PM
*To:* Rowland, Chris
*Cc:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] verify file existance custom action



Hmmm, I've never used a directory search like that.  So you're saying that
your MYFOLDER property isn't getting set when the directory search is
performed?  I think you probably *will* need to maybe use a custom action
then since I don't think you can dynamically manipulate a directory search,
or tell it when to perform it as I think file searches get executed during
the AppSearch sequence?  I could be wrong, but I don't think you can use the
FileSearch like this.

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

That actually looks like exactly what I want… much cleaner than my C++
hackjob.





That gives me a followup question, however.  I plugged your suggestion
(with Depth="0") into my dialog I use to browse to the directory that
contains the file.

It appears that the property I'm trying to set to the browsed-to directory
doesn't contain the browsed-to directory when the DirectorySearch is
performed.



  





  







  

  NOT
MYFILEEXISTS

  MYFILEEXISTS







I initialized MYFOLDER with 

This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)

It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )



Thanks for the help so far, this feels like a much better way than what I
was previously attempting.
 --

*From:* Levi Wilson [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 3:50 PM
*To:* Rowland, Chris
*Cc:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] verify file existance custom action



Can you post your CA C++ code?  Also, you don't need to have a DLL custom
action to check for the existence of a file.  You can do something like this
in your WiX source:


  

  



If the file has been found, then the MyFileExists property will be set to
the full path of your file.  Is this what you're looking for?

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

I read that "managed code" in a custom action is a no-no (please forgive
me if I use the wrong terminology) so I am attempting to write my custom
action without using managed code.  Most examples I find seem to use it,
however, so I'm doing the best I can.



I wrote a simple VC++ app (.exe) that will determine if some files exist.
I probably did it badly, but it worked in that context.

I took the same code, and cut& paste into a VC++ file I had setup to
create my dll.

The code was previously a working snippet that would simply set a msi
property to "true" and return ERROR_SUCCESS.

I am now trying to make it do something useful.



After the cut& paste I got some build errors and followed (somewhat) the
steps listed here to resolve them. http://support.microsoft.com/?kbid=814472


The dll built successfully, but when I run the installer I get error 2896,
"Executing action [2] failed."  That doesn't tell me too much.



I stepped backwards until I had one line that I could comment/uncomment to
make the dll work(return "true")/not work(error 2896)



The one line that causes it to fail (and concequently causes the dll to
double in size) is:



ifstream fin1(filename);



Down the road I was doing 'if (fin1.good())' to see if the file exists
(like I said, probably a bad way, but it was the first thing I did that
seemed to work)



Is attempting to do this fundamentally wrong?

Also, I'm running the installer with /l* but I'm still not getting
anything particularly helpful.  Are there better techniques for debugging?






-
Take Surveys. Earn Cash. Influence the Fu

Re: [WiX-users] verify file existance custom action

[Chris.Rowland]

If I look at the log after a completed installation, I can see the
following property values.

 

Property(S): MYFOLDER = C:\FTP\#This is the folder I
selected in the dialog

...

Property(S): MYFILEEXISTS = C:\requiredfile.txt  #this is
where the file was found (MYFOLDER was initialized to 'c:\')

 

So MYFOLDER did get set, but it seems to happen after the directory
search took place.  Would it be possible to have AppSearch happen
sometime in the UI sequence, or would that break something else?  It
looks like by default It happens very early on.

 

 



From: Levi Wilson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 4:36 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action

 

Hmmm, I've never used a directory search like that.  So you're saying
that your MYFOLDER property isn't getting set when the directory search
is performed?  I think you probably will need to maybe use a custom
action then since I don't think you can dynamically manipulate a
directory search, or tell it when to perform it as I think file searches
get executed during the AppSearch sequence?  I could be wrong, but I
don't think you can use the FileSearch like this. 

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

That actually looks like exactly what I want... much cleaner than my C++
hackjob.

 

 

That gives me a followup question, however.  I plugged your suggestion
(with Depth="0") into my dialog I use to browse to the directory that
contains the file.

It appears that the property I'm trying to set to the browsed-to
directory doesn't contain the browsed-to directory when the
DirectorySearch is performed.

 

  





   





 

  

  NOT
MYFILEEXISTS

  MYFILEEXISTS



 

 

I initialized MYFOLDER with 

This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)

It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )

 

Thanks for the help so far, this feels like a much better way than what
I was previously attempting.



From: Levi Wilson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 3:50 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action

 

Can you post your CA C++ code?  Also, you don't need to have a DLL
custom action to check for the existence of a file.  You can do
something like this in your WiX source:

 
  

   



If the file has been found, then the MyFileExists property will be set
to the full path of your file.  Is this what you're looking for?

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

I read that "managed code" in a custom action is a no-no (please forgive
me if I use the wrong terminology) so I am attempting to write my custom
action without using managed code.  Most examples I find seem to use it,
however, so I'm doing the best I can.

 

I wrote a simple VC++ app (.exe) that will determine if some files
exist.  I probably did it badly, but it worked in that context. 

I took the same code, and cut& paste into a VC++ file I had setup to
create my dll.

The code was previously a working snippet that would simply set a msi
property to "true" and return ERROR_SUCCESS.

I am now trying to make it do something useful.

 

After the cut& paste I got some build errors and followed (somewhat) the
steps listed here to resolve them.
http://support.microsoft.com/?kbid=814472 

The dll built successfully, but when I run the installer I get error
2896, "Executing action [2] failed."  That doesn't tell me too much.

 

I stepped backwards until I had one line that I could comment/uncomment
to make the dll work(return "true")/not work(error 2896)

 

The one line that causes it to fail (and concequently causes the dll to
double in size) is:

 

ifstream fin1(filename);

 

Down the road I was doing 'if (fin1.good())' to see if the file exists
(like I said, probably a bad way, but it was the first thing I did that
seemed to work)

 

Is attempting to do this fundamentally wrong?

Also, I'm running the installer with /l* but I'm still not getting
anything particularly helpful.  Are there better techniques for
debugging?

 

 



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

Re: [WiX-users] How to create folders and shortcuts in the Start Menu? (Wix 3.0)

[Levi Wilson]

I've only been working with WiX for a little over a month, so I'll _try_ to
answer your questions to the best of my knowledge:

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



I'd just like to ask some questions relating to this area, because I
cannot
find much meaningful documentation about it.
All we want to do is create shortcuts to some of the files we are
installaing. We are using the latest Votive. Assume we are happy to
install
to all users.

1) What exactly does it mean to "advertise" a short cut?



I believe that you can have advertised, and non-advertised shortcuts.  What
this means I think is that you can potentially have a component that gets
added, but isn't necessarily installed but can be when someone clicks on the
shortcut.  This happens I believe in certain office installations where when
you click on the shortcut you get that Windows Installer message box
indicating that it is installing something.  I'm not 100% clear on when to
use or not use advertised shortcuts, but I typically have just been setting
Advertised="yes".

2) Using "advertised shortcuts" and the  tip you made earlier,

we have managed to create a shortcut that is visible within a sub
directory
of Start Menu. But it doesn't actually link correctly; on inspection the
target name is set to the name of the product. Why is this?



I think that I'd have to look at your wxs source for this shortcut to see if
something doesn't look correct.  If you want another example, you can look
in the WiX v3 src folder to see how the WiX install is setup using WiX.  I
believe it's in src\Setup.

3) Should I set ALLUSERS = 1 as well? How does it manifest? Would it effect

the previous point? From what I cans see, the ICE errors are not fixed by
ALLUSERS=1.



I  pretty much have always been setting ALLUSERS = 1.  From what I've read
in this newsgroup, it seems that it's pretty difficult to maintain a true
per-user installation, so I've opted for simplicity :-)  Adding this
property was just a guess, but you still may need to use the  element to rid yourself of them.

4) Are icons required to get the Start menu shortcut working correctly?


No.

5) Does there exist a working example in Wix 3.0? Should we perhaps not be

using Wix 3.0?



AFAIK, WiX 3.0 is a perfectly viable solution for MOST situations.  There
has been the occasional bug that has passed through the message board here
that just simply haven't been ported from v2 to v3 yet, but for most
situations v3.0 is perfectly fine.  I've been using it for all of my
installations and haven't ran into any issues.  There have been other
postings within the last month that discuss this very issue if you'd like to
check them out.

Levi Wilson wrote:

>
> Someone correct me if I'm wrong, but I think that if you want the
shortcut
> installed for All Users, you need to define this property:
>
> 
>
> If you don't, inside that  you can have this:
>
>  On="uninstall"
> />
>
> On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:
>>
>>
>> Yes, the installation runs fine but doesn't create the folders in the
>> Start
>> Menu at all. I manage now to change the source to the following:
>>
>> > Source="$(var.TrunkComponentRelease)\Dot Net SDK Release Notes.doc" >
>> > Directory="ProgramMenuFolder1"
>> LongName="NewShortcut3" Name="NewShort"  Advertise="yes"
Show="normal"/>
>> 
>>   
>> 
>>   
>> 
>>
>> but I received the following error:
>>
>> Error   17  ICE64: The directory ProgramMenuFolder1 is in the user
>> profile but
>> is not listed in the RemoveFile table.
>> D:\BlackDeath\SuperSolution\WixDotNetSDK\WixDotNetSDKRelease.wxs
>> 240
>> 1
>> WixDotNetSDKRelease
>>
>>
>> Thanks,
>> Erich.
>>
>>
>> Levi Wilson wrote:
>> >
>> > What didn't work?  Can you post your WiX fragment for us to look
>> at?  Only
>> > the portion of the wxs file that has the shortcut that you're trying
to
>> > create.  Did the installation go through, but your start menu folder
>> not
>> > get
>> > created?  What happened?
>> >
>> > On 3/15/07, Erich Buhler <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> Hi Levi,
>> >> I tried the example you included, but it didn't work in Wix 3.0.
Could
>> >> you
>> >> provide me a whole example please?
>> >>
>> >> Thanks,
>> >> Erich.
>> >>
>> >>
>> >> Levi Wilson wrote:
>> >> >
>> >> > There's this section:
>> >> >
>> >> > <*Component* Id='Manual'
>> Guid='YOURGUID-574D-4A9A-A266-5B5EC2C022A4'>
>> >> >   <*File* Id='Manual' Name='Manual.pdf' DiskId='1'
>> Source='Manual.pdf
>> '>
>> >> > <*Shortcut* Id="startmenuManual" Directory="ProgramMenuDir"
>> >> > Name="Manual" LongName="Instruction Manual" />
>> >> >   
>> >> > 
>> >> >
>> >> > And then there's the section that defines the "ProgramMenuDir":
>> >> >
>> >> > <*Directory* Id="ProgramMenuFolder" Name="PMenu"
>> LongName="Programs">
>> >> >   <*Directory* Id="ProgramMenuDir" Name='Foobar10'
LongName="Foobar
>> >> 1.0"
>> >> > />
>> >> > 
>> >> >
>> >> > The  definition 

Re: [WiX-users] Windows Installer 4.0 msi schema

[Thomas Svare]

Hello,

 

Mostly for informational/research purposes.  I know it's documented but
I'd like to get a look at things.

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 4:48 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: Re: [WiX-users] Windows Installer 4.0 msi schema

 

Why do you want all MSI tables?  EnsureTable will get the table you
specify.  It isn't intended to add all tables though.

 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 15, 2007 2:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I looked at the command line options and I hope I didn't overlook the
obvious.

 

Is there a way to have Wix create an msi with all the tables in the
schema even though they may be empty?

 

Thanks,

Tom

 



From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 5:09 PM
To: Mike Dimmick; Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Windows Installer 4.0 msi schema

 

Although, if it is a standard MSI table you shouldn't need CustomTable
at all (if you do, it's a bug in the WiX toolset ).

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Dimmick
Sent: Wednesday, March 14, 2007 2:48 PM
To: 'Thomas Svare'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Windows Installer 4.0 msi schema

 

The PatchCertificates element is supported in WiX v3.0, which generates
MsiPatchCertificate table entries.

 

If you need a table that isn't supported by WiX, you can use the
 element.

 

-- 

Mike Dimmick

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: 14 March 2007 21:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows Installer 4.0 msi schema

 

Hello,

 

I'm not sure if I'm phrasing this correctly but I'll throw it out there
anyway...

 

Is there any way with Wix to pick up new tables in the Windows Installer
4.0 msi schema?  I'm particularly interested in the MSIPatchCertificate
table.

 

Thanks,

Tom

 

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