jhennessey wrote:
>
> The bug is still open, see the submitter's comments:
> http://sourceforge.net/tracker/?func=detail&aid=3302804&group_id=105970&atid=642714
> http://sourceforge.net/tracker/?func=detail&aid=3302804&group_id=105970&atid=642714
>
>
It would be great if any of the WiX devel
Hi,
There are 2 msi installer files, both of them write the same file in the same
location. Objective is to overwrite the file by the latest installer.
As of now, the file is not versioned. So Installer re-writes the file only when
the modified date is older than created date of the existing fil
You could write a CA to put the file in a temp location each time, check the
creation date on both (or some other unique variable), and then move it into
the proper directory. You would have to write additional code to handle backup
of the pre-existing file in the instance of an update removal o
I have started receiving this error
lit.exe : error LIT0103: The system cannot find the file
'..\Content.Client\dir1\Content\Integration\common\niem\ut_offender-tracking-misc\2.0\ut_offender-tracking-misc.xsd'
with type ''. [D:\Builds\1\Product\version\Source\client
\Fragment.TX.TarrantCounty
It could be that you have an old wixobj out there for that component. You could
try removing that and rebuilding.
Jon
-Original Message-
From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
Sent: Tuesday, October 18, 2011 10:21 AM
To: General discussion for Windows Instal
Another option is to use the element tied to the same
Component as your element. This will always clear out the
existing file prior to the current install writing the new one. Works
for rollback and uninstall.
The RemoveFiles action is always scheduled before the InstallFi
Interesting solution. Very nice.
Jon
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, October 18, 2011 10:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using wix how to always overwrite a file?
Anoth
That was what I was thinking to. I purged my workspace and did a fresh get; I
don't have the behavior on my desktop.
I deleted the build directories on the build machine, and I still have the
issue.
The relative directory structure is the same, and it appears to be just these
two files that
I tried Chad's solution and it works fine.
Thanks Jon and Chad.
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Tuesday, October 18, 2011 8:39 PM
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] Using wix how to al
Follow up - I implemented a custom action that uses gacUtil.exe to
uninstall the old assemblies and scheduled it just after CostFinalize in
the InstallExecuteSequence.
-Original Message-
From: Gregory Swanson [mailto:gswan...@athoc.com]
Sent: Thursday, October 13, 2011 3:50 PM
To: wix-use
That's very odd. The old MSI that installed those v.3 assemblies is the
one that should be removing them, not the newer MSI. If you don't
consider the upgrade, but just uninstall that older MSI through Control
Panel does it not remove the GAC'ed files? The Major Upgrade simply
uninstalls that previ
How are the files being GAC'ed in the old installer? Custom action or using
the File element attributes?
--
John Merryweather Cooper
Jack Henry & Associates, Inc. (Premier Tech, Inc.)
Build & Install Engineer - jXchange
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
-Original Messa
Yes, running an uninstall from Control Panel does remove the old
assemblies. But if I just run a Major Upgrade, the old assemblies are
left behind. It doesn't seem right to be using a custom action to
remove the old assemblies.
Thanks,
Greg
-Original Message-
From: Chad Petersen [mailto
They're installed using the Wix File element for .Net Assemblies, like
this:
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Tuesday, October 18, 2011 11:16 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Replacin
It might not be an issue, but just reading your code I'd tend to avoid
the SharedDllRefCount. But, reading that also makes me wonder if there
was a particular reason for using that? Do other packages you know of
also deliver the same DLL?
I'm not sure how to generate an uninstall log when the Majo
The information on the Wiki is sparse; can someone provide a pointer to any
existing documentation as it relates to passing parameters to LIT from inside
the Tool Settings page? Do I use the options on the command line? Or do I use
the parameter names as documented in the MSBuild Task Referenc
I'd like to add you to my professional network on LinkedIn.
- Sandeep
Sandeep Sisodiya
--
India
Confirm that you know Sandeep Sisodiya:
https://www.linkedin.com/e/-n70kyl-gtxae6d9-4x/isd/4605191625/kkBRcwj1/?hs=false&tok=0RM_S_znQNrAY1
--
You are receiving Invitation to Connect emails. Click
I figured this out, (posting to share)...
It would appear that the filepath-name limitation in LIT is something less that
211 characters. I shortened the file name by 13 characters; and the issue
went away. The buildserver path is about a dozen characters longer than the
resulting local dev
We do have other applications that share some of these components, and
that list is growing. But looking in the SharedDLLs key in the
registry, I see that none of the .Net dlls are listed so I guess the
SharedDLLRefCount attribute is not needed with .Net dlls.
After running the Major Upgrade, th
I want to clarify what I was trying to say: after running the Major
Upgrade and looking at the verbose log, under the RemoveExistingProducts
action, I found a line for one of the old components that contains one
of the v.3 Assemblies - it looks like Windows Installer is planning to
remove it:
MSI (
20 matches
Mail list logo
