Sigh 4 warnings x 6 merge modules :(
Okay thanks all :)
Steve
-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
Sent: September-24-13 10:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module question...
On
On Tuesday, September 24, 2013, StevenOgilvie wrote:
> I have added it back to 1 WIXLIB
>
> when I compile it works but I get this error twice for each merge module:
> Warning 22 ICE30: The target file 'kd1er3dy.dll|SQLite.Interop.dll'
> might be
> installed in '[TARGETDIR]\EnterpriseAuditLog
have an example?
Thanks,
Steve
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: September-24-13 5:22 PM
To: General discussion for Windows Installer XML toolset.;
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module question...
It's a
sday, September 24, 2013 1:26 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module question...
I have added it back to 1 WIXLIB
when I compile it works but I get this error twice for each merge module:
Warning 22 ICE30: The target file 'kd1er3dy.dll|SQLite.In
I have added it back to 1 WIXLIB
when I compile it works but I get this error twice for each merge module:
Warning 22 ICE30: The target file 'kd1er3dy.dll|SQLite.Interop.dll' might
be
installed in '[TARGETDIR]\EnterpriseAuditLogService\' by two different
conditionalized components on an LFN
he file table. All the binaries will (every time I've looked)
> have the same version.
>
> > From: laasu...@hotmail.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 20 Aug 2013 09:07:53 +0200
> > Subject: Re: [WiX-users] Merge module not working
> >
Orca. Check the file table. All the binaries will (every time I've looked) have
the same version.
> From: laasu...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 20 Aug 2013 09:07:53 +0200
> Subject: Re: [WiX-users] Merge module not working
>
> I am happ
os...@live.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 19 Aug 2013 23:37:57 -0700
> Subject: Re: [WiX-users] Merge module not working
>
> There is a fair bit of debate about the propriety of including the policy
> MSMs. Some argue that they should be included (MS d
ourceforge.net
> Date: Tue, 20 Aug 2013 08:16:47 +0200
> Subject: Re: [WiX-users] Merge module not working
>
> Thank you for your reply.
>
> Adding the policy merge module solved the issue.
>
> I would consider updating the
> http://wix.sourceforge.net/manual-wix3/
r describe the purpose of the policy msm very briefly.
Lars
> Date: Mon, 19 Aug 2013 14:46:11 -0700
> From: phildgwil...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Merge module not working
>
> A couple of other things to look at, assuming you&#x
A couple of other things to look at, assuming you've looked at Blair's
comment:
One issue with these SxS Dlls is that the policy merge module makes a
difference. IIRC, the VC redist exe will install the Dlls and the policy
file that redirects requests to the appropriate Dll. So I'd add the policy
Did the merge module come from the same service pack level of Visual Studio as
was used to build the application?
> From: laasu...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 19 Aug 2013 11:34:36 +0200
> Subject: [WiX-users] Merge module not working
>
> Using Wix 3.7
>
> I
On 23-Jul-12 11:57, Rune Moberg wrote:
> I have a mergemodule from Sybase (SQL Anywhere 12 ADO.Net provider)
> where the following line exists in the EventMapping table:
> Dialog_ = ProgressDlg
> Control_ = ActionData
> Event = ActionData
> Attribute = Text
That's horrible on several levels.
> In
I think you want a "retargetable" Merge Module. I think that keyword will
help in the documentation.
On Wed, Jul 13, 2011 at 5:07 AM, Leigh Wetmore wrote:
> Hi Rob,
>
> Thanks - I ran Orca (a great tool!) on my MSI, and I found out that the
> merge module files are actually installing to a subfo
Hi Rob,
Thanks - I ran Orca (a great tool!) on my MSI, and I found out that the
merge module files are actually installing to a subfolder within the
structure created by the MSI. The MSI files are going to:
TARGETDIR/ProgramFiles/INSTALLLOCATION
whereas the merge module files are going to:
TAR
The Fragment seems like it should have worked. Fastest thing might be to
open the Merge Module using Orca and see if your Component definition is in
there. If not, then I'm a little surprised since that ComponentGroupRef
should do it. if it is in the Merge Module then you'll want to check your
Mer
e registry entries
including in the merge module build.
Phil Wilson
-Original Message-
From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com]
Sent: Friday, July 08, 2011 8:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge module files n
ching [mailto:r...@robmensching.com]
Sent: Thursday, July 07, 2011 3:19 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge module files not getting registered
Are the Components that contain the registration being installed? A verbose
log file will tell all.
ion data for those merge module files is present in
> the MSI. Any more idea?
>
> Thanks a lot,
> Miaohsi
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Wednesday, July 06, 2011 10:47 PM
> To: General discussion for Windows Install
: Wednesday, July 06, 2011 10:47 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge module files not getting registered
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 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
est Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
Sent: 30 March 2011 16:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module not identifying my fragment
aller XML toolset.
> Subject: Re: [WiX-users] Merge Module not identifying my fragment files
>
> I'm guessing it's probably because there's no reference to the Fragment so
> it's not including it. Try adding a ComponentGroupRef for FooFiles under your
> FOO Dire
I'm guessing it's probably because there's no reference to the Fragment
so it's not including it. Try adding a ComponentGroupRef for FooFiles
under your FOO Directory or something else which links the Fragment to
your Module Element. That should sort it out.
Palbinder Sandher
Software Deployment
> Id="lan">1036 ...
>>
>> where "..." is any additional markup you require.
>>
>> This will produce one MSM for each language. You will then include them
>> using the same value for Language in your "Merge" element.
>>
>> -Original
: ... Id="lan">1036 ...
>
> where "..." is any additional markup you require.
>
> This will produce one MSM for each language. You will then include them
> using the same value for Language in your "Merge" element.
>
> -----Original Message---
The presence of that table in your MSI simply tells you that an MSM with
that identity was used in creating your MSI. Your WXS already has all of the
information that the MSM had contributed.
If you intend to continue using your MSM in building your MSI, you would
need to identify which parts of y
mail.com]
Sent: Tuesday, October 19, 2010 11:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module
Hi,
I am using windows 7 OS,
i my merge module is somthing like this,
http://schemas.microsoft.com/wix/2006/wi";
xmlns:difx=
t; Sent: Tuesday, October 19, 2010 12:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module
>
> Thanks for reply
>
> I am using same machine for both projects the merge module as well as main
> project. There is no OS differenc
er 19, 2010 12:31 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module
Thanks for reply
I am using same machine for both projects the merge module as well as main
project. There is no OS difference or any other configuration change
if i do merge module with
Thanks for reply
I am using same machine for both projects the merge module as well as main
project. There is no OS difference or any other configuration change
if i do merge module with only language "1033" it works properly, but when
i tried to do it with localization
just i tried to do the thi
What machine (OS/service pack) are you using to build? What language are you
trying to set the merge module to that it doesn't accept?
-Original Message-
From: sagar shinde [mailto:sagar.i...@gmail.com]
Sent: Monday, October 18, 2010 6:23 AM
To: WiX-users@lists.sourceforge.net
Subject: [W
On 3/25/2010 3:11 AM, Johann Taferl, T-AU wrote:
> Votive automatically generates following line(s):
>
You can change the Harvest property to false to stop automatic harvesting.
--
sig://boB
http://joyofsetup.com/
]
Sent: Mittwoch, 24. März 2010 21:16
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Module extracts msm file in target directory
On 3/24/2010 11:54 AM, Johann Taferl, T-AU wrote:
> I don't know, if this is an error or intended behavior:
>
> When I create a simple me
Subject: Re: [WiX-users] Merge Module extracts msm file in target directory
On 3/24/2010 11:54 AM, Johann Taferl, T-AU wrote:
> I don't know, if this is an error or intended behavior:
>
> When I create a simple merge module (in my test with only one file in
> it) and refer to this
On 3/24/2010 11:54 AM, Johann Taferl, T-AU wrote:
> I don't know, if this is an error or intended behavior:
>
> When I create a simple merge module (in my test with only one file in
> it) and refer to this merge module, the merge module - and its content -
> is not extracted to a temporary director
On 3/4/2010 11:01 AM, admiristra...@cox.net wrote:
> I guess I'm completely missing how to version files then. I don't
> find any attributes or child elements of component or file that seem
> related. I'm not aware of any consistent file-versioning aspect of
> the windows file systems. Also,
ence Park,
> Glasgow G20 0SP
> Email Disclaimer
>
>
> -Original Message-
> From: admiristra...@cox.net [mailto:admiristra...@cox.net]
> Sent: 04 March 2010 16:02
> To: General discussion for Windows Installer XML toolset.;
> b...@joyofsetup.com
> Subject: Re
...@cox.net]
Sent: 04 March 2010 16:02
To: General discussion for Windows Installer XML toolset.;
b...@joyofsetup.com
Subject: Re: [WiX-users] Merge Module versioning, or equivalent
Hi Bob,
I guess I'm completely missing how to version files then. I don't find
any attributes or child e
Hi Bob,
I guess I'm completely missing how to version files then. I don't find any
attributes or child elements of component or file that seem related. I'm
not aware of any consistent file-versioning aspect of the windows file
systems. Also, I expect a need to version non-files, such as registr
On 3/3/2010 4:14 PM, admiristra...@cox.net wrote:
> Can someone please detail how Merge Module versioning is supposed to work?
>
There's no such thing. Merge modules are a collection of tables and rows
that are merged into your .msi package, losing their identities in the
process. All versio
ode twice in order to
> >>>> distribute
> >>>>> it to two locations.
> >>>>>
> >>>>> On Thu, Jan 14, 2010 at 10:54 PM, Wilson, Phil
> >>>>> wrote:
> >>>>>
> >>>>>> Are you su
ute
>>>>> it to two locations.
>>>>>
>>>>> On Thu, Jan 14, 2010 at 10:54 PM, Wilson, Phil
>>>>> wrote:
>>>>>
>>>>>> Are you sure about that WinSxS location? I believe the 7.1 merge
>> modules
>>>
t; will install the Dlls in the user's application folder. I don't think
> >> they
> >>>> went WinSxS until Visual Studio 2005.
> >>>>
> >>>> Phil Wilson
> >>>>
> >>>> -Original Message-
> >>>
;>>
>>>> Phil Wilson
>>>>
>>>> -Original Message-
>>>> From: Pally Sandher [mailto:pally.sand...@iesve.com]
>>>> Sent: Thursday, January 14, 2010 3:47 AM
>>>> To: General discussion for Windows Installer XML toolset
>
> >> -Original Message-
> >> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> >> Sent: Thursday, January 14, 2010 3:47 AM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: Re: [WiX-users] Merge Module for msvcr71.
essage-
>> From: Pally Sandher [mailto:pally.sand...@iesve.com]
>> Sent: Thursday, January 14, 2010 3:47 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Merge Module for msvcr71.dll
>>
>>
>> > Id="m
nSxS until Visual Studio 2005.
>
> Phil Wilson
>
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Thursday, January 14, 2010 3:47 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Modul
Wilson
>
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Thursday, January 14, 2010 3:47 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module for msvcr71.dll
>
>
>
com]
Sent: Thursday, January 14, 2010 3:47 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module for msvcr71.dll
That is all you should Ricky need assuming you're using the VC++ 7 merge
modules provided with Visual St
56
>> Registered Office - Helix Building, West Of Scotland Science Park,
>> Glasgow G20 0SP
>> Email Disclaimer
>>
>> -Original Message-
>> From: Rob Hamflett [mailto:r...@snsys.com]
>> Sent: 14 January 2010 09:29
>> To: wix-users@lists.sourceforge.net
&
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>
> -Original Message-
> From: Rob Hamflett [mailto:r...@snsys.com]
> Sent: 14 January 2010 09:29
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Me
ourceforge.net
Subject: Re: [WiX-users] Merge Module for msvcr71.dll
Doesn't the merge module install the file to the Windows system folder?
If that's the case then you shouldn't need to install the file anywhere
else.
Rob
On 14/01/2010 09:16, ricky sundrani wrote:
> I am trying t
Doesn't the merge module install the file to the Windows system folder? If
that's the case then you
shouldn't need to install the file anywhere else.
Rob
On 14/01/2010 09:16, ricky sundrani wrote:
> I am trying to use a merge module for msvcr71.dll since its strongly
> recommended to use merge
38 is correct now (32 is an old incorrect value). The easiest way to solve
this problem is to use the EnsureTable element for the Extension table. The
WiX toolset will then use its definition (which is correct) for the column
before the Merge Module is merged and fix the error.
On Mon, Nov 30, 200
Prabhakaran Paulraj wrote:
> <
> <
> <
> <
> <
>
However you're posting is munging the code too much to see the structure.
--
sig://boB
http://joyofsetup.com/
--
Register Now & Save for Velocity, the Web Performan
Sorry, I figured it out. I was really swamped and starving and when
intellisense went all red~ I was confused. It seems there are no
attributes of this element, you just have to close it out and move on to the
Custom element.
The intelisense experience is a bit wierd though...
Christo
Langley
Senior Developer
Tel: +64 9 486 9010
alang...@winscribe.com
www.winscribe.com
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: Tuesday, 13 January 2009 1:52 p.m.
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-user
ndows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module doesnt remove all files
Thanks Rob,
Just curious, I couldn't find any documentation on this - in a wix MSI,
features contain components, and that defines which components are actually
installed.
In a WiX Merge, there is no
Verbose log file should show you the Components being uninstalled. That's the
place to start.
-Original Message-
From: Adam Langley [mailto:alang...@winscribe.com]
Sent: Monday, January 12, 2009 16:21
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Merge M
Are the source files there? It sounds like you might want all of the files
compressed, so make sure your Package/@Compress attribute is set as you expect.
-Original Message-
From: Chris Matthews [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 07:32
To: General discussion for Wi
Roberto Almanza wrote:
> I tried passing in the INSTALLDIR as a parameter to the call, but it is
> being passed in as the empty string.
If INSTALLDIR is coming from the .msi package that consumes the .msm,
it's not going to work: Merge modules are supposed to be self-contained,
so their IDs are
I simplified my approach a bit and was able to get the exe to be copied over
(along with a few xml files) and run...
However, now I have a problem where I attempt to open the files when running
the exe, the current directory is set to c:\.
I tried passing in the INSTALLDIR as a parameter to the c
ll with us (and has
been since the Windows Installer was written ).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Blair Murri
Sent: Thursday, July 31, 2008 21:24
To: [EMAIL PROTECTED]
Cc: General discussion for Windows Installer XML toolset.
Subject: R
alf Of Christopher
Painter
Sent: Wednesday, July 23, 2008 10:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help
What feedback? All I saw was a childish quip/troll post.
Personally I'm sick of the component rules and it's associa
From: Rob Mensching <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: "General discussion for Windows Installer XML toolset."
>
> Date: Wednesday, July 23, 2008, 11:39 AM
> Hey, wait a minute here.
>
> First, Automating Component/@Guids
> 1. How do you manage updates to the "database" in source
> control? Do people update the file before building or does
> the build machine checkout/checkin automatically? If the
> latter, what source control systems does it support... (you
> can see where I'm going )?
We use cvsnt as our s
the
Component/@Guid creates.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 08:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help
Christopher Karper wrote
his better than using auto-generated-stable Guids?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall
Sent: Wednesday, July 23, 2008 01:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module Help
> The cas
aller XML toolset.
Subject: Re: [WiX-users] Merge Module Help
John Hall wrote:
> Ah, we don't do patches, which is why it works for me :)
>
That's also an option. That's what ClickThrough does, using "early"
major upgrades every time. In that case, you don't
ere. This is where we talk
about the WiX toolset.
Thank you.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 08:54
To: [EMAIL PROTECTED]
Cc: General discussion for Windows Installer XML toolset.
Subject: Re:
John Hall wrote:
> Ah, we don't do patches, which is why it works for me :)
>
That's also an option. That's what ClickThrough does, using "early"
major upgrades every time. In that case, you don't even need stable IDs.
--
sig://boB
http://joyofsetup.com/
---
> John Hall wrote:
> > I have written a tool that auto-generates .wxs files for some parts
> > of my project - we ship a lot of example scripts. It only handles
> > files and generates one component per file. The tool maintains a
> > database (well, an XML file) that lists all the GUIDs ever
> > a
Christopher Painter wrote:
> Once again you pedantically pick through my comment without actually offering
> anything constructive yourself.
Wow, I'm really put in my place, aren't I?
--
sig://boB
http://joyofsetup.com/
I was thinking that the missing file would be the exception. Can you clarify
what you have in mind?
--- On Wed, 7/23/08, Christopher Karper <[EMAIL PROTECTED]> wrote:
> From: Christopher Karper <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: &q
Christopher Karper wrote:
> FWIW, I personally would rather manage the process by exception, instead of
> *always*.
>
Yes, some help is usually better than none. It's all about managing
expectations. If it's possible to automatically generate the original
setups, not being able to generate pa
on setting that declares the event as a warning and
automatically implements the punctured components pattern but I think that
assumes too much that the missing file is correctly missing.
--- On Wed, 7/23/08, Bob Arnson <[EMAIL PROTECTED]> wrote:
> From: Bob Arnson <[EMAIL PROTECTED]
FWIW, I personally would rather manage the process by exception, instead of
*always*.
Chris
On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Christopher Painter wrote:
> > This would be a pretty easy scenario to handle. Check the WXS against
> the XML and if a component
Christopher Painter wrote:
> This would be a pretty easy scenario to handle. Check the WXS against the
> XML and if a component is missing, throw an error and suggest the puncture
> component pattern ( transitive=true condition=false, 0 byte files for
> storage )
>
"Throw an error" isn't t
wrote:
> From: Bob Arnson <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Merge Module Help
> To: "General discussion for Windows Installer XML toolset."
>
> Date: Wednesday, July 23, 2008, 9:32 AM
> John Hall wrote:
> > I have written a tool that auto-generates
John Hall wrote:
> I have written a tool that auto-generates .wxs files for some parts of
> my project - we ship a lot of example scripts. It only handles files and
> generates one component per file. The tool maintains a database (well,
> an XML file) that lists all the GUIDs ever allocated, and a
> The case that gets really tricky is to have one build where a Resource
> disappears (usually accidentally) then the next build where the
> Resource comes back. It needs to get the same Component and GUID.
I have written a tool that auto-generates .wxs files for some parts of
my project - we s
PROTECTED] On Behalf Of James Minnis
Sent: Saturday, July 19, 2008 17:49
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Merge Module Help
That's an excellent point. The devil, as always, is in the details of when
someone screws u
s Minnis
Sent: Sat 19/07/2008 21:11
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Merge Module Help
Based on what people said in earlier messages, I'm migrating to using a
wixlib with a fragment generated by Heat. A lack of samples or useful
d
-
> From: [EMAIL PROTECTED] [mailto:wix-users-
> [EMAIL PROTECTED] On Behalf Of Rob Mensching
> Sent: Saturday, July 19, 2008 1:15 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
>
> I think you've over-simplified the
lf Of James Minnis
Sent: Saturday, July 19, 2008 13:08
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Merge Module Help
I couldn't find a feature request for that with a couple of quick searches,
but it is possible that I missed it.
This is defi
nstaller XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
>
> James Minnis wrote:
> > Right now, I'm generating a merge module
>
> Do you have a specific need for a merge module? (i.e., are you sharing
> it with others so they can create installers?) If not, avoid m
PROTECTED] On Behalf Of Rob Mensching
> Sent: Saturday, July 19, 2008 11:01 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
>
> This is a constant feature request (I'm surprised there isn't a feature
> request alrea
it will get some
attention.
-Jamey
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wix-users-
> [EMAIL PROTECTED] On Behalf Of Luke Bakken
> Sent: Saturday, July 19, 2008 8:09 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merg
James Minnis wrote:
> Right now, I'm generating a merge module
Do you have a specific need for a merge module? (i.e., are you sharing
it with others so they can create installers?) If not, avoid merge
modules. They needlessly complicate things, as you're finding out with #1.
> 1) I want to cre
Message-
> From: [EMAIL PROTECTED] [mailto:wix-users-
> [EMAIL PROTECTED] On Behalf Of Luke Bakken
> Sent: Saturday, July 19, 2008 8:09 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
>
> >> I'm surpr
>> I'm surprised that Heat doesn't have the functionality of leaving the
>> existing GUIDs in place. I just presumed I wasn't seeing how to do it.
>
> There was (is?) a project called "Paraffin" (http://xrl.us/mnhwj) for
> managing GUIDs. I've never used it so I can't vouch for it, but it may
> be
> updates, but it is very much not ideal. The biggest problem with this is
> the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file
> for the merge module.
Don't use VS to edit your XML. Something like Notepad2 or Vim or any
modern text editor should work great.
> I'm surpris
AIL PROTECTED] On Behalf Of Christopher Karper
> > Sent: Friday, July 18, 2008 5:52 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Merge Module Help
> >
> > I can't really answer intelligently to question #1, as
for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
>
> I can't really answer intelligently to question #1, as to question #2,
> I'll
> do my best.
>
> Heat is really built for initial import functionality, not continual
> maintenance
I can't really answer intelligently to question #1, as to question #2, I'll
do my best.
Heat is really built for initial import functionality, not continual
maintenance. You do not want your GUIDs changing on your components with
each build, it will turn upgrades into a nightmare, and will make p
8 00:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge module question
> By extension, we do not need tools like WiX as we don't need
> tools like compilers. We can all hack binary codes directly
> to the processor and be done with it.
>
> BTW
> By extension, we do not need tools like WiX as we don't need
> tools like compilers. We can all hack binary codes directly
> to the processor and be done with it.
>
> BTW, .msm is like a .o to a .c
I think of them more like a static library, i.e. a .lib file ... :)
john
Anidil wrote:
> Can't we author all the setup components inside an msm?Do we really need wix
> then?What all are the advantages of going for wix instead of deploying an
> application using merge modules?
By extension, we do not need tools like WiX as we don't need tools like
compilers. We can all
You can think of merge modules (MSMs) like an application DLL: it's a package
of install instructions that can be included in a parent installer. You still
need some sort of tool to author the MSM, something that explains what files to
include, where they should go, and what the order of install
1 - 100 of 136 matches
Mail list logo
