The Merge Modules are supposed to carry the actions they require. If the
Merge Module is not authored correctly, you can ensure the actions get in
the final MSI by doing something like:
Or whatever actions you need. Notice there are no attributes on those
actions. That ensures they get
PS: There is this bug (more of a feature request) open that would allow you
to manually provide all the necessary information that the Binder
(light.exe) gets by building:
http://sourceforge.net/tracker/?func=detail&aid=3166824&group_id=105970&atid=642714
There is a lot of data gathered so it isn'
Wow, no faith from the peanut gallery.
If the file is signed (something else we calculate during build when
referencing the file) we will use the signature of the file not the hash. If
the signature on the file changed in between the point that you built and
the user downloaded the actual file, ch
The managed BA host (MBA) definitely supports .NET 3.5.
Remember, you don't use the MBA unless you are writing your BA in managed
code. I wrote the WiX toolset's BA in managed code to demonstrate how it can
be done and I like .NET Framework 4.0 so I chose to write the BA using it.
If you would rat
On 06-Jul-11 13:10, Shal Philipp wrote:
> May be there is some recomendations from Microsoft not to change file
> composition of feature that is shared? Will be glad to see some. It will be
> good argument in an argue.
Yes, in the MSI SDK. Various blogs also cover it, such as
http://robmensching.
On 06-Jul-11 13:26, Roy Chastain wrote:
> Are you trying to tell me that the Burn bootstrapper REQUIRES .NET 4.0
> to run?
No, it doesn't require any version of .NET. Obviously, if you want to
use a managed BA, .NET is required and as I said above:
> note that the current managed BA has
> only
> They're used by the Burn managed bootstrapper app to manage installing
> .NET. They're still needed but note that the current managed BA has
only
> supported (tested/validated) .NET 4, not 3.5. At the moment, you're in
> uncharted waters.
Are you trying to tell me that the Burn bootstrapper R
> Light uses the source file to get information about the file to put
into
> the manifest (e.g., file size, hash); if specified, it also uses it to
> embed, but that's optional.
So you are telling me that I must have a local copy of any of the
Microsoft install packages that I wish to have downl
Yes. It is all ok with components - share IDs, references, etc. But feature
can be changed. It is unreal to force developers stick to the unite
composition of files. They change it time to time and it is inevitability.
May be there is some recomendations from Microsoft not to change file
compositio
On 01-Jul-11 15:27, jjbean wrote:
> In many cases, I've found that even when using the win32 api directly, it's
> not possible to rollback uninstalled drivers, the exact behavior is very
> platform dependent. In many cases, the api returns "reboot required", at
> which point there is no chance of r
On 06-Jul-11 08:41, Roy Chastain wrote:
> I ASSUMED that SourceFile meant that it would find the file
> on the local system and "embed" in the output. Given that there is a
> DownloadUrl specified, that behavior does not make too much sense.
Light uses the source file to get information about the
On 06-Jul-11 08:50, Roy Chastain wrote:
> What are the purposes of these two variables and is this something that
> needs to be emulated when authoring an install with a prereq of .NET 3.5
> SP1?
They're used by the Burn managed bootstrapper app to manage installing
.NET. They're still needed but
On 01-Jul-11 16:36, Sidky Macatangay wrote:
> Any idea on how
> this can be resolved?
You need both Publish elements: one to launch and one to close the dialog.
--
sig://boB
http://joyofsetup.com/
--
All of the data ge
On 06-Jul-11 09:06, Shal Philipp wrote:
> We have such a problem: We have several products with general part
> (feature). Components (files) in this feature maybe different in newer
> versions. Some products can be installed together.
If you're sharing components, they must all follow the componen
Dear All,
We have two features (Client and Server) in an WiX installer and both of them
include a merge module, called CFI. Some of the CFI files are self-registering.
During the install runtime, if we select both features to install, then these
CFI files register properly. However, if we selec
Hi all!
We have such a problem: We have several products with general part
(feature). Components (files) in this feature maybe different in newer
versions. Some products can be installed together. If we install product "A"
with version of general feature 1 (files "a","b","c") and then install
prod
The fragment to install .NET Framework 4.0 used in the WiX install has
the following
What are the purposes of these two variables and is this something that
needs to be emulated when authoring an install with a prereq of .NET 3.5
SP1?
---
I am trying to author a bundle that has .NET 3.5 SP1 as a requirement.
I found the fragment used in the WiX install for .NET 4.0 and changed
the (appropriate) pieces. I removed the SourceFile and added a Name
attribute. I ASSUMED that SourceFile meant that it would find the file
on the local sys
18 matches
Mail list logo
