David White wrote
So the question is, how do I write my own bootstrapper UI when all I have
is v2? I have seen no windows forms apps. Can I write a simple Windows
forms app? Or do I have to go to C++ where I can link the runtime with it?
Yes, the managed layer only uses .NET 2.0 so you can
This post may help:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Resume-Installation-Plan-td7579146.html
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Resume-Installation-Plan-td7579146.html
Easiest thing to do is to create a custom object that keeps
I haven't read the book but I noticed the same thing awhile ago. Check out my
posting if interested:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Performance-Issues-with-File-table-sequencing-td4777168.html
Just don't set the ExePackage/@RepairCommand attribute. That should disable
repair for the exe.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-Way-to-do-no-action-in-case-of-Repair-for-an-ExePackage-tp7584034p7584035.html
Sent from the
Are you signing your bundle? If not, do so...typically AV is more forgiving
of signed files. Also, the burn engine is what writes those keys you
mention.
For reference, there are steps in the WiX CHM file that indicate how to sign
bundles.
--
View this message in context:
Take a look at the PlanPackageBegin function in InstallationViewModel.cs (the
WiX installer BA). You'll see that it sets the request state to none if it
is the netfx package.
If you aren't using your own BA then you could just copy the appropriate
code from the NetFx*.wxs file and remove the
I found this issue as well and already opened a bug for it:
http://sourceforge.net/p/wix/bugs/3160/
http://sourceforge.net/p/wix/bugs/3160/
--
View this message in context:
Add this to ensure that the custom action data is hidden as well:
Property Id=ExecXmlFile Hidden=yes/
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Prevent-logging-tp7582177p7582224.html
Sent from the wix-users mailing list archive at
I just created a stand-alone executable. As long are you already require .NET
then it makes sense to do it in C#. In my particular case I did it in vc++
(and statically linked the runtime) so I could use it for both native and
managed bundles.
--
View this message in context:
Just wanted to share this with anyone who might run into the same issue I
did...
If you are doing a fresh install of WiX 3.6 and you have Visual Studio 2005
installed then the setup will fail. It will also fail to create a layout.
You can get around the installation issue by copying
Those are the search element for use with burn in 3.6+. I have found that the
burn searches are capable of detecting if a key exists or not. However,
these won't be useful to you if you aren't using burn (they won't execute in
an MSI).
--
View this message in context:
UPDATE: OK, using the recommendation of creating a stub EXE I have got this
working. Here's what I did in case anyone else needs to handle this type of
installer.
1. Created a stub executable that manages the installation and removal of
the package. The stub exe does a few things:
a) Parses
I was wondering if anyone out there has had the unfortunate task of trying to
bootstrap an InstallAnywhere package?
I ask because apparently to uninstall these types of packages you need to
launch an uninstall.exe file that gets installed by the setup executable.
That being the case it appears
Yeah I have never even been exposed to this type of installer until very
recently. Should I file a bug for 3.7 to track this?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-InstallAnywhere-ExePackage-tp7580040p7580047.html
Sent from the
Good idea, I'm going to look into this approach and post back if I'm
successful...thanks for the idea!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-InstallAnywhere-ExePackage-tp7580040p7580050.html
Sent from the wix-users mailing list
Don't try to set feature states by directly setting the ADDLOCAL property
from the UI. Instead you should use the
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367537%28v=vs.85%29.aspx
AddLocal and
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371210%28v=vs.85%29.aspx
Well this isn't exactly pretty but I did find a way to do what you want. You
can create a CustomTable element for the ControlCondition table and then add
rows as you need them (WiX didn't seem to mind that this was a standard
table).
Here's the WiX authoring for the ControlCondition table:
I haven't used it myself but have you looked at John Robbins' Paraffin tool?
Here's a link to it (note the current version is 3.6 I believe):
http://www.wintellect.com/cs/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
Take a look at this (if you haven't already):
http://wix.sourceforge.net/manual-wix3/WixUI_customizations.htm
http://wix.sourceforge.net/manual-wix3/WixUI_customizations.htm
I usually end up just copying from the existing source and creating my own
dialogs and dialog sets. Since you can't
Rob Mensching-7 wrote
Save the values you need in a persisted Variable *before* calling Apply().
When you come back after reboot, the values will still be there.
Basically, in Burn we fixed the problem that MSI does not store Property
values by allowing Variables to be persisted. smile/
In my BA I have several packages and features. I decide which of these to
install by showing a UI that allows the user to select them individually.
If one of the packages requires an immediate reboot what is the recommended
way of persisting the plan for after reboot (I don't want to have the
Ravi Raj wrote
I am populating UserName property in UI textbox and then storing it in
registry. For this I am using custom action to set this variable at
UISqeuence and ExecuteSequence. Everything works great.
I found that if I change this value to something else, my registry is
never
Bob Uva-2 wrote
I'm using WixUI_FeatureTree with a few custom dialogs. I want to get a
string entered by the user on one dialog and use it in a call to a managed
custom action implemented in a C# DLL assembly. What is the best, and
hopefully easiest, way to do this?
The process will
raviraj87 wrote
I am using
session.Message(InstallMessage.Error | (InstallMessage)(icon) |
(InstallMessage)MessageBoxButtons.OK,
new Record { FormatString = message });
to display any messages during deferred CA and everything works great.
The message box
Kannan24 wrote
Hi,
1. I followed the update to set the msiproperty values in managed code,
but i cannot achieve to set the property value.
I have used the below code.
Bundle.wxs:
Variable Name=UI Value=False/
Chain
MsiPackage Id=SketchUpPlugin Name=Wixdata
raviraj87 wrote
I want to pass a file name in the argument of Custom Action. These files
are getting installed into the system. Can I pass the component id of
these
files rather than passing hard coded name?
You can use this expression [#/filekey/] to get the full path of a file.
Take a
Neil Sleightholm wrote
I have looked at InstallationViewModel.cs some more and I think I am
starting to understand it.
One question how do you detect that the bundle is already installed and
hence display uninstall/repair?
In the WiX BA it looks like they handle this in
Rob Mensching-7 wrote
Creating an installation engine in WiX is not something to consider until
WiX v4. smile/
Sorry my curiosity has gotten the better of me...is this actually being
seriously considered (I like the idea)?
--
View this message in context:
Neil Sleightholm wrote
It is possible to write managed bootstrapper in .Net 2.0? All the example
code I have found uses Threading.Dispatcher.CurrentDispatcher but that
isn't available in .Net 2.0 so I was wondering if there was an
alternative.
You see that because they are using WPF
Neil Sleightholm wrote
I have created a very basic managed bootstrapper and it is loaded
correctly by my bundle but it doesn't actually run the install it just
stays in memory but with nothing happening. I have looked at the WiX
install and just can't figure out what I need to do next, I
Created bug
https://sourceforge.net/tracker/?func=detailaid=3531882group_id=105970atid=642714
3531882 .
Thanks!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Related-MSI-Detection-Question-tp7578654p7578676.html
Sent from the wix-users
I have an MSI package that detects the VSTO runtime via an entry in the
Upgrade table (I just use it for a launch condition in the MSI.)
When burn detects the related MSIs for this package it finds the VSTO
runtime and indicates that the operation is a MajorUpgrade. This seems a
bit odd to me.
Yes, if you reference anything in a fragment it brings in the entire fragment
(not just the element you referenced).
It doesn't look like there is a RegistrySearchRef element (perhaps submit a
feature request). So, I would recommend putting the searches in an include
file so you can pull them in
No you need to know the name of the standard or custom action that you want
it to run after or before.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CustomAction-not-running-tp7263897p7269311.html
Sent from the wix-users mailing list archive at
If you are using a condition on your component then you set
Component/@Transitive to yes. That should force Windows Installer to
reevaluate the condition during reinstall.
--
View this message in context:
Windows Installer does this be design so you really shouldn't try working
around it. But, see this post for more information:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-allow-32-bit-installer-to-write-to-C-Program-Files-td5544693.html#a5550286
But what if the component is not installed at first installation? Would
Component/@Transitive=yes make it to install during reinstall?
Yes, as long as the component condition evaluates to true during reinstall.
Take a look at the WiX help file. It describes the attribute very well.
--
View this
Disclaimer: As you probably know, it is a bad practice to register files this
way during installation. The preferred way is to author the actual registry
values that get written during registration.
Ignoring the disclaimer, you shouldn't rely on using the value of the
ADDLOCAL property. Instead,
Well, for DLLs it is pretty easy because you can use heat.exe to generate the
authoring for you. However, it doesn't handle EXEs.
See this thread for more details:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-and-COM-executable-registry-extraction-td1308713.html
Are you running a 32 bit installer on a 64-bit machine? If so, then
%SystemRoot%\system32 is going to resolve to C:\Windows\SysWOW64. So,
make sure that C:\Windows\SysWOW64\Novell\Nici exists or the search will
fail.
--
View this message in context:
Try setting the RegistrySearch/@Type attribute to directory instead of
raw.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-setting-with-configurable-install-directory-problem-with-value-of-SystemRoot-tp7255442p7260751.html
Sent from the
Looks like you need to write your own BA:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-bootstrap-a-single-MSI-not-showing-BA-UI-at-all-td6926187.html
You can do it in native or managed code.
Take a look at the burn solution file in the source (src\burn\burn.sln). You
can see both the wixstdba (native) and WixBA (managed) projects for
examples. I haven't come across any tutorials or anything like that though.
--
View this message in context:
][2012-01-30T10:54:11]: Burn v3.6.2527.0, path:
C:\jhennessey\Installed Applications\WiX\3.6.2527.0\wix36.exe, cmdline:
'-burn.unelevated BurnPipe.{A0517E6A-F456-4BFE-AF46-55990426E173}
{545AA060-697B-411F-982D-36A592091F4B} 24900'
[6374:6378][2012-01-30T10:54:11]: Setting string variable
And here is the log from the uninstall of v3.6.2520.0
--
[0DD4:0DD8][2012-01-30T10:56:55]: Burn v3.6.2520.0, path:
C:\ProgramData\Package
Cache\{c18586f8-ce3c-4cb7-b003-162f6b341878}\WiX36.exe, cmdline: '-uninstall
-quiet -burn.related.upgrade
I created SF Bug 3481704 for the issue (log files attached to bug).
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-6-Upgrade-Leaves-Files-in-Cache-v3-6-2520-0-to-v3-6-2527-0-tp7237051p7237232.html
Sent from the wix-users mailing list archive
A bootstrapper needs to be an executable. MSIs cannot launch other MSIs.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bootstrapping-Issues-tp7225413p7228980.html
Sent from the wix-users mailing list archive at Nabble.com.
I posted a commented on your SF bug and figured I would post it here as well:
I couldn't view your attached image (I think it's corrupt) but I suspect
the problem might be the same issue I was seeing at one point with my own
experimental BA.
My issue was rooted in the fact that the engine
Although I wrote this bug up for a different reason (
https://sourceforge.net/tracker/?func=detailaid=2013944group_id=105970atid=642714
https://sourceforge.net/tracker/?func=detailaid=2013944group_id=105970atid=642714
), if you read the comments you'll see that I was getting a similar issue. I
My suggestion is that you store this information in some soft of database and
have the application (or a configuration application ) manage the settings.
I think you'll find it difficult to be able to try and save / merge all this
data as time goes on.
--
View this message in context:
Unfortunately MSI UI doesn't natively support an Open File Dialog. So, yeah,
you'll need a custom action to display one.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-there-a-UI-Control-to-pick-an-existing-file-tp7195026p7196469.html
Sent from
Define the properties that you want passed to your MSI using MsiProperty
elements under the corresponding MsiPackage element. You can set the
MsiProperty@Value attribute to the value of a Variable element. Your BA
can change / update the value of the Burn variable.
So here's a burn variable that
I can also verify that BootstrapperApplicationData.xml doesn't contain the
payload information...it's in the manifest file.
I think it would be advantageous to include all of the information from the
manifest in the BootstrapperApplicationData.xml file (or at least write the
manifest to the
Created SF Feature Request 3472491:
https://sourceforge.net/tracker/?func=detailaid=3472491group_id=105970atid=642717
https://sourceforge.net/tracker/?func=detailaid=3472491group_id=105970atid=642717
.
--
View this message in context:
You could change the registry value for the service that maps to the startup
type. In your case you said the service name was wzcsvc so you would
change this registry value (DWORD):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\wzcsvc\Start
to 2.
Here's a little bit of info on these
You should condition the CA based upon the installation state of the
component containing your EXE. Check
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012%28v=vs.85%29.aspx
MSDN for full details but let's say your component id is
componentA...then the condition on your CA would
That's strange...I just checked and the property is correct for my machine
(Windows 7 x64). How much RAM do you actually have installed and what is the
property saying?
--
View this message in context:
This post may help:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/problem-with-icon-for-Add-Remove-Programs-applet-td689139.html#a689141
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/problem-with-icon-for-Add-Remove-Programs-applet-td689139.html#a689141
--
View
The BootstrapperApplicationData.xml file gets extracted to the same directory
as your BA. So, you could just get the directory of the current executing
assembly (your BA assembly) and then load/parse the XML file.
I recommend searching the %temp% directory for
BootstrapperApplicationData.xml
I always grab the binaries (we check them in) but still use the MSI for
Votive. I have VS2005, VS2008, and VS2010 but only need votive for 2010. So,
I don't install anything but the VS2010 integration.
--
View this message in context:
It seemed to be right when I clicked install (caching?) so that makes sense.
It looks like the AV is more forgiving to signed exes so I might try signing
it with a test certificate to see what happens.
--
View this message in context:
Is there a way to extract the MSI then?
The problem with providing just the exe right now is that it doesn't support
installing only select features (like the MSI does).
I was thinking that /layout might work but the WiX BA doesn't support that
switch (not sure if that extracts embedded stuff
The last few builds of WiX 3.6 that I have tried installing have been blocked
by my antivirus (Kaspersky 3.6). It detects it as PDM.Trojan.generic.
I was just wondering if anyone else's AV has started giving them problems
with WiX36.exe lately?
--
View this message in context:
Check the feed: http://wix.sourceforge.net/releases/wix3.6.feed
http://wix.sourceforge.net/releases/wix3.6.feed . The bug you mentioned was
fixed in v3.6.1929.0.
--
View this message in context:
Glad to help. I was merely pointing out where you could look to find the
history of the changes so if you are still seeing a bug then go ahead and
file one for the devs.
--
View this message in context:
When you use a type 51 custom action it doesn't call MsiSetTargetPath because
you've told it you are setting a property and not a directory. Try using a
type 35 custom action (after CostFinalize) by using the Directory attribute
instead of Property.
--
View this message in context:
I have notice on Nabble that their are several posts which do not specify a
sub-forum (the options are wix-user or wix-devs) which corresponds to the
two different mailing lists.
I am not sure, but I believe that if you don't choose a sub-forum then your
post will only be seen by those who
Try running YouBurnInstaller.exe /layout (I remember seeing something about
this on the bug tracker. I think you can also specify the directory to
create the layout in).
--
View this message in context:
I am using a managed bootstrapper application and I am trying to figure out
how to detect if the bundle is already installed.
I am able to detect the packages by handling the *DetectPackageComplete*
event but I can't just assume that the bundle is installed by detecting one
of the packages in it
The bug is still open, see the submitter's comments:
http://sourceforge.net/tracker/?func=detailaid=3302804group_id=105970atid=642714
http://sourceforge.net/tracker/?func=detailaid=3302804group_id=105970atid=642714
--
View this message in context:
You can specify an XSL transform to apply after heat harvests the files.
Here's what my xslt file looks like:
?xml version=1.0 encoding=utf-8?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:msxsl=urn:schemas-microsoft-com:xslt
exclude-result-prefixes=msxsl
I'm using the heat task for MSBuild so I just specify the path to my xlst
file with the Transforms property. Here's an abbreviated example:
HeatDirectory Transforms=c:\myfile.xslt ... /
You can also specify it with the -t parameter on the commandline. Look at
the WiX chm file for more details.
If you want to avoid having to make a bogus upgrade element just use the
EnsureTable element for the Upgrade table. Then you would be able to add
your custom rows with no problems (since the empty table will be in the
MSI).
--
View this message in context:
Try using the Directory attribute instead of the Property attribute in
your custom actions.
--
View this message in context:
It looks like they have an older version of 3.5 installed than you do. I
believe it used to v3.5 but was later switched to use v3.x. If you both
install the same version it should solve your problem.
--
View this message in context:
All builds will say Windows Installer XML Toolset 3.5 but you need to check
the actual build version (I think the latest is 3.5.2430.0).
v3.x\Wix.targets is what is current
--
View this message in context:
I haven't worked with burn yet but from what I can tell it looks like you
would just set a burn variable to be passed to the MSI. So to install a set
a features you could just set the ADDLOCAL property as appropriate (in your
custom UI). You could also just split your large MSI into separate MSIs
All you need to do is check in the binaries as per WiX.chm. This was you can
have have as many versions of WiX as you want side-by-side.
The major problem though is that you can't have two different versions of
Votive (which I'll assume you're using) installed on your development
machines (this
I don't have the answer to this question but I have also tried to find ways
in the past to send feedback to the Windows Installer team.
Why is there no way to report bugs or suggest enhancements? I know that
there is a (rarely updated)Windows Installer blog but why nothing official
(think
Good catch, I didn't even notice he was creating a merge module.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5650417.html
Sent from the wix-users mailing list archive at Nabble.com.
Try using the WiX Util extension PermissionEx element instead (it doesn't
remove all the permissions like the standard Windows Installer action does).
It's documented in the WiX help file.
--
View this message in context:
Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it
will not be included in the MSI.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5638617.html
Sent from the wix-users mailing list archive at
1. MSI feature tree doesn't let you grey out the feature. However, you can
use a feature condition to totally remove it from the tree. If you do this
though you need to ensure that the feature is always enabled on remove or
else it will be orphaned. See Bob's post:
If you set the ARPINSTALLLOCATION property to the value of INSTALLLOCATION it
should work:
!--Set ARPINSTALLLOCATION--
CustomAction Id=SetProperty_InstallLocation Property=ARPINSTALLLOCATION
Value=[INSTALLLOCATION]/
InstallExecuteSequence
Custom Action=SetProperty_InstallLocation
Burn does not require the .NET Framework, you can code your UX in native code
if you want to. (The WiX 3.6 installer is using managed code for the UI so
it installs .NET for you before presenting the UX.)
--
View this message in context:
You should schedule it before LaunchConditions in both the InstallUISequence
(I'm assuming you are using standard MSI UI) and InstallExecuteSequence.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/sequencing-custom-actions-tp5573077p5584163.html
I think I figured out why I get the duplicate symbols when building now.
It seems that lit.exe includes all project references in the resulting
library(?) I don't think it should be this way though. I think that a
library's project references should just be passed to light.exe when
building
1. I have a library with some commonly used stuff call it
Library.Common.wixlib
2. I have a library which uses some parts of Library.Common.wixlib call it
Library.Product1.wixlib (so it references Library.Common.wixlib)
3. I have an additional library which uses some parts of
After days of researching why the current installer that I am porting from
InstallShield (it's a pure MSI not InstallScript) to WiX installs so much
slower I think I have found an answer. It looks like WiX sequences files in
the file table by their file id. In comparison it appears that
Were you using Components containing single files as generated by heat.exe?
Many of the components only contain a single file but others have multiple
files per component (mostly for ASP.NET projects that contain a lot of
files). Note that I only have to support major upgrades so having multiple
Set the property's value to {} using a set property custom action or
publish event.
--
View this message in context:
http://n2.nabble.com/Un-define-a-property-tp4597319p4597833.html
Sent from the wix-users mailing list archive at Nabble.com.
Awhile ago I started playing around with external ui and found that if the
MSI doesn't actually have an appsearch table then I got the same exact
error. Try opening an MSI that you know for a fact has a search and see if
that works. Also, if you end up developing a good external ui it would be
I just fired up my old project and it looks like it is working (of course I'm
not sure if this is the best way way of doing it). Here's a snippet of how I
did it:
Installer.SetInternalUI(InstallUIOptions.Silent);
session =
:
jhennessey wrote:
1. I remember reading that burn will allow you to provide a custom UI
.dll.
If this is still the case, can this be a .Net assembly?
Not unless somebody does the work to host the CLR. Burn has to be
native
code so we can
94 matches
Mail list logo
