date:20071206

Re: [WiX-users] Output Window bugs with latest versions of Wix?

2007-12-06 Thread Anthony Wieser

I couldn't find it in the bug database.

And it looks like you meant the Error List window in VS2005, not the Task Pane. 
 I can confirm that the messages show up in the Error List though, so thanks 
for the workaround.


Anthony Wieser
Wieser Software Ltd

- Original Message - 
From: "Justin Rockwood" <[EMAIL PROTECTED]>
To: "'Anthony Wieser'" <[EMAIL PROTECTED]>; 
Sent: Wednesday, December 05, 2007 4:24 PM
Subject: RE: [WiX-users] Output Window bugs with latest versions of Wix?


> This is a known bug and we're working on a fix. It's actually a bug in
> Visual Studio 2005 and not in our stuff, but we're working to get a fix for
> it. It works fine in Visual Studio 2008. Also, the task pane should show the
> errors in the correct format in both versions as a workaround.
> 
> Thanks,
> Justin
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser
> Sent: Wednesday, December 05, 2007 5:15 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Output Window bugs with latest versions of Wix?
> 
> Has the output format changed.  The latest versions of Wix I have
> (3.0.3530.0, and 3.0.3526.0, 3.0.3509.0, and 3.0,3502.0) aren't setting the
> output for error messages correctly in my copy of Visual Studio 2005.
> 


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Handling Feature Dependencies

2007-12-06 Thread John Hall

What version of WiX are you using? I found a bug with FeatureGroups
earlier in WiX 3
(https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1760155&gr
oup_id=105970
 ), which apparently has been fixed.
 
John


  _  

From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: 06 December 2007 06:21
To: [EMAIL PROTECTED]
Cc: John Hall; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Handling Feature Dependencies


[EMAIL PROTECTED] wrote: 

light.exe : error LGHT0204 : ICE03: Not a valid foreign
key; Table: FeatureCompo

nents, Column: Feature_, Key(s):
grpRequiredModules.uplevel.66332652_9C28_58B1_F

F1F_C8B3B9A1E18E


That looks like it's a combination of the feature group name and
components from the merge module. Sounds like a bug in the linker -- can
you file a bug on SF?


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

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re posting Condition for Silent Install

2007-12-06 Thread Stefan Pavlik

Hi Again...

You cannot use the INSTALLUILEVEL_NONE string in the WiX. It is
defined only in some C++ header file and you can use it in the C++
project.
You need to use the UILevel property. It means:


  UILevel=2


UILevel is name of property and 2 is value which means
INSTALLUILEVEL_NONE.

Regards

Stefan
SaiTeja wrote:
> Hi
> 
>  I want to execute some custom actions only in Silent Mode
> 
> For ex: Custaction1,Custaction2,Custaction3,Custaction4, etc
> When I run in Silent Mode Custaction1 and Custaction2,
> Custaction3,Custaction4 Should execute
> When I run in UI mode, only Custaction3, Custaction4 should execute
> 
> I tried in two ways.
> 
>  INSTALLUILEVEL_NONE
>   
>   For custom action:
> 
>   
>  SilentInstall
>   
> 
> and another way is (No Ppty)
> 
> 
>  INSTALLUILEVEL_NONE Action>
>  
> 
> But its not working fine.
> 
> It would be great if any one gave solution
> 
> 
> 
> SaiTeja wrote:
>> Hi Stefan,
>>
>> Thanks for you resp. Following is my sample code. Plz let me know the way
>> is correct or not
>>
>>  INSTALLUILEVEL_NONE
>>   
>> For custom action:
>>
>>   
>>  SilentInstall> Action>
>>   
>>
>>   
>>   > VBScriptCall='Hello' Return='check'/>
>>   
>>
>>
>> Thanks
>> Hi,
>>
>>
>>
>>
>>
>> Stefan Pavlik-2 wrote:
>>> Hi,...
>>>
>>> You should create the condition for the CustomAction based on the
>>> UILevel property: http://msdn2.microsoft.com/en-us/library/aa372096.aspx
>>>
>>>
>>> UILevel:
>>>
>>> NSTALLUILEVEL_NONE  2 Completely silent installation.
>>> INSTALLUILEVEL_BASIC3 Simple progress and error handling.
>>> INSTALLUILEVEL_REDUCED  4 Authored UI, wizard dialogs suppressed.
>>> INSTALLUILEVEL_FULL 5 Authored UI with wizards, progress, errors.
>>>
>>> Regards
>>>
>>> Stefan
>>>
>>> SaiTeja wrote:
 Hi,

 I want to execute particular custom action [OR] I want to execute some
 lines
 of my wix code only in silent mode.

 Any answers?



>>> -- 
>>> Stefan Pavlik | [EMAIL PROTECTED]
>>> Whitestein Technologies s.r.o. | www.whitestein.com
>>> Panenska 28 | 811 03 Bratislava | Slovak Republic
>>> Main +421 2 5443-5502 | Direct +421 2 5930-0735
>>>
>>> -
>>> SF.Net email is sponsored by: The Future of Linux Business White Paper
>>> from Novell.  From the desktop to the data center, Linux is going
>>> mainstream.  Let it simplify your IT future.
>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>
> 

-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies s.r.o. | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0735

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re posting Condition for Silent Install

2007-12-06 Thread SaiTeja


Hi Stefan,

Thanks a lot...

Its working now. Thanq so much



Stefan Pavlik-2 wrote:
> 
> Hi Again...
> 
> You cannot use the INSTALLUILEVEL_NONE string in the WiX. It is
> defined only in some C++ header file and you can use it in the C++
> project.
> You need to use the UILevel property. It means:
> 
> 
>   UILevel=2
> 
> 
> UILevel is name of property and 2 is value which means
> INSTALLUILEVEL_NONE.
> 
> Regards
> 
> Stefan
> SaiTeja wrote:
>> Hi
>> 
>>  I want to execute some custom actions only in Silent Mode
>> 
>> For ex: Custaction1,Custaction2,Custaction3,Custaction4, etc
>> When I run in Silent Mode Custaction1 and Custaction2,
>> Custaction3,Custaction4 Should execute
>> When I run in UI mode, only Custaction3, Custaction4 should execute
>> 
>> I tried in two ways.
>> 
>>  INSTALLUILEVEL_NONE
>>   
>>   For custom action:
>> 
>>   
>>  SilentInstall> Action>
>>   
>> 
>> and another way is (No Ppty)
>> 
>> 
>>  > Sequence='1200'>INSTALLUILEVEL_NONE> Action>
>>  
>> 
>> But its not working fine.
>> 
>> It would be great if any one gave solution
>> 
>> 
>> 
>> SaiTeja wrote:
>>> Hi Stefan,
>>>
>>> Thanks for you resp. Following is my sample code. Plz let me know the
>>> way
>>> is correct or not
>>>
>>>  INSTALLUILEVEL_NONE
>>>   
>>> For custom action:
>>>
>>>   
>>>  SilentInstall>> Action>
>>>   
>>>
>>>   
>>>   >> VBScriptCall='Hello' Return='check'/>
>>>   
>>>
>>>
>>> Thanks
>>> Hi,
>>>
>>>
>>>
>>>
>>>
>>> Stefan Pavlik-2 wrote:
 Hi,...

 You should create the condition for the CustomAction based on the
 UILevel property:
 http://msdn2.microsoft.com/en-us/library/aa372096.aspx


 UILevel:

 NSTALLUILEVEL_NONE 2 Completely silent installation.
 INSTALLUILEVEL_BASIC   3 Simple progress and error handling.
 INSTALLUILEVEL_REDUCED 4 Authored UI, wizard dialogs suppressed.
 INSTALLUILEVEL_FULL5 Authored UI with wizards, progress, errors.

 Regards

 Stefan

 SaiTeja wrote:
> Hi,
>
> I want to execute particular custom action [OR] I want to execute some
> lines
> of my wix code only in silent mode.
>
> Any answers?
>
>
>
 -- 
 Stefan Pavlik | [EMAIL PROTECTED]
 Whitestein Technologies s.r.o. | www.whitestein.com
 Panenska 28 | 811 03 Bratislava | Slovak Republic
 Main +421 2 5443-5502 | Direct +421 2 5930-0735

 -
 SF.Net email is sponsored by: The Future of Linux Business White Paper
 from Novell.  From the desktop to the data center, Linux is going
 mainstream.  Let it simplify your IT future.
 http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


>>>
>> 
> 
> -- 
> Stefan Pavlik | [EMAIL PROTECTED]
> Whitestein Technologies s.r.o. | www.whitestein.com
> Panenska 28 | 811 03 Bratislava | Slovak Republic
> Main +421 2 5443-5502 | Direct +421 2 5930-0735
> 
> -
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Condition-for-Silent-Install-tf4935094.html#a14189841
Sent from the wix-users mailing list archive at Nabble.com.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Condition Privileged not working

2007-12-06 Thread Gonzalo Diethelm

Hello everyone,

I need a Wix 2.0 package to be installed only by administrator users, so
I added the following as a child of the Product element:

  Privileged

Then I logged in as a non-administrator user in Windows XP  SP2 and ran
the installer. I never saw the "Admins only" message, and the
installation proceeded Ok to the end. Am I missing something?

Thanks and best regards,

-- 
Gonzalo Diethelm
[EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Votive on VS 2008?

2007-12-06 Thread Chris Bardon

Just out of curiosity, has anyone done a rebuild for the Votive plugin
to work with VS 2008?  I just installed the RTM this week, and I'm
looking to try moving some of my VS2005 projects up.  So far, anything
that includes a setup won't build.  

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Handling Feature Dependencies

2007-12-06 Thread Robert.Priest

That may be it. I am using 3.0.2925.0. I will upgrade to the latest
weekly release (looks like right now its 3.0.3530.0) , and try that. I
will let you know how it goes.

From: John Hall [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 06, 2007 5:16 AM
To: Robert Priest
Cc: wix-users@lists.sourceforge.net; Bob Arnson
Subject: RE: [WiX-users] Handling Feature Dependencies

What version of WiX are you using? I found a bug with FeatureGroups
earlier in WiX 3
(https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1760155&gr
oup_id=105970
 ), which apparently has been fixed.

John

From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: 06 December 2007 06:21
To: [EMAIL PROTECTED]
Cc: John Hall; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Handling Feature Dependencies

[EMAIL PROTECTED] wrote: 

light.exe : error LGHT0204 : ICE03: Not a valid foreign key;
Table: FeatureCompo

nents, Column: Feature_, Key(s):
grpRequiredModules.uplevel.66332652_9C28_58B1_F

F1F_C8B3B9A1E18E

That looks like it's a combination of the feature group name and
components from the merge module. Sounds like a bug in the linker -- can
you file a bug on SF?

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

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition Privileged not working

2007-12-06 Thread Stefan Pavlik

Hi...

I am using similar condition with WiX 2.0 for two years and it is
working OK.

You should check the verbose log of the installation.

msiexec.exe /i YourProduct.msi /l*v log_file.log

regards

Stefan

Gonzalo Diethelm wrote:
> Hello everyone,
> 
> I need a Wix 2.0 package to be installed only by administrator users, so
> I added the following as a child of the Product element:
> 
>   Privileged
> 
> Then I logged in as a non-administrator user in Windows XP  SP2 and ran
> the installer. I never saw the "Admins only" message, and the
> installation proceeded Ok to the end. Am I missing something?
> 
> Thanks and best regards,
> 
> 
> -- 
> Gonzalo Diethelm
> [EMAIL PROTECTED] 
> 
> 
> 
> 
> -
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> 
> 
> 
> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies s.r.o. | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0735

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Create Directory with name from Property

2007-12-06 Thread EricT-in-Ottawa


I'm trying to (using WiX V2) create a directory where the name is supplied
via CustomAction.  The customaction determines the name and creates a
property (I've also supplied the property on the msiexec command-line, same
diff).  But I don't know how to specify the LongName and Name fields of the
Directory (as well as a shortcut created on the desktop that should have the
same visible name as the property) so that the value is taken from the
property. 
I tried 
 
   
  
  
   

 but it actually creates a real folder called [LONGDIRECTORY], with square
brackets and all.  
If anybody could point me at how to specify a directory and Shortcut in the
way I need it, I'd be happy!
Thanks,
Eric T.
-- 
View this message in context: 
http://www.nabble.com/Create-Directory-with-name-from-Property-tf4957414.html#a14196967
Sent from the wix-users mailing list archive at Nabble.com.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Votive on VS 2008?

2007-12-06 Thread Richard

In article <[EMAIL PROTECTED]>,
"Chris Bardon" <[EMAIL PROTECTED]>  writes:

> Just out of curiosity, has anyone done a rebuild for the Votive plugin
> to work with VS 2008?  I just installed the RTM this week, and I'm
> looking to try moving some of my VS2005 projects up.  So far, anything
> that includes a setup won't build. =20

Are you trying the 2.0 or the 3.0?
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download

Legalize Adulthood! 

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Create Directory with name from Property

2007-12-06 Thread Richard

In article <[EMAIL PROTECTED]>,
EricT-in-Ottawa <[EMAIL PROTECTED]>  writes:

> I'm trying to (using WiX V2) create a directory where the name is supplied
> via CustomAction.  The customaction determines the name and creates a
> property [...]

The reason this doesn't work is that the column data type for the
Directory table isn't Formatted, so properties are not substituted
into the text that is generated for the filename.

You could write an immediate mode custom action that would update the
Directory table with the desired directory name after you've sanitized
the input to validate it as a long and short filename.  Then you
proceed normally and let Windows Installer create the directory with
the associated name.  This would be the most robust way to attack the
problem.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download

Legalize Adulthood! 

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Disabling the next button in a feature tree dialog when no features are selected

2007-12-06 Thread Robert.Priest

Hello everyone,

I know this has been covered before...

And I have read the posts at: 

http://www.nabble.com/Disabling-Next-if-no-features-selected-tf2333818.h
tml#a6493541
http://www.nabble.com/Disabling-the-next-button-in-a-feature-tree-dialog
-when-no-features-are-selected-tf2333648.html#a6492891


Bob Arson replies to the first one with:  "Summary: I don't think it's
possible. You'd certainly have to modify the dialog even if it were."


Well, I am using a  modified version of the CustomizeDlg.wxs file and it
is still not working...

If it doesn't work, then I guess I will have to accept that. But:

1.  Is it actually a Microsoft Bug or a Wix Bug? I have seen the
same thing in other installers (I tried a few others to test).

2.  Why does the Browse button and the Selection Path  properly
respond turning a feature  on and off?

3.  Why  when I de-select ALL features and go to Disk Usage (That
should probably turn off also), does it still report that space is
needed in the "Required " column.?

I even get a log entry of : MSI (c) (2C:54) [13:42:16:104]:
PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its
current value is '12330'. Its new value: '0'.





If you care to look, here are the conditions that I added to my Modified
CustomizeDlg:








-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] XmlFile cannot access network drive

2007-12-06 Thread Mendelson, Michael

> I am using Wix 3.0 for an installation to a network drive.  During the
> install an xml configuration file is put into the install directory,
> and then values are pushed in using XmlFile.  
> 
> This breaks during XmlFile when installing to a network drive, because
> of access issues.
> 
> The file is placed on the shared drive without a problem, but XmlFile
> fails when opening or editing the file.  The error seems to come from
> MSXML.  Here's what the log looks like:
> 
> Action start 10:25:25: InstallFinalize.
> MSI (s) (98:BC) [10:25:30:612]: Creating MSIHANDLE (60) of type 790536
> for thread 444
> MSI (s) (98!7C) [10:25:31:093]: Creating MSIHANDLE (61) of type 790531
> for thread 2684
> ExecXmlFile:  Error 0x80070005: failed to load XML file:
> \\machine1\transfer\Install\SetupConfig.xml
> MSI (s) (98!7C) [10:25:31:103]: Closing MSIHANDLE (61) of type 790531
> for thread 2684
> MSI (s) (98!7C) [10:25:31:103]: Creating MSIHANDLE (62) of type 790531
> for thread 2684
> MSI (s) (98!7C) [10:25:33:076]: Product: My Product Network Install --
> Error 25531. Failed to open XML file
> \\machine1\transfer\Install\SetupConfig.xml, system error: -2147024891
> MSI (s) (98!7C) [10:25:33:086]: Closing MSIHANDLE (62) of type 790531
> for thread 2684
> MSI (s) (98:7C) [10:25:33:116]: Closing MSIHANDLE (60) of type 790536
> for thread 444
> 
> Using the filemon.exe tool to dig into the problem, I found that the
> process is not run under the (administrative) user who started the
> process, but as the internal SYSTEM user.  This is causing an ACCESS
> DENIED error.
> 
> The question is how to get the configured file onto a network drive?
> 
> 
> My understanding is that XmlFile is a "stock" custom action.  I could
> use XmlFile to edit the file locally and then push it out to the
> network drive using another custom action - but if all custom actions
> run under the SYSTEM user, this would not work either
> 
> Thanks, anyone!
> 
> Michael


The information contained in this message is intended only for the recipient, 
and may be a confidential attorney-client communication or may otherwise be 
privileged and confidential and protected from disclosure. If the reader of 
this message is not the intended recipient, or an employee or agent responsible 
for delivering this message to the intended recipient, please be aware that any 
dissemination or copying of this communication is strictly prohibited. If you 
have received this communication in error, please immediately notify us by 
replying to the message and deleting it from your computer.  The McGraw-Hill 
Companies, Inc. reserves the right, subject to applicable local law, to monitor 
and review the content of any electronic message or information sent to or from 
McGraw-Hill employee e-mail addresses without informing the sender or recipient 
of the message.

-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Multiple cab files per media element (disk)

2007-12-06 Thread Craig Miller

How can I specify that several cab files should be placed on a single media
element?  

I am receiving an error:  

light.exe : fatal error LGHT0017 : Failed to create cab
'C:\Users\Craig\AppData\Local\Temp\v_zodjcx\AZ2.cab' while cabbing file
'..\USGS Topographic\24\AZ\o33110G7.tif' with error 0x80004005.

I have nearly an entire DVDs worth of data that I want to put on a single
DVD.  Right now I'm placing all of my files into a single cab file, but I
appear to be hitting a cabinet (*.cab) filesize limitation.  I am assuming
that I need to split my files across multiple cab files that all get placed
on a single DVD.

Is this the correct solution, and if so, how do I specify a media element
that contains more than one cab file?

These are my media entries.  The files in question are going on
TOPO_AZ_DISK2.





Thanks for the help.


---
http://www.overlandnavigator.com
Touchscreen Friendly GPS Mapping 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.16.15/1174 - Release Date: 12/6/2007
10:11 AM
 


-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Condition Privileged not working

2007-12-06 Thread Gonzalo Diethelm

This was happening due to some weird interaction between ALLUSERS and
all version of the app already installed. It is working now. Thanks a
lot.

On Thu, 2007-12-06 at 15:59 +0100, Stefan Pavlik wrote:

> Hi...
> 
> I am using similar condition with WiX 2.0 for two years and it is
> working OK.
> 
> You should check the verbose log of the installation.
> 
> msiexec.exe /i YourProduct.msi /l*v log_file.log
> 
> regards
> 
> Stefan
> 
> Gonzalo Diethelm wrote:
> > Hello everyone,
> > 
> > I need a Wix 2.0 package to be installed only by administrator users, so
> > I added the following as a child of the Product element:
> > 
> >   Privileged
> > 
> > Then I logged in as a non-administrator user in Windows XP  SP2 and ran
> > the installer. I never saw the "Admins only" message, and the
> > installation proceeded Ok to the end. Am I missing something?
> > 
> > Thanks and best regards,
> > 
> > 
> > -- 
> > Gonzalo Diethelm
> > [EMAIL PROTECTED] 
> > 
> > 
> > 
> > 
> > -
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > 
> > 
> > 
> > 
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> 


-- 
Gonzalo Diethelm
[EMAIL PROTECTED]
-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WiX-commits] Wix 2 and service

2007-12-06 Thread Gonzalo Diethelm

Ok, I am recanting from my past sins and turning to ServiceInstall and
ServiceControl and away from my CustomActions to install / uninstall my
service. However, I get the exact same symptom as before: when
uninstalling the service, there is a long pause. Since it's been some
time, allow me to restate the situation for your clarity.

My Wix 2.0 installer is running as administrator (using Condition
Privileged) and installing a Windows service. Here is the relevant piece
from the Wix file:

Installation works fine and the service is started. When I run the
uninstallation and the service is not running, it also works fine and
the service is uninstalled. But when I try to uninstall and the service
is running, the uninstaller hangs for about two minutes and then
finishes (properly uninstalling the service after the long pause). The
uninstallation log shows the following (with some manual translations
from Spanish to English done by me):

Action was initiated at 16:15:29: InstallValidate.
MSI (s) (60:DC) [16:15:29:843]: PROPERTY CHANGE: Modifying
CostingComplete property. Its current value is '0'. Its new value: '1'.
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: BindImage 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: ProgId 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: PublishComponent 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: SelfReg 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: Extension 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: Font 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: Shortcut 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2205 2:  3: Class 
MSI (s) (60:DC) [16:15:29:843]: Note: 1: 2727 2:  
MSI (s) (60:DC) [16:17:41:984]: Note: 1: 2205 2:  3: Error 
MSI (s) (60:DC) [16:17:41:984]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1607 
MSI (s) (60:DC) [16:17:42:000]: Note: 1: 2205 2:  3: Error 
MSI (s) (60:DC) [16:17:42:000]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1603 
Information 1603. The file E:\Program Files\Excelente\XLNsrvr\bin
\bgutil.dll is in user by the following process: Name: bgserver, Id.:
500, Windows title: '(not determined yet)'. Close this application and
try again.
... [several identical messages for other DLLs and EXEs]
MSI (s) (60:DC) [16:17:42:015]: Note: 1: 2727 2:  
MSI (c) (E4:04) [16:17:42:015]: File In Use: -bgserver- Window could not
be found. Process ID: 500
MSI (c) (E4:04) [16:17:42:015]: File In Use: -OProtSvc- Window could not
be found. Process ID: 264
MSI (c) (E4:04) [16:17:42:015]: No window with title could be found for
FilesInUse

The error message appears for two processes: my service and OProtSvc
(which is a service provided by Intel to manage their WiFi card). My
questions are:

1. Am I setting the ServiceInstall and ServiceControl elements properly?
2. Should I expect the uninstaller to gracefully stop my service without
this long pause? The service stops very quickly (it takes not more than
1 or 2 seconds to stop), and if I stop it manually there is no pause
during uninstallation.
3. The reason OProtSvc appears as using my files is this: I install the
OpenSSL DLLs into a private directory; among them, libeay32.dll. The
Intel OProtSvc service does use this library, but of course it CANNOT be
using it from my folder, which is private (this same DLL appears in
"/Program Files/Intel/Wireless/Bin/libeay32.dll" and
"/WINDOWS/system32/libeay32.dll"). So it looks like there is a match
done on the DLL name regardless of its path... Would this be a bug?
4. If this long pause constitutes proper and expected behaviour, what is
the recommendation for me? Should I somehow pop up a window telling the
user to stop the service before uninstalling? But if this is the case,
why have a "stop" command for ServiceControl if it will cause this much
grief?

Thanks for any feedback and best regards.

On Tue, 2007-10-02 at 22:51 -0700, Bob Arnson wrote:

> Gonzalo Diethelm wrote: 
> 
> > I guess that's arguable. I already had to provide all those details
> > (service name, startup information, etc.) in the EXE itself, in
> > order to support the /install, /remove, /start and /stop switches.
> > Why would I want to repeat that in the installer, instead of just
> > calling the EXE?
> 
> 
> Because the .exe doesn't provide the functionality you get "for free"
> from MSI when you duplicate the data in the .msi package. Do you
> handle install, uninstall, repair, modify, upgrades, and patching?
> It's possible, of course, but at a cost far higher than duplicating
> the data. And if data duplication is your biggest concern, you can
> single-source it by preprocessing the data, either into a header in
> your code or an include file in your WiX authoring (one of the
> advantages of XML).
> 
> 
> -- 
> sig://boB
> http://joyofsetup.com/

-- 
Gonzalo Diethelm
[EMAIL PROTECTED]
-
SF.Net email is spo

Re: [WiX-users] Votive on VS 2008?

2007-12-06 Thread Chris Bardon

I'm using 3.0.  Note that I didn't just try reinstalling (I have both VS
2005 and 2008 installed on my laptop), since I was worried that might
mess up the associations with the 2005 IDE.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard
Sent: Thursday, December 06, 2007 12:30 PM
To: WiX Users
Subject: Re: [WiX-users] Votive on VS 2008?

In article
<[EMAIL PROTECTED]
>,
"Chris Bardon" <[EMAIL PROTECTED]>  writes:

> Just out of curiosity, has anyone done a rebuild for the Votive plugin
> to work with VS 2008?  I just installed the RTM this week, and I'm
> looking to try moving some of my VS2005 projects up.  So far, anything
> that includes a setup won't build. =20

Are you trying the 2.0 or the 3.0?
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download

Legalize Adulthood! 

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Multi-file assembly problem

2007-12-06 Thread Geoff Finger

Short version:
Is there any way to override what seems to be the default behavior and
force Wix/msi to install additional file elements in an assembly
Component into the WinSxS folder even though they aren't included in
the main file's manifest? Or alternately are there any kind and
generous souls out there who know how to correctly combine several
dlls into one multifile assembly using mt.exe , makecat and signtool?

Long version:
I've got a couple legacy dlls that I'm trying to include as
Side-by-side assemblies. I've gone through this process with other
files just fine before. The problem in this case is that one of the
dlls tries to load the others directly via LoadLibrary, and after
digging through the code a little it seems that changing that behavior
would cascade into rewriting the whole library. Making them into a
multifile assembly seems like it would work, but all the instructions
for making those are for C# code compiled with .NET, no explanation
about how to handle legacy code.

This would seem like an occasion to just give up on the whole assembly
idea, but I happened to discover while testing an installation that if
i just copy DLLs 2 and 3 to the Side-by-side folder for DLL 1 then the
whole thing works. So if I can just get Wix to put the files there
everything will be great.

However I've run into issues trying to get the files to install in
that manner. If i add the files to the dll 1 Component then the log
file says things like:

MSI (s) (5C:A8) [13:44:49:394]: Executing op:
AssemblyCopy(SourceName=DLL2.dll|DLL2I.dll,SourceCabKey=DLL2FileLocal.D0119AF2____,DestName=DLL2.dll,Attributes=16384,FileSize=57344,PerTick=32768,,VerifyMedia=1,ComponentId={7049DC30-651B-427D-A90B-3FAF27B23C27}AssemblyMode=0,)
MSI (s) (5C:A8) [13:44:49:394]: Source for file
'DLL2FileLocal.D0119AF2____' is compressed
InstallFiles: File: DLL2.dll, Directory: , Size: 57344

However nothing actually gets copied the DLL1 side-by-side folder
except for DLL1 itself.

I then tried changing the DLL1 manifest to include DLLs 2 and 3. That
either causes an installation error:
Error 1935. An error occured during the installation of assembly
component {7049DC30----}. HRESULT: 0x800736CC.
assembly interface: IAssemblyCacheItem, function: Commit, assembly
name:
DLL1,version="1.0.0.0",type="win32",processorArchitecture="X86",publicKeyToken="0301"

Or it _does_ cause them to get copied over to the DLL1 side-by-side
folder, but then my program can't find DLL1 anymore for reasons I
can't figure out. (Depends says the Side-by-Side configuration has an
error, but when I right click on DLL1.dll in the depends file window
and select Properties it can find the file in WinSxS just fine.)
(The difference between the two problems is at what point I embed the
modified manifest file into the original DLL1 file using mt.exe)

I will be much obliged to anyone who can clear any of this mess up.

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] SQLExtension

2007-12-06 Thread Quattro IV

Hello, the wix wiki regarding the SQLExtension mentions "There is a serious
bug with how the *SqlExtension* handles the SqlDatabase
Elementwhen
creating a database. If a database with the same name
*already exists* it will always be *dropped*. At this time it is *not
recommended* to use the *SqlExtension* to create databases." Has this been
fixed in the latest builds? Thanks.

Reese
-
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Multi-file assembly problem

2007-12-06 Thread Kelly Leahy

> Or it _does_ cause them to get copied over to the DLL1 side-by-side
> folder, but then my program can't find DLL1 anymore for reasons I
> can't figure out.

Uhh... I think I can explain this one. Consider the following case:

DLL1 in folder
DLL2 in folder

DLL1 loads DLL2 using LoadLibrary (and relative path).

Application loads DLL1 by absolute path (like the way SxS works).

DLL1 won't successfully load DLL2. Also, if DLL1 'statically' binds to
DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path.

The key thing here is that the only 'application folder' that is used to
resolve DLL dependencies is the EXE path, not the DLL path.

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

Under no circumstances is the location of the DLL that is loading the
other DLL used in determining the DLL search path. This is why people
have so many problems with COM in-process servers that try to load DLL
dependencies from their "application" directory.

"Geoff Finger" <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
12/06/2007 03:38 PM

To
wix-users@lists.sourceforge.net
cc

Subject
[WiX-users] Multi-file assembly problem

However I've run into issues trying to get the files to install in
that manner. If i add the files to the dll 1 Component then the log
file says things like:

However nothing actually gets copied the DLL1 side-by-side folder
except for DLL1 itself.

I will be much obliged to anyone who can clear any of this mess up.

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

Re: [WiX-users] Multi-file assembly problem

2007-12-06 Thread Geoff Finger

The problem is that if I installed everything via the old method (each
of the three files set up as its own assembly with its own WinSxS
folder) and then copied the DLL2 and DLL3 files from their WinSxS
folders into the WinSxS folder for DLL1 then everything ran correctly.

If i can just recreate that situation with the installer then
everything would be fine, but Wix/Msi seems to refuse to copy
additional files into DLL1's WinSxS folder unless they're included in
the assembly manifest. Despite the fact they're part of DLL1's
Component block in Wix.

On Dec 6, 2007 4:10 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>
> > Or it _does_ cause them to get copied over to the DLL1 side-by-side
>  > folder, but then my program can't find DLL1 anymore for reasons I
>  > can't figure out.
>
> Uhh...  I think I can explain this one.  Consider the following case:
>
> DLL1 in folder 
> DLL2 in folder 
>
> DLL1 loads DLL2 using LoadLibrary (and relative path).
>
> Application loads DLL1 by absolute path (like the way SxS works).
>
> DLL1 won't successfully load DLL2.  Also, if DLL1 'statically' binds to
> DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path.
>
> The key thing here is that the only 'application folder' that is used to
> resolve DLL dependencies is the EXE path, not the DLL path.
>
> http://msdn2.microsoft.com/en-us/library/ms682586.aspx
>
> Under no circumstances is the location of the DLL that is loading the other
> DLL used in determining the DLL search path.  This is why people have so
> many problems with COM in-process servers that try to load DLL dependencies
> from their "application" directory.
>
>
>
>
>  "Geoff Finger" <[EMAIL PROTECTED]>
>
> Sent by: [EMAIL PROTECTED]
>
> 12/06/2007 03:38 PM
>
> To wix-users@lists.sourceforge.net
>
> cc
>
> Subject [WiX-users] Multi-file assembly problem
>
>
>
>
>
>
> Short version:
>  Is there any way to override what seems to be the default behavior and
>  force Wix/msi to install additional file elements in an assembly
>  Component into the WinSxS folder even though they aren't included in
>  the main file's manifest? Or alternately are there any kind and
>  generous souls out there who know how to correctly combine several
>  dlls into one multifile assembly using mt.exe , makecat and signtool?
>
>  Long version:
>  I've got a couple legacy dlls that I'm trying to include as
>  Side-by-side assemblies. I've gone through this process with other
>  files just fine before. The problem in this case is that one of the
>  dlls tries to load the others directly via LoadLibrary, and after
>  digging through the code a little it seems that changing that behavior
>  would cascade into rewriting the whole library. Making them into a
>  multifile assembly seems like it would work, but all the instructions
>  for making those are for C# code compiled with .NET, no explanation
>  about how to handle legacy code.
>
>  This would seem like an occasion to just give up on the whole assembly
>  idea, but I happened to discover while testing an installation that if
>  i just copy DLLs 2 and 3 to the Side-by-side folder for DLL 1 then the
>  whole thing works. So if I can just get Wix to put the files there
>  everything will be great.
>
>  However I've run into issues trying to get the files to install in
>  that manner. If i add the files to the dll 1 Component then the log
>  file says things like:
>
>  MSI (s) (5C:A8) [13:44:49:394]: Executing op:
>
> AssemblyCopy(SourceName=DLL2.dll|DLL2I.dll,SourceCabKey=DLL2FileLocal.D0119AF2____,DestName=DLL2.dll,Attributes=16384,FileSize=57344,PerTick=32768,,VerifyMedia=1,ComponentId={7049DC30-651B-427D-A90B-3FAF27B23C27}AssemblyMode=0,)
>  MSI (s) (5C:A8) [13:44:49:394]: Source for file
>  'DLL2FileLocal.D0119AF2____' is compressed
>  InstallFiles: File: DLL2.dll, Directory: , Size: 57344
>
>  However nothing actually gets copied the DLL1 side-by-side folder
>  except for DLL1 itself.
>
>  I then tried changing the DLL1 manifest to include DLLs 2 and 3. That
>  either causes an installation error:
>  Error 1935. An error occured during the installation of assembly
>  component {7049DC30----}. HRESULT: 0x800736CC.
>  assembly interface: IAssemblyCacheItem, function: Commit, assembly
>  name:
> DLL1,version="1.0.0.0",type="win32",processorArchitecture="X86",publicKeyToken="0301"
>
>  Or it _does_ cause them to get copied over to the DLL1 side-by-side
>  folder, but then my program can't find DLL1 anymore for reasons I
>  can't figure out. (Depends says the Side-by-Side configuration has an
>  error, but when I right click on DLL1.dll in the depends file window
>  and select Properties it can find the file in WinSxS just fine.)
>  (The difference between the two problems is at what point I embed the
>  modified manifest file into the original DLL1 file using mt.exe)
>
>  I will be much obliged to anyone who can clear any of this

Re: [WiX-users] Multi-file assembly problem

2007-12-06 Thread Geoff Finger

Yes, I'm creating the manifests myself. Or rather I'm taking the
automatically generated manifests, modifying them if necessary, and
signing them "by hand" using mt.exe, makecat and signtool.

I started out with manifest dependencies in DLL1 for DLL2 and DLL3,
but that doesn't help with a LoadLibrary call, which expects to load
the files directly. (I could remove the LoadLibrary call, but the
results of that are passed on to a couple different functions, which
pass results on to a couple different functions, and in the end
ripping it out would directly or indirectly effect a lot of the code.)

Putting the multiple file references into a single manifest file was
what I was trying at the end of the original email. If I embedded the
manifest back into the DLL1 file then Wix threw an error on
installation. If I just left the original unmodified manifest in the
DLL1 file then all the files get installed to the correct place, but
then the program can't locate DLL1 anymore. It seems like I may need
to do something differently with the manifest embedding for multifile
assemblies, but I'm not sure what.

The _simple_ solution would be finding a way to just force Wix to copy
the files over without futzing about with the manifests any more than
I already have.

On Dec 6, 2007 4:58 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>
> Are you creating the manifest yourself?
>
> You should be able to create a manifest that has dependency references in it
> for DLL2 and DLL3...
>
> See the  and  tags in Manifest reference:
> http://msdn2.microsoft.com/en-us/library/aa374219.aspx
>
> It also looks like you can put multiple files in a single 'assembly
> manifest', but I don't know how to get WiX to install them.
>
> I still don't understand why your LoadLibrary works when you have the files
> in the same folder though - I'd be curious to see what GetModuleFileName
> returns on those modules.
>
> Kelly
>
>
>
>
>
> "Geoff Finger" <[EMAIL PROTECTED]>
>
> Sent by: [EMAIL PROTECTED]
>
> 12/06/2007 04:29 PM
>
> To wix-users@lists.sourceforge.net, [EMAIL PROTECTED]
>
> cc
>
> Subject Re: [WiX-users] Multi-file assembly problem
>
>
>
>
>
>
> The problem is that if I installed everything via the old method (each
>  of the three files set up as its own assembly with its own WinSxS
>  folder) and then copied the DLL2 and DLL3 files from their WinSxS
>  folders into the WinSxS folder for DLL1 then everything ran correctly.
>
>  If i can just recreate that situation with the installer then
>  everything would be fine, but Wix/Msi seems to refuse to copy
>  additional files into DLL1's WinSxS folder unless they're included in
>  the assembly manifest. Despite the fact they're part of DLL1's
>  Component block in Wix.
>
>  On Dec 6, 2007 4:10 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>  >
>  > > Or it _does_ cause them to get copied over to the DLL1 side-by-side
>  >  > folder, but then my program can't find DLL1 anymore for reasons I
>  >  > can't figure out.
>  >
>  > Uhh...  I think I can explain this one.  Consider the following case:
>  >
>  > DLL1 in folder 
>  > DLL2 in folder 
>  >
>  > DLL1 loads DLL2 using LoadLibrary (and relative path).
>  >
>  > Application loads DLL1 by absolute path (like the way SxS works).
>  >
>  > DLL1 won't successfully load DLL2.  Also, if DLL1 'statically' binds to
>  > DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the path.
>  >
>  > The key thing here is that the only 'application folder' that is used to
>  > resolve DLL dependencies is the EXE path, not the DLL path.
>  >
>  > http://msdn2.microsoft.com/en-us/library/ms682586.aspx
>  >
>  > Under no circumstances is the location of the DLL that is loading the
> other
>  > DLL used in determining the DLL search path.  This is why people have so
>  > many problems with COM in-process servers that try to load DLL
> dependencies
>  > from their "application" directory.
>  >
>  >
>  >
>  >
>  >  "Geoff Finger" <[EMAIL PROTECTED]>
>  >
>  > Sent by: [EMAIL PROTECTED]
>  >
>  > 12/06/2007 03:38 PM
>  >
>  > To wix-users@lists.sourceforge.net
>  >
>  > cc
>  >
>  > Subject [WiX-users] Multi-file assembly problem
>  >
>  >
>  >
>  >
>  >
>  >
>  > Short version:
>  >  Is there any way to override what seems to be the default behavior and
>  >  force Wix/msi to install additional file elements in an assembly
>  >  Component into the WinSxS folder even though they aren't included in
>  >  the main file's manifest? Or alternately are there any kind and
>  >  generous souls out there who know how to correctly combine several
>  >  dlls into one multifile assembly using mt.exe , makecat and signtool?
>  >
>  >  Long version:
>  >  I've got a couple legacy dlls that I'm trying to include as
>  >  Side-by-side assemblies. I've gone through this process with other
>  >  files just fine before. The problem in this case is that one of the
>  >  dlls tries to load the others directly via LoadLibrary, and after
>  >  digging through the code a little it

Re: [WiX-users] Multi-file assembly problem

2007-12-06 Thread Kelly Leahy

Are you creating the manifest yourself?

You should be able to create a manifest that has dependency references in 
it for DLL2 and DLL3...

See the  and  tags in Manifest reference:
http://msdn2.microsoft.com/en-us/library/aa374219.aspx

It also looks like you can put multiple files in a single 'assembly 
manifest', but I don't know how to get WiX to install them.

I still don't understand why your LoadLibrary works when you have the 
files in the same folder though - I'd be curious to see what 
GetModuleFileName returns on those modules.

Kelly




"Geoff Finger" <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
12/06/2007 04:29 PM

To
wix-users@lists.sourceforge.net, [EMAIL PROTECTED]
cc

Subject
Re: [WiX-users] Multi-file assembly problem






The problem is that if I installed everything via the old method (each
of the three files set up as its own assembly with its own WinSxS
folder) and then copied the DLL2 and DLL3 files from their WinSxS
folders into the WinSxS folder for DLL1 then everything ran correctly.

If i can just recreate that situation with the installer then
everything would be fine, but Wix/Msi seems to refuse to copy
additional files into DLL1's WinSxS folder unless they're included in
the assembly manifest. Despite the fact they're part of DLL1's
Component block in Wix.

On Dec 6, 2007 4:10 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>
> > Or it _does_ cause them to get copied over to the DLL1 side-by-side
>  > folder, but then my program can't find DLL1 anymore for reasons I
>  > can't figure out.
>
> Uhh...  I think I can explain this one.  Consider the following case:
>
> DLL1 in folder 
> DLL2 in folder 
>
> DLL1 loads DLL2 using LoadLibrary (and relative path).
>
> Application loads DLL1 by absolute path (like the way SxS works).
>
> DLL1 won't successfully load DLL2.  Also, if DLL1 'statically' binds to
> DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the 
path.
>
> The key thing here is that the only 'application folder' that is used to
> resolve DLL dependencies is the EXE path, not the DLL path.
>
> http://msdn2.microsoft.com/en-us/library/ms682586.aspx
>
> Under no circumstances is the location of the DLL that is loading the 
other
> DLL used in determining the DLL search path.  This is why people have so
> many problems with COM in-process servers that try to load DLL 
dependencies
> from their "application" directory.
>
>
>
>
>  "Geoff Finger" <[EMAIL PROTECTED]>
>
> Sent by: [EMAIL PROTECTED]
>
> 12/06/2007 03:38 PM
>
> To wix-users@lists.sourceforge.net
>
> cc
>
> Subject [WiX-users] Multi-file assembly problem
>
>
>
>
>
>
> Short version:
>  Is there any way to override what seems to be the default behavior and
>  force Wix/msi to install additional file elements in an assembly
>  Component into the WinSxS folder even though they aren't included in
>  the main file's manifest? Or alternately are there any kind and
>  generous souls out there who know how to correctly combine several
>  dlls into one multifile assembly using mt.exe , makecat and signtool?
>
>  Long version:
>  I've got a couple legacy dlls that I'm trying to include as
>  Side-by-side assemblies. I've gone through this process with other
>  files just fine before. The problem in this case is that one of the
>  dlls tries to load the others directly via LoadLibrary, and after
>  digging through the code a little it seems that changing that behavior
>  would cascade into rewriting the whole library. Making them into a
>  multifile assembly seems like it would work, but all the instructions
>  for making those are for C# code compiled with .NET, no explanation
>  about how to handle legacy code.
>
>  This would seem like an occasion to just give up on the whole assembly
>  idea, but I happened to discover while testing an installation that if
>  i just copy DLLs 2 and 3 to the Side-by-side folder for DLL 1 then the
>  whole thing works. So if I can just get Wix to put the files there
>  everything will be great.
>
>  However I've run into issues trying to get the files to install in
>  that manner. If i add the files to the dll 1 Component then the log
>  file says things like:
>
>  MSI (s) (5C:A8) [13:44:49:394]: Executing op:
>
> 
AssemblyCopy(SourceName=DLL2.dll|DLL2I.dll,SourceCabKey=DLL2FileLocal.D0119AF2____,DestName=DLL2.dll,Attributes=16384,FileSize=57344,PerTick=32768,,VerifyMedia=1,ComponentId={7049DC30-651B-427D-A90B-3FAF27B23C27}AssemblyMode=0,)
>  MSI (s) (5C:A8) [13:44:49:394]: Source for file
>  'DLL2FileLocal.D0119AF2____' is compressed
>  InstallFiles: File: DLL2.dll, Directory: , Size: 57344
>
>  However nothing actually gets copied the DLL1 side-by-side folder
>  except for DLL1 itself.
>
>  I then tried changing the DLL1 manifest to include DLLs 2 and 3. That
>  either causes an installation error:
>  Error 1935. An error occured during the installation of assembly
>  component {7049DC30----}.

Re: [WiX-users] Multi-file assembly problem

2007-12-06 Thread Maletz, Josh

Have you tried putting them in separate components or just using the
CopyFile element?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Geoff
Finger
Sent: Thursday, December 06, 2007 6:16 PM
Cc: wix-users@lists.sourceforge.net;
[EMAIL PROTECTED]
Subject: Re: [WiX-users] Multi-file assembly problem

Yes, I'm creating the manifests myself. Or rather I'm taking the
automatically generated manifests, modifying them if necessary, and
signing them "by hand" using mt.exe, makecat and signtool.

I started out with manifest dependencies in DLL1 for DLL2 and DLL3,
but that doesn't help with a LoadLibrary call, which expects to load
the files directly. (I could remove the LoadLibrary call, but the
results of that are passed on to a couple different functions, which
pass results on to a couple different functions, and in the end
ripping it out would directly or indirectly effect a lot of the code.)

Putting the multiple file references into a single manifest file was
what I was trying at the end of the original email. If I embedded the
manifest back into the DLL1 file then Wix threw an error on
installation. If I just left the original unmodified manifest in the
DLL1 file then all the files get installed to the correct place, but
then the program can't locate DLL1 anymore. It seems like I may need
to do something differently with the manifest embedding for multifile
assemblies, but I'm not sure what.

The _simple_ solution would be finding a way to just force Wix to copy
the files over without futzing about with the manifests any more than
I already have.

On Dec 6, 2007 4:58 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>
> Are you creating the manifest yourself?
>
> You should be able to create a manifest that has dependency references
in it
> for DLL2 and DLL3...
>
> See the  and  tags in Manifest
reference:
> http://msdn2.microsoft.com/en-us/library/aa374219.aspx
>
> It also looks like you can put multiple files in a single 'assembly
> manifest', but I don't know how to get WiX to install them.
>
> I still don't understand why your LoadLibrary works when you have the
files
> in the same folder though - I'd be curious to see what
GetModuleFileName
> returns on those modules.
>
> Kelly
>
>
>
>
>
> "Geoff Finger" <[EMAIL PROTECTED]>
>
> Sent by: [EMAIL PROTECTED]
>
> 12/06/2007 04:29 PM
>
> To wix-users@lists.sourceforge.net,
[EMAIL PROTECTED]
>
> cc
>
> Subject Re: [WiX-users] Multi-file assembly problem
>
>
>
>
>
>
> The problem is that if I installed everything via the old method (each
>  of the three files set up as its own assembly with its own WinSxS
>  folder) and then copied the DLL2 and DLL3 files from their WinSxS
>  folders into the WinSxS folder for DLL1 then everything ran
correctly.
>
>  If i can just recreate that situation with the installer then
>  everything would be fine, but Wix/Msi seems to refuse to copy
>  additional files into DLL1's WinSxS folder unless they're included in
>  the assembly manifest. Despite the fact they're part of DLL1's
>  Component block in Wix.
>
>  On Dec 6, 2007 4:10 PM, Kelly Leahy <[EMAIL PROTECTED]> wrote:
>  >
>  > > Or it _does_ cause them to get copied over to the DLL1
side-by-side
>  >  > folder, but then my program can't find DLL1 anymore for reasons
I
>  >  > can't figure out.
>  >
>  > Uhh...  I think I can explain this one.  Consider the following
case:
>  >
>  > DLL1 in folder 
>  > DLL2 in folder 
>  >
>  > DLL1 loads DLL2 using LoadLibrary (and relative path).
>  >
>  > Application loads DLL1 by absolute path (like the way SxS works).
>  >
>  > DLL1 won't successfully load DLL2.  Also, if DLL1 'statically'
binds to
>  > DLL2, it will fail to load DLL1 altogether, since DLL2 isn't on the
path.
>  >
>  > The key thing here is that the only 'application folder' that is
used to
>  > resolve DLL dependencies is the EXE path, not the DLL path.
>  >
>  > http://msdn2.microsoft.com/en-us/library/ms682586.aspx
>  >
>  > Under no circumstances is the location of the DLL that is loading
the
> other
>  > DLL used in determining the DLL search path.  This is why people
have so
>  > many problems with COM in-process servers that try to load DLL
> dependencies
>  > from their "application" directory.
>  >
>  >
>  >
>  >
>  >  "Geoff Finger" <[EMAIL PROTECTED]>
>  >
>  > Sent by: [EMAIL PROTECTED]
>  >
>  > 12/06/2007 03:38 PM
>  >
>  > To wix-users@lists.sourceforge.net
>  >
>  > cc
>  >
>  > Subject [WiX-users] Multi-file assembly problem
>  >
>  >
>  >
>  >
>  >
>  >
>  > Short version:
>  >  Is there any way to override what seems to be the default behavior
and
>  >  force Wix/msi to install additional file elements in an assembly
>  >  Component into the WinSxS folder even though they aren't included
in
>  >  the main file's manifest? Or alternately are there any kind and
>  >  generous souls out there who know how to correctly combine several
>  >  dlls into one multifile assembly using mt.exe , makecat and
signtool?
>  >
>  >

Re: [WiX-users] Output Window bugs with latest versions of Wix?

Re: [WiX-users] Handling Feature Dependencies

Re: [WiX-users] Re posting Condition for Silent Install

Re: [WiX-users] Re posting Condition for Silent Install

[WiX-users] Condition Privileged not working

[WiX-users] Votive on VS 2008?

Re: [WiX-users] Handling Feature Dependencies

Re: [WiX-users] Condition Privileged not working

[WiX-users] Create Directory with name from Property

Re: [WiX-users] Votive on VS 2008?

Re: [WiX-users] Create Directory with name from Property

[WiX-users] Disabling the next button in a feature tree dialog when no features are selected

[WiX-users] XmlFile cannot access network drive

[WiX-users] Multiple cab files per media element (disk)

Re: [WiX-users] Condition Privileged not working

Re: [WiX-users] [WiX-commits] Wix 2 and service

Re: [WiX-users] Votive on VS 2008?

[WiX-users] Multi-file assembly problem

[WiX-users] SQLExtension

Re: [WiX-users] Multi-file assembly problem

Re: [WiX-users] Multi-file assembly problem

Re: [WiX-users] Multi-file assembly problem

Re: [WiX-users] Multi-file assembly problem

Re: [WiX-users] Multi-file assembly problem

24 matches

Site Navigation

Mail list logo

Footer information