Re: [WiX-users] Getting started writing a custom Bootstrapper interface
-Original Message- From: Igor Brejc [mailto:igor.br...@gmail.com] Sent: 20. oktober 2012 20:04 To: General discussion for Windows Installer XML toolset. Subject: 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). I absolutely agree with this point. It would be very helpful to have interfaces defined for BootstrapperApplication containing the events it exposes, as well as for the Engine class. It's nigh impossible to do unit tests on the interface classes without this step. I've created my own, but that feels kind of hacky. I would file a feature request, but the sourceforge website seems to be throwing Error 500s right now. 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). Pretty much what I had to do too. I really hope the documentation situation is going to improve before the 3.7 release, because right now it's kind of ridiculous. I feel like I just have wishful thinking and half-truths to go on and many times during the development process things broke because my assumptions (based on what I could glean from source code and random postings) were not correct. I'm kind of worrying about what's going to break next due to something that is not obvious from the source code. Best regards, Igor Brejc Regards, Daniel E. Bruce -- 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
Sourceforge cooperated with me now, so I filed a feature request: https://sourceforge.net/p/wix/feature-requests/709/ Daniel E. Bruce -Original Message- From: Daniel Bruce [mailto:daniel.br...@prediktor.no] Sent: 22. oktober 2012 13:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting started writing a custom Bootstrapper interface -Original Message- From: Igor Brejc [mailto:igor.br...@gmail.com] Sent: 20. oktober 2012 20:04 To: General discussion for Windows Installer XML toolset. Subject: 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). I absolutely agree with this point. It would be very helpful to have interfaces defined for BootstrapperApplication containing the events it exposes, as well as for the Engine class. It's nigh impossible to do unit tests on the interface classes without this step. I've created my own, but that feels kind of hacky. I would file a feature request, but the sourceforge website seems to be throwing Error 500s right now. 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). Pretty much what I had to do too. I really hope the documentation situation is going to improve before the 3.7 release, because right now it's kind of ridiculous. I feel like I just have wishful thinking and half-truths to go on and many times during the development process things broke because my assumptions (based on what I could glean from source code and random postings) were not correct. I'm kind of worrying about what's going to break next due to something that is not obvious from the source code. Best regards, Igor Brejc Regards, Daniel E. Bruce -- 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
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.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
type=Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup,
BootstrapperCore
section name=host
type=Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection,
BootstrapperCore /
/sectionGroup
/configSections
startup useLegacyV2RuntimeActivationPolicy=true
supportedRuntime version=v4.0 /
/startup
wix.bootstrapper
host assemblyName=YourAssemblyName
supportedFramework version=v4\Full /
supportedFramework version=v4\Client /
/host
/wix.bootstrapper
/configuration
Then, finally, in your bundle.wxs file add a reference to your assembly and put
in this snippet to refer to your bootstrapper application properly, again
replacing as necessary:
BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'
Payload Name='BootstrapperCore.config'
SourceFile='$(var.YourAssemblyName.TargetDir)\YourAssemblyName.BootstrapperCore.config'
/
Payload SourceFile='$(var.YourAssemblyName.TargetPath)' /
/BootstrapperApplicationRef
Now if you want to be able to run this with F5 from Visual Studio, you should
build your bundle once first, then set your WPF assembly as the startup
project, go into its project properties under Debug, set it to Start external
program and point it to the exe file from your bundle. This is necessary
because you can't set wixprojects as startup projects. If you want to debug the
bootstrapper application and set breakpoints and whatnot, you need to attach to
the process manually (ctrl+alt+p in my VS2010) after pressing F5, because of
how Burn works. To facilitate this, I created a function like this that I call
at the very beginning of my BootstrapperApplication.Run method:
[Conditional(DEBUG)]
private void ShowDebugMessageBox()
{
MessageBox.Show(If you want to debug the Bootstrapper Application, you
should attach the debugger to the .NET process now and click the button.);
}
Sorry if any of this got horribly mangled in transport, but hopefully you can
pick out what to do and this gives you something to work from.
Regards,
Daniel E. Bruce
-Original Message-
From: Hans ter Horst
Re: [WiX-users] Elevation of Bootstrapper Application
Thank you for your answers, Neil and Rob. I have dabbled with persist=yes before, and it didn't seem like it worked for me, but I may just have not been doing it correctly. Am I right in assuming that doing a definition like this would cause the variable to persist and when uninstalling it will retain the value it had at the end of the initial installation, with no extra work involved? Variable Name= Server Persisted=yes/ I would prefer to not do it this way, as doing so would require pushing the responsibility for defining the persisted data into the bundle.wxs, which splits my data in a way I would like to avoid. We use the same MBA with multiple bundle.wxs files (with various subsets of our product suite), so it would make the installers less DRY if we had to define the variables each bundle.wxs needed. However, if it were possible to mark variables for persisting from the MBA, that would be perfectly fine for our solution, as we are right now just persisting certain Burn variables written to during the installation process. Regarding elevation, looking into the problem more seems to indicate that my options are to either put a manifest on our bundle executable, or launch a child process with elevated privileges and communicate data I need handled in an elevated context to that child process (from what I can tell, this is what burn does). Is this correct, or have I missed any simpler ways of elevating? Daniel E. Bruce -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 15. oktober 2012 19:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application It remembers them for a specific Bundle. There is not currently a mechanism to get to the state of another Bundle (I think there is a feature request open to enable that). On Mon, Oct 15, 2012 at 10:10 AM, Neil Sleightholm n...@x2systems.comwrote: you can set Variables and mark them Persist='yes' and Burn will remember them for you. Am I correct that it remembers them for Uninstall/Repair but there is no way to recall them if you do an upgrade? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 15 October 2012 17:50 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. -- 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 -- virtually, Rob Mensching http://RobMensching.com LLC -- 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 ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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
[WiX-users] Elevation of Bootstrapper Application
Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -- 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] Elevation of Bootstrapper Application
The values are set by our custom Managed Bootstrapper Application via the standard .NET Registry API, and not by any of the included packages. Since the information to be stored is on the bundle-level (which packages are selected for installation), it can't be moved into an MSI. I have attempted using IBurnEngine-Elevate(), but as far as I can see (and as I expect from it being a method of the engine), that does not give the managed bootstrapper application process elevated privileges. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 15. oktober 2012 14:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway --- --- 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 ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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
[WiX-users] WIC as a prereq before .NET 4.0 in Burn with custom BA
Hello, We are attempting to roll out a managed bootstrapper that depends on .NET 4.0. On some platforms this requires WIC (Windows Imaging Component) to be installed prior to running the .NET 4.0 installer, which is giving us some issues. We have tried to solve this issue in a few ways, but none have worked, so I posted to stack overflow about it. Nobody has responded so far, so I'm crossposting here to see if anybody has any input. If so, it would be nice if you could take a look at the SO question, which has all the details, and perhaps shoot me an answer either there or here. http://stackoverflow.com/questions/12727583/adding-wic-as-a-requirement-before-net-4-0-in-wix-burn-custom-managed-bootstrap Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -- 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] WIC as a prereq before .NET 4.0 in Burn with custom BA
Thank you for the answer, however I can't see how you specify that this is to be run by the prerequisite installer that usually installs .NET before launching the managed BA. Is this then not necessary, or was I unclear on our problem? Our problem is not in specifying the packages (though thank you for that), but getting them to run prior to the .NET 4.0 package in the native installer that is launched if .NET 4.0 is not present on the machine. We think this would require setting the variable WixMbaPrereqPackageId to some package that does this for us, but it's unclear what this value would be or if this is actually the solution we need. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 8. oktober 2012 10:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WIC as a prereq before .NET 4.0 in Burn with custom BA This is my WIC install: util:FileSearch Path=[SystemFolder]\windowscodecs.dll Variable=windowscodecs Result=exists / !-- This is only required on Windows 2003 and Windows 2003 R2 -- PackageGroup Id=WIC ExePackage Id=WIC_x86 Compressed=yes Permanent=yes Name=Redist\wic_x86_enu.exe SourceFile=..\Packages\wic_x86_enu.exe InstallCommand=/quiet /norestart DetectCondition=windowscodecs InstallCondition=VersionNT=v5.2 AND NOT VersionNT64 Vital=yes ExitCode Value =3010 Behavior=forceReboot / /ExePackage ExePackage Id=WIC_x64 Compressed=yes Permanent=yes Name=Redist\wic_x64_enu.exe SourceFile=..\Packages\wic_x64_enu.exe InstallCommand=/quiet /norestart DetectCondition=windowscodecs InstallCondition=VersionNT=v5.2 AND VersionNT64 Vital=yes ExitCode Value =3010 Behavior=forceReboot / /ExePackage /PackageGroup I have manually downloaded the file and embed them in my bundle. Neil Hello, We are attempting to roll out a managed bootstrapper that depends on .NET 4.0. On some platforms this requires WIC (Windows Imaging Component) to be installed prior to running the .NET 4.0 installer, which is giving us some issues. We have tried to solve this issue in a few ways, but none have worked, so I posted to stack overflow about it. Nobody has responded so far, so I'm crossposting here to see if anybody has any input. If so, it would be nice if you could take a look at the SO question, which has all the details, and perhaps shoot me an answer either there or here. http://stackoverflow.com/questions/12727583/adding-wic-as-a- requirement -be fore-net-4-0-in-wix-burn-custom-managed-bootstrap Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway --- --- 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 ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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
Re: [WiX-users] How to create a feature tree with burn?
I'm trying to accomplish something similar with my own Bootstrapper Application, and would like to find this XML file. What is the suggested way of locating this file? I'm unsure how to locate my BA DLL at runtime without resorting to magic strings. In addition, is there any documentation at all about this file, and its format? Is it a supported way of accessing bundle information, or is it just a magic file? I can't seem to locate anything about it apart from scattered mailing list posts. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 20. august 2012 23:37 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to create a feature tree with burn? BootstrapperApplicationData.xml is provided with your BA. It's right next to the DLL at runtime. You won't see it until the BA is running. On Mon, Aug 20, 2012 at 10:34 AM, CristianI i.crist...@gmx.net wrote: It's good to hear, that these things are possible =) But where do I find the BootstrapperApplicationData.xml? I read that it should be extracted to the temporary folder, but it's not working for me. Do I have to do something special, am I missing something or is it enough compile it the usually way with candle and light? Thanks again very much for the help; I'm trying to get as much info about OnPlanPackageBegin() as I can find in the next hours =) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How- to-c reate-a-feature-tree-with-burn-tp7579948p7579957.html Sent from the wix-users mailing list archive at Nabble.com. -- 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 -- virtually, Rob Mensching http://RobMensching.com LLC -- 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 ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ___ ___ -- 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
