[WiX-users] How to deal with heat output for registering COM components?
Hello folks,
last time I dealt with extracting registering informations with heat is about
two years ago and I used wix 3.6 for that. Unfortunately I lost the command
that I used to extract those informations :(
Now I have a new .NET component, that I need to register on a client
workstation with my MSI installer.
First I switched to wix 3.8 - as it seems plausible to me to get up to date.
So I tried to use heat again ...
C:\Program Files (x86)\WiX Toolset v3.8\bin\heat.exe file
Bestellschnittstellen.tlb -out Bestellschnittstellen_reg.wxs -srd -gg -sfrag
-suid -cg Bestellschnittstellen_CG
... and arrived to get a file like this one (shortened version):
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Fragment
DirectoryRef Id=TARGETDIR /
/Fragment
Fragment
ComponentGroup Id=Bestellschnittstellen_CG
Component Id=Bestellschnittstellen.tlb Directory=TARGETDIR
Guid={D052E472-3A43-4834-8947-67FC72350A90}
File Id=Bestellschnittstellen.tlb KeyPath=yes
Source=SourceDir\Bestellschnittstellen.tlb /
RegistryValue Root=HKCR
Key=Interface\{0780A3A7-AB94-3B8C-869C-598DA74B53DD}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string Action=write /
RegistryValue Root=HKCR
Key=Interface\{0780A3A7-AB94-3B8C-869C-598DA74B53DD}\TypeLib
Value={74E0DC9F-AE47-47D4-A0D4-CACC527FCD4C} Type=string Action=write /
/!-- ... much more entries ...--
RegistryValue Root=HKCR
Key=TypeLib\{74E0DC9F-AE47-47D4-A0D4-CACC527FCD4C}\1.0\0\win32
Value=[#Bestellschnittstellen.tlb] Type=string Action=write /
RegistryValue Root=HKCR
Key=TypeLib\{74E0DC9F-AE47-47D4-A0D4-CACC527FCD4C}\1.0
Value=Bestellschnittstellen Type=string Action=write /
/Component
/ComponentGroup
/Fragment
/Wix
My former files for registration looked like this:
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Fragment
ComponentGroup Id=ProfiSucheAdoNet_CG
Component Id=cmpD588201B6DA724272123E389DE30E47E
Directory=TARGETDIR Guid={D15499E3-395C-418B-9ED3-264138F5D0EE}
KeyPath=yes
RegistryKey Key=ProfiSucheAdoNet.CAdoNet Root=HKCR
RegistryValue Value=ProfiSucheAdoNet.CAdoNet
Type=string /
/RegistryKey
/Component
Component Id=cmpC63C3912BB5230843F8D05423F6E1DCB
Directory=TARGETDIR Guid={2A157D0D-1A4E-4E04-8EED-64491B5609B4}
KeyPath=yes
RegistryKey Key=ProfiSucheAdoNet.CAdoNet\CLSID Root=HKCR
RegistryValue
Value={6C95A0E3-0C3A-330E-897B-4136BEC814EE} Type=string /
/RegistryKey
/Component
// and so on
So why there is such a difference? Am I doing something wrong or has heat
changed in the mean time?
And if my new attempt is the right thing, how can I deal with the tlb-File?
If I integrate that fragment into my main-wxs-file and build the solution, I
get this error:
Fehler 5 ICE69: 'Bestellschnittstellen.tlb' references invalid
file.J:\Projekte\shortend...\Bestellschnittstellen_reg.wxs
182 1 Profi32SQLClient
Sounds plausible as the referencd tlb-File is of course not included into the
MSI-Project (yet).
So my questions are:
- Can I achieve to get the second result, that my older attempt did
produce? And if so, of course *how* can I tune heat to give me that? (I would
appreciate that, because it worked good and I did not need to provide the
tlb-file somewhere in the project)
- If my new attempt is the right way these days, how do I include the
tlb-file into my msi-project? What is the right / best way to do it?
I hope someone can help me!
Best regards,
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG
Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - 27
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung
GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Dr. Britta Kahlfuss
Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt.
Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher
schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist
sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der
Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung
überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre
Richtigkeit.
--
Meet PCI DSS 3.0 Compliance Requirements
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Igor,
I allready guessed that... unfortunately not much developers create such things
for Open Source or Free Software projects :-(
But thanks for telling us about your BA design and the decisions you took! That
also helps :-)
Best regards,
Christian
-Ursprüngliche Nachricht-
Von: Igor Brejc [mailto:igor.br...@gmail.com]
Gesendet: Dienstag, 23. Oktober 2012 10:13
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Christian,
Unfortunately I cannot release the source code, it's the property of the
company I work for.
Best regards,
Igor
On Mon, Oct 22, 2012 at 8:30 AM, Christian Hausknecht chauskne...@beracom.de
wrote:
Hello Igor,
is there any chance that you could provide us the source code?
Bets regards,
Christian
-Ursprüngliche Nachricht-
Von: Igor Brejc [mailto:igor.br...@gmail.com]
Gesendet: Samstag, 20. Oktober 2012 20:04
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper
interface
Hi,
Some more pointers from me. I've implemented a custom managed
bootstrapper using WinForms. The GUI actually looks pretty much the
same as the standard MSI setup wizard, but implemented with custom C#
code using MVP
(model-view-presenter) pattern. This enables me to unit-test the
wizard without actually running the installation.
I've also hidden the WiX bootstrapper engine behind an adapter
interface (I called it IInstallEngine). This way I can run the wizard as a
normal
Windows Forms application and click through it (again, without the
need to run the actual Windows installation), since in that mode the
wizard uses a mocked implementation of IInstallEngine. I just simply
added the static Main method which has the similar logic to the Run().
(Note to Rob: perhaps it would be a good idea to change the design of
the managed bootstrapper so that it works with interfaces instead of
concrete implementations, this would be really helpful for unit
testing and simulation).
The wizard has one added feature: a debug window which can be turned
on through the command line and displays all the install log messages
directly in the setup wizard.
The documentation for the managed BS is pretty scarce, so I had to
look into WiX's source code and do a lot of trials and errors to get
to this point (and I still have some issues to work through).
Best regards,
Igor Brejc
On Fri, Oct 19, 2012 at 10:39 AM, Hans ter Horst hoshis...@gmail.com
wrote:
Thanks Daniel, this is precisely what I needed!
On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce
daniel.br...@prediktor.no
wrote:
To resolve Microsoft.Tools.WindowsInstallerXml.Bootstrapper, you
need to add a reference to BootstrapperCore, which in my
installation was located under C:\Program Files (x86)\WiX Toolset
v3.7\SDK\BootstrapperCore.dll.
You
should be able to find yours in a similar location.
You are correct that there is little information about how to get
started with Burn, and the little information there is to find is
scattered
around
the net and pretty terse, so I'll give you enough to get started,
then
you
should be able to look at the source code for the WiX BA to
continue (I highly recommend having the source around to look at
either way, because there is really no other way to get
information about most
things).
For my WPF-based bootstrapper interface, I started a regular WPF
application project and changed its output type to class library.
Then
I
have a class that inherits from BootstrapperApplication looking
something like this:
public class MyBA : BootstrapperApplication {
static public Threading.Dispatcher Dispatcher { get; private set; }
static public View.InstallerWindow Window { get; private set; }
static public App TheApp { get; private set; }
protected override void Run()
{
TheApp = new App();
TheApp.InitializeComponent();
// Send a reference to the Application to access things,
if necessary
TheApp.BA = this;
MyBA.Dispatcher = Threading.Dispatcher.CurrentDispatcher;
TheApp.Run();
this.Engine.Quit(TheApp.ExitCode);
}
}
And in my WPF Application class I have code like this to bring up
a
pretty
standard MVVM application window:
public partial class App : Application {
public View.InstallerWindow Window { get; private set; }
public
Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperAppli
ca
tion
BA
{ get; set; }
public int ExitCode
{
get
{
return state.InstallerResult;
}
}
private InstallationState state;
protected override void OnStartup
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hello Igor,
is there any chance that you could provide us the source code?
Bets regards,
Christian
-Ursprüngliche Nachricht-
Von: Igor Brejc [mailto:igor.br...@gmail.com]
Gesendet: Samstag, 20. Oktober 2012 20:04
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi,
Some more pointers from me. I've implemented a custom managed bootstrapper
using WinForms. The GUI actually looks pretty much the same as the standard MSI
setup wizard, but implemented with custom C# code using MVP
(model-view-presenter) pattern. This enables me to unit-test the wizard without
actually running the installation.
I've also hidden the WiX bootstrapper engine behind an adapter interface (I
called it IInstallEngine). This way I can run the wizard as a normal
Windows Forms application and click through it (again, without the need to run
the actual Windows installation), since in that mode the wizard uses a mocked
implementation of IInstallEngine. I just simply added the static Main method
which has the similar logic to the Run().
(Note to Rob: perhaps it would be a good idea to change the design of the
managed bootstrapper so that it works with interfaces instead of concrete
implementations, this would be really helpful for unit testing and simulation).
The wizard has one added feature: a debug window which can be turned on through
the command line and displays all the install log messages directly in the
setup wizard.
The documentation for the managed BS is pretty scarce, so I had to look into
WiX's source code and do a lot of trials and errors to get to this point (and I
still have some issues to work through).
Best regards,
Igor Brejc
On Fri, Oct 19, 2012 at 10:39 AM, Hans ter Horst hoshis...@gmail.comwrote:
Thanks Daniel, this is precisely what I needed!
On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce
daniel.br...@prediktor.no
wrote:
To resolve Microsoft.Tools.WindowsInstallerXml.Bootstrapper, you
need to add a reference to BootstrapperCore, which in my
installation was located under C:\Program Files (x86)\WiX Toolset
v3.7\SDK\BootstrapperCore.dll.
You
should be able to find yours in a similar location.
You are correct that there is little information about how to get
started with Burn, and the little information there is to find is
scattered
around
the net and pretty terse, so I'll give you enough to get started,
then
you
should be able to look at the source code for the WiX BA to continue
(I highly recommend having the source around to look at either way,
because there is really no other way to get information about most things).
For my WPF-based bootstrapper interface, I started a regular WPF
application project and changed its output type to class library.
Then
I
have a class that inherits from BootstrapperApplication looking
something like this:
public class MyBA : BootstrapperApplication {
static public Threading.Dispatcher Dispatcher { get; private set; }
static public View.InstallerWindow Window { get; private set; }
static public App TheApp { get; private set; }
protected override void Run()
{
TheApp = new App();
TheApp.InitializeComponent();
// Send a reference to the Application to access things, if
necessary
TheApp.BA = this;
MyBA.Dispatcher = Threading.Dispatcher.CurrentDispatcher;
TheApp.Run();
this.Engine.Quit(TheApp.ExitCode);
}
}
And in my WPF Application class I have code like this to bring up a
pretty
standard MVVM application window:
public partial class App : Application {
public View.InstallerWindow Window { get; private set; }
public
Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplica
tion
BA
{ get; set; }
public int ExitCode
{
get
{
return state.InstallerResult;
}
}
private InstallationState state;
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
InstallationState state = new InstallationState(BA, ...);
this.state = state;
InstallerViewModel vm = new InstallerViewModel(state, ...,
Threading.Dispatcher.CurrentDispatcher);
var Window = new View.InstallerWindow(vm);
state.ParentHwnd = new WindowInteropHelper(Window).Handle;
Window.Show();
state.Initialize();
}
}
You also need to create a config file so the Burn managed
bootstrapper host can find your application, which should be named
something like YourAssemblyName.BootstrapperCore.config and look
something like this, replacing YourAssemblyName with your own assembly's
name:
?xml version=1.0 encoding=utf-8 ? configuration
configSections
sectionGroup name=wix.bootstrapper
Re: [WiX-users] Bootstrapping SQL Server 2012 Express
Hello, Can you install the Server by hand? Iirc you do not need / should use XML entity escaping in variables. But perhaps I am wrong. ( if I want a inside the ``manufacturer``-Tag, I need to write ``amp;`` - but when I delegate that into a variable I can refer to the symbol) -Ursprüngliche Nachricht- Von: Nick Ramirez [mailto:nickra...@hotmail.com] Gesendet: Donnerstag, 4. Oktober 2012 05:54 An: wix-users@lists.sourceforge.net Betreff: [WiX-users] Bootstrapping SQL Server 2012 Express I haven't been able to install SQL Server 2012 Express on Windows 7 64-bit using Burn. Has someone been successful with this that can point out what's wrong with my setup? /ExePackage Id=SQLSERVER SourceFile=SQLEXPR_x64_ENU.exe DetectCondition=SqlInstanceFound InstallCommand=$(var.SqlInstallCommand) UninstallCommand=$(var.SqlUninstallCommand) RepairCommand=$(var.SqlRepairCommand) // I am using these parameters for the install command: //ACTION=Install /Q /INDICATEPROGRESS /IACCEPTSQLSERVERLICENSETERMS /FEATURES=SQLEngine /INSTANCENAME=$(var.SqlServerInstance) /SQLSVCACCOUNT=quot;NT AUTHORITY\Network Servicequot; /SQLSYSADMINACCOUNTS=quot;BUILTIN\Administratorsquot;/ The bootstrapper fails with the message: Invalid pointer. The Burn log shows: /Error 0x80004003: Process returned error: 0x80004003 Error 0x80004003: Failed to execute EXE package. Error 0x80004003: Failed to configure per-machine EXE package. Applied execute package: SQLSERVER, result: 0x80004003, restart: None Error 0x80004003: Failed to execute EXE package./ And the SQL log shows, although I don't know if it's relevant: /Saved .Net security policy file 10/03/2012 23:45:50.370 Attempting to release setup mutex 10/03/2012 23:45:50.386 Setup mutex has been released 10/03/2012 23:45:50.402 SQM key not found 10/03/2012 23:45:50.417 Setup closed with exit code: 0x84C40013/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapping-SQL-Server-2012-Express-tp7581083.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExePackage uninstalled on upgrade
Hey Neil, thank you for this example (even you are not sure, if that is sufficient ;-) )! I have one question: Why do you want to include a SQL Server into your installation package? This way the user is forced to have the server on the same machine as the application - or is that desired by you? -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Montag, 1. Oktober 2012 22:11 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] ExePackage uninstalled on upgrade After a little trial and error I came up with this: dep:Provides Key=SQLServer2008R2ExpressSP1 Version=10.50.2500.0 / Where dep is defined as: xmlns:dep=http://schemas.microsoft.com/wix/DependencyExtension; dep:Provides / is placed as a child of the ExePackage. What this does is create a registry key in HKCR\Installer\Dependencies and this ties the package to the bundle. It appears to work ok but I would appreciate any feedback if this is incorrect or there is more I need to do. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 01 October 2012 18:43 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ExePackage uninstalled on upgrade The WiX toolset automatically creates a dependency provider for packages that it can (MsiPackage and in WiX v3.7, MspPackage). Since ExePackages are opaque, you'd need to add your own dependency provider (Provides element from WixDependencyExtension) to get the engine to do reference counting. On Mon, Oct 1, 2012 at 6:44 AM, Neil Sleightholm n...@x2systems.com wrote: More info: Running v1 installs SQL, v2 removes it, v3,4,5 etc installs SQL then immediately removes it! In the log file created for the upgrade there is this entry [1664:16B4][2012-10-01T13:30:31]: Skipping dependency registration on package with no dependency providers: SQLServerExpress. Neil I have a simple burn package that install SQL express and one MSI. The install works the first time I run it but when I upgrade it the SQL package is removed (if I upgrade again it is put back). It appears from the logs that it doesn't recognise that the package is referenced and so the upgrade causes it to be removed. My authoring looks like this: ?define InstanceName = TEMP ? ?define SqlWebLink = http://download.microsoft.com/download/D/1/8/D1869DEC-2638-4854-81B7-0 F374 55F35EA/SQLEXPR_x86_ENU.exe ? !-- Read SQL Server keys to find current instance and version -- util:RegistrySearch Id=SqlInstanceFound Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL Value=$(var.InstanceName) Result=exists Variable=SqlInstanceFound / PackageGroup Id=SQLServerExpress ExePackage Id=SQLServerExpress DisplayName=SQL Server 2008 R2 Express Cache=no Compressed=no PerMachine=yes Permanent=no Vital=yes Name=Redist\SQLEXPR_x86_ENU.exe SourceFile=Redist\SQLEXPR_x86_ENU.exe DownloadUrl=$(var.SqlWebLink) InstallCommand=/ACTION=Install /INSTANCENAME=$(var.InstanceName) /FEATURES=SQL /SECURITYMODE=SQL /SAPWD=pass /TCPENABLED=1 /SQLSVCACCOUNT=quot;NT AUTHORITY\NETWORK SERVICEquot; /SQLSVCSTARTUPTYPE=Manual /SQLSYSADMINACCOUNTS=BUILTIN\Administrators /Q /HIDECONSOLE /SkipRules=RebootRequiredCheck /IAcceptSQLServerLicenseTerms RepairCommand=/ACTION=Repair /INSTANCENAME=$(var.InstanceName) /Q /HIDECONSOLE UninstallCommand=/Action=Uninstall /INSTANCENAME=$(var.InstanceName) /FEATURES=SQL /Q /HIDECONSOLE DetectCondition=SqlInstanceFound ExitCode Value =3010 Behavior=forceReboot / /ExePackage /PackageGroup Can anyone see why the package is removed on upgrade? Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com - - Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC
Re: [WiX-users] Burn and Upgrades
Ok. It would be cool if you could use a Burn-Package like a Msi-Package and it would know, if it is allowed to perform an upgrade. I have tested yet, that the WiXStBA stops with an error, if one tries to install an older bundle over a newer yet installed one. So I was hoping that you can specify the allowed versions in order to get a better failing message. But now it seems to me, that I need a custom BA if I want to achieve that goal? For our upgrades it could be possible, that a Msi-Package is sufficient - but first of all I am not sure about that yet and on the other hand I am not sure if it is possible to make the full installation via a burn bundle and the upgrades only via a Msi. As my C# knowledges are not so profound yet, I would like to avoid writing a custom BA... -Ursprüngliche Nachricht- Von: Rob Mensching [mailto:r...@robmensching.com] Gesendet: Montag, 1. Oktober 2012 06:12 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Burn and Upgrades No. Why do you need min-max version restrictions? Today, if you have multiple Bundles with the same UpgradeCode, the higher version upgrades the lower versions. You can also upgrade other Bundle's UpgradeCodes by adding a RelatedBundle with the Action='upgrade' and the Id='UpgradeCodeOfOtherBundles'. Technically speaking, the Bundle/@UpgradeCode attribute is just short hand for the RelatedBundle syntax. That and it is required. 2012/9/28 Christian Hausknecht chauskne...@beracom.de Hello folks, is there anything in Burn that provides a possibility to define a minimum and a maximum bundle version for and upgrade like the UpgradeVersion-Tags in WiX? And if not is there a way to handle a check without writing a custom BA? Overall what is the exact behavior of a bundle that recognizes that its version is higher than the one of the installed bundle? Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: Major Upgrades, Burn and determining, which actions to do
Hey Rob, thanks for your answer. @1.) Yes, I did so and sadly the copied content gets removed :-( So I assume I will write a CA that handles the copying and take the responsibility for the files away from WiX. @2.) Yes, that sounds like a good idea - as I do not know the scripts very well yet I will evaluate that issue. Greetings, Chris -Ursprüngliche Nachricht- Von: Rob Mensching [mailto:r...@robmensching.com] Gesendet: Freitag, 28. September 2012 04:58 An: General discussion for Windows Installer XML toolset. Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users] Major Upgrades, Burn and determining, which actions to do 1. IIRC, (I try to avoid CopyFile so I could be mistaken) uninstalling an MSI does not remove the copied content. You could create a quick MSI to verify. 2. I highly recommend making your scripts idempotent. Thus, you can always run them and if they've already been applied, they do nothing. Makes life much easier. On Thu, Sep 27, 2012 at 1:29 AM, Christian Hausknecht chauskne...@beracom.de wrote: Hello folks, as I did not get any answers to my last question, I try to be more precise today. I want to make an Installer with burn, that installs quite a big application. So there are different things to do, like just install some files, copy some files around, initiating a database and so on. Now I need to plan an update strategy before I actually start working on implementing the installer. As far as I know today, a major upgrade always deletes all elements which are related with the given Upgradecode. So that is in fact sometimes a problem. I have some formular templates which are copied to a different location after installation (with copyfile-Tag). So are those formular copies also uninstalled during a major upgrade? If so, is there a way to prevent them from being uninstalled? As customers can change the copies the update should not delete their work... only the new default formulars should be shipped... Another thing that gets me stuck is executing a script for database modification. Assuming I have a version 1.0.0 and some further versions like 1.0.1, 1.0.2, and so on. My plan is to build a full installer and an update installer for each version. But of course the update installer should be running on every customer machine that has a version prior to the current one. But how can I tell burn not to execute all database scripts but only those needed based upon the current version? For example a client has the version 1.0.1 (no matter if he fully installed at that version or made already an update from 1.0.0). Now the current version is 1.0.2. If he launches the current update installer, it should only execute the db-update-script that is needed in order to transform 1.0.1 db to a 1.0.2 db. But of course the db-script for transforming a 1.0.0 to a 1.0.1 is also bundled within the installer, as other customers might still stay at the 1.0.0. I definitely do not want to ship x different update installers for x existing program version that must be executed in a special sequence... so how can I achieve that goal? I hope you can help me with that issue :) Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Got visibility? Most devs has no idea what their production app looks like. Find out how
Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: Major Upgrades, Burn and determining, which actions to do
Hi Neil, @1.) Ah... I think I never tested to change the file and then run the update installer... I will figure that out! Would be nice, if that is the trick :-) Yes, I need to copy files. We have formular templates that the user can change. We always ship our default templates as a backup, but we do not want to override the customized templates. But if you are right, that would perfectly fit our needs I think! @2.) I just got the confirmation that our scripts behave exactly like that (so they are idempotent like Rob said it) - one thing less to bother with... -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Freitag, 28. September 2012 10:04 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: Major Upgrades, Burn and determining, which actions to do 1. I think that if the file is changed after a copy then it is not removed. Do you need to copy the file? If not you could mark it permanent. 2. We use idempotent scripts for SQL so that there is a single SQL script that can update from any version to the latest. Neil Hey Rob, thanks for your answer. @1.) Yes, I did so and sadly the copied content gets removed :-( So I assume I will write a CA that handles the copying and take the responsibility for the files away from WiX. @2.) Yes, that sounds like a good idea - as I do not know the scripts very well yet I will evaluate that issue. Greetings, Chris -Ursprüngliche Nachricht- Von: Rob Mensching [mailto:r...@robmensching.com] Gesendet: Freitag, 28. September 2012 04:58 An: General discussion for Windows Installer XML toolset. Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users] Major Upgrades, Burn and determining, which actions to do 1. IIRC, (I try to avoid CopyFile so I could be mistaken) uninstalling an MSI does not remove the copied content. You could create a quick MSI to verify. 2. I highly recommend making your scripts idempotent. Thus, you can always run them and if they've already been applied, they do nothing. Makes life much easier. On Thu, Sep 27, 2012 at 1:29 AM, Christian Hausknecht chauskne...@beracom.de wrote: Hello folks, as I did not get any answers to my last question, I try to be more precise today. I want to make an Installer with burn, that installs quite a big application. So there are different things to do, like just install some files, copy some files around, initiating a database and so on. Now I need to plan an update strategy before I actually start working on implementing the installer. As far as I know today, a major upgrade always deletes all elements which are related with the given Upgradecode. So that is in fact sometimes a problem. I have some formular templates which are copied to a different location after installation (with copyfile-Tag). So are those formular copies also uninstalled during a major upgrade? If so, is there a way to prevent them from being uninstalled? As customers can change the copies the update should not delete their work... only the new default formulars should be shipped... Another thing that gets me stuck is executing a script for database modification. Assuming I have a version 1.0.0 and some further versions like 1.0.1, 1.0.2, and so on. My plan is to build a full installer and an update installer for each version. But of course the update installer should be running on every customer machine that has a version prior to the current one. But how can I tell burn not to execute all database scripts but only those needed based upon the current version? For example a client has the version 1.0.1 (no matter if he fully installed at that version or made already an update from 1.0.0). Now the current version is 1.0.2. If he launches the current update installer, it should only execute the db-update-script that is needed in order to transform 1.0.1 db to a 1.0.2 db. But of course the db-script for transforming a 1.0.0 to a 1.0.1 is also bundled within the installer, as other customers might still stay at the 1.0.0. I definitely do not want to ship x different update installers for x existing program version that must be executed in a special sequence... so how can I achieve that goal? I hope you can help me with that issue :) Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für
[WiX-users] Burn and Upgrades
Hello folks, is there anything in Burn that provides a possibility to define a minimum and a maximum bundle version for and upgrade like the UpgradeVersion-Tags in WiX? And if not is there a way to handle a check without writing a custom BA? Overall what is the exact behavior of a bundle that recognizes that its version is higher than the one of the installed bundle? Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Major Upgrades, Burn and determining, which actions to do
Hello folks, as I did not get any answers to my last question, I try to be more precise today. I want to make an Installer with burn, that installs quite a big application. So there are different things to do, like just install some files, copy some files around, initiating a database and so on. Now I need to plan an update strategy before I actually start working on implementing the installer. As far as I know today, a major upgrade always deletes all elements which are related with the given Upgradecode. So that is in fact sometimes a problem. I have some formular templates which are copied to a different location after installation (with copyfile-Tag). So are those formular copies also uninstalled during a major upgrade? If so, is there a way to prevent them from being uninstalled? As customers can change the copies the update should not delete their work... only the new default formulars should be shipped... Another thing that gets me stuck is executing a script for database modification. Assuming I have a version 1.0.0 and some further versions like 1.0.1, 1.0.2, and so on. My plan is to build a full installer and an update installer for each version. But of course the update installer should be running on every customer machine that has a version prior to the current one. But how can I tell burn not to execute all database scripts but only those needed based upon the current version? For example a client has the version 1.0.1 (no matter if he fully installed at that version or made already an update from 1.0.0). Now the current version is 1.0.2. If he launches the current update installer, it should only execute the db-update-script that is needed in order to transform 1.0.1 db to a 1.0.2 db. But of course the db-script for transforming a 1.0.0 to a 1.0.1 is also bundled within the installer, as other customers might still stay at the 1.0.0. I definitely do not want to ship x different update installers for x existing program version that must be executed in a special sequence... so how can I achieve that goal? I hope you can help me with that issue :) Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Architecture of an installer
Hello folks, as I have to implement an installer with WiX and burn, that must handle updates, I try to figure out, how the windows installer concepts for those tasks functions and how to set up a nice architecture around this. As I have no experience with this yet, I do not want to construct an installer that produces something that cannot easily be upgraded later on. To give you more impression about the tasks I have to do, imagine first of all a classical task within a Msi-Package: Just install some files, copy some of them around and that's almost all. Then I would like to bundle that one into a burn Package in order to execute some other tasks, e.g. installing some prerequisites, creating some shortcuts, register some DLLs, create caspol rules, ... I have all those things already within a burn bundle, so I could just execute that one. If it is better it should also be quite easy to just use the same code for the bundle I create now. The final step is to modify an access database and perhaps and probably also a SQL Server DB. So my questions are: Should I just use the premade Installer.exe for the middle tasks I need here too? And if there will be Updates coming, most of them will be just concerning the first Msi (that one, which just install files) and probably would require some database modifying tasks. So what is the way to go there? Create a separate Update-Package for each Update? (If I understood the logic behind that topic right, I just have to use the *same* UpgradeCode within the burn package and the bundled Msi-Packages and modify the version numbers and the product-ID within a Msi-Package?) What is the right architecture for problems like that? What are the experiences made by you? One Installer for full installation and Updates or separate them? If one should use only one Installer, how can I determine, which Actions should only be done in an upgrade process and which only within a full installation process? Although WiX is a great framework imho there is a lack of *good* documentation dealing with holistic practices around the whole installation stuff. (Not the fault of the developers of course, just a fact. So I do not want to blame anybody!) So I hope I can get some advice from this nice community :) Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Getting the Name of the system drive within Burn or WiX?
Hello folks, As the subject already shows, I need to know the drive letter of the system drive within a burn-bundle or a Msi-Package (I am not already sure, where exactly I will need it, but I definitely need it). I looked at the page of the predefined burn variables, but I did not find anything helpful. (http://wix.sourceforge.net/manual-wix3/bundle_built_in_variables.htm) After I googled a while I found this page: http://stackoverflow.com/questions/810273/how-can-i-get-the-system-drive-letter So obviously there is an Environment-Variable which holds this information. But I could use that one only within a Msi-Package afaik. So for a burn bundle that would be no solution. So my question is: Is there a good way to solve this issue? And if there is no universal way, what would be the best practices for realizing that for the two different cases? Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting the Name of the system drive within Burn or WiX?
Of course I did not see it :-( Thank you for that hint! It sounds quite good - I will try that one. Perhaps a description with the relation to %SystemDrive% or perhaps the same name would be a good idea instead of ``WindowsVolume``... but perhaps I am wrong and that name is already good ;-) If that works, then I can use this for burn and the environment variable %SystemDrive% for Msis. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Montag, 24. September 2012 14:14 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Getting the Name of the system drive within Burn or WiX? Did you see the Burn variable WindowsVolume ? Is that what you need ? -Original Message- From: Christian Hausknecht [mailto:chauskne...@beracom.de] Sent: 24 September 2012 12:42 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting the Name of the system drive within Burn or WiX? Hello folks, As the subject already shows, I need to know the drive letter of the system drive within a burn-bundle or a Msi-Package (I am not already sure, where exactly I will need it, but I definitely need it). I looked at the page of the predefined burn variables, but I did not find anything helpful. (http://wix.sourceforge.net/manual-wix3/bundle_built_in_variables.htm) After I googled a while I found this page: http://stackoverflow.com/questions/810273/how-can-i-get-the-system-drive-lett er So obviously there is an Environment-Variable which holds this information. But I could use that one only within a Msi-Package afaik. So for a burn bundle that would be no solution. So my question is: Is there a good way to solve this issue? And if there is no universal way, what would be the best practices for realizing that for the two different cases? Greetings, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: To regasm or to not regasm...
Unfortunately that is not the case! Later on the Client will be run on multiple machines - that is the clue about this special installation method: The real Client binaries and other stuff is only installed on *one* physical machine. The real users do not have most stuff locally; they just refer to those files via a network folder. I know about the CAS issues and that problem can be solved with granting rights. -Ursprüngliche Nachricht- Von: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Gesendet: Mittwoch, 29. August 2012 17:57 An: General discussion for Windows Installer XML toolset. Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users] To regasm or to not regasm... If you are only wanting to register these DLL's for your own private usage within a single application, I'd strongly suggest using registration free COM and deploy them with the application. This allows the OS to load the info into the activation context at application start, and would allow you to have multiple folders with multiple versions without the need to invoke a setup/repair operation when switching between them. Regardless of if you register the DLL or use it in isolation, I seem to remember issues with .Net assemblies running on a network share being in a sandboxed zone where the CAS (prior to 4.0) would not allow the evil network binary to be able to do privileged operations without messing with the machine policy (granting full trust to our strong name). Jacob -Original Message- From: Christian Hausknecht [mailto:chauskne...@beracom.de] Sent: Wednesday, August 29, 2012 10:44 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] To regasm or to not regasm... Hello folks, me again :-D The next problem I must solve requires some experience that I do not have, so I hope I can get good advice as usual from here :) Base problem is quite easy: I need to register some DLLs during installation process. But my initial situation is like this: I do not install the DLLs on the local system! They are already located in a mounted net drive (is it called like this in the Windows-World?). The proper location can be different on every system, so one might have access to it like this X:\foo\bar\bin\MyDLL.dll some other might have a different drive name. So the path to the dll differs. My question is now: Is it possible to use ``heat`` to harvest the information *once* from the build-server and integrate them into my wix-project as usual? That is the way Rob mentioned here: http://stackoverflow.com/a/1397481 But is that an option for my situation? Is the path something that affects the registration? And is it possible just to keep some parts (e.g. TypeLib-Part?!?) from the heat-output, as I do not want to install the dll locally? So can I just register the dlls with wix or is there always an installation process on top? And if so, what parts do I need? If all else fails I think I just have to call ``regasm`` from a CustomAction - that should not be the problem to implement. But as Rob mentioned, it is perhaps not a good solution. So if it is possible to solve this with plain wix, I would definitely appreciate that. I hope it is understandable for you, sorry my English is not so good :( If something is still confusing or not sufficiently explained, please let me know. If not, please help me :) Best regards, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Spam-Wahrscheinlichkeit=27]Re: To regasm or to not regasm...
Thank you for your hints. On my machine I did not found the ``tlbexp`` program
- but ``regasm`` provides the ``/tlb``-option. I used that one to extract the
typelib informations. I heated both files, the reg and the tlb file with
heat and put the Component / ComponentGroup in my feature. It seems to work,
although the client does not start yet... I hope that is based upon other
things or small details. Conceptually I like this approach - and if there is
not much change within the DLLs, the manual adaption of the heat-output is
handable.
One thing I am not yet sure about is the output from heat from the tlb-file:
Component Id=cmp11F9322FF1064D034FA4BA9BCF618492
Guid=PUT-GUID-HERE
File Id=filA9EB85D16EFF314C782F721AFA2261D2 KeyPath=yes
Source=SomePath\on\my\machine\FooSucheAdoNet.tlb
TypeLib Id={49BC1412-C947-4A6D-B95A-57E0E02BFF4A}
Description=FooSucheAdoNet
HelpDirectory=dirDAF1C2FD4864E498714038FD83871114 Language=0
MajorVersion=1 MinorVersion=0
Interface Id={1CBBF282-15AF-31B7-AAB2-D5DB582EBA6D}
Name=_Form ProxyStubClassId32={00020424---C000-0046} /
Interface Id={3C242570-930A-307B-8991-6C6EE413F432}
Name=_CConnectionClass
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={6A6B94C5-BCF4-314F-9363-D6F910C89B51}
Name=IAdoNetInterface
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={99ECAE46-1F0D-34AC-95DB-C7CA3F81DF2D}
Name=_CAdoNet ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
/Component
In the file-Tag is the only path information I found - is this file being
installed somewhere? And if so, where the hack is the relation to the locations
of the DLLs? I would strongly assume, that *somewhere* there must be a path
information for the program in order to find the needed Objects. The whole
process of registering DLLs in a registry and so on has the reason, that a
program can search the registry in order to find a DLL and then load and us it.
Or am I wrong with that?
I that is right, where is the relation???
Perhaps there is still missing something and that is the reason, why the
program does not start...
Hopefully someone can help me furthermore!
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 29. August 2012 18:05
An: General discussion for Windows Installer XML toolset.
Betreff: [Spam-Wahrscheinlichkeit=27]Re: [WiX-users] To regasm or to not
regasm...
When I last regasmed anything, I was using Wix2 and the tallow tool but the
process should apply to heat too.
Regasm /regfile doesn't create type lib, so use tlbexp to create a type lib.
Use typelib elements to register the type lib.
Use regasm /regfile to create a registration file.
Use heat to convert the registration file to registryvalues in wix source
code.
In the wix source code, replace any codebase (or other) paths with the
[SOMEPROPERTY] syntax. (Normally, you'd set the paths to [#DLL File ID].)
Ideally you should harvest from a machine that's as clean as possible. You can
set SOMEPROPERTY at install time to the full dll path.
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] To regasm or to not regasm...
Hello folks,
me again :-D
The next problem I must solve requires some experience that I do not have, so I
hope I can get good advice as usual from here :)
Base problem is quite easy: I need to register some DLLs during installation
process.
But my initial situation is like this:
I do not install the DLLs on the local system! They are already located in a
mounted net drive (is it called like this in the Windows-World?). The proper
location can be different on every system, so one might have access to it like
this X:\foo\bar\bin\MyDLL.dll some other might have a different drive name.
So the path to the dll differs.
My question is now: Is it possible to use ``heat`` to harvest the information
*once* from the build-server and integrate them into my wix-project as usual?
That is the way Rob mentioned here: http://stackoverflow.com/a/1397481
But is that an option for my situation? Is the path something that affects the
registration? And is it possible just to keep some parts (e.g.
TypeLib-Part?!?) from the heat-output, as I do not want to install the dll
locally? So can I just register the dlls with wix or is there always an
installation process on top? And if so, what parts do I need?
If all else fails I think I just have to call ``regasm`` from a CustomAction
- that should not be the problem to implement. But as Rob mentioned, it is
perhaps not a good solution. So if it is possible to solve this with plain
wix, I
Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: [Spam-Wahrscheinlichkeit=27]Re: To regasm or to notregasm...
Hm... is it necessary that the tlb file is installed? I could provide this file
in the network folder...
And if not, is the location important?
No, I did not use /codebase... I better should I suppose ;-) Ok, I will
evaluate that.
Thx so far
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Donnerstag, 30. August 2012 11:13
An: General discussion for Windows Installer XML toolset.
Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users]
[Spam-Wahrscheinlichkeit=27]Re: To regasm or to notregasm...
Yes, the File element installs the file.
Did you specify /codebase when running regasm ? If you do, the wix source code
contains the codebase registry values that I mentioned. If you omit
/codebase, .Net assumes the dll is in the GAC.
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 30 August 2012 10:08
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [Spam-Wahrscheinlichkeit=27]Re: To regasm or to not
regasm...
Thank you for your hints. On my machine I did not found the ``tlbexp`` program
- but ``regasm`` provides the ``/tlb``-option. I used that one to extract the
typelib informations. I heated both files, the reg and the tlb file with
heat and put the Component / ComponentGroup in my feature. It seems to work,
although the client does not start yet... I hope that is based upon other
things or small details. Conceptually I like this approach - and if there is
not much change within the DLLs, the manual adaption of the heat-output is
handable.
One thing I am not yet sure about is the output from heat from the tlb-file:
Component Id=cmp11F9322FF1064D034FA4BA9BCF618492
Guid=PUT-GUID-HERE
File Id=filA9EB85D16EFF314C782F721AFA2261D2 KeyPath=yes
Source=SomePath\on\my\machine\FooSucheAdoNet.tlb
TypeLib Id={49BC1412-C947-4A6D-B95A-57E0E02BFF4A}
Description=FooSucheAdoNet
HelpDirectory=dirDAF1C2FD4864E498714038FD83871114 Language=0
MajorVersion=1 MinorVersion=0
Interface
Id={1CBBF282-15AF-31B7-AAB2-D5DB582EBA6D} Name=_Form
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={3C242570-930A-307B-8991-6C6EE413F432} Name=_CConnectionClass
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={6A6B94C5-BCF4-314F-9363-D6F910C89B51} Name=IAdoNetInterface
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={99ECAE46-1F0D-34AC-95DB-C7CA3F81DF2D} Name=_CAdoNet
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
/Component
In the file-Tag is the only path information I found - is this file being
installed somewhere? And if so, where the hack is the relation to the locations
of the DLLs? I would strongly assume, that *somewhere* there must be a path
information for the program in order to find the needed Objects.
The whole process of registering DLLs in a registry and so on has the reason,
that a program can search the registry in order to find a DLL and then load and
us it. Or am I wrong with that?
I that is right, where is the relation???
Perhaps there is still missing something and that is the reason, why the
program does not start...
Hopefully someone can help me furthermore!
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 29. August 2012 18:05
An: General discussion for Windows Installer XML toolset.
Betreff: [Spam-Wahrscheinlichkeit=27]Re: [WiX-users] To regasm or to not
regasm...
When I last regasmed anything, I was using Wix2 and the tallow tool but the
process should apply to heat too.
Regasm /regfile doesn't create type lib, so use tlbexp to create a type lib.
Use typelib elements to register the type lib.
Use regasm /regfile to create a registration file.
Use heat to convert the registration file to registryvalues in wix source
code.
In the wix source code, replace any codebase (or other) paths with the
[SOMEPROPERTY] syntax. (Normally, you'd set the paths to [#DLL File ID].)
Ideally you should harvest from a machine that's as clean as possible. You can
set SOMEPROPERTY at install time to the full dll path.
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 16:44
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] To regasm or to not regasm...
Hello folks,
me again :-D
The next problem I must solve requires some experience that I do not have, so I
hope I can get good advice as usual from here :)
Base problem is quite easy: I need to register some DLLs during installation
process.
But my initial situation is like this:
I do not install the DLLs on the local system! They are already located in a
mounted net drive (is it called like
Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: [Spam-Wahrscheinlichkeit=27]Re: To regasm or to notregasm...
Ok, I refactored everything and called ``regasm`` with ``/codebase``-option.
Now I have the paths in the wxs-file and could manage to make them point to a
location based upon a wix-property. Perfect! Also I set the ``Advertise=yes``
attribute in the ``TypeLib``-Tags and removed the enclosing ``File``-Tags so
the *.tlb files are not installed.
Unfortunately the program does not start yet, but I think that depends on other
still missing things.
Thx so far
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Donnerstag, 30. August 2012 11:50
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re:
[Spam-Wahrscheinlichkeit=27]Re: To regasm or to notregasm...
Hm... is it necessary that the tlb file is installed? I could provide this file
in the network folder...
And if not, is the location important?
No, I did not use /codebase... I better should I suppose ;-) Ok, I will
evaluate that.
Thx so far
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Donnerstag, 30. August 2012 11:13
An: General discussion for Windows Installer XML toolset.
Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users]
[Spam-Wahrscheinlichkeit=27]Re: To regasm or to notregasm...
Yes, the File element installs the file.
Did you specify /codebase when running regasm ? If you do, the wix source code
contains the codebase registry values that I mentioned. If you omit
/codebase, .Net assumes the dll is in the GAC.
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 30 August 2012 10:08
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [Spam-Wahrscheinlichkeit=27]Re: To regasm or to not
regasm...
Thank you for your hints. On my machine I did not found the ``tlbexp`` program
- but ``regasm`` provides the ``/tlb``-option. I used that one to extract the
typelib informations. I heated both files, the reg and the tlb file with
heat and put the Component / ComponentGroup in my feature. It seems to work,
although the client does not start yet... I hope that is based upon other
things or small details. Conceptually I like this approach - and if there is
not much change within the DLLs, the manual adaption of the heat-output is
handable.
One thing I am not yet sure about is the output from heat from the tlb-file:
Component Id=cmp11F9322FF1064D034FA4BA9BCF618492
Guid=PUT-GUID-HERE
File Id=filA9EB85D16EFF314C782F721AFA2261D2 KeyPath=yes
Source=SomePath\on\my\machine\FooSucheAdoNet.tlb
TypeLib Id={49BC1412-C947-4A6D-B95A-57E0E02BFF4A}
Description=FooSucheAdoNet
HelpDirectory=dirDAF1C2FD4864E498714038FD83871114 Language=0
MajorVersion=1 MinorVersion=0
Interface
Id={1CBBF282-15AF-31B7-AAB2-D5DB582EBA6D} Name=_Form
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={3C242570-930A-307B-8991-6C6EE413F432} Name=_CConnectionClass
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={6A6B94C5-BCF4-314F-9363-D6F910C89B51} Name=IAdoNetInterface
ProxyStubClassId32={00020424---C000-0046} /
Interface
Id={99ECAE46-1F0D-34AC-95DB-C7CA3F81DF2D} Name=_CAdoNet
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
/Component
In the file-Tag is the only path information I found - is this file being
installed somewhere? And if so, where the hack is the relation to the locations
of the DLLs? I would strongly assume, that *somewhere* there must be a path
information for the program in order to find the needed Objects.
The whole process of registering DLLs in a registry and so on has the reason,
that a program can search the registry in order to find a DLL and then load and
us it. Or am I wrong with that?
I that is right, where is the relation???
Perhaps there is still missing something and that is the reason, why the
program does not start...
Hopefully someone can help me furthermore!
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 29. August 2012 18:05
An: General discussion for Windows Installer XML toolset.
Betreff: [Spam-Wahrscheinlichkeit=27]Re: [WiX-users] To regasm or to not
regasm...
When I last regasmed anything, I was using Wix2 and the tallow tool but the
process should apply to heat too.
Regasm /regfile doesn't create type lib, so use tlbexp to create a type lib.
Use typelib elements to register the type lib.
Use regasm /regfile to create a registration file.
Use heat to convert the registration file to registryvalues in wix source
code.
In the wix source code, replace any codebase (or other) paths with the
[SOMEPROPERTY] syntax. (Normally, you'd set the paths to [#DLL
Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Ok, my idea was good, but there is a problem with it. Burn does not support
searching *during* the installation process. So even if I have the correct
sequence in my chain, the RegistrySearch is always done at the beginning before
any packages are executed :-( Therefore my little helper program has not been
called yet when the search happens and so the key is not found.
I found the answer here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html
I did not recognize that, as I do not delete the key after uninstall. So my
installer always found one as it was written in the previous installation
process...
So back to brainstorming... I think only a custom action can help me now? (That
I can place in my MsiPackage and call it before any other actions?)
Damn, I wished I could get around that... imho creating your own CA looks quite
difficult...
Bet regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Hm... no answer yet? Are my questions not understandable or too strange? ;-)
Ok, as perhaps some users might be interested in a solution, I present the way
I have chosen for now:
Basic Idea is to simply write a small C# Program, that gets the Path from a wix
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write
the result (the plain source path) into a defined registry key. Other
components of an installer bundle can retrieve this key and use the information
for further setup process.
The Mini-Program look like this:
namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1},
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename,
Path.GetDirectoryName(args[0]));
}
}
}
As you can see I use resource-strings for the definition of the registry key.
The fragment within the burn bundle to call the programm:
Fragment
PackageGroup Id=RegisterPath
ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
SourceFile=$(var.RegisterPathPath)
InstallCommand='[WixBundleOriginalSource]'
Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
/Fragment
As you can see I use the ``WixBundleOriginalSource``-variable provided from
burn (Which is the heart of the problem ;-) ).
Further down in my bundle package I refer to this in order to provide the path
to a Msi-Package:
Fragment
util:RegistrySearch Id=BasePathSearch
Variable=BASEPATHPROP
Root=HKCU
Key=Software\$(var.Manufacturer)
Result=value
Value=BasePath /
PackageGroup Id=ClientMsi
MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
/MsiPackage
/PackageGroup
/Fragment
One must take care that the Properties of the C#-Program and the attributes of
the RegistrySearch within the wix bundle are equal. Normally that does not
change too often, so I can live with that workaround for the moment.
Of course I would appreciate a more elegant solution; the best would be a
predefined variable by burn itself ;-)
Best regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 13:00
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Ok, I kept thinking about the problem and I have an idea, that probably could
lead to the right direction.
I can define a msi-property within the bundle definition to that one must
assign the current path and that can be used within the MSI package definition
as reference. I tried the following approach:
!-- Define MsiProperty within the burn bundle file -- MsiPackage
SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYSOURCEDIR Value=[WixBundleOriginalSource]\/
/MsiPackage
!-- Reference the property within the MSI definition -- Shortcut
Id=Foo_ShortCut
Name=Foo
Description=Foo
Target=[MYSOURCEDIR]Foo.exe
WorkingDirectory=ProgramFilesFolder/
That would work fine besides the wix variable `` WixBundleOriginalSource``
holds not only the path of the starting dir but the complete path *including*
the exe-filename :-( Is there any way to trim the value or maybe another
burn-variable, that holds only the path?
-Ursprüngliche Nachricht-
Von: Christian Hausknecht
Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Ok, I try to explain the background:
The installer will be located in a remote folder in which most executables of
the client are located. The Clients are practically not really installed on the
local machine, only Shortcuts with the path to the executables on the remote
folder are generated (besides some other stuff).
Therefore I need the path, from which the installer was called. As I wrote at
the beginning, burn only offers a *complete path* including the name of the
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the
installer name.
That's the problem I have to solve :-)
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Just stepping back at bit but why do you need the source of the burn install
passed into your MSI?
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Ok, my idea was good, but there is a problem with it. Burn does not support
searching *during* the installation process. So even if I have the correct
sequence in my chain, the RegistrySearch is always done at the beginning before
any packages are executed :-( Therefore my little helper program has not been
called yet when the search happens and so the key is not found.
I found the answer here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html
I did not recognize that, as I do not delete the key after uninstall. So my
installer always found one as it was written in the previous installation
process...
So back to brainstorming... I think only a custom action can help me now? (That
I can place in my MsiPackage and call it before any other actions?)
Damn, I wished I could get around that... imho creating your own CA looks quite
difficult...
Bet regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Hm... no answer yet? Are my questions not understandable or too strange? ;-)
Ok, as perhaps some users might be interested in a solution, I present the way
I have chosen for now:
Basic Idea is to simply write a small C# Program, that gets the Path from a wix
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write
the result (the plain source path) into a defined registry key. Other
components of an installer bundle can retrieve this key and use the information
for further setup process.
The Mini-Program look like this:
namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1},
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename,
Path.GetDirectoryName(args[0]));
}
}
}
As you can see I use resource-strings for the definition of the registry key.
The fragment within the burn bundle to call the programm:
Fragment
PackageGroup Id=RegisterPath
ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
SourceFile=$(var.RegisterPathPath)
InstallCommand='[WixBundleOriginalSource]'
Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
/Fragment
As you can see I use the ``WixBundleOriginalSource``-variable provided from
burn (Which is the heart of the problem ;-) ).
Further down in my bundle package I refer to this in order to provide the path
to a Msi-Package:
Fragment
util:RegistrySearch Id=BasePathSearch
Variable=BASEPATHPROP
Root=HKCU
Key=Software\$(var.Manufacturer)
Result=value
Value=BasePath /
PackageGroup Id=ClientMsi
MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
/MsiPackage
/PackageGroup
/Fragment
One must take care that the Properties of the C#-Program and the attributes of
the RegistrySearch within the wix bundle are equal. Normally that does not
change too often, so I can live with that workaround for the moment.
Of course I would appreciate a more elegant solution; the best would be a
predefined variable by burn itself ;-)
Best regards,
-Ursprüngliche Nachricht-
Von: Christian
Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Ok, finally I just implemented a custom action, that performs the string
manipulation and sets a new property to the session. This property value I can
grab easily from within my product.wxs:
Binary Id=MyCustomAction.dll SourceFile=$(var.global.MyCAPath)/
CustomAction Id=AdjustPath BinaryKey=MyCustomAction.dll
DllEntry=AdjustPath Execute=immediate/
!-- Execute Sequenz--
InstallExecuteSequence
Custom Action=AdjustPath Before=CostFinalize/
/InstallExecuteSequence
After that I can refer to the propery named ``FOOBASEPATH`` where the trimmed
path resides.
And here is the C# Code for the Custom Action:
namespace MyCustomActions
{
public class CustomActions
{
[CustomAction]
public static ActionResult AdjustPath(Session session)
{
session.Log(Begin AdjustPath);
session[FOOBASEPATH] =
Path.GetDirectoryName(session[BURNSOURCEDIR]) + @\;
session.Log(End AdjustPath);
return ActionResult.Success;
}
}
}
As CAs are only callable from within Msi-Packages I must provide a temporary
Property containing the value of the Built-in burn property ``
WixBundleOriginalSource``. I named it ``BURNSOURCEDIR``. So I can set this
Property as a MsiProperty in my (burn) bundle definition:
MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=BURNSOURCEDIR Value=[WixBundleOriginalSource]/
/MsiPackage
So the calling sequence is like this:
1.) call the Msi-Package and provide a Property named ``BURNSOURCEDIR`` with
the value of ``WixBundleOriginalSource``
2.) In the Msi-Package execute the custom action
3.) The CA sets the new Property ``FOOBASEPATH``
4.) Use ``FOOBASEPATH`` everywhere in the Msi-Package where one need it
5.) be happy :-D
Puh... much work for some little thing. But gained more knowledge about WiX,
burn and Windows Installer technologies. And in the end it works :-)
Best regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Mittwoch, 29. August 2012 11:58
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Ok, I try to explain the background:
The installer will be located in a remote folder in which most executables of
the client are located. The Clients are practically not really installed on the
local machine, only Shortcuts with the path to the executables on the remote
folder are generated (besides some other stuff).
Therefore I need the path, from which the installer was called. As I wrote at
the beginning, burn only offers a *complete path* including the name of the
installer (e.g. ``Z:\Foo\Bar\setup.exe``). I need the path without the
installer name.
That's the problem I have to solve :-)
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Mittwoch, 29. August 2012 11:41
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Just stepping back at bit but why do you need the source of the burn install
passed into your MSI?
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 29 August 2012 10:39
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Ok, my idea was good, but there is a problem with it. Burn does not support
searching *during* the installation process. So even if I have the correct
sequence in my chain, the RegistrySearch is always done at the beginning before
any packages are executed :-( Therefore my little helper program has not been
called yet when the search happens and so the key is not found.
I found the answer here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-value-created-by-first-msi-as-input-to-second-msi-in-chain-td7518069.html
I did not recognize that, as I do not delete the key after uninstall. So my
installer always found one as it was written in the previous installation
process...
So back to brainstorming... I think only a custom action can help me now? (That
I can place in my MsiPackage and call it before any other actions?)
Damn, I wished I could get around that... imho creating your own CA looks quite
difficult...
Bet regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Dienstag, 28. August 2012 10:33
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Hm... no answer yet? Are my questions not understandable or too strange? ;-)
Ok, as perhaps some users might be interested in a solution, I present the way
I have chosen for now:
Basic Idea
[WiX-users] To regasm or to not regasm...
Hello folks, me again :-D The next problem I must solve requires some experience that I do not have, so I hope I can get good advice as usual from here :) Base problem is quite easy: I need to register some DLLs during installation process. But my initial situation is like this: I do not install the DLLs on the local system! They are already located in a mounted net drive (is it called like this in the Windows-World?). The proper location can be different on every system, so one might have access to it like this X:\foo\bar\bin\MyDLL.dll some other might have a different drive name. So the path to the dll differs. My question is now: Is it possible to use ``heat`` to harvest the information *once* from the build-server and integrate them into my wix-project as usual? That is the way Rob mentioned here: http://stackoverflow.com/a/1397481 But is that an option for my situation? Is the path something that affects the registration? And is it possible just to keep some parts (e.g. TypeLib-Part?!?) from the heat-output, as I do not want to install the dll locally? So can I just register the dlls with wix or is there always an installation process on top? And if so, what parts do I need? If all else fails I think I just have to call ``regasm`` from a CustomAction - that should not be the problem to implement. But as Rob mentioned, it is perhaps not a good solution. So if it is possible to solve this with plain wix, I would definitely appreciate that. I hope it is understandable for you, sorry my English is not so good :( If something is still confusing or not sufficiently explained, please let me know. If not, please help me :) Best regards, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Hm... no answer yet? Are my questions not understandable or too strange? ;-)
Ok, as perhaps some users might be interested in a solution, I present the way
I have chosen for now:
Basic Idea is to simply write a small C# Program, that gets the Path from a wix
burn bundle via CLI, shortens it by removing the ``setup.exe``-part and write
the result (the plain source path) into a defined registry key. Other
components of an installer bundle can retrieve this key and use the information
for further setup process.
The Mini-Program look like this:
namespace RegisterPath
{
class Program
{
static void Main(string[] args)
{
Registry.SetValue(string.Format(@{0}\{1},
RegisterPath.Properties.Resources.root, RegisterPath.Properties.Resources.key),
RegisterPath.Properties.Resources.valuename,
Path.GetDirectoryName(args[0]));
}
}
}
As you can see I use resource-strings for the definition of the registry key.
The fragment within the burn bundle to call the programm:
Fragment
PackageGroup Id=RegisterPath
ExePackage Name=RegisterPath.exe Id=RegisterPath_PK
SourceFile=$(var.RegisterPathPath)
InstallCommand='[WixBundleOriginalSource]'
Cache=no Compressed=yes PerMachine=yes Vital=yes/
/PackageGroup
/Fragment
As you can see I use the ``WixBundleOriginalSource``-variable provided from
burn (Which is the heart of the problem ;-) ).
Further down in my bundle package I refer to this in order to provide the path
to a Msi-Package:
Fragment
util:RegistrySearch Id=BasePathSearch
Variable=BASEPATHPROP
Root=HKCU
Key=Software\$(var.Manufacturer)
Result=value
Value=BasePath /
PackageGroup Id=ClientMsi
MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYBASEPATH Value=[BASEPATHPROP]\/
/MsiPackage
/PackageGroup
/Fragment
One must take care that the Properties of the C#-Program and the attributes of
the RegistrySearch within the wix bundle are equal. Normally that does not
change too often, so I can live with that workaround for the moment.
Of course I would appreciate a more elegant solution; the best would be a
predefined variable by burn itself ;-)
Best regards,
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 13:00
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to get the SourceDir in a MSI package that is
bundled within burn?
Ok, I kept thinking about the problem and I have an idea, that probably could
lead to the right direction.
I can define a msi-property within the bundle definition to that one must
assign the current path and that can be used within the MSI package definition
as reference. I tried the following approach:
!-- Define MsiProperty within the burn bundle file -- MsiPackage
SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYSOURCEDIR Value=[WixBundleOriginalSource]\/
/MsiPackage
!-- Reference the property within the MSI definition -- Shortcut
Id=Foo_ShortCut
Name=Foo
Description=Foo
Target=[MYSOURCEDIR]Foo.exe
WorkingDirectory=ProgramFilesFolder/
That would work fine besides the wix variable `` WixBundleOriginalSource``
holds not only the path of the starting dir but the complete path *including*
the exe-filename :-( Is there any way to trim the value or maybe another
burn-variable, that holds only the path?
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 11:04
An: wix-users@lists.sourceforge.net
Betreff: [WiX-users] How to get the SourceDir in a MSI package that is bundled
within burn?
Hello folks,
I have basically the same question as the guy here:
http://stackoverflow.com/questions/10573135/wix-installer-how-can-i-get-setup-exes-current-directory
I have created a MSI where some Shortcuts for the Menu and the Desktop are
created. They are created for applications, which are already installed and
therefore are not part of my installation routine. The installer itself is
located in the same directory. If I just test the MSI, then
``Target=[SourceDir]Foo.exe`` just works as expected. But when I embedd this
MSI into a bundle built with burn, then [SourceDir] does not refer to the
Directory, where the Installer is located. Instead it refers to
%TEMP%\{ProductID}\{Version}\Foo.exe. But I do not need this path but the one
I get if I install the MSI directly.
As the Path is variable, I *must* be able to refer to the actual starting
directory of the installer.exe. Can anyone provide a solution for that?
Greetings,
Mit freundlichen Grüßen
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG
[WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Hello folks,
I have basically the same question as the guy here:
http://stackoverflow.com/questions/10573135/wix-installer-how-can-i-get-setup-exes-current-directory
I have created a MSI where some Shortcuts for the Menu and the Desktop are
created. They are created for applications, which are already installed and
therefore are not part of my installation routine. The installer itself is
located in the same directory. If I just test the MSI, then
``Target=[SourceDir]Foo.exe`` just works as expected. But when I embedd this
MSI into a bundle built with burn, then [SourceDir] does not refer to the
Directory, where the Installer is located. Instead it refers to
%TEMP%\{ProductID}\{Version}\Foo.exe. But I do not need this path but the one
I get if I install the MSI directly.
As the Path is variable, I *must* be able to refer to the actual starting
directory of the installer.exe. Can anyone provide a solution for that?
Greetings,
Mit freundlichen Grüßen
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG
Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung
GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt.
Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher
schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist
sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der
Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung
überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre
Richtigkeit.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to get the SourceDir in a MSI package that is bundled within burn?
Ok, I kept thinking about the problem and I have an idea, that probably could
lead to the right direction.
I can define a msi-property within the bundle definition to that one must
assign the current path and that can be used within the MSI package definition
as reference. I tried the following approach:
!-- Define MsiProperty within the burn bundle file --
MsiPackage SourceFile=$(var.ClientMSIPath)
MsiProperty Name=MYSOURCEDIR Value=[WixBundleOriginalSource]\/
/MsiPackage
!-- Reference the property within the MSI definition --
Shortcut Id=Foo_ShortCut
Name=Foo
Description=Foo
Target=[MYSOURCEDIR]Foo.exe
WorkingDirectory=ProgramFilesFolder/
That would work fine besides the wix variable `` WixBundleOriginalSource``
holds not only the path of the starting dir but the complete path *including*
the exe-filename :-( Is there any way to trim the value or maybe another
burn-variable, that holds only the path?
-Ursprüngliche Nachricht-
Von: Christian Hausknecht [mailto:chauskne...@beracom.de]
Gesendet: Montag, 27. August 2012 11:04
An: wix-users@lists.sourceforge.net
Betreff: [WiX-users] How to get the SourceDir in a MSI package that is bundled
within burn?
Hello folks,
I have basically the same question as the guy here:
http://stackoverflow.com/questions/10573135/wix-installer-how-can-i-get-setup-exes-current-directory
I have created a MSI where some Shortcuts for the Menu and the Desktop are
created. They are created for applications, which are already installed and
therefore are not part of my installation routine. The installer itself is
located in the same directory. If I just test the MSI, then
``Target=[SourceDir]Foo.exe`` just works as expected. But when I embedd this
MSI into a bundle built with burn, then [SourceDir] does not refer to the
Directory, where the Installer is located. Instead it refers to
%TEMP%\{ProductID}\{Version}\Foo.exe. But I do not need this path but the one
I get if I install the MSI directly.
As the Path is variable, I *must* be able to refer to the actual starting
directory of the installer.exe. Can anyone provide a solution for that?
Greetings,
Mit freundlichen Grüßen
Christian Hausknecht
Entwicklung
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg
T: +49 (0)40 547 241 - DW
F: +49 (0)40 547 241 - 60
M: chauskne...@beracom.demailto:chauskne...@beracom.de
http://www.beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende
Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg,
RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich
und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch
auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des
Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei
inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser
Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen
übernimmt jedoch keine Haftung für ihre Richtigkeit.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can a wixlib contain a theme file?
Hello folks, is it possible to create a wixlib that holds a theme file and a localization file? I have to build two different burn-bundles, one for a server installation (already finished) and one for the corresponding client. Both share some logic, as common prerequisits for example. But also the theme should be identical. For the first case I have read, that one can create a wixlib and reference that from within each burn project. But is this also possible for a theme file? And if that is impossible, what is a good practice to organize common components? If I put them in a project independent directory, how will wix-tools find them during build process? I hope someone can give me some advise :) Best regards, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can a wixlib contain a theme file?
Hello folks, is it possible to create a wixlib that holds a theme file and a localization file? I have to build two different burn-bundles, one for a server installation (already finished) and one for the corresponding client. Both share some logic, as common prerequisits for example. But also the theme should be identical. For the first case I have read, that one can create a wixlib and reference that from within each burn project. But is this also possible for a theme file? And if that is impossible, what is a good practice to organize common components? If I put them in a project independent directory, how will wix-tools find them during build process? I hope someone can give me some advise :) Best regards, Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 - DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can a wixlib contain a theme file? (second attempt)
Hello folks, is it possible to create a wixlib that holds a theme file and a localization file? I have to build two different burn-bundles, one for a server installation (already finished) and one for the corresponding client. Both share some logic, as common prerequisits for example. But also the theme should be identical. For the first case I have read, that one can create a wixlib and reference that from within each burn project. But is this also possible for a theme file? And if that is impossible, what is a good practice to organize “common components”? If I put them in a project independent directory, how will wix-tools find them during build process? I hope someone can give me some advise Best regards, PS: Sorry for double post, but my first mail seemed broken to me… Mit freundlichen Grüßen Christian Hausknecht Entwicklung BeraCom Beratung und Software-Entwicklung GmbH Co. KG Weidestr. 134, 22083 Hamburg T: +49 (0)40 547 241 – DW F: +49 (0)40 547 241 - 60 M: chauskne...@beracom.demailto:chauskne...@beracom.de http://www.beracom.de = Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg, RG Hamburg, HRB 64844 Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist vertraulich und exklusiv für den/die Adressaten bestimmt. Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In jedem Fall ist sicherzustellen, dass keinerlei inhaltliche Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to bundle a configuration file in burn?
Thank you for your hint, but could you give me an example, how to express that
in WiX?
I would write this as naïve attempt:
ExePackage Id=SQLServer SourceFile=X:\Software\Applikationen\SQL
Server\2008 R2\SQLEXPR32_x86_DEU.exe
InstallCommand='/QS /ACTION=Install /SAPWD=express
/IACCEPTSQLSERVERLICENSETERMS /CONFIGURATIONFILE=C:\some\path\config.ini
Payload Id=SQLServerConfigFile SourceFile=C:\some\path\config.ini /
/ExePackage
But the /CONFIGURATIONFILE-Parameter links to a location in my local FS. When
the installer gets started it will not find the file in that location...
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 09:06
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
You should be able to do this using the PayLoad element as a child of your
ExePackage element.
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 13 August 2012 11:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to bundle a configuration file in burn?
Hello folks,
I would like to build a setup file for a MS SQL Server 2008 Express Edition
with a predefined configuration. One can pass a parameter
/ConfigurationFile={Absolute path to a ConfigFile.ini} to the setup file of
SQLServer in which many parameters are defined. Those config files can easily
be generated by the SQL Server UI-Setup Mode and therefore I would like to use
them also in my bundle. Now I face the problem of how I can provide the
required file and in addition which path I must define within the parameter. Is
there any chance to handle that with burn?
If not I have to provide *all* needed configuration parameters by hand to the
setup-file; this would solve the problem, but I consider this to be not very
comfortable... (I would have to change this long parameter-string every time
something changed...)
I hope you can give me some good advice, in order to avoid long trial and
errors.
Best regards,
Mit freundlichen Grüßen
Christian Hausknecht
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG Weidestraße 134, 22083 Hamburg
Tel.: +49 (0)40 547241 - 27
eMail: chauskne...@beracom.demailto:tneld...@beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende
Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg,
RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to bundle a configuration file in burn?
Ah... you mean that one should only provide a relative path like this:
/CONFIGURATIONFILE=config.ini
? That sounds promising... I will try and report about it later on :-)
Thx
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 11:07
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
I have to admit I haven't tried it yet (although probably will be doing exactly
the same thing later today). Have you tried removing the path from the
/CONFIGURATIONFILE parameter?
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 14 August 2012 08:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to bundle a configuration file in burn?
Thank you for your hint, but could you give me an example, how to express that
in WiX?
I would write this as naïve attempt:
ExePackage Id=SQLServer SourceFile=X:\Software\Applikationen\SQL
Server\2008 R2\SQLEXPR32_x86_DEU.exe
InstallCommand='/QS /ACTION=Install /SAPWD=express
/IACCEPTSQLSERVERLICENSETERMS /CONFIGURATIONFILE=C:\some\path\config.ini
Payload Id=SQLServerConfigFile SourceFile=C:\some\path\config.ini /
/ExePackage
But the /CONFIGURATIONFILE-Parameter links to a location in my local FS. When
the installer gets started it will not find the file in that location...
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 09:06
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
You should be able to do this using the PayLoad element as a child of your
ExePackage element.
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 13 August 2012 11:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to bundle a configuration file in burn?
Hello folks,
I would like to build a setup file for a MS SQL Server 2008 Express Edition
with a predefined configuration. One can pass a parameter
/ConfigurationFile={Absolute path to a ConfigFile.ini} to the setup file of
SQLServer in which many parameters are defined. Those config files can easily
be generated by the SQL Server UI-Setup Mode and therefore I would like to use
them also in my bundle. Now I face the problem of how I can provide the
required file and in addition which path I must define within the parameter. Is
there any chance to handle that with burn?
If not I have to provide *all* needed configuration parameters by hand to the
setup-file; this would solve the problem, but I consider this to be not very
comfortable... (I would have to change this long parameter-string every time
something changed...)
I hope you can give me some good advice, in order to avoid long trial and
errors.
Best regards,
Mit freundlichen Grüßen
Christian Hausknecht
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG Weidestraße 134, 22083 Hamburg
Tel.: +49 (0)40 547241 - 27
eMail: chauskne...@beracom.demailto:tneld...@beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich haftende
Gesellschafterin: BeraCom Beratung und Software-Entwicklung GmbH Sitz Hamburg,
RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263
Re: [WiX-users] How to bundle a configuration file in burn?
Thanks for evaluating that... I had other stuff to do, so I was not able to
check that yet. But I remember that I stumbled last days over the fact, that I
must provide the *full* path to the SQLServer installation programs. So it is
quite obvious, that it reacts the same way within a BA.
For now I wrote a little helper script that extracts all parameters from the
given INI file and joines them to appropriate parameters that I can easily copy
and paste into my bundle.wxs. Not really nice, but it works for now. And as one
anyway has to update the whole bundle if a configuration parameter changes, I
can live with this workaround.
But I would appreciate if you can provide a solution for this kind of issue in
the future - just to change a config file is definitely more robust than
hacking in the bundle definition file :-)
Thx for your efforts and for wix of course ;-)
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 16:46
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
Unfortunately is doesn’t work, SQL needs to full path. What we would need is a
burn variable point to the cache folder - I'll add a defect so it is not lost.
Neil
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 14 August 2012 15:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to bundle a configuration file in burn?
If that does not work, we should add a way to get the full path to a payload
via the Burn variable mechanism. That won't help you in WiX v3.6 but we should
be able to add it in WiX v3.7.
On Tue, Aug 14, 2012 at 2:37 AM, Christian Hausknecht chauskne...@beracom.de
wrote:
Ah... you mean that one should only provide a relative path like this:
/CONFIGURATIONFILE=config.ini
? That sounds promising... I will try and report about it later on :-)
Thx
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 11:07
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
I have to admit I haven't tried it yet (although probably will be
doing exactly the same thing later today). Have you tried removing the
path from the /CONFIGURATIONFILE parameter?
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 14 August 2012 08:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to bundle a configuration file in burn?
Thank you for your hint, but could you give me an example, how to
express that in WiX?
I would write this as naïve attempt:
ExePackage Id=SQLServer SourceFile=X:\Software\Applikationen\SQL
Server\2008 R2\SQLEXPR32_x86_DEU.exe
InstallCommand='/QS /ACTION=Install /SAPWD=express
/IACCEPTSQLSERVERLICENSETERMS /CONFIGURATIONFILE=C:\some\path\config.ini
Payload Id=SQLServerConfigFile SourceFile=C:\some\path\config.ini
/
/ExePackage
But the /CONFIGURATIONFILE-Parameter links to a location in my local FS.
When the installer gets started it will not find the file in that
location...
-Ursprüngliche Nachricht-
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Dienstag, 14. August 2012 09:06
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] How to bundle a configuration file in burn?
You should be able to do this using the PayLoad element as a child of
your ExePackage element.
Neil
-Original Message-
From: Christian Hausknecht [mailto:chauskne...@beracom.de]
Sent: 13 August 2012 11:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to bundle a configuration file in burn?
Hello folks,
I would like to build a setup file for a MS SQL Server 2008 Express
Edition with a predefined configuration. One can pass a parameter
/ConfigurationFile={Absolute path to a ConfigFile.ini} to the setup
file of SQLServer in which many parameters are defined. Those config
files can easily be generated by the SQL Server UI-Setup Mode and
therefore I would like to use them also in my bundle. Now I face the
problem of how I can provide the required file and in addition which
path I must define within the parameter. Is there any chance to handle that
with burn?
If not I have to provide *all* needed configuration parameters by hand
to the setup-file; this would solve the problem, but I consider this
to be not very comfortable... (I would have to change this long
parameter-string every time something changed...)
I hope you can give me some good advice, in order to avoid long trial
and errors.
Best regards,
Mit freundlichen Grüßen
Christian Hausknecht
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG Weidestraße 134, 22083
[WiX-users] How to bundle a configuration file in burn?
Hello folks,
I would like to build a setup file for a MS SQL Server 2008 Express Edition
with a predefined configuration. One can pass a parameter
/ConfigurationFile={Absolute path to a ConfigFile.ini} to the setup file of
SQLServer in which many parameters are defined. Those config files can easily
be generated by the SQL Server UI-Setup Mode and therefore I would like to use
them also in my bundle. Now I face the problem of how I can provide the
required file and in addition which path I must define within the parameter. Is
there any chance to handle that with burn?
If not I have to provide *all* needed configuration parameters by hand to the
setup-file; this would solve the problem, but I consider this to be not very
comfortable... (I would have to change this long parameter-string every time
something changed...)
I hope you can give me some good advice, in order to avoid long trial and
errors.
Best regards,
Mit freundlichen Grüßen
Christian Hausknecht
BeraCom
Beratung und Software-Entwicklung GmbH Co. KG
Weidestraße 134, 22083 Hamburg
Tel.: +49 (0)40 547241 - 27
eMail: chauskne...@beracom.demailto:tneld...@beracom.de
=
Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932
Persönlich haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung
GmbH
Sitz Hamburg, RG Hamburg, HRB 64844
Geschäftsführer: Arno Schaefer, Britta Kahlfuss
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
