Hi
How can I change the path of the WIX-Tools for Msbuild/Votive?
I have old installer projects (build with Wix 3.0) an I want to build
them, but if I try to build them msbuild use the new wix version.
regards
Robert
Hello,
I've got following problem...
I have got a main application and an add-on tool. The add-on can be
installed only if .net framework 3.5 is installed and main application
must be able to install the add-on when user updates his system to .net 3.5.
My current solution consists of two
Put both into the same MSI, but under different features.
From your main application, add the add-on feature when .net 3.5 is
discovered. MsiConfigureFeature() would possibly be a good candidate.
-Original Message-
From: Jan Bilek [mailto:bil...@gmail.com]
Sent: Wednesday, January 20,
Votive (and the related WiX support for MSBuild) use the $(WIX) property
(which is normally set from the %WIX% environment variable).
-Original Message-
From: INRO(Robert Inzinger) [mailto:robert.inzin...@skidata.com]
Sent: Wednesday, January 20, 2010 5:06 AM
To:
Sorry, I was incorrect.
Wix.targets uses the $(WixTasksPath) property, which defaults to a path that
looks like
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\WixTasks.dll
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Wednesday, January 20, 2010 10:16 AM
To: 'General
Good idea, but what if user decides to install the add-on later (after
he updates his OS)? Wouldn't he have to reinstall main application? This
solution is my last resort. It will work, but it seems to be too
complicated (for me and users aswell).
Isn't there any other easier way?
Thanks.
Jan
Summary:
I wrote a few lines of code to detect if the application being put into
the MSI has any new assemblies which haven't been added to the WiX code.
This seems to work fine.
I'm trying to figure out how to get the WiX build to fail if my
detection algorithm indicates that the WiX code
As it exists now, the few lines of code exist as a console application.
I'm looking for suggestions on how to integrate this into the build, so
perhaps it's more of a Visual Studio question than a WiX question.
Any suggestions?
sounds like you should read up on creating custom tasks for
My experiments shows that the MUI shortcut only work with two conditions
met:
1) The resource must be *native*;
2) The exe that the shortcut points to must coexist with the resources
in *one* binary. “An exe + a satellite resource dll” does not work.
Please let me know if anyone has
I think the idea here is that the add-on is literally a feature choice that's
already part of the main application, part of the MSI setup, so you don't
re-install anything. You go into Add/Remove Programs, choose Modify, and select
the add-on feature to install it.
Phil Wilson
So I suppose this is a problem for all MSIs? Can anyone confirm it?
Personally I don't think this is a big problem. But any small issue is a P1
issue in our team. :-) So I own them an explanation.
Thanks.
From: little.forest little.for...@ymail.com
To:
Hello,
I have an application that is wrapped in an MSI. It contains 1 service and 1
exectuable that is 'in use' during an upgrade.
On Windows XP, I do not get any notice/popup that the service and executable
is in use with any dialog to ask me if i want to ignore or shut it down.
On Windows 7,
The differences are because Windows 7 has an MSI engine that has better
detection of files that are in use (using the Restart Manager). All other
things being equal, you'd expect the XP install to ask for a reboot at the end
(because it can't detect all in-use situations) and the Windows 7
I'd be very surprised if anyone could answer that question, certainly
not reliably and completely. As the message clearly says, it's
unsupported; and as the message helpfully explains, that means it's not
guaranteed to work. That means anything can happen. Developers of
everything which ever
I thought this was a Windows 7 thing, part of the snap feature?
Phil Wilson
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Wednesday, January 20, 2010 2:42 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install on Windows 7: minimize
So I guess my question is how do I ignore those dialogs to not show up
during an install?
From what I read, ignoring the MSIRESTARTMANAGERCONTROL during a Full UI
install has no effect.
The other method I tried was removing the dialogs completely, which
resulted in error 2803...however
My reference to the API MsiConfigureFeature() was intended to have it called
by the main application whenever it detects that the add-on isn't installed
but the framework is. End users don't have to do a thing (except run the
main application).
-Original Message-
From: Jan Bilek
Simplest is the Exec task, assuming that your console application returns
0 for success and non-zero for break-my-build.
-Original Message-
From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com]
Sent: Wednesday, January 20, 2010 1:00 PM
To: General discussion for Windows Installer XML
That's the way MUI works.
http://msdn.microsoft.com/library/dd319073.aspx
-Original Message-
From: Lian Jiang [mailto:jiangok2...@gmail.com]
Sent: Wednesday, January 20, 2010 1:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] how to create a
Simon, Blair: Thanks for your input.
This may not be the best solution, but I wrote up notes on my hack to
get MSBuild to list the missing files.
Rudamentary WiX Orphan Prevention
http://jamesreubenknowles.com/rudamentary-wix-orphan-prevention-812
20 matches
Mail list logo
