Do both of your installers use the same component ID for that DLL?
Robert Barnes robert.bar...@gmail.com
01/14/2010 11:53 PM
Please respond to
General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
To
wix-users@lists.sourceforge.net
cc
Subject
[WiX-users]
No. Unfortunately, the ICEs in the WiX toolset come from the MSI SDK. If
they were in WiX we'd fix 'em! smile/
On Thu, Jan 14, 2010 at 11:05 PM, Castro, Edwin G. (Hillsboro)
edwin.cas...@fiserv.com wrote:
FYI: I found that light.exe has a -sice:ICE argument.
Are the ICE distributed by WiX
It sounds like you either need to put them there yourself without using the
merge module, or look at
adding a CopyFile element.
Rob
On 14/01/2010 18:27, ricky sundrani wrote:
There is a link:
http://support.microsoft.com/default.aspx/kb/326922.
What is currently being followed for
Tried using the copyfile element inside a component. But the fileid
attribute does not resolve to the file id specified in the merge module.
Thanks.
On Fri, Jan 15, 2010 at 1:55 PM, Rob Hamflett r...@snsys.com wrote:
It sounds like you either need to put them there yourself without using the
I think IDs from the merge module get prepended with the merge module ID in
some way. You might
want to just add the merge module once, build it, and then see what the file ID
is in Orca.
Rob
On 15/01/2010 08:31, ricky sundrani wrote:
Tried using the copyfile element inside a component. But
Ya Rob,you are correct, wix does append the module id to the the file id. So
i did change the file id in the copy file correspondingly. But i don think
wix allows to resolve fild id references from merge modules.
On Fri, Jan 15, 2010 at 2:18 PM, Rob Hamflett r...@snsys.com wrote:
I think IDs
In that case I think you'll need to forget the merge module and just add the
files as you would
normally.
Rob
On 15/01/2010 09:06, ricky sundrani wrote:
Ya Rob,you are correct, wix does append the module id to the the file id. So
i did change the file id in the copy file correspondingly. But
Yes.. I too think dats the only way out..
Thanks for you time.
On Fri, Jan 15, 2010 at 2:54 PM, Rob Hamflett r...@snsys.com wrote:
In that case I think you'll need to forget the merge module and just add
the files as you would
normally.
Rob
On 15/01/2010 09:06, ricky sundrani wrote:
Ya
On Thu, 14 Jan 2010 15:16:05 -0500
Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com wrote:
We have an automated build that runs continually. We'd like each MSI
produced to behave as a major upgrade so that we can apply any newer
MSI on a target environment easily. Our build process fixes
Hi,
Is it Possible to configure DCOM component different issues?
Thanks,
Leo Kushnir
http://blogs.microsoft.co.il/blogs/leokushnir/
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's
This is requested often but the Windows Installer doesn't support a single
package that can install 32-bit and 64-bit Components on 32-bit and 64-bit
OSs. With the candle -arch switch it isn't hard to get a single set of .wxs
files to build 32-bit and 64-bit MSI files... but you need two. sigh/
Hi,
I have an application installed using an MSI built with WIX 3.0. When I
remove the application via ARP, it uninstalls and the icon and the
application entry in ARP gets deleted. However if I follow this procedure:
1. Click on Change option in ARP.
2. Then proceed with uninstall option provided
I'm using the WDK to build a C++ custom action DLL that gets included
in my MSI that I create using WiX 3.5. The problem I've come across is
that the WiX headers are located in C:\Program Files (x86)\Windows
Installer XML v3.5\SDK\inc, and the WDK doesn't appear to recognise
long filenames.
1. Yes, you will have full control over what packages get installed.
2. No, not yet. However, it is about time to start trying it out:
http://robmensching.com/blog/posts/2010/1/15/Burn-moves-to-a-new-foundation
On Thu, Jan 14, 2010 at 10:36 AM, John L Krupka john.kru...@nmwco.comwrote:
Yeah, it's not trivial but we should solve this problem eventually.
On Thu, Jan 14, 2010 at 8:52 AM, Brian Rogers rogers.br...@gmail.comwrote:
Not sure if it is that straight forward. I think the reason we keep punting
this feature is the dependencies heat.exe has on the Wix core project (
You can't merge a Merge Module twice. You can connect the Merge Module to
multiple Features but that won't get what you want. I think in your case,
you'll have to use a CopyFile element to copy the decorated File/@Id from
the Merge Module.
On Thu, Jan 14, 2010 at 10:00 PM, ricky sundrani
The minor upgrade works ok now. I have discovered that I change
REINSTALLMODE property in a screen, so the new package was never cached.
Thank you for answering though.
Bob Arnson-6 wrote:
On 1/12/2010 9:11 AM, Mihail Roman wrote:
msiexec /i Package.msi REINSTALL=ALL REINSTALLMODE=vomus
Hi all,
I tried to apply the How To: Run the installed application after
installation chapter from the WiX manual in a WiX file that also
contains a modified version of the WixUI_InstallDir dialog that does
not show an EULA confirmation dialog.
I added this Publish tag just before the /UI
Hi all,
2010/1/15 Reinier Lamers lam...@textkernel.nl:
As an extra clue, I see a shell window behind the application window
when it is run from the installer. Does this mean that the installed
EXE is a console application? If so, could it help to compile it as a
GUI application?
I found out
Looks like it's a bug in ICE61.
According to the MSDN documentation, VersionMin VersionMax both must
be a valid product version as described for the ProductVersion
property. See -
http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
ProductVersion properties are valid if The third field
Hi,
I'm having problems doing a major upgrade. I'm using WiX 3.5 to install a
driver using DIFxAPP and start it using ServiceControl:
Component Id=sctp.sys Win64=$(var.Win64)
Guid=fa538c80-6b0b-4736-b479-a3dce8f8a6a8
File Id=sctp.sys Name=sctp.sys KeyPath=yes Checksum=yes
I have a situation where version 2.0 of our product was set up with an option
in the UI for user's to install at per-user or per-machine (bad design
flaw). Now in the 3.0 version of our product it's per-machine by default.
I've read that when toggling the ALLUSERS context in a major upgrade
No, the installers are both completely different with their own component IDs.
2010/1/15 kelly.le...@milliman.com:
Do both of your installers use the same component ID for that DLL?
Robert Barnes robert.bar...@gmail.com
01/14/2010 11:53 PM
Please respond to
General discussion for Windows
I can't find any information on these errors on Google, so I'm coming to the
list.
Lessee here... VS 2k10 b2 using Windows Installer Toolkit 3.5. Executables
have a file version of 3.5.1204.0, running the installer on a 2k8 server. The
installer is for a website.
Minor bug:
Here is the problem(our QA found it):
In Windows 7, install the build. When the installation starts, minimize the
installation wizard. When the installation finished, the install wizard shows
on the top-left of the screen. We can only see a slice of the install
wizard(the close button X shows
More likely than not it's a bug in the new IIS7 support. Can you add this
information and as much of your .wxs file as possible to a new bug?
On Fri, Jan 15, 2010 at 1:25 PM, Will Sullivan wsulli...@softdocs.comwrote:
I can't find any information on these errors on Google, so I'm coming to
the
26 matches
Mail list logo