[WiX-users] FilesInUse in a different session

[Anidil]

Hello there

Is there a way to show the files in use dialog if the application files are
kept opened in a different vista session?

Thanks
Anidil
-- 
View this message in context: 
http://www.nabble.com/FilesInUse-in-a-different-session-tp18626251p18626251.html
Sent from the wix-users mailing list archive at Nabble.com.


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

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Bob Arnson]

Alan Sinclair wrote:
> Unfortunately dark gets an exception when extracting the files from our
> MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
> option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
> (not the latest WiX 3))
>   

If all you're interested in is the files, just use WiX v3's version of 
dark -- it doesn't have this problem.

> Is it useful/appropriate to submit this as a bug? 

Please do. I can reproduce the problem.

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



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

Re: [WiX-users] Multiple Installs without Un-Install?

[Christopher Painter]

He emailed me off list.  Basically his product doesn't actually install 
anything.  He's looking at a fake MSI design where he basically just wants to 
leverage MSI/WiX MSSQL CA's since that's the way other teams  have done it 
where he works.

Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Wed, 7/23/08, John Nannenga <[EMAIL PROTECTED]> wrote:

> From: John Nannenga <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 23, 2008, 10:17 PM
> Any particular reason they do this?  (I'm not bashing
> folks or anything like that; I'm simply genuinely
> curious what the advantage would be in doing this)
> 
> 
> As Chris mentioned, you could modify the maintenance
> process to support your needs, leaving the product
> installed.
> 
> If that option doesn't appeal to you and you simply
> want your ideal way of "the MSI would un-install
> itself after it finished creating the database",
> here's a rather interesting option:
> 
> Presuming your SQL installation routine doesn't use a
> rollback script...  you could, force failure after your SQL
> installation is complete (which would then 'rollback the
> installation' and leave your DB stuff intact while not
> leaving the MSI [shim] installed).  Modify the UI end
> dialogs accordingly.  (though the MSI error code returned
> would still be failure, but if nothing's looking at
> that, what the heck, right?)
> 
> Or if that's too corny, you could wrap the MSI; either
> an external UI handler [a bit of work] or simply a batch
> script [or simply a utility] to perform the installation,
> then when completed, perform a silent un-installation.
> 
> 
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Daniel Zak
> Sent: Wednesday, July 23, 2008 8:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Multiple Installs without
> Un-Install?
> 
> I spoke to three different teams in our organization and
> they all use an MSI
> to install a database. I decided to try this as an
> alternative to the DOS
> batch script I used in the previous version of our
> software.
> 
> 
> On Wed, Jul 23, 2008 at 10:14 AM, John Nannenga
> <[EMAIL PROTECTED]>
> wrote:
> 
> > > Ideally, the MSI would un-install itself after it
> finished creating the
> > > database.
> >
> > This might be off topic, but curiosity got the best of
> me; given that to be
> > the case, why would this be in an MSI at all?
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] On Behalf Of
> Daniel Zak
> > Sent: Wednesday, July 23, 2008 12:05 PM
> > To: [EMAIL PROTECTED]; General
> discussion for Windows
> > Installer XML toolset.
> > Subject: Re: [WiX-users] Multiple Installs without
> Un-Install?
> >
> > The user wants to have the ability to install a
> database from any remote
> > machine. Also, additional databases would be installed
> at some other point
> > in time (e.g. perhaps 3 months later the user decides
> they need a second
> > database).
> >
> > Ideally, the MSI would un-install itself after it
> finished creating the
> > database.
> > Cheers,
> > Daniel
> >
> > On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter
> <
> > [EMAIL PROTECTED]> wrote:
> >
> > > You could modify the maintenance UI experience to
> have an option for
> > > creating additional database instances which
> would then execute your
> > script
> > > again but I'm wondering if it wouldn't be
> simpler to just write a small
> > > application utility and put it in the start menu
> to allow a user to
> > perform
> > > database management functions like creating
> additional named database
> > > instances.
> > >
> > > How do you feel about that?
> > >
> > > --- On Wed, 7/23/08, Daniel Zak
> <[EMAIL PROTECTED]> wrote:
> > >
> > > > From: Daniel Zak
> <[EMAIL PROTECTED]>
> > > > Subject: Re: [WiX-users] Multiple Installs
> without Un-Install?
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Wednesday, July 23, 2008, 1:28 AM
> > >  > Hi Christopher,
> > > >
> > > > I need multiple instances only of the
> database.
> > > >
> > > > Cheers,
> > > > Daniel
> > > >
> > > >
> > > > > Message: 9
> > > > > Date: Tue, 22 Jul 2008 05:31:10 -0700
> (PDT)
> > > > > From: Christopher Painter
> > > > <[EMAIL PROTECTED]>
> > > > > Subject: Re: [WiX-users] Multiple
> Installs without
> > > > Un-Install?
> > > > > To: "General discussion for
> Windows Installer XML
> > > > toolset."
> > > > >   
> 
> > > > > Message-ID:
> > > >
> <[EMAIL PROTECTED]>
> > > > > Content-Type: text/plain;
> charset=us-ascii
> > > > >
> > > > > Windows Installer supports multiple
> instance
> > > > installation, but the question
> > > > > I have is do you need multiple
> instances of your
> > > > product or o

Re: [WiX-users] Multiple Installs without Un-Install?

[John Nannenga]

Any particular reason they do this?  (I'm not bashing folks or anything like 
that; I'm simply genuinely curious what the advantage would be in doing this)


As Chris mentioned, you could modify the maintenance process to support your 
needs, leaving the product installed.

If that option doesn't appeal to you and you simply want your ideal way of "the 
MSI would un-install itself after it finished creating the database", here's a 
rather interesting option:

Presuming your SQL installation routine doesn't use a rollback script...  you 
could, force failure after your SQL installation is complete (which would then 
'rollback the installation' and leave your DB stuff intact while not leaving 
the MSI [shim] installed).  Modify the UI end dialogs accordingly.  (though the 
MSI error code returned would still be failure, but if nothing's looking at 
that, what the heck, right?)

Or if that's too corny, you could wrap the MSI; either an external UI handler 
[a bit of work] or simply a batch script [or simply a utility] to perform the 
installation, then when completed, perform a silent un-installation.





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Zak
Sent: Wednesday, July 23, 2008 8:00 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Installs without Un-Install?

I spoke to three different teams in our organization and they all use an MSI
to install a database. I decided to try this as an alternative to the DOS
batch script I used in the previous version of our software.


On Wed, Jul 23, 2008 at 10:14 AM, John Nannenga <[EMAIL PROTECTED]>
wrote:

> > Ideally, the MSI would un-install itself after it finished creating the
> > database.
>
> This might be off topic, but curiosity got the best of me; given that to be
> the case, why would this be in an MSI at all?
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Daniel Zak
> Sent: Wednesday, July 23, 2008 12:05 PM
> To: [EMAIL PROTECTED]; General discussion for Windows
> Installer XML toolset.
> Subject: Re: [WiX-users] Multiple Installs without Un-Install?
>
> The user wants to have the ability to install a database from any remote
> machine. Also, additional databases would be installed at some other point
> in time (e.g. perhaps 3 months later the user decides they need a second
> database).
>
> Ideally, the MSI would un-install itself after it finished creating the
> database.
> Cheers,
> Daniel
>
> On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter <
> [EMAIL PROTECTED]> wrote:
>
> > You could modify the maintenance UI experience to have an option for
> > creating additional database instances which would then execute your
> script
> > again but I'm wondering if it wouldn't be simpler to just write a small
> > application utility and put it in the start menu to allow a user to
> perform
> > database management functions like creating additional named database
> > instances.
> >
> > How do you feel about that?
> >
> > --- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:
> >
> > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> > > To: wix-users@lists.sourceforge.net
> > > Date: Wednesday, July 23, 2008, 1:28 AM
> >  > Hi Christopher,
> > >
> > > I need multiple instances only of the database.
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > > Message: 9
> > > > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > > > From: Christopher Painter
> > > <[EMAIL PROTECTED]>
> > > > Subject: Re: [WiX-users] Multiple Installs without
> > > Un-Install?
> > > > To: "General discussion for Windows Installer XML
> > > toolset."
> > > >
> > > > Message-ID:
> > > <[EMAIL PROTECTED]>
> > > > Content-Type: text/plain; charset=us-ascii
> > > >
> > > > Windows Installer supports multiple instance
> > > installation, but the question
> > > > I have is do you need multiple instances of your
> > > product or only multiple
> > > > instances of your database?
> > > >
> > > > Christopher Painter, Author of Deployment Engineering
> > > Blog
> > > > Have a hot tip, know a secret or read a really good
> > > thread that deserves
> > > > attention? E-Mail Me
> > > >
> > > >
> > > > --- On Mon, 7/21/08, Daniel Zak
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > > > Subject: [WiX-users] Multiple Installs without
> > > Un-Install?
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Date: Monday, July 21, 2008, 11:51 PM
> > > > > Hello,
> > > > >
> > > > > I created a script to install an SQL Server
> > > database. A
> > > > > user needs to be
> > > > > able to run the script multiple times to install
> > > multiple
> > > > > databases.
> > > > > However, the script requires the user to first
> > > un-install
> > > > > the product (which
> > > > > does not delete the database) before being able
> > > to install
> > > > >

Re: [WiX-users] Copy files and folders from target machine

[Rob Mensching]

The only way to do it without having to worry about uninstall and rollback is 
to list all the files as File elements.  Everything else requires custom code.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sajid1105
Sent: Wednesday, July 23, 2008 18:32
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Copy files and folders from target machine



Can anyone tell me how to copy folders(including sub-directories and files)
in one location in the target machine to another location? I do not want to
package these files in msi at build time. these files exist only in the user
computer that I will access during installation. Is there a way to do that
in WIX? if so how does it handle the uninstall and rollback?
--
View this message in context: 
http://www.nabble.com/Copy-files-and-folders-from-target-machine-tp18623880p18623880.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] Build Fails with NAnt. The format ofthefile 'NAntTasks.dll' is invalid.

[Gavin Bee]

Eric,

My apologies for leaving that part out.  CustomOutputPath needs to be used
to set the value of OutputPath.  So your Debug and Release PropertyGroups
end up looking like the following 

  
$(CustomOutputPath)
obj\Debug\
Debug
  
  
$(CustomOutputPath)
obj\Release\
   

Note that in the above your output path ends up being the same for debug and
release.

Gavin :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Wednesday, July 23, 2008 5:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format ofthefile
'NAntTasks.dll' is invalid.

Thanks Gavin, 

I think I'm very close. It still builds my .msi, but I can't get the
CustomOutput argument to work. I haven't worked with msbuild project
files before so I'm sure my code is wrong. Maybe you can easily see what
I'm doing wrong. 

Nant Code:







 
 


Project File:

http://schemas.microsoft.com/developer/msbuild/2003";>
  
Debug
3.0
{2891ae0b-bf21-405f-b3af-87075ee2f574}
2.0
SuiteSetup
Package
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets
$(ProgramFiles)\Windows Installer XML
v3\bin\
  
  
bin\Debug\
obj\Debug\
$(CustomOutputPath)
Debug
  
  
bin\Release\
obj\Release\
$(CustomOutputPath)
  
  

  
  



  
  


Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin Bee
Sent: Wednesday, July 23, 2008 2:54 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Build Fails with NAnt. The format ofthefile
'NAntTasks.dll' is invalid.

Sounds like you need to pass the desired output path to msbuild from
nant.
You can use the /property command line argument to msbuild.exe to pass
property values from NAnt into MSBUILD.

We use the a NAnt exec task that looks something like the following:
  






   

You could just add another argument to the list of args



You will then have to update your wixproj file to use these property
values
to populate OutputPath and OutputName as appropriate.

Hope that helps,
Gavin :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Wednesday, July 23, 2008 2:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

Great, that worked. I was able to build my installer using my NAnt build
file. However. I need to specify an output path every time the .msi gets
built. Right now the output path is what is set in the protect
properties. The reason I need to separate the build versions is that
ultimately I need to look at the different versions to create patches.
Can you recommend a way to do this with the msbuild command?

Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Tuesday, July 22, 2008 5:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

One option to consider is using the shipping MSBuild .targets file that
has a complete build process for WiX in conjunction with NAnt. Trying to
re-construct a build process using individual tasks is often fraught
with peril, and using the one that ships with WiX is almost always a
better idea.

You would create a .wixproj that uses the MSBuild process for building
WiX (a quick way to do this is to create a WiX project in Visual
Studio), and then in your nant build script just do . You'll get our well-tested and supported
build process for free, yet still be able to use nant as your overall
build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric

[WiX-users] Copy files and folders from target machine

[Sajid1105]

Can anyone tell me how to copy folders(including sub-directories and files)
in one location in the target machine to another location? I do not want to
package these files in msi at build time. these files exist only in the user
computer that I will access during installation. Is there a way to do that
in WIX? if so how does it handle the uninstall and rollback?
-- 
View this message in context: 
http://www.nabble.com/Copy-files-and-folders-from-target-machine-tp18623880p18623880.html
Sent from the wix-users mailing list archive at Nabble.com.


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

Re: [WiX-users] Multiple Installs without Un-Install?

[Daniel Zak]

I spoke to three different teams in our organization and they all use an MSI
to install a database. I decided to try this as an alternative to the DOS
batch script I used in the previous version of our software.


On Wed, Jul 23, 2008 at 10:14 AM, John Nannenga <[EMAIL PROTECTED]>
wrote:

> > Ideally, the MSI would un-install itself after it finished creating the
> > database.
>
> This might be off topic, but curiosity got the best of me; given that to be
> the case, why would this be in an MSI at all?
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Daniel Zak
> Sent: Wednesday, July 23, 2008 12:05 PM
> To: [EMAIL PROTECTED]; General discussion for Windows
> Installer XML toolset.
> Subject: Re: [WiX-users] Multiple Installs without Un-Install?
>
> The user wants to have the ability to install a database from any remote
> machine. Also, additional databases would be installed at some other point
> in time (e.g. perhaps 3 months later the user decides they need a second
> database).
>
> Ideally, the MSI would un-install itself after it finished creating the
> database.
> Cheers,
> Daniel
>
> On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter <
> [EMAIL PROTECTED]> wrote:
>
> > You could modify the maintenance UI experience to have an option for
> > creating additional database instances which would then execute your
> script
> > again but I'm wondering if it wouldn't be simpler to just write a small
> > application utility and put it in the start menu to allow a user to
> perform
> > database management functions like creating additional named database
> > instances.
> >
> > How do you feel about that?
> >
> > --- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:
> >
> > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> > > To: wix-users@lists.sourceforge.net
> > > Date: Wednesday, July 23, 2008, 1:28 AM
> >  > Hi Christopher,
> > >
> > > I need multiple instances only of the database.
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > > Message: 9
> > > > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > > > From: Christopher Painter
> > > <[EMAIL PROTECTED]>
> > > > Subject: Re: [WiX-users] Multiple Installs without
> > > Un-Install?
> > > > To: "General discussion for Windows Installer XML
> > > toolset."
> > > >
> > > > Message-ID:
> > > <[EMAIL PROTECTED]>
> > > > Content-Type: text/plain; charset=us-ascii
> > > >
> > > > Windows Installer supports multiple instance
> > > installation, but the question
> > > > I have is do you need multiple instances of your
> > > product or only multiple
> > > > instances of your database?
> > > >
> > > > Christopher Painter, Author of Deployment Engineering
> > > Blog
> > > > Have a hot tip, know a secret or read a really good
> > > thread that deserves
> > > > attention? E-Mail Me
> > > >
> > > >
> > > > --- On Mon, 7/21/08, Daniel Zak
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > > > Subject: [WiX-users] Multiple Installs without
> > > Un-Install?
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Date: Monday, July 21, 2008, 11:51 PM
> > > > > Hello,
> > > > >
> > > > > I created a script to install an SQL Server
> > > database. A
> > > > > user needs to be
> > > > > able to run the script multiple times to install
> > > multiple
> > > > > databases.
> > > > > However, the script requires the user to first
> > > un-install
> > > > > the product (which
> > > > > does not delete the database) before being able
> > > to install
> > > > > a new database.
> > > > >
> > > > > Is there anything I can do to avoid requiring the
> > > user to
> > > > > explicitly
> > > > > un-install the product?
> > > > >
> > > > > I included an extract of the script as a text
> > > file.
> > > > >
> > > > > Thank you,
> > > > > Daniel
> > >
> -
> > > This SF.Net email is sponsored by the Moblin Your Move
> > > Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK
> > > & win great prizes
> > > Grand prize is a trip for two to an Open Source event
> > > anywhere in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> > -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@li

Re: [WiX-users] Ugly Uninstall under Vista

[Rob Mensching]

Known issue.  Stupid bug on their part.  You probably could register your 
bootstrapper as the uninstaller for your product but that requires a fair bit 
of work and can get very tricky to do correctly (read about ARPSYSCOMPONENT on 
the internet... some really strange things that need to be handled, IIRC).

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen
Sent: Wednesday, July 23, 2008 14:42
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Ugly Uninstall under Vista

I found KB929467 which discusses this VERY briefly. It simply says "To
work around this issue, click Allow in the User Account Control dialog
box to let the repair or remove operation continue." Does anyone have a
real way to work around this?

--Quinton

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Quinton
Tormanen
Sent: Wednesday, July 23, 2008 2:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Ugly Uninstall under Vista

I'm sure this has been discussed before but I couldn't find anything
searching the mailing list archive. My apologies if you guys have seen
this many times.



I have a relatively small application .msi installer based on WiX
(9.6MB). I distribute it wrapped in a bootstrap executable. Everything
works great, but I'm greatly annoyed that after all the work I went
through to digitally sign the .msi, .exe, and the application itself,
when the user does an uninstall on Windows Vista with UAC enabled, the
user gets a UAC warning about an unsigned program wanting access to
their computer. This makes my installer/uninstaller look highly
unprofessional. I think I know the general reason for this. That is, I
expect that Windows Installer builds an abbreviated version of my .msi
installer and caches it to use for the uninstall, repair, etc. However,
Windows Installer can't digitally sign it on my behalf (or anyone else's
for that matter) so it generates the ugliest of UAC warnings.



So, is there some way around this? I'm thinking that since my installer
is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi
as is? Or perhaps someone could otherwise point me in the right
direction? Perhaps I should save a copy of my .msi in my install folder
and then somehow point Windows Installer to it for the uninstall?



Thanks for any help you can provide.



Quinton Tormanen

Software Engineer

Delta Computer Systems, Inc.

http://www.deltamotion.com 




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

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


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

Re: [WiX-users] Ugly Uninstall under Vista

[Quinton Tormanen]

I found KB929467 which discusses this VERY briefly. It simply says "To
work around this issue, click Allow in the User Account Control dialog
box to let the repair or remove operation continue." Does anyone have a
real way to work around this?

--Quinton

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Quinton
Tormanen
Sent: Wednesday, July 23, 2008 2:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Ugly Uninstall under Vista

I'm sure this has been discussed before but I couldn't find anything
searching the mailing list archive. My apologies if you guys have seen
this many times.

 

I have a relatively small application .msi installer based on WiX
(9.6MB). I distribute it wrapped in a bootstrap executable. Everything
works great, but I'm greatly annoyed that after all the work I went
through to digitally sign the .msi, .exe, and the application itself,
when the user does an uninstall on Windows Vista with UAC enabled, the
user gets a UAC warning about an unsigned program wanting access to
their computer. This makes my installer/uninstaller look highly
unprofessional. I think I know the general reason for this. That is, I
expect that Windows Installer builds an abbreviated version of my .msi
installer and caches it to use for the uninstall, repair, etc. However,
Windows Installer can't digitally sign it on my behalf (or anyone else's
for that matter) so it generates the ugliest of UAC warnings.

 

So, is there some way around this? I'm thinking that since my installer
is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi
as is? Or perhaps someone could otherwise point me in the right
direction? Perhaps I should save a copy of my .msi in my install folder
and then somehow point Windows Installer to it for the uninstall?

 

Thanks for any help you can provide.

 

Quinton Tormanen

Software Engineer

Delta Computer Systems, Inc.

http://www.deltamotion.com  

 


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

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

[WiX-users] Ugly Uninstall under Vista

[Quinton Tormanen]

I'm sure this has been discussed before but I couldn't find anything
searching the mailing list archive. My apologies if you guys have seen
this many times.

 

I have a relatively small application .msi installer based on WiX
(9.6MB). I distribute it wrapped in a bootstrap executable. Everything
works great, but I'm greatly annoyed that after all the work I went
through to digitally sign the .msi, .exe, and the application itself,
when the user does an uninstall on Windows Vista with UAC enabled, the
user gets a UAC warning about an unsigned program wanting access to
their computer. This makes my installer/uninstaller look highly
unprofessional. I think I know the general reason for this. That is, I
expect that Windows Installer builds an abbreviated version of my .msi
installer and caches it to use for the uninstall, repair, etc. However,
Windows Installer can't digitally sign it on my behalf (or anyone else's
for that matter) so it generates the ugliest of UAC warnings.

 

So, is there some way around this? I'm thinking that since my installer
is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi
as is? Or perhaps someone could otherwise point me in the right
direction? Perhaps I should save a copy of my .msi in my install folder
and then somehow point Windows Installer to it for the uninstall?

 

Thanks for any help you can provide.

 

Quinton Tormanen

Software Engineer

Delta Computer Systems, Inc.

http://www.deltamotion.com  

 

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

Re: [WiX-users] Build Fails with NAnt. The format ofthefile 'NAntTasks.dll' is invalid.

[Eric Latendresse]

Thanks Gavin, 

I think I'm very close. It still builds my .msi, but I can't get the
CustomOutput argument to work. I haven't worked with msbuild project
files before so I'm sure my code is wrong. Maybe you can easily see what
I'm doing wrong. 

Nant Code:







 
 


Project File:

http://schemas.microsoft.com/developer/msbuild/2003";>
  
Debug
3.0
{2891ae0b-bf21-405f-b3af-87075ee2f574}
2.0
SuiteSetup
Package
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets
$(ProgramFiles)\Windows Installer XML
v3\bin\
  
  
bin\Debug\
obj\Debug\
$(CustomOutputPath)
Debug
  
  
bin\Release\
obj\Release\
$(CustomOutputPath)
  
  

  
  



  
  


Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin Bee
Sent: Wednesday, July 23, 2008 2:54 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Build Fails with NAnt. The format ofthefile
'NAntTasks.dll' is invalid.

Sounds like you need to pass the desired output path to msbuild from
nant.
You can use the /property command line argument to msbuild.exe to pass
property values from NAnt into MSBUILD.

We use the a NAnt exec task that looks something like the following:
  






   

You could just add another argument to the list of args



You will then have to update your wixproj file to use these property
values
to populate OutputPath and OutputName as appropriate.

Hope that helps,
Gavin :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Wednesday, July 23, 2008 2:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

Great, that worked. I was able to build my installer using my NAnt build
file. However. I need to specify an output path every time the .msi gets
built. Right now the output path is what is set in the protect
properties. The reason I need to separate the build versions is that
ultimately I need to look at the different versions to create patches.
Can you recommend a way to do this with the msbuild command?

Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Tuesday, July 22, 2008 5:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

One option to consider is using the shipping MSBuild .targets file that
has a complete build process for WiX in conjunction with NAnt. Trying to
re-construct a build process using individual tasks is often fraught
with peril, and using the one that ships with WiX is almost always a
better idea.

You would create a .wixproj that uses the MSBuild process for building
WiX (a quick way to do this is to create a WiX project in Visual
Studio), and then in your nant build script just do . You'll get our well-tested and supported
build process for free, yet still be able to use nant as your overall
build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric






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



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

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Jason Brenton]

Hmm, am I going to have to access these via a C++ component or homemade
wrapper, or is there an existing .net wrapper?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: Wednesday, July 23, 2008 2:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

All binary streams including the "hidden" streams can be accessed from code
via the _Streams table:
http://msdn.microsoft.com/en-us/library/aa372919.aspx

Orca doesn't show it, but the table is queryable with MSI SQL like any other
table.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason Brenton
Sent: Wednesday, July 23, 2008 1:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Can these streams be accessed from an extension dll/customaction? It could
give some real convenient features and full installer control that way.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair
Sent: Wednesday, July 23, 2008 2:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Is there any other way to get the .cab out of the .msi? (I know about
NTFS file streams, but this must be something else.)

Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
(not the latest WiX 3))

Is it useful/appropriate to submit this as a bug? I'm guessing it's
maybe something specific to my WiX installation, because presumably dark
is working for other people. This is what dark says:

F:\b2\depot\dev\alan\ctxprodcodes\temp
> dark /x f:\bin Wix-3.0.4318.0.msi wix.xml
Microsoft (R) Windows Installer Xml Decompiler Version 2.0.5805.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.


Wix-3.0.4318.0.msi
dark.exe : error DARK0001 : Could not find file
'f:\bin\extract\1\lt0x6ngl.con'.

Exception Type: System.IO.FileNotFoundException

Stack Trace:
   at System.IO.__Error.WinIOError(Int32 errorCode, String
maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String
destFileName, Boolean overwrite)

   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTable(XmlWrite
r writer, String component, String keyPath, String componentPathShort,
String componentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentRecord(Xm
lWriter writer, String directory, String rootPathShort, String
rootPathLong, Record record)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentTable(Str
ing directory, String rootPathShort, String rootPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProductElement(Boo
lean writeDocumentElements)
   at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(String
inputPath, String outputPath)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)

Thanks


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used
> Orca to extract the CAB, then used Windows Explorer to get at the
> contents. But the MSIs produced by the WiX toolset on a project I've
> inherited don't have a CAB visible anywhere. The binaries are
> definitely inside the MSI, though --the Wise Installation Studio
> manages to extract
> them-- so how do I get at them?
>

Embedded cabs are stored as a stream in the .msi. You can use the Dark
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode
> (msiexec /a ...) but with these MSIs, there's only a "Finished"
> dialog, and it took me a while to find that the files had been
> installed to Y:\ What do I need to do to make Admin installs
manageable from a WiX MSI?
>

The built-in UI doesn't have support for admin-image directory
selection, but you can use the command line to specify properties like
TARGETDIR.

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



---

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Jason Ginchereau]

All binary streams including the "hidden" streams can be accessed from code via 
the _Streams table: http://msdn.microsoft.com/en-us/library/aa372919.aspx

Orca doesn't show it, but the table is queryable with MSI SQL like any other 
table.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Brenton
Sent: Wednesday, July 23, 2008 1:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Can these streams be accessed from an extension dll/customaction? It could
give some real convenient features and full installer control that way.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair
Sent: Wednesday, July 23, 2008 2:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Is there any other way to get the .cab out of the .msi? (I know about
NTFS file streams, but this must be something else.)

Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
(not the latest WiX 3))

Is it useful/appropriate to submit this as a bug? I'm guessing it's
maybe something specific to my WiX installation, because presumably dark
is working for other people. This is what dark says:

F:\b2\depot\dev\alan\ctxprodcodes\temp
> dark /x f:\bin Wix-3.0.4318.0.msi wix.xml
Microsoft (R) Windows Installer Xml Decompiler Version 2.0.5805.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.


Wix-3.0.4318.0.msi
dark.exe : error DARK0001 : Could not find file
'f:\bin\extract\1\lt0x6ngl.con'.

Exception Type: System.IO.FileNotFoundException

Stack Trace:
   at System.IO.__Error.WinIOError(Int32 errorCode, String
maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String
destFileName, Boolean overwrite)

   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTable(XmlWrite
r writer, String component, String keyPath, String componentPathShort,
String componentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentRecord(Xm
lWriter writer, String directory, String rootPathShort, String
rootPathLong, Record record)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentTable(Str
ing directory, String rootPathShort, String rootPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProductElement(Boo
lean writeDocumentElements)
   at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(String
inputPath, String outputPath)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)

Thanks


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used
> Orca to extract the CAB, then used Windows Explorer to get at the
> contents. But the MSIs produced by the WiX toolset on a project I've
> inherited don't have a CAB visible anywhere. The binaries are
> definitely inside the MSI, though --the Wise Installation Studio
> manages to extract
> them-- so how do I get at them?
>

Embedded cabs are stored as a stream in the .msi. You can use the Dark
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode
> (msiexec /a ...) but with these MSIs, there's only a "Finished"
> dialog, and it took me a while to find that the files had been
> installed to Y:\ What do I need to do to make Admin installs
manageable from a WiX MSI?
>

The built-in UI doesn't have support for admin-image directory
selection, but you can use the command line to specify properties like
TARGETDIR.

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




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

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Jason Brenton]

Can these streams be accessed from an extension dll/customaction? It could
give some real convenient features and full installer control that way.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair
Sent: Wednesday, July 23, 2008 2:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Is there any other way to get the .cab out of the .msi? (I know about
NTFS file streams, but this must be something else.)

Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
(not the latest WiX 3))

Is it useful/appropriate to submit this as a bug? I'm guessing it's
maybe something specific to my WiX installation, because presumably dark
is working for other people. This is what dark says:

F:\b2\depot\dev\alan\ctxprodcodes\temp
> dark /x f:\bin Wix-3.0.4318.0.msi wix.xml
Microsoft (R) Windows Installer Xml Decompiler Version 2.0.5805.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.


Wix-3.0.4318.0.msi
dark.exe : error DARK0001 : Could not find file
'f:\bin\extract\1\lt0x6ngl.con'.

Exception Type: System.IO.FileNotFoundException

Stack Trace:
   at System.IO.__Error.WinIOError(Int32 errorCode, String
maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String
destFileName, Boolean overwrite)

   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTable(XmlWrite
r writer, String component, String keyPath, String componentPathShort,
String componentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentRecord(Xm
lWriter writer, String directory, String rootPathShort, String
rootPathLong, Record record)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentTable(Str
ing directory, String rootPathShort, String rootPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProductElement(Boo
lean writeDocumentElements)
   at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(String
inputPath, String outputPath)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)

Thanks 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used 
> Orca to extract the CAB, then used Windows Explorer to get at the 
> contents. But the MSIs produced by the WiX toolset on a project I've 
> inherited don't have a CAB visible anywhere. The binaries are 
> definitely inside the MSI, though --the Wise Installation Studio 
> manages to extract
> them-- so how do I get at them?
>   

Embedded cabs are stored as a stream in the .msi. You can use the Dark
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode 
> (msiexec /a ...) but with these MSIs, there's only a "Finished" 
> dialog, and it took me a while to find that the files had been 
> installed to Y:\ What do I need to do to make Admin installs
manageable from a WiX MSI?
>   

The built-in UI doesn't have support for admin-image directory
selection, but you can use the command line to specify properties like
TARGETDIR.

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




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

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

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Alan Sinclair]

Is there any other way to get the .cab out of the .msi? (I know about
NTFS file streams, but this must be something else.)

Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
(not the latest WiX 3))

Is it useful/appropriate to submit this as a bug? I'm guessing it's
maybe something specific to my WiX installation, because presumably dark
is working for other people. This is what dark says:

F:\b2\depot\dev\alan\ctxprodcodes\temp
> dark /x f:\bin Wix-3.0.4318.0.msi wix.xml
Microsoft (R) Windows Installer Xml Decompiler Version 2.0.5805.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.


Wix-3.0.4318.0.msi
dark.exe : error DARK0001 : Could not find file
'f:\bin\extract\1\lt0x6ngl.con'.

Exception Type: System.IO.FileNotFoundException

Stack Trace:
   at System.IO.__Error.WinIOError(Int32 errorCode, String
maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String
destFileName, Boolean overwrite)

   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTable(XmlWrite
r writer, String component, String keyPath, String componentPathShort,
String componentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentRecord(Xm
lWriter writer, String directory, String rootPathShort, String
rootPathLong, Record record)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentTable(Str
ing directory, String rootPathShort, String rootPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml
Writer writer, String parent, String parentPathShort, String
parentPathLong)
   at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProductElement(Boo
lean writeDocumentElements)
   at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(String
inputPath, String outputPath)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args)

Thanks 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used 
> Orca to extract the CAB, then used Windows Explorer to get at the 
> contents. But the MSIs produced by the WiX toolset on a project I've 
> inherited don't have a CAB visible anywhere. The binaries are 
> definitely inside the MSI, though --the Wise Installation Studio 
> manages to extract
> them-- so how do I get at them?
>   

Embedded cabs are stored as a stream in the .msi. You can use the Dark
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode 
> (msiexec /a ...) but with these MSIs, there's only a "Finished" 
> dialog, and it took me a while to find that the files had been 
> installed to Y:\ What do I need to do to make Admin installs
manageable from a WiX MSI?
>   

The built-in UI doesn't have support for admin-image directory
selection, but you can use the command line to specify properties like
TARGETDIR.

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




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

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

Re: [WiX-users] An easy way to set the ALLUSERS property if installing as admin

[Rob Mensching]

Can you provide a bit more of the full scenario?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bir, Steve
Sent: Wednesday, July 23, 2008 12:17
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] An easy way to set the ALLUSERS property if installing as 
admin

I have been looking for an easy way to set the ALLUSERS property if the
users has admin privs. Could anyone point me in the right direction?



Thank you



"There is nothing more important than our customers."

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


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

Re: [WiX-users] Build Fails with NAnt. The format of thefile 'NAntTasks.dll' is invalid.

[Gavin Bee]

Sounds like you need to pass the desired output path to msbuild from nant.
You can use the /property command line argument to msbuild.exe to pass
property values from NAnt into MSBUILD.

We use the a NAnt exec task that looks something like the following:
  






   

You could just add another argument to the list of args



You will then have to update your wixproj file to use these property values
to populate OutputPath and OutputName as appropriate.

Hope that helps,
Gavin :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Wednesday, July 23, 2008 2:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

Great, that worked. I was able to build my installer using my NAnt build
file. However. I need to specify an output path every time the .msi gets
built. Right now the output path is what is set in the protect
properties. The reason I need to separate the build versions is that
ultimately I need to look at the different versions to create patches.
Can you recommend a way to do this with the msbuild command?

Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Tuesday, July 22, 2008 5:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

One option to consider is using the shipping MSBuild .targets file that
has a complete build process for WiX in conjunction with NAnt. Trying to
re-construct a build process using individual tasks is often fraught
with peril, and using the one that ships with WiX is almost always a
better idea.

You would create a .wixproj that uses the MSBuild process for building
WiX (a quick way to do this is to create a WiX project in Visual
Studio), and then in your nant build script just do . You'll get our well-tested and supported
build process for free, yet still be able to use nant as your overall
build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric






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



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


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


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event an

Re: [WiX-users] session.GetProdutProperty() always throws InvalidHandleException

[Jason Ginchereau]

Oh, now I see it. Session.GetProductProperty() is not the API you're looking 
for. That one calls into MsiGetProductProperty 
(http://msdn.microsoft.com/en-us/library/aa370133.aspx) which is only callable 
on a Session obtained from MsiOpenProduct.

To get and set ordinary installation properties, use the indexer on the Session 
class. For example: session["FOO"]

Since this confused even me, I should make sure it's clear in the DTF 
documentation. Honestly I don't fully understand the purpose of that other API.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Hopper
Sent: Wednesday, July 23, 2008 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

The custom action is set to "immediate", I've also tried "commit".









   
   
   


Thanks,
-Nate

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau
Sent: Wednesday, July 23, 2008 11:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

Is your custom action deferred? Deferred CAs cannot access properties other 
than CustomActionData.

Sources are in the wix3-sources.zip in the release folder of each build. There 
is a wix3-pdbs.zip that comes out of every build, but it isn't getting 
published -- I think because SF doesn't give us enough space. You can always 
build the sources yourself to get symbols.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Hopper
Sent: Wednesday, July 23, 2008 10:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

Wix Build - 3.0.4318.0

I'm using the new "C# Custom Action Project" to build a managed custom action.  
When invoking session.GetProductProperty("FOO"),  an InvalidHandleException is 
always thrown.  Calls to session.Log() are processes normally and messages do 
appear in the install log indicting that at least in some cases the handle is 
still valid.  Any ideas?

[Microsoft.Deployment.WindowsInstaller.InvalidHandleException] {"The 
handle is invalid."}

Stack Trace:
   at Microsoft.Deployment.WindowsInstaller.Session.GetProductProperty(String 
property)
   at CustomAction1.CustomActions.CustomAction1(Session session)


Where can I find the source/symbols for 
Microsoft.Deployment.WindowsInstaller.dll?

Thanks,
-Nate



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

[WiX-users] An easy way to set the ALLUSERS property if installing as admin

[Bir, Steve]

I have been looking for an easy way to set the ALLUSERS property if the
users has admin privs. Could anyone point me in the right direction?

 

Thank you

 

"There is nothing more important than our customers."

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

Re: [WiX-users] DTF - Using ExtractFiles Method

[Powell, Simon]

Thank you that's excellent news. 


Regards
Simon Powell

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: 23 July 2008 17:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method

I should be able to get the fix into this week's build.

The workaround would be to edit the problematic File table keys in the
MSI so that they match the case of the filenames in the cabinet.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Powell,
Simon
Sent: Wednesday, July 23, 2008 12:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method


Do you have any idea when you might be able to fix this issue?  If
priority is low, can you think of a possible workround? I don't really
want to use an admin install.

Regards
Simon Powell

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: 22 July 2008 20:14
To: General discussion for Windows Installer XML toolset.
Cc: Jones, Ben
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method

It's a bug in DTF -- ExtractFiles is being case-sensitive where it
shouldn't. A few of the files in Cabs.winrk.cab have different casing
than their File table keys in rktools.msi. The Windows Installer engine
handles that okay but DTF doesn't. Can you open a bug on SourceForge for
tracking?

However the problem with SQL Server 2005 client tools is different.
There, the Media.Cabinet value is "#Sql.cab". The number sign (#)
indicates the cabinet should be in an embedded stream in the MSI
package, but it is not actually there! Running msiexec /a on that
package confirms the problem as it gives error 2356. "Could not locate
cabinet in stream: Sql.cab." Maybe their bootstrapper does something to
fixup the MSI at install time?

-Jason-

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Powell,
Simon
Sent: Monday, July 21, 2008 3:11 PM
To: wix-users@lists.sourceforge.net
Cc: Jones, Ben
Subject: [WiX-users] DTF - Using ExtractFiles Method

Hi,

I'm using the ExtractFiles Method to extract files from the Windows 2003
Resource kit msi (rktools.msi). Below is a simple snippet of code used :

InstallPackage MsiPackage = new InstallPackage(txtMsi.Text,
DatabaseOpenMode.ReadOnly); MsiPackage.WorkingDirectory = "c:\\temp";
Regex myReg = new Regex("exe", RegexOptions.IgnoreCase); string[]
filekeys = MsiPackage.FindFiles(myReg);
MsiPackage.ExtractFiles(filekeys);

Some of the files fail to extract return the following
FileNotFoundException :

Could not find file 'c:\temp\Program Files\Windows Resource
Kits\Tools\nlsinfo.exe'.

It's strange, because the file exists in the extracted cab file
(Cabs.winrk.cab), all the files extract correctly to c:\temp if I use
msiexec /a rktools.msi (but this  gives me no control over the files I
extract). Is this a bug or am I doing something wrong? This problem
happens with a number of MSIs including sqlrun.msi of the SQL Server
2005 client tools.

Your help will be much appreciated.

Regards
Simon Powell





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


--
This e-mail is confidential and the information contained in it may be
privileged.  It should not be read, copied or used by anyone other than
the intended recipient.  If you have received it in error, please
contact the sender immediately by telephoning +44 (0)20 7623 8000 or by
return email, and delete the e-mail and do not disclose its contents to
any person.  We believe, but do not warrant, that this e-mail and any
attachments are virus free, but you must take full responsibility for
virus checking.  Please refer to
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail
disclaimer statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking
division of Dresdner Bank AG, and operates through Dresdner Bank AG,
Dresdner Kleinwort Limited, Dresdner Kleinwort Securities Limited and
their affiliated or associated companies.  Dresdner Bank AG is a company
incorporated in Germany with limited liability and registered in England
(registered no. FC007638, place of business 30 Gresham Street, London
EC2V 7PG), and is authorised by the German Federal Financial Supervisory
Authority and by the Financial Services Authority ('FSA') and regulated
by the FSA for the conduct of designated business in t

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Alan Sinclair]

Thanks! 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used 
> Orca to extract the CAB, then used Windows Explorer to get at the 
> contents. But the MSIs produced by the WiX toolset on a project I've 
> inherited don't have a CAB visible anywhere. The binaries are 
> definitely inside the MSI, though --the Wise Installation Studio 
> manages to extract
> them-- so how do I get at them?
>   

Embedded cabs are stored as a stream in the .msi. You can use the Dark
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode 
> (msiexec /a ...) but with these MSIs, there's only a "Finished" 
> dialog, and it took me a while to find that the files had been 
> installed to Y:\ What do I need to do to make Admin installs
manageable from a WiX MSI?
>   

The built-in UI doesn't have support for admin-image directory
selection, but you can use the command line to specify properties like
TARGETDIR.

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




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

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

Re: [WiX-users] session.GetProdutProperty() always throws InvalidHandleException

[Nathan Hopper]

The custom action is set to "immediate", I've also tried "commit".









   
   
   


Thanks,
-Nate

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau
Sent: Wednesday, July 23, 2008 11:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

Is your custom action deferred? Deferred CAs cannot access properties other 
than CustomActionData.

Sources are in the wix3-sources.zip in the release folder of each build. There 
is a wix3-pdbs.zip that comes out of every build, but it isn't getting 
published -- I think because SF doesn't give us enough space. You can always 
build the sources yourself to get symbols.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Hopper
Sent: Wednesday, July 23, 2008 10:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

Wix Build - 3.0.4318.0

I'm using the new "C# Custom Action Project" to build a managed custom action.  
When invoking session.GetProductProperty("FOO"),  an InvalidHandleException is 
always thrown.  Calls to session.Log() are processes normally and messages do 
appear in the install log indicting that at least in some cases the handle is 
still valid.  Any ideas?

[Microsoft.Deployment.WindowsInstaller.InvalidHandleException] {"The 
handle is invalid."}

Stack Trace:
   at Microsoft.Deployment.WindowsInstaller.Session.GetProductProperty(String 
property)
   at CustomAction1.CustomActions.CustomAction1(Session session)


Where can I find the source/symbols for 
Microsoft.Deployment.WindowsInstaller.dll?

Thanks,
-Nate


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

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

Re: [WiX-users] Build Fails with NAnt. The format of thefile 'NAntTasks.dll' is invalid.

[Eric Latendresse]

Great, that worked. I was able to build my installer using my NAnt build
file. However. I need to specify an output path every time the .msi gets
built. Right now the output path is what is set in the protect
properties. The reason I need to separate the build versions is that
ultimately I need to look at the different versions to create patches.
Can you recommend a way to do this with the msbuild command?

Eric Latendresse



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Tuesday, July 22, 2008 5:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of thefile
'NAntTasks.dll' is invalid.

One option to consider is using the shipping MSBuild .targets file that
has a complete build process for WiX in conjunction with NAnt. Trying to
re-construct a build process using individual tasks is often fraught
with peril, and using the one that ships with WiX is almost always a
better idea.

You would create a .wixproj that uses the MSBuild process for building
WiX (a quick way to do this is to create a WiX project in Visual
Studio), and then in your nant build script just do . You'll get our well-tested and supported
build process for free, yet still be able to use nant as your overall
build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric






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



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


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

Re: [WiX-users] Build Fails with NAnt. The format of the file 'NAntTasks.dll' is invalid.

[Gavin Bee]

We execute msbuild from nant to build our products and wix installers.  The
key to making this integration relatively painless was Szymon Kobalczyk's
Xml Logger for MSBuild.  Have a look at
http://geekswithblogs.net/kobush/articles/xmllogger.aspx for details.

Gavin :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Wednesday, July 23, 2008 3:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

In my experience changing to use msbuild from nant isn't as easy as it
seems. When it is all working there isn't a problem but seeing errors
reported correctly especially in my integration tool of choice (ccnet) is
particularly hard (I had to resort to parsing the output file). This also
assumes that your projects are edited using a VS wixproj - this isn't always
the case.
 
Now a plea to the WiX team - please don't drop nant support in favour of
msbuild. 
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Tue 22/07/2008 23:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.



One option to consider is using the shipping MSBuild .targets file that has
a complete build process for WiX in conjunction with NAnt. Trying to
re-construct a build process using individual tasks is often fraught with
peril, and using the one that ships with WiX is almost always a better idea.

You would create a .wixproj that uses the MSBuild process for building WiX
(a quick way to do this is to create a WiX project in Visual Studio), and
then in your nant build script just do . You'll get our well-tested and supported
build process for free, yet still be able to use nant as your overall build
driver.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric





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


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




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

Re: [WiX-users] session.GetProdutProperty() always throws InvalidHandleException

[Jason Ginchereau]

Is your custom action deferred? Deferred CAs cannot access properties other 
than CustomActionData.

Sources are in the wix3-sources.zip in the release folder of each build. There 
is a wix3-pdbs.zip that comes out of every build, but it isn't getting 
published -- I think because SF doesn't give us enough space. You can always 
build the sources yourself to get symbols.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Hopper
Sent: Wednesday, July 23, 2008 10:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] session.GetProdutProperty() always throws 
InvalidHandleException

Wix Build - 3.0.4318.0

I'm using the new "C# Custom Action Project" to build a managed custom action.  
When invoking session.GetProductProperty("FOO"),  an InvalidHandleException is 
always thrown.  Calls to session.Log() are processes normally and messages do 
appear in the install log indicting that at least in some cases the handle is 
still valid.  Any ideas?

[Microsoft.Deployment.WindowsInstaller.InvalidHandleException] {"The 
handle is invalid."}

Stack Trace:
   at Microsoft.Deployment.WindowsInstaller.Session.GetProductProperty(String 
property)
   at CustomAction1.CustomActions.CustomAction1(Session session)


Where can I find the source/symbols for 
Microsoft.Deployment.WindowsInstaller.dll?

Thanks,
-Nate


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

[WiX-users] session.GetProdutProperty() always throws InvalidHandleException

[Nathan Hopper]

Wix Build - 3.0.4318.0

I'm using the new "C# Custom Action Project" to build a managed custom action.  
When invoking session.GetProductProperty("FOO"),  an InvalidHandleException is 
always thrown.  Calls to session.Log() are processes normally and messages do 
appear in the install log indicting that at least in some cases the handle is 
still valid.  Any ideas?

[Microsoft.Deployment.WindowsInstaller.InvalidHandleException] {"The 
handle is invalid."}

Stack Trace:
   at Microsoft.Deployment.WindowsInstaller.Session.GetProductProperty(String 
property)
   at CustomAction1.CustomActions.CustomAction1(Session session)


Where can I find the source/symbols for 
Microsoft.Deployment.WindowsInstaller.dll?

Thanks,
-Nate

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

Re: [WiX-users] Merge Module Help

[Christopher Painter]

What feedback?  All I saw was a childish quip/troll post.

Personally I'm sick of the component rules and it's associated gotchas.  These 
are artificial problem caused by an overly complicated design. 

Developers want xcopy simplicity.   The features are nice from a platform 
presevatin perspective but nearly 10 years have gone by since it was invented 
and we are still sitting around a table scratching our head how to solve the 
authoring headaches that it created.  Talk about analysis paralysis.



--- On Wed, 7/23/08, Rob Mensching <[EMAIL PROTECTED]> wrote:

> From: Rob Mensching <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 23, 2008, 11:39 AM
> Hey, wait a minute here.
> 
> First, Automating Component/@Guids requires a bullet-proof
> solution. The side-effects of violating the Component Rules
> are nasty on two fronts a) once violated there are no real
> good ways out (something will get messed up on the
> user's machine) and b) you don't usually realize
> you've violated the rules until it is too late (like
> when you need a critical security fix).  If you're
> going to suggest a solution to this problem then expect it
> to be "pedantically picked through".  From there
> you should adapt your solution based on feedback or specify
> how the feedback is actually addressed by the solution or
> note that your solution doesn't work and try something
> different.  Partial success isn't an option here
> because the "partial failures" are so horrible.
> 
> 
> Second, please take the personal comments elsewhere.  This
> is where we talk about the WiX toolset.
> 
> 
> Thank you.
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Bob Arnson
> Sent: Wednesday, July 23, 2008 08:54
> To: [EMAIL PROTECTED]
> Cc: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
> 
> Christopher Painter wrote:
> > Once again you pedantically pick through my comment
> without actually offering anything constructive yourself.
> 
> Wow, I'm really put in my place, aren't I?
> 
> --
> sig://boB
> http://joyofsetup.com/
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

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

Re: [WiX-users] Multiple Installs without Un-Install?

[Christopher Painter]

It sounds like your MSI doesn't really install a product but is just a wrapper 
for some sort of configuration utility that is designed to create database 
instances and quit.

Does that sound right?


--- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:

> From: Daniel Zak <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> To: [EMAIL PROTECTED], "General discussion for Windows Installer XML 
> toolset." 
> Date: Wednesday, July 23, 2008, 12:04 PM
> The user wants to have the ability to install a database
> from any remote
> machine. Also, additional databases would be installed at
> some other point
> in time (e.g. perhaps 3 months later the user decides they
> need a second
> database).
> 
> Ideally, the MSI would un-install itself after it finished
> creating the
> database.
> Cheers,
> Daniel
> 
> On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter <
> [EMAIL PROTECTED]> wrote:
> 
> > You could modify the maintenance UI experience to have
> an option for
> > creating additional database instances which would
> then execute your script
> > again but I'm wondering if it wouldn't be
> simpler to just write a small
> > application utility and put it in the start menu to
> allow a user to perform
> > database management functions like creating additional
> named database
> > instances.
> >
> > How do you feel about that?
> >
> > --- On Wed, 7/23/08, Daniel Zak
> <[EMAIL PROTECTED]> wrote:
> >
> > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > Subject: Re: [WiX-users] Multiple Installs
> without Un-Install?
> > > To: wix-users@lists.sourceforge.net
> > > Date: Wednesday, July 23, 2008, 1:28 AM
> >  > Hi Christopher,
> > >
> > > I need multiple instances only of the database.
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > > Message: 9
> > > > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > > > From: Christopher Painter
> > > <[EMAIL PROTECTED]>
> > > > Subject: Re: [WiX-users] Multiple Installs
> without
> > > Un-Install?
> > > > To: "General discussion for Windows
> Installer XML
> > > toolset."
> > > >   
> 
> > > > Message-ID:
> > >
> <[EMAIL PROTECTED]>
> > > > Content-Type: text/plain; charset=us-ascii
> > > >
> > > > Windows Installer supports multiple instance
> > > installation, but the question
> > > > I have is do you need multiple instances of
> your
> > > product or only multiple
> > > > instances of your database?
> > > >
> > > > Christopher Painter, Author of Deployment
> Engineering
> > > Blog
> > > > Have a hot tip, know a secret or read a
> really good
> > > thread that deserves
> > > > attention? E-Mail Me
> > > >
> > > >
> > > > --- On Mon, 7/21/08, Daniel Zak
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > From: Daniel Zak
> <[EMAIL PROTECTED]>
> > > > > Subject: [WiX-users] Multiple Installs
> without
> > > Un-Install?
> > > > > To: wix-users@lists.sourceforge.net
> > > > > Date: Monday, July 21, 2008, 11:51 PM
> > > > > Hello,
> > > > >
> > > > > I created a script to install an SQL
> Server
> > > database. A
> > > > > user needs to be
> > > > > able to run the script multiple times
> to install
> > > multiple
> > > > > databases.
> > > > > However, the script requires the user
> to first
> > > un-install
> > > > > the product (which
> > > > > does not delete the database) before
> being able
> > > to install
> > > > > a new database.
> > > > >
> > > > > Is there anything I can do to avoid
> requiring the
> > > user to
> > > > > explicitly
> > > > > un-install the product?
> > > > >
> > > > > I included an extract of the script as
> a text
> > > file.
> > > > >
> > > > > Thank you,
> > > > > Daniel
> > >
> -
> > > This SF.Net email is sponsored by the Moblin Your
> Move
> > > Developer's challenge
> > > Build the coolest Linux based applications with
> Moblin SDK
> > > & win great prizes
> > > Grand prize is a trip for two to an Open Source
> event
> > > anywhere in the world
> > >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> >
> -
> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin
> SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event
> anywhere in the world
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >


  

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
B

Re: [WiX-users] Multiple Installs without Un-Install?

[John Nannenga]

> Ideally, the MSI would un-install itself after it finished creating the
> database.

This might be off topic, but curiosity got the best of me; given that to be the 
case, why would this be in an MSI at all?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Zak
Sent: Wednesday, July 23, 2008 12:05 PM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Installs without Un-Install?

The user wants to have the ability to install a database from any remote
machine. Also, additional databases would be installed at some other point
in time (e.g. perhaps 3 months later the user decides they need a second
database).

Ideally, the MSI would un-install itself after it finished creating the
database.
Cheers,
Daniel

On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter <
[EMAIL PROTECTED]> wrote:

> You could modify the maintenance UI experience to have an option for
> creating additional database instances which would then execute your script
> again but I'm wondering if it wouldn't be simpler to just write a small
> application utility and put it in the start menu to allow a user to perform
> database management functions like creating additional named database
> instances.
>
> How do you feel about that?
>
> --- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:
>
> > From: Daniel Zak <[EMAIL PROTECTED]>
> > Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> > To: wix-users@lists.sourceforge.net
> > Date: Wednesday, July 23, 2008, 1:28 AM
>  > Hi Christopher,
> >
> > I need multiple instances only of the database.
> >
> > Cheers,
> > Daniel
> >
> >
> > > Message: 9
> > > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > > From: Christopher Painter
> > <[EMAIL PROTECTED]>
> > > Subject: Re: [WiX-users] Multiple Installs without
> > Un-Install?
> > > To: "General discussion for Windows Installer XML
> > toolset."
> > >
> > > Message-ID:
> > <[EMAIL PROTECTED]>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > Windows Installer supports multiple instance
> > installation, but the question
> > > I have is do you need multiple instances of your
> > product or only multiple
> > > instances of your database?
> > >
> > > Christopher Painter, Author of Deployment Engineering
> > Blog
> > > Have a hot tip, know a secret or read a really good
> > thread that deserves
> > > attention? E-Mail Me
> > >
> > >
> > > --- On Mon, 7/21/08, Daniel Zak
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > > Subject: [WiX-users] Multiple Installs without
> > Un-Install?
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Monday, July 21, 2008, 11:51 PM
> > > > Hello,
> > > >
> > > > I created a script to install an SQL Server
> > database. A
> > > > user needs to be
> > > > able to run the script multiple times to install
> > multiple
> > > > databases.
> > > > However, the script requires the user to first
> > un-install
> > > > the product (which
> > > > does not delete the database) before being able
> > to install
> > > > a new database.
> > > >
> > > > Is there anything I can do to avoid requiring the
> > user to
> > > > explicitly
> > > > un-install the product?
> > > >
> > > > I included an extract of the script as a text
> > file.
> > > >
> > > > Thank you,
> > > > Daniel
> > -
> > This SF.Net email is sponsored by the Moblin Your Move
> > Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK
> > & win great prizes
> > Grand prize is a trip for two to an Open Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.so

Re: [WiX-users] source and src from tallow

[F. David del Campo Hill]

Dear Brian,

Thanks for the info.

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rogers
Sent: 23 July 2008 17:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] source and src from tallow

Hey David,

It looks like build 2.0.5325.0 (
http://wix.cvs.sourceforge.net/wix/wix2.0/inc/wixver.h?r1=1.35&r2=1.36).
This matches the check-in date for the change below.

http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?r1=1.4&r2=1.5
http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=log

Revision *1.5* -
(view)
(download)
(annotate)
- [select for 
diffs]
*Wed Jun 27 05:42:52 2007 UTC* (12 months, 3 weeks ago) by *robmen*
Branch: 
*MAIN*
CVS Tags: 
*HEAD*
Changes since *1.4: +5 -1 lines*

BobArnso: sfbug:1680395 - emit File/@Source instead of src

Thanks,

--
Brian Rogers
"Intelligence removes complexity." - Me
http://www.codeplex.com/wixml/


On Wed, Jul 23, 2008 at 4:08 AM, F. David del Campo Hill <
[EMAIL PROTECTED]> wrote:

> Dear WiX,
>
>We have a build process for a statistical application which uses WiX
> to create a MSI for distribution over Active Directory. This process creates
> a files.wxs fragment using tallow.exe, and then parses it through a Perl
> script to create a .wxs file which candle.exe and light.exe can compile.
> This Perl script is obviously very sensitive to the format tallow.exe
> outputs. We have found that if we compile with tallow.exe from WiX
> 2.0.4221.0, the fragment created has "src=" in its Components, while with
> the latest tallow.exe from WiX 2.0.5805.0, it uses "Source=".
>
>We have changed the script to fit the newer format, but we still
> need to advise our users on the difference and I would like to ask: which
> was the first version where tallow.exe started to use "Source=" instead of
> "src="?
>
>Thank you for your time.
>
>Yours,
>
>F. David del Campo Hill
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

Re: [WiX-users] Multiple Installs without Un-Install?

[Daniel Zak]

The user wants to have the ability to install a database from any remote
machine. Also, additional databases would be installed at some other point
in time (e.g. perhaps 3 months later the user decides they need a second
database).

Ideally, the MSI would un-install itself after it finished creating the
database.
Cheers,
Daniel

On Wed, Jul 23, 2008 at 6:19 AM, Christopher Painter <
[EMAIL PROTECTED]> wrote:

> You could modify the maintenance UI experience to have an option for
> creating additional database instances which would then execute your script
> again but I'm wondering if it wouldn't be simpler to just write a small
> application utility and put it in the start menu to allow a user to perform
> database management functions like creating additional named database
> instances.
>
> How do you feel about that?
>
> --- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:
>
> > From: Daniel Zak <[EMAIL PROTECTED]>
> > Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> > To: wix-users@lists.sourceforge.net
> > Date: Wednesday, July 23, 2008, 1:28 AM
>  > Hi Christopher,
> >
> > I need multiple instances only of the database.
> >
> > Cheers,
> > Daniel
> >
> >
> > > Message: 9
> > > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > > From: Christopher Painter
> > <[EMAIL PROTECTED]>
> > > Subject: Re: [WiX-users] Multiple Installs without
> > Un-Install?
> > > To: "General discussion for Windows Installer XML
> > toolset."
> > >
> > > Message-ID:
> > <[EMAIL PROTECTED]>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > Windows Installer supports multiple instance
> > installation, but the question
> > > I have is do you need multiple instances of your
> > product or only multiple
> > > instances of your database?
> > >
> > > Christopher Painter, Author of Deployment Engineering
> > Blog
> > > Have a hot tip, know a secret or read a really good
> > thread that deserves
> > > attention? E-Mail Me
> > >
> > >
> > > --- On Mon, 7/21/08, Daniel Zak
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > > Subject: [WiX-users] Multiple Installs without
> > Un-Install?
> > > > To: wix-users@lists.sourceforge.net
> > > > Date: Monday, July 21, 2008, 11:51 PM
> > > > Hello,
> > > >
> > > > I created a script to install an SQL Server
> > database. A
> > > > user needs to be
> > > > able to run the script multiple times to install
> > multiple
> > > > databases.
> > > > However, the script requires the user to first
> > un-install
> > > > the product (which
> > > > does not delete the database) before being able
> > to install
> > > > a new database.
> > > >
> > > > Is there anything I can do to avoid requiring the
> > user to
> > > > explicitly
> > > > un-install the product?
> > > >
> > > > I included an extract of the script as a text
> > file.
> > > >
> > > > Thank you,
> > > > Daniel
> > -
> > This SF.Net email is sponsored by the Moblin Your Move
> > Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK
> > & win great prizes
> > Grand prize is a trip for two to an Open Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module Help

[John Hall]

> 1.  How do you manage updates to the "database" in source 
> control?  Do people update the file before building or does 
> the build machine checkout/checkin automatically?  If the 
> latter, what source control systems does it support... (you 
> can see where I'm going )?

We use cvsnt as our source control system, and my build/release script
does an update before building. The custom build task currently just
generates a build warning if it's had to update the database, and that's
my cue to commit the file back into CVS. There's probably nothing
stopping me from making the commit automatic, but it means I can keep an
eye on what is going on.

> 2.  How is this better than using auto-generated-stable Guids?

It's probably not. I'm not sure heat had that functionality when I
implemented what I have implemented, and I wasn't aware that
auto-generated GUIDs were possible.

It's worth noting that I only use this method for parts of the installer
where there are collections of simple files that need installing, with
no other resources. These files are changed by other people on the team,
sometimes people who are not developers, and so it makes my life easy to
harvest them. I've got it working well enough for our environment and
the constraints we operate under; it may not work so well for others.
For example, I also have build tasks that generate wxs fragments for VB6
COM controls, stripping out some of the needless stuff that VB puts in
the registry, which is duplicated across all controls, again using a
similar scheme to store GUID state.

Regards,
John

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

Re: [WiX-users] Merge Module Help

[Rob Mensching]

IMHO, when you automate part of the process, you take responsibility for the 
automation always being correct.  To me that means the automation needs to be 
able to handle all of the scenarios.  Patching is one of the scenarios.  Run 
the deduction to the end and you see what a difficult problem the 
Component/@Guid creates.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 08:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help

Christopher Karper wrote:
> FWIW, I personally would rather manage the process by exception, instead of
> *always*.
>

Yes, some help is usually better than none. It's all about managing
expectations. If it's possible to automatically generate the original
setups, not being able to generate patches might be surprising.

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



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


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

Re: [WiX-users] Merge Module Help

[Rob Mensching]

1.  How do you manage updates to the "database" in source control?  Do people 
update the file before building or does the build machine checkout/checkin 
automatically?  If the latter, what source control systems does it support... 
(you can see where I'm going )?

2.  How is this better than using auto-generated-stable Guids?


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall
Sent: Wednesday, July 23, 2008 01:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help

> The case that gets really tricky is to have one build where a Resource

> disappears (usually accidentally) then the next build where the
> Resource comes back.  It needs to get the same Component and GUID.

I have written a tool that auto-generates .wxs files for some parts of
my project - we ship a lot of example scripts. It only handles files and
generates one component per file. The tool maintains a database (well,
an XML file) that lists all the GUIDs ever allocated, and adds entries
as it needs. That file is kept in source control.

This seems to work well for me - have I missed something important?

Regards,
John

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


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

Re: [WiX-users] source and src from tallow

[Brian Rogers]

Hey David,

It looks like build 2.0.5325.0 (
http://wix.cvs.sourceforge.net/wix/wix2.0/inc/wixver.h?r1=1.35&r2=1.36).
This matches the check-in date for the change below.

http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?r1=1.4&r2=1.5
http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=log

Revision *1.5* -
(view)
(download)
(annotate)
- [select for 
diffs]
*Wed Jun 27 05:42:52 2007 UTC* (12 months, 3 weeks ago) by *robmen*
Branch: 
*MAIN*
CVS Tags: 
*HEAD*
Changes since *1.4: +5 -1 lines*

BobArnso: sfbug:1680395 - emit File/@Source instead of src

Thanks,

-- 
Brian Rogers
"Intelligence removes complexity." - Me
http://www.codeplex.com/wixml/


On Wed, Jul 23, 2008 at 4:08 AM, F. David del Campo Hill <
[EMAIL PROTECTED]> wrote:

> Dear WiX,
>
>We have a build process for a statistical application which uses WiX
> to create a MSI for distribution over Active Directory. This process creates
> a files.wxs fragment using tallow.exe, and then parses it through a Perl
> script to create a .wxs file which candle.exe and light.exe can compile.
> This Perl script is obviously very sensitive to the format tallow.exe
> outputs. We have found that if we compile with tallow.exe from WiX
> 2.0.4221.0, the fragment created has "src=" in its Components, while with
> the latest tallow.exe from WiX 2.0.5805.0, it uses "Source=".
>
>We have changed the script to fit the newer format, but we still
> need to advise our users on the difference and I would like to ask: which
> was the first version where tallow.exe started to use "Source=" instead of
> "src="?
>
>Thank you for your time.
>
>Yours,
>
>F. David del Campo Hill
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module Help

[Rob Mensching]

ClickThrough also ensures that there is no overlap between the versions.  
That's important to remember as well.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 09:17
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help

John Hall wrote:
> Ah, we don't do patches, which is why it works for me :)
>

That's also an option. That's what ClickThrough does, using "early"
major upgrades every time. In that case, you don't even need stable IDs.

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


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


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

Re: [WiX-users] Merge Module Help

[Rob Mensching]

Hey, wait a minute here.

First, Automating Component/@Guids requires a bullet-proof solution. The 
side-effects of violating the Component Rules are nasty on two fronts a) once 
violated there are no real good ways out (something will get messed up on the 
user's machine) and b) you don't usually realize you've violated the rules 
until it is too late (like when you need a critical security fix).  If you're 
going to suggest a solution to this problem then expect it to be "pedantically 
picked through".  From there you should adapt your solution based on feedback 
or specify how the feedback is actually addressed by the solution or note that 
your solution doesn't work and try something different.  Partial success isn't 
an option here because the "partial failures" are so horrible.


Second, please take the personal comments elsewhere.  This is where we talk 
about the WiX toolset.


Thank you.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 08:54
To: [EMAIL PROTECTED]
Cc: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help

Christopher Painter wrote:
> Once again you pedantically pick through my comment without actually offering 
> anything constructive yourself.

Wow, I'm really put in my place, aren't I?

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


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


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

Re: [WiX-users] Merge Module Help

[Bob Arnson]

John Hall wrote:
> Ah, we don't do patches, which is why it works for me :)
>   

That's also an option. That's what ClickThrough does, using "early" 
major upgrades every time. In that case, you don't even need stable IDs.

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


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

Re: [WiX-users] Merge Module Help

[John Hall]

> John Hall wrote:

> > I have written a tool that auto-generates .wxs files for some parts
> > of my project - we ship a lot of example scripts. It only handles
> > files and generates one component per file. The tool maintains a
> > database (well, an XML file) that lists all the GUIDs ever
> > allocated, and adds entries as it needs. That file is kept in source
> > control.
> >
> > This seems to work well for me - have I missed something important?
> >   
> 
> What happens when someone wants to remove a file? (You can't 
> remove a component in a patch.)

Ah, we don't do patches, which is why it works for me :)

John

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

Re: [WiX-users] DTF - Using ExtractFiles Method

[Jason Ginchereau]

I should be able to get the fix into this week's build.

The workaround would be to edit the problematic File table keys in the MSI so 
that they match the case of the filenames in the cabinet.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Powell, Simon
Sent: Wednesday, July 23, 2008 12:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method


Do you have any idea when you might be able to fix this issue?  If
priority is low, can you think of a possible workround? I don't really
want to use an admin install.

Regards
Simon Powell

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: 22 July 2008 20:14
To: General discussion for Windows Installer XML toolset.
Cc: Jones, Ben
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method

It's a bug in DTF -- ExtractFiles is being case-sensitive where it
shouldn't. A few of the files in Cabs.winrk.cab have different casing
than their File table keys in rktools.msi. The Windows Installer engine
handles that okay but DTF doesn't. Can you open a bug on SourceForge for
tracking?

However the problem with SQL Server 2005 client tools is different.
There, the Media.Cabinet value is "#Sql.cab". The number sign (#)
indicates the cabinet should be in an embedded stream in the MSI
package, but it is not actually there! Running msiexec /a on that
package confirms the problem as it gives error 2356. "Could not locate
cabinet in stream: Sql.cab." Maybe their bootstrapper does something to
fixup the MSI at install time?

-Jason-

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Powell,
Simon
Sent: Monday, July 21, 2008 3:11 PM
To: wix-users@lists.sourceforge.net
Cc: Jones, Ben
Subject: [WiX-users] DTF - Using ExtractFiles Method

Hi,

I'm using the ExtractFiles Method to extract files from the Windows 2003
Resource kit msi (rktools.msi). Below is a simple snippet of code used :

InstallPackage MsiPackage = new InstallPackage(txtMsi.Text,
DatabaseOpenMode.ReadOnly); MsiPackage.WorkingDirectory = "c:\\temp";
Regex myReg = new Regex("exe", RegexOptions.IgnoreCase); string[]
filekeys = MsiPackage.FindFiles(myReg);
MsiPackage.ExtractFiles(filekeys);

Some of the files fail to extract return the following
FileNotFoundException :

Could not find file 'c:\temp\Program Files\Windows Resource
Kits\Tools\nlsinfo.exe'.

It's strange, because the file exists in the extracted cab file
(Cabs.winrk.cab), all the files extract correctly to c:\temp if I use
msiexec /a rktools.msi (but this  gives me no control over the files I
extract). Is this a bug or am I doing something wrong? This problem
happens with a number of MSIs including sqlrun.msi of the SQL Server
2005 client tools.

Your help will be much appreciated.

Regards
Simon Powell





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


--
This e-mail is confidential and the information contained in it may be 
privileged.  It should not be read, copied or used by anyone other than the 
intended recipient.  If you have received it in error, please contact the 
sender immediately by telephoning +44 (0)20 7623 8000 or by return email, and 
delete the e-mail and do not disclose its contents to any person.  We believe, 
but do not warrant, that this e-mail and any attachments are virus free, but 
you must take full responsibility for virus checking.  Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of 
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort 
Limited, Dresdner Kleinwort Securities Limited and their affiliated or 
associated companies.  Dresdner Bank AG is a company incorporated in Germany 
with limited liability and registered in England (registered no. FC007638, 
place of business 30 Gresham Street, London EC2V 7PG), and is authorised by the 
German Federal Financial Supervisory Authority and by the Financial Services 
Authority ('FSA') and regulated by the FSA for the conduct of designated 
business in the UK.  Dresdner Kleinwort Limited is a company incorporated in 
England (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG), and is authorised and regulated by the FSA.  Dresdner Kleinwort 
Securities Limited is a company incorporated in England (registered no.

Re: [WiX-users] Merge Module Help

[Bob Arnson]

Christopher Painter wrote:
> Once again you pedantically pick through my comment without actually offering 
> anything constructive yourself. 

Wow, I'm really put in my place, aren't I?

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


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

Re: [WiX-users] Merge Module Help

[Christopher Painter]

I was thinking that the missing file would be the exception.  Can you clarify 
what you have in mind?


--- On Wed, 7/23/08, Christopher Karper <[EMAIL PROTECTED]> wrote:

> From: Christopher Karper <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 23, 2008, 10:38 AM
> FWIW, I personally would rather manage the process by
> exception, instead of
> *always*.
> 
> Chris
> 
> On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson
> <[EMAIL PROTECTED]> wrote:
> 
> > Christopher Painter wrote:
> > > This would be a pretty easy scenario to handle. 
> Check the WXS against
> > the XML and if a component is missing, throw an error
> and suggest the
> > puncture component pattern ( transitive=true
> condition=false,  0 byte files
> > for storage )
> > >
> >
> > "Throw an error" isn't the kind of
> automation most people are looking for.
> >
> > --
> > sig://boB
> > http://joyofsetup.com/
> >
> >
> >
> >
> -
> > This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin
> SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event
> anywhere in the world
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

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

Re: [WiX-users] Merge Module Help

[Bob Arnson]

Christopher Karper wrote:
> FWIW, I personally would rather manage the process by exception, instead of
> *always*.
>   

Yes, some help is usually better than none. It's all about managing 
expectations. If it's possible to automatically generate the original 
setups, not being able to generate patches might be surprising.

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



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

Re: [WiX-users] Register DLL for use with Microsoft Management Console

[Bob Arnson]

Christopher Karper wrote:
> There's a snap-in CA that Wix offers, but I believe it's for powershell, not
> MMC.  

There's an extension in WiX v2 for MMC but nobody's had the occasion to 
migrate it to WiX v3...

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



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

Re: [WiX-users] Merge Module Help

[Christopher Painter]

Once again you pedantically pick through my comment without actually offering 
anything constructive yourself. Do you feel better now?   FWIW it would be nice 
if you applied your own comment to programs like HEAT because when I saw run a 
heat harvest command and get a JIT exception, that's certainly not the behavior 
that I'm looking for in a tool that's supposed to make life easier not harder.

Information, Warning, Error... pick one.  I pick error because if the installer 
consumed a file that is no longer there you need to know about it.   You could 
have a configuration setting that declares the event as a warning and 
automatically implements the punctured components pattern but I think that 
assumes too much that the missing file is correctly missing.


--- On Wed, 7/23/08, Bob Arnson <[EMAIL PROTECTED]> wrote:

> From: Bob Arnson <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: [EMAIL PROTECTED], "General discussion for Windows Installer XML 
> toolset." 
> Date: Wednesday, July 23, 2008, 10:33 AM
> Christopher Painter wrote:
> > This would be a pretty easy scenario to handle.  Check
> the WXS against the XML and if a component is missing, throw
> an error and suggest the puncture component pattern (
> transitive=true condition=false,  0 byte files for storage
> )
> >   
> 
> "Throw an error" isn't the kind of automation
> most people are looking for.
> 
> -- 
> sig://boB
> http://joyofsetup.com/


  

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

Re: [WiX-users] Merge Module Help

[Christopher Karper]

FWIW, I personally would rather manage the process by exception, instead of
*always*.

Chris

On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson <[EMAIL PROTECTED]> wrote:

> Christopher Painter wrote:
> > This would be a pretty easy scenario to handle.  Check the WXS against
> the XML and if a component is missing, throw an error and suggest the
> puncture component pattern ( transitive=true condition=false,  0 byte files
> for storage )
> >
>
> "Throw an error" isn't the kind of automation most people are looking for.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Register DLL for use with Microsoft Management Console

[Paul Adams]

Cool thanks.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: 23 July 2008 16:37
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Register DLL for use with Microsoft Management Console

There's a snap-in CA that Wix offers, but I believe it's for powershell, not
MMC.  I couldn't get it to work for me in any evet for the MMC stuff.  I
have a managed code MMC 3.0 snap in that I install.   You have to make the
registry entries yourself using the snap-in's COM guid.  You will also need
to be aware of the 64/32 bit boundary for your installer.  If it's a manged
code SnapIn, you should register it in the 64 & 32 bit registry in a 64 bit
installer.

Here's a cut up sample from my installer.   It's in a merge module, so
you'll note the use of [MergeRedirectFolder] instead of [TargetFolder] or
whatever you'll use in an .msi project.  Also, note the FX: prefix to the
snap in guid, this is only required for snapins written in .NET.





















I'm not positive which Values are strictly required and not, so you can
experiment with which ones you need to use.  Also, Ideally, I'd have the
assembly binding use the version of the included .dll, but I haven't
researched exactly what I need to do to have that keep up automatically.

Regarding how to install a shortcut to the snapin, that's a little bit more
work.   You need to create a console file (.msc) that references your snap
in.  Then, include that in your install, probably dropping it in your
program files folder, then, you create a shortcut to the .msc file in the
user's start menu...  or even better for an MMC console, in the
administrative tools folder.  this shortcut is done up like any other file
shortcut.  you can find many tutorials online and in the docs for it.


Hope this helps!


On Wed, Jul 23, 2008 at 11:24 AM, Paul Adams <[EMAIL PROTECTED]>
wrote:

> Hi All,
>
> Does anyone know the syntax to register a particular DLL automatically with
> a MMC (as a snapin)? I know the DLL works correctly as a snapin - if you
> register it manually it works correctly.
>
>
> Also, how to create a shortcut to this MMC snapin in the start manu?
>
> Kind Regards,
>
> Paul
>
> Paul Adams
>
> Systems Developer
>
> Agresso Limited
>
>
>
> Riverside House
>
> Direct
>
> +44 (0) 1792 524 530
>
> Normandy Road
>
> Switchboard
>
> +44 (0) 1792 524 524
>
> Swansea
>
> Fax
>
> +44 (0) 1792 524 525
>
> SA1 2JA
>
> www.agresso.com
> ERP...with NO Expiry Date(tm)
>
>
>
>
> 
> This email is from Agresso Limited.  Its contents, including any
> attachments, are confidential to the person or business to which it is
> addressed.  If you are not the intended recipient you may not read, copy, or
> make any other use of this email or its contents.  If received in error,
> please tell the sender immediately and then delete it from your system.
>  Thank you.
>
> Any opinions expressed in this email are not necessarily those of Agresso
> Limited.
>
> Although we have taken steps to ensure that this email and any attachments
> are virus free, neither Agresso Limited or the sender accepts any
> responsibility for viruses, it is your responsibility to scan the email and
> attachments to ensure they are actually virus free.
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

This email is from Agresso Limited.  Its contents, including any attachments, 
are confidential to the person or business to which it is addressed.  If you 
are not the intended recipient you may not read, copy, or make any other use of 
this email or its contents.  If received in error, please tell the sender 
immediately and then delete it fro

Re: [WiX-users] Register DLL for use with Microsoft Management Console

[Christopher Karper]

There's a snap-in CA that Wix offers, but I believe it's for powershell, not
MMC.  I couldn't get it to work for me in any evet for the MMC stuff.  I
have a managed code MMC 3.0 snap in that I install.   You have to make the
registry entries yourself using the snap-in's COM guid.  You will also need
to be aware of the 64/32 bit boundary for your installer.  If it's a manged
code SnapIn, you should register it in the 64 & 32 bit registry in a 64 bit
installer.

Here's a cut up sample from my installer.   It's in a merge module, so
you'll note the use of [MergeRedirectFolder] instead of [TargetFolder] or
whatever you'll use in an .msi project.  Also, note the FX: prefix to the
snap in guid, this is only required for snapins written in .NET.





















I'm not positive which Values are strictly required and not, so you can
experiment with which ones you need to use.  Also, Ideally, I'd have the
assembly binding use the version of the included .dll, but I haven't
researched exactly what I need to do to have that keep up automatically.

Regarding how to install a shortcut to the snapin, that's a little bit more
work.   You need to create a console file (.msc) that references your snap
in.  Then, include that in your install, probably dropping it in your
program files folder, then, you create a shortcut to the .msc file in the
user's start menu...  or even better for an MMC console, in the
administrative tools folder.  this shortcut is done up like any other file
shortcut.  you can find many tutorials online and in the docs for it.


Hope this helps!


On Wed, Jul 23, 2008 at 11:24 AM, Paul Adams <[EMAIL PROTECTED]>
wrote:

> Hi All,
>
> Does anyone know the syntax to register a particular DLL automatically with
> a MMC (as a snapin)? I know the DLL works correctly as a snapin - if you
> register it manually it works correctly.
>
>
> Also, how to create a shortcut to this MMC snapin in the start manu?
>
> Kind Regards,
>
> Paul
>
> Paul Adams
>
> Systems Developer
>
> Agresso Limited
>
>
>
> Riverside House
>
> Direct
>
> +44 (0) 1792 524 530
>
> Normandy Road
>
> Switchboard
>
> +44 (0) 1792 524 524
>
> Swansea
>
> Fax
>
> +44 (0) 1792 524 525
>
> SA1 2JA
>
> www.agresso.com
> ERP...with NO Expiry Date(tm)
>
>
>
>
> 
> This email is from Agresso Limited.  Its contents, including any
> attachments, are confidential to the person or business to which it is
> addressed.  If you are not the intended recipient you may not read, copy, or
> make any other use of this email or its contents.  If received in error,
> please tell the sender immediately and then delete it from your system.
>  Thank you.
>
> Any opinions expressed in this email are not necessarily those of Agresso
> Limited.
>
> Although we have taken steps to ensure that this email and any attachments
> are virus free, neither Agresso Limited or the sender accepts any
> responsibility for viruses, it is your responsibility to scan the email and
> attachments to ensure they are actually virus free.
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module Help

[Bob Arnson]

Christopher Painter wrote:
> This would be a pretty easy scenario to handle.  Check the WXS against the 
> XML and if a component is missing, throw an error and suggest the puncture 
> component pattern ( transitive=true condition=false,  0 byte files for 
> storage )
>   

"Throw an error" isn't the kind of automation most people are looking for.

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



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

[WiX-users] Register DLL for use with Microsoft Management Console

[Paul Adams]

Hi All,

Does anyone know the syntax to register a particular DLL automatically with a 
MMC (as a snapin)? I know the DLL works correctly as a snapin - if you register 
it manually it works correctly.


Also, how to create a shortcut to this MMC snapin in the start manu?

Kind Regards,

Paul

Paul Adams

Systems Developer

Agresso Limited



Riverside House

Direct

+44 (0) 1792 524 530

Normandy Road

Switchboard

+44 (0) 1792 524 524

Swansea

Fax

+44 (0) 1792 524 525

SA1 2JA

www.agresso.com
ERP...with NO Expiry Date(tm)




This email is from Agresso Limited.  Its contents, including any attachments, 
are confidential to the person or business to which it is addressed.  If you 
are not the intended recipient you may not read, copy, or make any other use of 
this email or its contents.  If received in error, please tell the sender 
immediately and then delete it from your system.  Thank you.

Any opinions expressed in this email are not necessarily those of Agresso 
Limited.

Although we have taken steps to ensure that this email and any attachments are 
virus free, neither Agresso Limited or the sender accepts any responsibility 
for viruses, it is your responsibility to scan the email and attachments to 
ensure they are actually virus free.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module Help

[Christopher Painter]

This would be a pretty easy scenario to handle.  Check the WXS against the XML 
and if a component is missing, throw an error and suggest the puncture 
component pattern ( transitive=true condition=false,  0 byte files for storage )

--- On Wed, 7/23/08, Bob Arnson <[EMAIL PROTECTED]> wrote:

> From: Bob Arnson <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 23, 2008, 9:32 AM
> John Hall wrote:
> > I have written a tool that auto-generates .wxs files
> for some parts of
> > my project - we ship a lot of example scripts. It only
> handles files and
> > generates one component per file. The tool maintains a
> database (well,
> > an XML file) that lists all the GUIDs ever allocated,
> and adds entries
> > as it needs. That file is kept in source control.
> >
> > This seems to work well for me - have I missed
> something important?
> >   
> 
> What happens when someone wants to remove a file? (You
> can't remove a 
> component in a patch.)
> 
> -- 
> sig://boB
> http://joyofsetup.com/
> 
> 
> 
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

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

Re: [WiX-users] Merge Module Help

[Bob Arnson]

John Hall wrote:
> I have written a tool that auto-generates .wxs files for some parts of
> my project - we ship a lot of example scripts. It only handles files and
> generates one component per file. The tool maintains a database (well,
> an XML file) that lists all the GUIDs ever allocated, and adds entries
> as it needs. That file is kept in source control.
>
> This seems to work well for me - have I missed something important?
>   

What happens when someone wants to remove a file? (You can't remove a 
component in a patch.)

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



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

Re: [WiX-users] Where are binaries in MSIs from WiX?

[Bob Arnson]

Alan Sinclair wrote:
> In the past I've found CAB files in the MSI's Binary table, and used
> Orca to extract the CAB, then used Windows Explorer to get at the
> contents. But the MSIs produced by the WiX toolset on a project I've
> inherited don't have a CAB visible anywhere. The binaries are definitely
> inside the MSI, though --the Wise Installation Studio manages to extract
> them-- so how do I get at them?
>   

Embedded cabs are stored as a stream in the .msi. You can use the Dark 
tool in WiX (or admin installs) to extract the files.

> Also, MSIs I've worked with before can be installed in Admin mode
> (msiexec /a ...) but with these MSIs, there's only a "Finished" dialog,
> and it took me a while to find that the files had been installed to Y:\
> What do I need to do to make Admin installs manageable from a WiX MSI?
>   

The built-in UI doesn't have support for admin-image directory 
selection, but you can use the command line to specify properties like 
TARGETDIR.

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



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

Re: [WiX-users] Build Fails with NAnt. The format of the file 'NAntTasks.dll' is invalid.

[Bob Arnson]

Eric Latendresse wrote:
> D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):
>
> Failure scanning \"C:\Program Files (x86)\Windows Installer XML
> v3\bin\Microsoft.
>
> Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.
>
> The format of the file
> 'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.
>   

Assuming that you're using a recent build of WiX v3, NAntTasks.dll is 
built with .NET 2.0, so you need to use a version of NAnt that loads in 
.NET 2.0.

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



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

Re: [WiX-users] Multiple Installs without Un-Install?

[Christopher Painter]

You could modify the maintenance UI experience to have an option for creating 
additional database instances which would then execute your script again but 
I'm wondering if it wouldn't be simpler to just write a small application 
utility and put it in the start menu to allow a user to perform database 
management functions like creating additional named database instances.

How do you feel about that?

--- On Wed, 7/23/08, Daniel Zak <[EMAIL PROTECTED]> wrote:

> From: Daniel Zak <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Multiple Installs without Un-Install?
> To: wix-users@lists.sourceforge.net
> Date: Wednesday, July 23, 2008, 1:28 AM
> Hi Christopher,
> 
> I need multiple instances only of the database.
> 
> Cheers,
> Daniel
> 
> 
> > Message: 9
> > Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
> > From: Christopher Painter
> <[EMAIL PROTECTED]>
> > Subject: Re: [WiX-users] Multiple Installs without
> Un-Install?
> > To: "General discussion for Windows Installer XML
> toolset."
> >
> > Message-ID:
> <[EMAIL PROTECTED]>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Windows Installer supports multiple instance
> installation, but the question
> > I have is do you need multiple instances of your
> product or only multiple
> > instances of your database?
> >
> > Christopher Painter, Author of Deployment Engineering
> Blog
> > Have a hot tip, know a secret or read a really good
> thread that deserves
> > attention? E-Mail Me
> >
> >
> > --- On Mon, 7/21/08, Daniel Zak
> <[EMAIL PROTECTED]> wrote:
> >
> > > From: Daniel Zak <[EMAIL PROTECTED]>
> > > Subject: [WiX-users] Multiple Installs without
> Un-Install?
> > > To: wix-users@lists.sourceforge.net
> > > Date: Monday, July 21, 2008, 11:51 PM
> > > Hello,
> > >
> > > I created a script to install an SQL Server
> database. A
> > > user needs to be
> > > able to run the script multiple times to install
> multiple
> > > databases.
> > > However, the script requires the user to first
> un-install
> > > the product (which
> > > does not delete the database) before being able
> to install
> > > a new database.
> > >
> > > Is there anything I can do to avoid requiring the
> user to
> > > explicitly
> > > un-install the product?
> > >
> > > I included an extract of the script as a text
> file.
> > >
> > > Thank you,
> > > Daniel
> -
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

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

[WiX-users] source and src from tallow

[F. David del Campo Hill]

Dear WiX,

We have a build process for a statistical application which uses WiX to 
create a MSI for distribution over Active Directory. This process creates a 
files.wxs fragment using tallow.exe, and then parses it through a Perl script 
to create a .wxs file which candle.exe and light.exe can compile. This Perl 
script is obviously very sensitive to the format tallow.exe outputs. We have 
found that if we compile with tallow.exe from WiX 2.0.4221.0, the fragment 
created has "src=" in its Components, while with the latest tallow.exe from WiX 
2.0.5805.0, it uses "Source=".

We have changed the script to fit the newer format, but we still need 
to advise our users on the difference and I would like to ask: which was the 
first version where tallow.exe started to use "Source=" instead of "src="?

Thank you for your time.

Yours,

F. David del Campo Hill

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

Re: [WiX-users] Merge Module Help

[John Hall]

> The case that gets really tricky is to have one build where a Resource

> disappears (usually accidentally) then the next build where the 
> Resource comes back.  It needs to get the same Component and GUID.

I have written a tool that auto-generates .wxs files for some parts of
my project - we ship a lot of example scripts. It only handles files and
generates one component per file. The tool maintains a database (well,
an XML file) that lists all the GUIDs ever allocated, and adds entries
as it needs. That file is kept in source control.

This seems to work well for me - have I missed something important?

Regards,
John

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

Re: [WiX-users] DTF - Using ExtractFiles Method

[Powell, Simon]

Do you have any idea when you might be able to fix this issue?  If
priority is low, can you think of a possible workround? I don't really
want to use an admin install. 

Regards
Simon Powell

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: 22 July 2008 20:14
To: General discussion for Windows Installer XML toolset.
Cc: Jones, Ben
Subject: Re: [WiX-users] DTF - Using ExtractFiles Method

It's a bug in DTF -- ExtractFiles is being case-sensitive where it
shouldn't. A few of the files in Cabs.winrk.cab have different casing
than their File table keys in rktools.msi. The Windows Installer engine
handles that okay but DTF doesn't. Can you open a bug on SourceForge for
tracking?

However the problem with SQL Server 2005 client tools is different.
There, the Media.Cabinet value is "#Sql.cab". The number sign (#)
indicates the cabinet should be in an embedded stream in the MSI
package, but it is not actually there! Running msiexec /a on that
package confirms the problem as it gives error 2356. "Could not locate
cabinet in stream: Sql.cab." Maybe their bootstrapper does something to
fixup the MSI at install time?

-Jason-

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Powell,
Simon
Sent: Monday, July 21, 2008 3:11 PM
To: wix-users@lists.sourceforge.net
Cc: Jones, Ben
Subject: [WiX-users] DTF - Using ExtractFiles Method

Hi,

I'm using the ExtractFiles Method to extract files from the Windows 2003
Resource kit msi (rktools.msi). Below is a simple snippet of code used :

InstallPackage MsiPackage = new InstallPackage(txtMsi.Text,
DatabaseOpenMode.ReadOnly); MsiPackage.WorkingDirectory = "c:\\temp";
Regex myReg = new Regex("exe", RegexOptions.IgnoreCase); string[]
filekeys = MsiPackage.FindFiles(myReg);
MsiPackage.ExtractFiles(filekeys);

Some of the files fail to extract return the following
FileNotFoundException :

Could not find file 'c:\temp\Program Files\Windows Resource
Kits\Tools\nlsinfo.exe'.

It's strange, because the file exists in the extracted cab file
(Cabs.winrk.cab), all the files extract correctly to c:\temp if I use
msiexec /a rktools.msi (but this  gives me no control over the files I
extract). Is this a bug or am I doing something wrong? This problem
happens with a number of MSIs including sqlrun.msi of the SQL Server
2005 client tools.

Your help will be much appreciated.

Regards
Simon Powell





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


--
This e-mail is confidential and the information contained in it may be 
privileged.  It should not be read, copied or used by anyone other than the 
intended recipient.  If you have received it in error, please contact the 
sender immediately by telephoning +44 (0)20 7623 8000 or by return email, and 
delete the e-mail and do not disclose its contents to any person.  We believe, 
but do not warrant, that this e-mail and any attachments are virus free, but 
you must take full responsibility for virus checking.  Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is the trading name of the investment banking division of 
Dresdner Bank AG, and operates through Dresdner Bank AG, Dresdner Kleinwort 
Limited, Dresdner Kleinwort Securities Limited and their affiliated or 
associated companies.  Dresdner Bank AG is a company incorporated in Germany 
with limited liability and registered in England (registered no. FC007638, 
place of business 30 Gresham Street, London EC2V 7PG), and is authorised by the 
German Federal Financial Supervisory Authority and by the Financial Services 
Authority ('FSA') and regulated by the FSA for the conduct of designated 
business in the UK.  Dresdner Kleinwort Limited is a company incorporated in 
England (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG), and is authorised and regulated by the FSA.  Dresdner Kleinwort 
Securities Limited is a company incorporated in England (registered no. 
1767419, registered office 30 Gresham Street, London EC2V 7PG), and is 
authorised an
 d regulated by the FSA.


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

Re: [WiX-users] Build Fails with NAnt. The format of the file 'NAntTasks.dll' is invalid.

[Neil Sleightholm]

In my experience changing to use msbuild from nant isn't as easy as it seems. 
When it is all working there isn't a problem but seeing errors reported 
correctly especially in my integration tool of choice (ccnet) is particularly 
hard (I had to resort to parsing the output file). This also assumes that your 
projects are edited using a VS wixproj - this isn't always the case.
 
Now a plea to the WiX team - please don't drop nant support in favour of 
msbuild. 
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Tue 22/07/2008 23:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Build Fails with NAnt. The format of the file 
'NAntTasks.dll' is invalid.



One option to consider is using the shipping MSBuild .targets file that has a 
complete build process for WiX in conjunction with NAnt. Trying to re-construct 
a build process using individual tasks is often fraught with peril, and using 
the one that ships with WiX is almost always a better idea.

You would create a .wixproj that uses the MSBuild process for building WiX (a 
quick way to do this is to create a WiX project in Visual Studio), and then in 
your nant build script just do . You'll 
get our well-tested and supported build process for free, yet still be able to 
use nant as your overall build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file 
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric





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


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


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

Re: [WiX-users] Build Fails with NAnt. The format of the file 'NAntTasks.dll' is invalid.

[Neil Sleightholm]

Which version of WiX are you using? I call WiX from nant and haven't seen any 
problems recently.
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: [EMAIL PROTECTED] on behalf of Eric Latendresse
Sent: Tue 22/07/2008 22:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file 
'NAntTasks.dll' is invalid.



I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric





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


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