Re: [WiX-users] Multiple Installs without Un-Install?
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. wix-users@lists.sourceforge.net 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
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=100url=/
___
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
[WiX-users] source and src from tallow
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=100url=/ ___ 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?
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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.
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=100url=/ ___ 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?
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=100url=/ ___ 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 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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
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.comhttp://localhost:3804/Desktop/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=100url=/ ___ 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 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=100url=/ ___ 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
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.
Component Id=ms_Native_RegistryOperations Guid={YOUR_COMPONENT_GUID}
Win64=yes
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}\NodeTypes
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}\Standalone
Action=createAndRemoveOnUninstall /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Type
Value=SampleSnapIn.SampleSnapIn, SampleSnapIn, Version=0.0.0.1,
Culture=neutral, PublicKeyToken=ee359021a7bf4bed Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=ApplicationBase Value=[MergeRedirectFolder] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=ConfigurationFile Value=[#SampleSnapIn.dll.config] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=NameString
Value=Sample MMC 3.0 SnapIn Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Description
Value=MMC 3.0 snap-in sample. Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Provider
Value=triCerat, Inc. (c) Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=AssemblyName Value=SampleSnapIn Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=ModuleName
Value=SampleSnapIn.dll Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=RuntimeVersion Value=v2.0.50727 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=FxVersion
Value=3.0.0.0 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=About
Value={----} Type=string Action=write
/
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=NameStringIndirect
Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-1 Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=DescriptionStringIndirect
Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-2 Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=IconIndirect Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-1
Type=string Action=write /
/Component
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
Re: [WiX-users] Register DLL for use with Microsoft Management Console
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.
Component Id=ms_Native_RegistryOperations Guid={YOUR_COMPONENT_GUID}
Win64=yes
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}\NodeTypes
Action=createAndRemoveOnUninstall /
RegistryKey Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}\Standalone
Action=createAndRemoveOnUninstall /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Type
Value=SampleSnapIn.SampleSnapIn, SampleSnapIn, Version=0.0.0.1,
Culture=neutral, PublicKeyToken=ee359021a7bf4bed Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=ApplicationBase Value=[MergeRedirectFolder] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=ConfigurationFile Value=[#SampleSnapIn.dll.config] Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=NameString
Value=Sample MMC 3.0 SnapIn Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Description
Value=MMC 3.0 snap-in sample. Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=Provider
Value=triCerat, Inc. (c) Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=AssemblyName Value=SampleSnapIn Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=ModuleName
Value=SampleSnapIn.dll Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=RuntimeVersion Value=v2.0.50727 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=FxVersion
Value=3.0.0.0 Type=string Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID} Name=About
Value={----} Type=string Action=write
/
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=NameStringIndirect
Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-1 Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=DescriptionStringIndirect
Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-2 Type=string
Action=write /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\MMC\SnapIns\FX:{SNAPIN_COM_GUID}
Name=IconIndirect Value=@[MergeRedirectFolder]SampleSnapIn.Resources,-1
Type=string Action=write /
/Component
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
Re: [WiX-users] Merge Module Help
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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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
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=100url=/ ___ 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 wrote: FWIW, I personally would rather manage the process by exception, instead of *always*. Yes, some help is usually better than none.g 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
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=100url=/
___
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
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=100url=/ ___ 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 wrote: Ah, we don't do patches, which is why it works for me :) That's also an option.g 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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.g 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=100url=/ ___ 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=100url=/ ___ 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
Hey David, It looks like build 2.0.5325.0 ( http://wix.cvs.sourceforge.net/wix/wix2.0/inc/wixver.h?r1=1.35r2=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.4r2=1.5 http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=log Revision *1.5* - (viewhttp://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?revision=1.5view=markup) (downloadhttp://wix.cvs.sourceforge.net/*checkout*/wix/wix2.0/src/tallow/tallow.cs?revision=1.5) (annotatehttp://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?annotate=1.5) - [select for diffs]http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?r1=1.5view=log *Wed Jun 27 05:42:52 2007 UTC* (12 months, 3 weeks ago) by *robmen* Branch: *MAIN*http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=logpathrev=MAIN CVS Tags: *HEAD*http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=logpathrev=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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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 smile/)? 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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.g 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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 smile/)? 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=100url=/ ___ 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?
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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
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.35r2=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.4r2=1.5 http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=log Revision *1.5* - (viewhttp://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?revision=1.5view=markup) (downloadhttp://wix.cvs.sourceforge.net/*checkout*/wix/wix2.0/src/tallow/tallow.cs?revision=1.5) (annotatehttp://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?annotate=1.5) - [select for diffs]http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?r1=1.5view=log *Wed Jun 27 05:42:52 2007 UTC* (12 months, 3 weeks ago) by *robmen* Branch: *MAIN*http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=logpathrev=MAIN CVS Tags: *HEAD*http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?view=logpathrev=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=100url=/ ___ 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=100url=/ ___ 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?
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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
Re: [WiX-users] Multiple Installs without Un-Install?
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. wix-users@lists.sourceforge.net 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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module Help
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[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=100url=/
___
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
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=100url=/
___
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.
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] mailto:[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 msbuild
project=myinstaller.wixproj. 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:
target name=CreateSetupPackageUsingWiX description=Create the installer
package using WiX Script
mkdir dir=${wix.release.dir}/
loadtasks
assembly=${wix.work.dir}/Microsoft.Tools.WindowsInstallerXml.NAntTasks.
dll/
candle out=${wix.work.dir}\ cultures=en-us
extensions=WixUtilExtension;WixWixSqlExtension;WixUIExtension
exedir=${wix.dir}\ rebuild=true
sources
include name=SuiteSetup.wxs /
/sources
/candle
light out=${wix.release.dir}/SuiteSetup.msi cultures=en-us
extensions=WixUtilExtension;WixWixSqlExtension;WixUIExtension
exedir=${wix.dir}\ rebuild=true
sources
include name=SuiteSetup.wixobj /
/sources
/light
/target
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=100url=/
___
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=100url=/
___
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
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 msbuild
project=myinstaller.wixproj. 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:
target name=CreateSetupPackageUsingWiX description=Create the
installer package using WiX Script
mkdir dir=${wix.release.dir}/
loadtasks
assembly=${wix.work.dir}/Microsoft.Tools.WindowsInstallerXml.NAntTasks.
dll/
candle out=${wix.work.dir}\ cultures=en-us
extensions=WixUtilExtension;WixWixSqlExtension;WixUIExtension
exedir=${wix.dir}\ rebuild=true
sources
include name=SuiteSetup.wxs /
/sources
/candle
light out=${wix.release.dir}/SuiteSetup.msi cultures=en-us
extensions=WixUtilExtension;WixWixSqlExtension;WixUIExtension
exedir=${wix.dir}\ rebuild=true
sources
include name=SuiteSetup.wixobj /
/sources
/light
/target
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=100url=/
___
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=100url=/
___
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=100url=/
___
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
The custom action is set to immediate, I've also tried commit.
Binary Id=CustomAction1.CA.dll
SourceFile=..\CustomAction1\bin\debug\CustomAction1.CA.dll /
CustomAction Id=MyCustomAction_DATA Property=MyCustomAction Value=foobar
/CustomAction
CustomAction Id=MyCustomAction BinaryKey=CustomAction1.CA.dll
DllEntry=CustomAction1 Execute=immediate /
InstallExecuteSequence
Custom Action=MyCustomAction_DATA After=InstallInitialize /
Custom Action=MyCustomAction After=MyCustomAction_DATA
/Custom
/InstallExecuteSequence
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=100url=/
___
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=100url=/
___
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?
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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DTF - Using ExtractFiles Method
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=100url=/
___
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.
[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=100url=/ ___ 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
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.
Binary Id=CustomAction1.CA.dll
SourceFile=..\CustomAction1\bin\debug\CustomAction1.CA.dll /
CustomAction Id=MyCustomAction_DATA Property=MyCustomAction Value=foobar
/CustomAction
CustomAction Id=MyCustomAction BinaryKey=CustomAction1.CA.dll
DllEntry=CustomAction1 Execute=immediate /
InstallExecuteSequence
Custom Action=MyCustomAction_DATA After=InstallInitialize /
Custom Action=MyCustomAction After=MyCustomAction_DATA
/Custom
/InstallExecuteSequence
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=100url=/
___
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
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=100url=/ ___ 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=100url=/ ___ 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?
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=100url=/ ___ 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=100url=/ ___ 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?
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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list
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/ - 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Where are binaries in MSIs from WiX?
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/ - This
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:
exec
program=${framework::get-framework-directory(framework::get-target-fram
ework())}\msbuild.exe resultproperty=msbuild.result
failonerror=true
arg value=${wix.work.dir}\SuiteSetup.wixproj/
arg value=/nologo/
arg value=/noconsolelogger/
arg value=/target:Build/
arg
value=/property:SolutionDir=${project::get-base-directory()}\\/
arg value=/property:CustomOutputPath=${wix.release.dir}/
arg
value=/property:CustomOutputName=${wix.release.dir}\Setup_${project.ver
sion}.msi/
/exec
Project File:
Project DefaultTargets=Build
xmlns=http://schemas.microsoft.com/developer/msbuild/2003;
PropertyGroup
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
ProductVersion3.0/ProductVersion
ProjectGuid{2891ae0b-bf21-405f-b3af-87075ee2f574}/ProjectGuid
SchemaVersion2.0/SchemaVersion
OutputNameSuiteSetup/OutputName
OutputTypePackage/OutputType
WixTargetsPath Condition= '$(WixTargetsPath)' == ''
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets/WixTargetsPat
h
WixToolPath$(ProgramFiles)\Windows Installer XML
v3\bin\/WixToolPath
/PropertyGroup
PropertyGroup Condition= '$(Configuration)' == 'Debug'
OutputPathbin\Debug\/OutputPath
IntermediateOutputPathobj\Debug\/IntermediateOutputPath
CustomOutputPath$(CustomOutputPath)/CustomOutputPath
DefineConstantsDebug/DefineConstants
/PropertyGroup
PropertyGroup Condition= '$(Configuration)' == 'Release'
OutputPathbin\Release\/OutputPath
IntermediateOutputPathobj\Release\/IntermediateOutputPath
CustomOutputPath$(CustomOutputPath)/CustomOutputPath
/PropertyGroup
ItemGroup
Compile Include=SuiteSetup.wxs /
/ItemGroup
ItemGroup
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixSqlExtension.dll /
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixUIExtension.dll /
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixUtilExtension.dll /
/ItemGroup
Import Project=$(WixTargetsPath) /
/Project
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:
exec
program=${framework::get-framework-directory(framework::get-target-fram
ewor
k())}\msbuild.exe resultproperty=msbuild.result failonerror=false
arg value=${product.sln}/
arg value=/nologo/
arg value=/noconsolelogger/
arg value=/target:Build/
arg
value=/property:SolutionDir=${project::get-base-directory()}\\/
arg value=/logger:Kobush.Build.Logging.XmlLogger,${
XmlLogger4MSBuild.directory}\bin\Release\Kobush.Build.dll;${compile.log.
xml}
/
/exec
You could just add another argument to the list of args
arg value=/property:CustomOutputPath=your output path/
arg value=/property:CustomOutputName=your output file name/
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
[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 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
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 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ugly Uninstall under Vista
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 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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?
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. wix-users@lists.sourceforge.net 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=100url=/ ___ 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=100url=/ ___ 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
[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=100url=/ ___ 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,
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
PropertyGroup Condition= '$(Configuration)' == 'Debug'
OutputPath$(CustomOutputPath)/OutputPath
IntermediateOutputPathobj\Debug\/IntermediateOutputPath
DefineConstantsDebug/DefineConstants
/PropertyGroup
PropertyGroup Condition= '$(Configuration)' == 'Release'
OutputPath$(CustomOutputPath)/OutputPath
IntermediateOutputPathobj\Release\/IntermediateOutputPath
/PropertyGroup
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:
exec
program=${framework::get-framework-directory(framework::get-target-fram
ework())}\msbuild.exe resultproperty=msbuild.result
failonerror=true
arg value=${wix.work.dir}\SuiteSetup.wixproj/
arg value=/nologo/
arg value=/noconsolelogger/
arg value=/target:Build/
arg
value=/property:SolutionDir=${project::get-base-directory()}\\/
arg value=/property:CustomOutputPath=${wix.release.dir}/
arg
value=/property:CustomOutputName=${wix.release.dir}\Setup_${project.ver
sion}.msi/
/exec
Project File:
Project DefaultTargets=Build
xmlns=http://schemas.microsoft.com/developer/msbuild/2003;
PropertyGroup
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
ProductVersion3.0/ProductVersion
ProjectGuid{2891ae0b-bf21-405f-b3af-87075ee2f574}/ProjectGuid
SchemaVersion2.0/SchemaVersion
OutputNameSuiteSetup/OutputName
OutputTypePackage/OutputType
WixTargetsPath Condition= '$(WixTargetsPath)' == ''
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets/WixTargetsPat
h
WixToolPath$(ProgramFiles)\Windows Installer XML
v3\bin\/WixToolPath
/PropertyGroup
PropertyGroup Condition= '$(Configuration)' == 'Debug'
OutputPathbin\Debug\/OutputPath
IntermediateOutputPathobj\Debug\/IntermediateOutputPath
CustomOutputPath$(CustomOutputPath)/CustomOutputPath
DefineConstantsDebug/DefineConstants
/PropertyGroup
PropertyGroup Condition= '$(Configuration)' == 'Release'
OutputPathbin\Release\/OutputPath
IntermediateOutputPathobj\Release\/IntermediateOutputPath
CustomOutputPath$(CustomOutputPath)/CustomOutputPath
/PropertyGroup
ItemGroup
Compile Include=SuiteSetup.wxs /
/ItemGroup
ItemGroup
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixSqlExtension.dll /
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixUIExtension.dll /
WixExtension Include=C:\Program Files (x86)\Windows Installer XML
v3\bin\WixUtilExtension.dll /
/ItemGroup
Import Project=$(WixTargetsPath) /
/Project
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:
exec
program=${framework::get-framework-directory(framework::get-target-fram
ewor
k())}\msbuild.exe resultproperty=msbuild.result failonerror=false
arg value=${product.sln}/
arg value=/nologo/
arg value=/noconsolelogger/
arg value=/target:Build/
arg
value=/property:SolutionDir=${project::get-base-directory()}\\/
arg value=/logger:Kobush.Build.Logging.XmlLogger,${
XmlLogger4MSBuild.directory}\bin\Release\Kobush.Build.dll;${compile.log.
xml}
/
/exec
You could just add another argument to the list of args
arg value=/property:CustomOutputPath=your output path/
arg value=/property:CustomOutputName=your output file name/
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
Re: [WiX-users] Copy files and folders from target machine
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=100url=/ ___ 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=100url=/ ___ 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?
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. wix-users@lists.sourceforge.net 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
Re: [WiX-users] Multiple Installs without Un-Install?
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. wix-users@lists.sourceforge.net 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. wix-users@lists.sourceforge.net 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,
Re: [WiX-users] Where are binaries in MSIs from WiX?
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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
