Are there any best practices for managing a larger WiX project in
VS2008? I need to create four MSIs (32/64 bit versions of two releases,
differing only by configuration files.).
* 32-bit specific WiX project containing 32-bit libraries from
developers
* 64-bit specific WiX
Pally,
Yes, the file IDs are unique, reside in separate component groups, which
are included in separate features. I'm rethinking what I'm doing at this
point, as it's a similar problem to doing 32/64-bit installs. I'm
thinking that I ought to tackle that before this to get my arms around
the
I have two sets of files to install, call them A and A' they have the
same file name. I have them in different component groups and different
features. I only want to install either one feature or the other, never
both. The selection is controlled by a bootstrapper.
The compiler is complaining
On 8 Feb 10 8:36 PM, Rob Mensching wrote:
Sorry, I saw GNU LGPL as just GPL.
That's my kind of mistake. Don't you start stealing my trademarked
behaviour!
--
The Planet: dedicated and managed hosting, cloud storage,
On 6 Feb 10 8:34 PM, Rob Mensching wrote:
Sadly, not well at all. GPL and CPL are not compatible.sigh/
You're correct that the GPL and CPL are not compatible. The question
that was not addressed, however, is what of *L*GPL?
LGPL (the Lesser GPL) is not the same as the GPL. IANAL but I
I wonder if I can use WiX with Delphi ?
I use WiX to build an installer for a Delphi project.
There's no integration into the Delphi IDE AFAIK.
--
The Planet: dedicated and managed hosting, cloud storage,
Summary:
I'm struggling to figure out the WiX code and MSI parameters to alter
installed features from the command line.
Details:
I have a WiX-generated MSI with two features, let's call them FeatureA
and FeatureB. I install from a bootstrapper which passes a command-line
parameter indicating
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
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
I'm sorry my search skills are failing here; I'm sure this is a common
question.
Is there a way to conditionally set the InstallScope attribute based on
passing a property in on the command line?
--
Throughout its
My WiX project has a handful of prerequisites, for example, the
application requires .NET 3.5 SP1. My WiX project correctly does not run
unless SP1 is installed. I understand that this needs to be done in a
bootstrapper. However, after a couple of hours of reading on the
Internet and
John L Krupka wrote:
You should be able to set up preconditions on those things in the msi.
Setupbld is not the place for that to the best of my knowledge.
This is where my lack of understanding how MSIs work raises its head.
My MSI has a condition where it needs .NET 3.5 SP1, and
If I had two applications which shared some core assemblies, how would
these handled between two installers? If I shared a WiX fragment source
file between two WiX projects, the components would have the same GUIDs.
Would that cause a problem or conflict? Could the two projects be
installed,
I have two applications, A and B. They are actually 99% the same
assemblies, basically differing only in config files which dictate which
classes obtain control (a very pluggable architecture). Thus we normally
install all the assemblies, and pass the extra config file in the shortcut.
They
... trying to figure out what was wrong with the install when the real
problem ...
That's OK. We may just have different attitudes. You say that you're
jaded from the other department blaming your department, saying
something is wrong with the install.
I was never blaming WiX or my
Just a guess, but in seeing that the registry entry is in the Installer
area, I am wondering if in the IS install if these private assembly files
are marked as the KeyPath, which is why they are being recorded here?
I couldn't say. The WiX version has them marked as keypath also.I'll do
Christopher,
I appreciate your enthusiasm and advice.
.NET is supposed to be XCopy deployment
You are correct about this. If I take a clean machine (with .NET
installed) and then
1. Install the IS original,
2. Install my WiX-produced version,
3. Copy both directories to a new clean
... decompile the old one with dark.exe to see what's different.
Thanks for the suggestion, Bob. This allowed me to pinpoint where in my
WiX code the problem lie.
--
Let Crystal Reports handle the reporting -
I'm porting a .NET product from and older InstallShield to WiX. My
ignorance of details of MSI and .NET's interactions with the registry
are showing through here.
I used heat to do the heavy lifting, and all files are in the correct
place after install.
However, I can't get the WiX-installed
19 matches
Mail list logo