For major updates, changing the GUIDs should not matter as it does an
uninstall of the old version then an install of the new version. I just
won't provide a patch to make that leap. This should be acceptable because
it will be infrequent.
For smaller changes, a minor upgrade via patch should
If you're using Votive, you can just create a .wixlib project. That will
set up everything you need.
I don't have a lot of experience with them, as I can't use them.
Chris
On Sat, Jul 19, 2008 at 2:51 AM, James Minnis [EMAIL PROTECTED]
wrote:
For major updates, changing the GUIDs should not
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 surprised
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 what
That's unfortunate.
I could probably write something to keep the GUIDs standardized, but it
would be more work than it's worth for a hobby project I'm doing in my spare
time.
Most of our updates will only involve changes to text files rather than
adding or removing files. That implies a patch
Dan Giambalvo wrote:
I don't really need to customize it's name, I simply want to override the
default FilesInUse dialog. If there was some way I could distinguish between
the name that the dialog gets in the MSI and the way I reference it in my
DialogRef / I'd be all set.
There
Dane Anderson (Volt) wrote:
I'm afraid that the WixUI built in dialogs won't do what I need to do.
You can use the stock WixUI dialogs for all the required UI and add new
dialogs. See, for example:
http://www.wixwiki.com/index.php?title=WixUI_Custom.
BUT the compiler/linker want that
I am following the instructions given at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx
and http://msdn.microsoft.com/en-us/library/aa370840(VS.85).aspx to prevent an
old package from installing. Below is the WIX file with the yellow highlight
This is a constant feature request (I'm surprised there isn't a feature request
already). Generating Component GUIDs that follow the Component Rules is an
*extremely hard* problem to solve perfectly. The auto-generated Component
GUIDs is pretty good (assuming it doesn't have any bugs) but has
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 definitely not a trivial problem to solve, but I don't see why it
would be an intractable one. For a first pass, I'd generate a fragment WXS
file where one element is a hash
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
documentation had left me doing trial and error to figure how.
If you think that there is a better method, please let me know what it is.
:)
-Jamey
I think you've over-simplified the Component Rules. Once a Component contains
a set of Resources, those Resources must ship in that Component with that GUID
forever. Resources are files, registry keys, shortcuts, etc. (basically almost
everything that can be a child of the Component element).
Hi,
I know that answer for this question may be on archive of this group.
Unfortunately search engine on sourceforge stopped working.
I've been struggling with WebFilter for some time but finally I've managed
to get it working (only for Default Web Site). Now I'm trying to enable user
to choose
WebSites are only identified by their IP:Port:Header today. Description isn't
supported today because that field is basically just user data (i.e. the user
can change it at will).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pawel Olszewski
Sent:
Thanks for the reply.
Yes the description is user data but a single description is bound to a
single index at the moment of installation. So searching by description
means really searching by iis web site index. In fact I would be presenting
description only for end user but storing the index for
Descriptions aren't guaranteed to be unique. The tuple isn't guaranteed to be
unique either but at least they don't both work when the same. All of the
Sites on the machine can have the same name and still work.
There isn't a great solution to the problem..
-Original Message-
From:
That's an excellent point. The devil, as always, is in the details of when
someone screws up. Since Murphy is looking out for us, it never manages to
work ideally. :)
-Jamey
[EMAIL PROTECTED]
-Original Message-
From:
17 matches
Mail list logo
