[WiX-users] WiX's license implications when bootstrapping
Hi, This has probably been asked before (although I couldn't find it): what are WiX's license implications when it comes to distributing bundles based on BootstrapperApplication? I understand the MS-RL does not apply to our own code, but the license clarification on the WiX page doesn't seem to address the fact that the bundle itself contains code from the WiX library (specifically the BootstrapperCore assembly): OuterCurve Foundation does not view the installer packages generated by WiX > as falling within the definition of a derivative work, merely because they > are produced using WiX. Thus, the installer packages generated by WiX will > normally fall outside the scope of the MS-RL, and any of your source code, > binaries, libraries, routines or other software components that are > incorporated in installer packages generated by WiX can be governed by > other licensing terms. The emphasis is on "merely because they are produced using WiX". BoostrapperCore bundles aren't just produced by WiX, they actually need to use WiX code in order for the bootstrapping to work (as I understand it). MS-RL states that For any file you distribute that contains code from the software (in source > code or binary format), you must provide recipients the source code to that > file along with a copy of this license, which license will govern that file. So I'm confused: do we have to provide the WiX source code if we distribute such bundles or not? Thank you, Igor Brejc -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Multiple Apply phases
Hi Lukas, Can you show us your install log file? On Wed, Nov 7, 2012 at 11:43 AM, Lukáš Tínes | ALVAO wrote: > Hi, > > I am fairly new to the Burn engine. I am writing managed BAand I stumble > upon this weird thing: > After ApplyComplete event (which according to documentation should be > fired when the engine has completed installing the bundle) sometimes i get > a few more apply phases (ApplyBegin - ApplyComplete). > > Is this expected behavior? If so, how can know when the packages > installation finished? > > Thanks, > > Lukas > > > > -- > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] custom actions in burn?
Hi,
I have the same thing (two MSIs, one 32 and the other 64 bit). I'm using
the managed bootstrapper with override of OnPlanPackageBegin() method to
control which one gets installed, without the need for custom actions:
protected override void
OnPlanPackageBegin(PlanPackageBeginEventArgs args)
{
base.OnPlanPackageBegin(args);
if (args.PackageId == "MPWI_Agent_x86")
{
if (Bitness.Is64BitOperatingSystem)
args.State = RequestState.Absent;
}
else if (args.PackageId == "MPWI_Agent_x64")
{
if (!Bitness.Is64BitOperatingSystem)
args.State = RequestState.Absent;
}
}
On Wed, Oct 31, 2012 at 5:21 PM, StevenOgilvie wrote:
> Hi all,
>
> I have a product that installs a 32 bit version and 64 bit version
> installer
> (two .msi)
> I have a custom action in product.wxs that determines the "bitness" of
> Microsoft Outlook (whether the user installed 32 bit or 64 bit version of
> Outlook, our product is an add-in).
>
> so I have 2 msi's, but only 1 should kick off from burn, can you write
> custom actions in Bundle.wxs?
>
> if so what would I set the condition sequence to? i.e.
>
> NOT
> Installed
>
>
> NOT
> Installed
>
>
> thanks,
>
> Steve
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/custom-actions-in-burn-tp7581691.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bundles, product codes and upgrades
Hi, Using the managed bootstrapper, I've noticed that when the DetectRelatedBundle event gets fired, the event argument Operation is set to MajorUpgrade, even though I only changed the version of the bundle (and the containing MSI package is running MinorUpgrade). I suspect this is happening because bundle's ProductCode is autogenerated by WiX and changes in every build. Is this true? Is there a way to provide my own ProductCode? Thanks, Igor -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Christian, If it was up to me, I would gladly open-source it, I think I too would benefit from other people's ideas, since I'm not really an expert in the Win Installer field. This bootstrapper thing is just a side project I'm working on. Anyway, if you or anyone else on this list have any questions about implementing custom .net bootstrappers, I'm ready to help if I can. Best regards, Igor On Tue, Oct 23, 2012 at 10:34 AM, Christian Hausknecht < chauskne...@beracom.de> wrote: > 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 > >wrote: > > > > > Thanks Daniel, this is precisely what I needed! > > > > > > On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce > > > > > >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 > > t
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 >wrote:
>
> > Thanks Daniel, this is precisely what I needed!
> >
> > On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce
> > > >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.Windo
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 wrote:
> Thanks Daniel, this is precisely what I needed!
>
> On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce >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.BootstrapperApplication
> 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.Bootstrap
Re: [WiX-users] WixManagedBootstrapperApplicationHost and .NET 2.0
Ok, I think I'm on to something. The ".NET missing dialog" no longer shows I have the following .config fragment commented out: Once I put the supportedFramework tags back into XML code, the dialog again starts to show up. Any explanations? p.s. one other thing: what is the appropriate supportedFramework for .NET 2.0? "v2.0" or just "v2"? On Tue, Oct 16, 2012 at 10:14 AM, Igor Brejc wrote: > On Mon, Oct 15, 2012 at 7:15 PM, Rob Mensching wrote: > >> What does your BootstrapperCore.config file look like? Does it correctly >> indicate the v2 NETFX should be used? >> On Mon, Oct 15, 2012 at 2:18 AM, Igor Brejc wrote: >> >> > Hi Rob, > > I've tried many combinations. Here's a typical one: > > > > > type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, > BootstrapperCore"> > > type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, > BootstrapperCore" /> > > > > > > > > > > > > > > > > > Here's the Netfx package fragment from Bundle.wxs: > > > > > > Cache="no" > Compressed="no" > PerMachine="yes" > Permanent="yes" > Vital="no" > SourceFile="C:\Users\brejc\Downloads\NetFx20SP2_x86.exe" > DownloadUrl=" > http://download.microsoft.com/download/c/6/e/c6e88215-0178-4c6c-b5f3-158ff77b1f38/NetFx20SP2_x86.exe > " > DetectCondition="NETFRAMEWORK20" > InstallCondition="FALSE"/> > > > > What's really odd is that I've now actually managed to make it work on > .NET 2.0-only machine (the ".NET missing" dialog is no longer shown). But > the problem is that I don't really know what caused it work, and > consequently I cannot know how to deal with this in the future. Now even if > I try to force it back to showing ".NET missing" dialog, I cannot do it. > > One other thing: I'm looking at the burn log from that machine and it > reports NETFRAMEWORK20 condition to be False: > > [0DDC:04C8][2012-10-16T09:38:20]: Setting string variable 'Netfx2' to > value '2.2.30729' > [0DDC:04C8][2012-10-16T09:38:20]: Condition 'NETFRAMEWORK20' evaluates to > false. > [0DDC:04C8][2012-10-16T09:38:20]: Detected partially cached package: > mpwi_x86.msi, invalid payload: mpwi_x86.msi, reason: 0x80070570 > [0DDC:04C8][2012-10-16T09:38:20]: Detected package: Netfx2Exe, state: > Absent, cached: None > > .NET 2.0 is definitively installed on the machine (SP 2). > I'm sure I'm doing something wrong, but I cannot really tell what. > > Thanks, > Igor > -- 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] WixManagedBootstrapperApplicationHost and .NET 2.0
On Mon, Oct 15, 2012 at 7:15 PM, Rob Mensching wrote: > What does your BootstrapperCore.config file look like? Does it correctly > indicate the v2 NETFX should be used? > On Mon, Oct 15, 2012 at 2:18 AM, Igor Brejc wrote: > > Hi Rob, I've tried many combinations. Here's a typical one: Here's the Netfx package fragment from Bundle.wxs: http://download.microsoft.com/download/c/6/e/c6e88215-0178-4c6c-b5f3-158ff77b1f38/NetFx20SP2_x86.exe " DetectCondition="NETFRAMEWORK20" InstallCondition="FALSE"/> What's really odd is that I've now actually managed to make it work on .NET 2.0-only machine (the ".NET missing" dialog is no longer shown). But the problem is that I don't really know what caused it work, and consequently I cannot know how to deal with this in the future. Now even if I try to force it back to showing ".NET missing" dialog, I cannot do it. One other thing: I'm looking at the burn log from that machine and it reports NETFRAMEWORK20 condition to be False: [0DDC:04C8][2012-10-16T09:38:20]: Setting string variable 'Netfx2' to value '2.2.30729' [0DDC:04C8][2012-10-16T09:38:20]: Condition 'NETFRAMEWORK20' evaluates to false. [0DDC:04C8][2012-10-16T09:38:20]: Detected partially cached package: mpwi_x86.msi, invalid payload: mpwi_x86.msi, reason: 0x80070570 [0DDC:04C8][2012-10-16T09:38:20]: Detected package: Netfx2Exe, state: Absent, cached: None .NET 2.0 is definitively installed on the machine (SP 2). I'm sure I'm doing something wrong, but I cannot really tell what. Thanks, Igor -- 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
