VS Setup and Deployment projects is an absolutely awful toolset for generating
anything related to setup and/or deployments.
Remember when Visual SourceSafe first came out over a decade ago, or am I
showing my age? At the time it was no good for all workgroups larger than two
people, and even
Thanks for explaining in detail :)
I am now planning to write merge module in wix :)
Thanks,
On Fri, Oct 16, 2009 at 12:48 PM, Blair os...@live.com wrote:
VS Setup and Deployment projects is an absolutely awful toolset for
generating anything related to setup and/or deployments.
Remember
I am trying to perform the following for Creating the COM+ application using WIX
Reference material:
www.tramontana.co.hu/wix/lesson6.phphttp://www.tramontana.co.hu/wix/lesson6.php
Component Id=MyCOM_dll DiskId=1
Guid=YOURGUID-242F-4B82-BDC7-588E59E9F393
File Id=MyCOM_dll Name=MyCOM.dll
1. You should use different ProductCodes. Otherwise it will be very
difficult to tell what product a user has installed. The real kicker (which
you may not be hit by directly) is if you ever try to create patches. Using
the same ProductCode will make patching basically impossible.
There is really
Usually, I recommend a simpler mechanism. Add -sval to your light.exe
calls then use smoke.exe to run validation serially at the end.
virtually, Rob Mensching - http://robmensching.com
On Thu, Oct 15, 2009 at 9:31 AM, Blair os...@live.com wrote:
Not sure. The semi-pseudocode would look like
Hi Wix-users,
I developed one installation package with Wix 3. And I installed the
current version to my machine. If I want to install the same version
again to my machine, just change the install path, the installation
package doesn't work. It will always install to the last path. And it
even
This is called multiple instance installation and is usually achieved
via the conception called instance transforms. The docs about it can
be found here:
http://msdn.microsoft.com/en-us/library/aa369523(VS.85).aspx
The WiX support to this is:
Here is the answer: If you install two packages with the same ProductCode
(and they have the same version) but the newer one is missing ANYTHING that
the older has (with regard to components in features) you will end up
advertising your installation and orphaning your already installed resources
Hi Yan,
Thanks a lot for you collecting the information. I will read the threads
through and hopefully find the solution.
Best regards,
Chunyan
-Ursprüngliche Nachricht-
Von: Yan Sklyarenko [mailto:y...@sitecore.net]
Gesendet: Freitag, 16. Oktober 2009 12:06
An: General discussion
Hi Wix - users,
I use PARAFFIN.exe to generated .WXS file to include and update the
files. It is an excellent tool. See the link:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2007/10/21/wix-a-bet
ter-tallow-paraffin.aspx?CommentPosted=true#commentmessage
However, I have another problem.
Check the error information in a verbose log file from a failed install.
Search for value 3 and you'll find it quickly. That usually tells you far
more information about what exactly is going wrong.
virtually, Rob Mensching - http://robmensching.com
On Fri, Oct 16, 2009 at 2:19 AM, Kusuma Sudheer
Guten Tag Jiang, Chunyan (GE Healthcare),
am Freitag, 16. Oktober 2009 um 13:15 schrieben Sie:
I will use this file in my .WXS file as Custom Action:
CustomAction Id=RUNInstall
FileKey=file_E92584CFAEE24DFD8B1E8BFD27E2F079 ExeCommand=RUN.exe
-install -quiet Return=asyncWait /
[...]
It is
I don't use Paraffin but have you verified that the File/@Id value is
staying constant from run to run? If it is check out a verbose log file from
a failed install to get more information about what failed.
virtually, Rob Mensching - http://robmensching.com
On Fri, Oct 16, 2009 at 4:15 AM, Jiang,
Hi Rob,
Thanks for your reply.
I checked the verbose log. And I found that the problem might not be caused by
the PARAFFIN. The log shows that custom action tries to call RUN.exe from the
path, which I set as default path, say d:\PathA, in main.wxs:
Directory Id=TARGETDIR Name=SourceDir
Forgive me if this has already been talked about but the source forge
usability for searching the mailing list is quaint.
I am seeing an issue where uninstalls are bombing if queue(s) created by the
installer are no longer present. Funny thing is the bombing uninstall
process actually creates the
Hello,
Our installer project has a large number of content files existing in a pretty
deep folder hierarchy. We use the heat.exe utility to generate a fragment for
all of them. This works great, the xml output looks correct. But when
performing a per-user install, one of the folders always
Since XP64 is based on Win2k3 64, their OS installer properties are
identical. Is there another way to distinguish the two operating systems?
We would like to add a launch condition that allows XP64 but not Win2k3
Server 64.
John
You missed the MsiNTProductType property.
Regards,
jjf
-Original Message-
From: John Lalande [mailto:johnlala...@gmail.com]
Sent: Friday, October 16, 2009 10:32 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows 2003 Server 64 bit and XP 64 bit
In a verbose installation log, search for the properties Content, Audio,
FBX, _394D1CD9, boku_programming_ui_02.fbm. See which one starts the
deviation from the others. Then look back to where that property gets set
and who sets it.
-Original Message-
From: Eric Anderson
MsiNTProductType will be different.
-Original Message-
From: John Lalande [mailto:johnlala...@gmail.com]
Sent: Friday, October 16, 2009 2:32 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Windows 2003 Server 64 bit and XP 64 bit
Since XP64 is based on Win2k3 64, their OS
Here's a long shot: Could the FBX and _394D1CD9 folders be treated differently
because they consist of all uppercase letters?
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, October 16, 2009 3:00 PM
To: 'General discussion for Windows Installer XML toolset.'
I believe the problem may have been that their identifiers were all uppercase.
Changing them to mixed case resolved the issue.
-Original Message-
From: Eric Anderson [mailto:eand...@microsoft.com]
Sent: Friday, October 16, 2009 4:16 PM
To: General discussion for Windows Installer XML
I am trying to get the header and port for the default website. My
application fails its install using wix if the user has changed the
port or header to something that is not the default. How do I go about
getting this information in Wix?
I see that I can use wildcards for
the IP address, but Port
23 matches
Mail list logo
