They're installed using the Wix File element for .Net Assemblies, like
this:
<Component Id='component132' Guid='6B1A694F-5FAF-4CB8-9644-8F679DB58238'
DiskId='1' SharedDllRefCount='yes' Location='local'>
<File Id='NETf57' Assembly='.net' KeyPath='yes'
Name='example.dll' Checksum='yes' Vital='yes' AssemblyManifest='NETf57'
Source='IWS\ServerObjects\DOTNET\example.dll' />
</Component>
-----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] Replacing .Net v.3 Assemblies with.Net
v.4Assembliesduring Major Upgrade
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 Message-----
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, October 18, 2011 12:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Replacing .Net v.3 Assemblies with .Net
v.4Assembliesduring Major Upgrade
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 previous package so no real extra mechanism is usually
required. Sounds like an issue of some sort with that older MSI. You've
probably done the best given the situation, but the real question is
what caused the situation in the first place? We use lots of GAC'ed
files and have not run into a given installer not uninstalling the
GAC'ed files it is responsible for.
-----Original Message-----
From: Gregory Swanson [mailto:gswan...@athoc.com]
Sent: Tuesday, October 18, 2011 10:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Replacing .Net v.3 Assemblies with .Net
v.4Assembliesduring Major Upgrade
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-users@lists.sourceforge.net
Subject: [WiX-users] Replacing .Net v.3 Assemblies with .Net v.4
Assembliesduring Major Upgrade
Hello:
I have an MSI developed with WIX, which packages (among other things) a
few .Net DLLs. Recently, these .Net v.3 DLLs have been updated to .Net
v.4.
I noticed that after running an upgrade, the .Net v.3 Assemblies remain
in the .Net 2 GAC (I noticed this after upgrades on Windows Server 2003
R2 and Windows Server 2008 R2). What I don't understand is: since I am
installing .Net v.4 Assemblies, should the .Net 3 Assemblies be removed
by the MSI or not? The .Net v.4 Assemblies are installed in the .Net 4
GAC and the application seems to work fine, but I would like to remove
the old v.3 Assemblies during upgrade.
While investigating how to do this, I found a reference to Bob Arnson's
blog ( http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/ ) and
followed his advice by setting RemoveExistingProducts to execute Before
InstallInitialize. It was set to After InstallFinalize previously.
Checking the verbose log, I do see that RemoveExistingProducts now
executes just before InstallInitialize, but the v.3 Assemblies were not
removed. The DLLs are authored one per component.
So I thought that maybe the scheduling of RemoveExistingProducts is not
the reason, maybe something else like file versioning (we have a build
engineer who manages that, and since the builds are automated I don't
usually notice a problem right away). I checked the file versions, and
one .Net v.3 DLL has a File Version of 2.3.0.0, while the .Net v.4 copy
has a File Version of 2.10.0.0. The Assembly version is the same for
both DLLs. I think this is the correct versioning to prevent a
side-by-side deployment when the DLLs are created with the same, or even
with different versions of .Net.
I'm pretty sure I could remove the .Net v.3 Assemblies with a simple
Custom Action, but I don't want to do that if there is a better
approach.
Thanks in advance for any help.
Greg
------------------------------------------------------------------------
------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------
------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------
------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it
are intended exclusively for the individual or entity to which it is
addressed. The message, together with any attachment, may contain
confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message
in error, please immediately advise the sender by reply email and delete
all copies.
------------------------------------------------------------------------
------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
