Install x64 & x86 managed assemblies in GAC

  • Thread starter Thread starter Jason Newell
  • Start date Start date
J

Jason Newell

I asked this question on CodeProject back in August 2009 but didn't get
any answer so I thought I'd try here. Here is a copy of my original
question.

All,

I have a C++/CLI assembly that is compiled for x64 and x86. These files
get installed in C:\Program Files and Program Files (x86) respectively
on 64 bit machines via a Visual Studio .NET 2008 setup project. I also
need these two assemblies to be installed into the GAC so that other
managed apps compiled as "Any CPU" will correctly load the right .dll. I
can manually install these two assemblies into the GAC using "gacutil
/i" but I'm having trouble figuring out how to set this up in a setup
project in VS.NET 2008.

The setup project property "TargetPlatform" is configured for "x64".
The setup project File System looks like this:
Global Assembly Cache Folder\Managed.dll /* (x64) */
Global Assembly Cache Folder\Managed.dll /* (x86) */
Program Files (64-bit) Folder\{AppName}\Managed.dll /* (x64) */
Program Files Folder\{AppName}\Managed.dll /* (x86) */

Upon building the project, I get 2 warnings:
WARNING: Two or more objects have the same target location
('[gac]Managed\2.0.0.0_487e2f56c7456732\Managed.dll')
WARNING: Two or more objects have the same target location
('[gac]Managed\2.0.0.0_487e2f56c7456732\Managed.dll')

I'm suspecting that VS.NET 2008 won't support what I'm trying to
accomplish but I wanted to do a sanity check with you guys first. If it
is ineeded the case, does anyone have alternative approaches or
installers that I can look into.

Thanks so much!

Jason Newell
www.jasonnewell.net
 
I've been working with another fellow via private email on this issue
and he found that by adding anything to the 'Condition' property of one
of the files listed to be installed into the GAC, the warnings go away
and the Setup actually installs correctly. For instance, he put 'NOT'
in the Condition property. I put a single space ' ' and it worked for me.

I find it very suspicious that this works. What do you guys think?

Jason Newell
www.jasonnewell.net
 
It's not just Visual Studio that gets confused, it's other tools too.
Internally in the MSI file all files to be installed have entries in the
File table and directories in the Component table. This defines their
location. All files except (you guessed it) files going to the GAC. If
they're going into the GAC this is marked by a null entry in the
File_Application field of the MsiAssembly table. That's rather weird, and
tools generally don't pick it up because dammit the Directory table is how
you say where files are being installed. This is one of several areas where
..NET stuff doesn't behave normally in the MSI world (another example is that
every installed file is actually on the system at the same time except
assemblies in the GAC, not available until the end of the install, Commit).

Enough of my rambling - if it works then it's ok, but in general it's
recommended to have separate install packages for different architectures.

http://blogs.msdn.com/heaths/archiv...ed-for-different-processor-architectures.aspx

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


Jason Newell said:
I asked this question on CodeProject back in August 2009 but didn't get any
answer so I thought I'd try here. Here is a copy of my original question.

All,

I have a C++/CLI assembly that is compiled for x64 and x86. These files
get installed in C:\Program Files and Program Files (x86) respectively on
64 bit machines via a Visual Studio .NET 2008 setup project. I also need
these two assemblies to be installed into the GAC so that other managed
apps compiled as "Any CPU" will correctly load the right .dll. I can
manually install these two assemblies into the GAC using "gacutil /i" but
I'm having trouble figuring out how to set this up in a setup project in
VS.NET 2008.

The setup project property "TargetPlatform" is configured for "x64".
The setup project File System looks like this:
Global Assembly Cache Folder\Managed.dll /* (x64) */
Global Assembly Cache Folder\Managed.dll /* (x86) */
Program Files (64-bit) Folder\{AppName}\Managed.dll /* (x64) */
Program Files Folder\{AppName}\Managed.dll /* (x86) */

Upon building the project, I get 2 warnings:
WARNING: Two or more objects have the same target location
('[gac]Managed\2.0.0.0_487e2f56c7456732\Managed.dll')
WARNING: Two or more objects have the same target location
('[gac]Managed\2.0.0.0_487e2f56c7456732\Managed.dll')

I'm suspecting that VS.NET 2008 won't support what I'm trying to
accomplish but I wanted to do a sanity check with you guys first. If it is
ineeded the case, does anyone have alternative approaches or installers
that I can look into.

Thanks so much!

Jason Newell
www.jasonnewell.net
Click to expand...
 
Phil,

Thanks for the feedback. I agree with your points about "in
general...". I'd like to try and explain my approach and why I need to
have the x64 & x86 version of the managed assembly installed.

I'll end up with 3 setup packages for my product.

[Setup32 - TargetPlatform: x86]
- Installs executables into ProgramFilesFolder\App
- Installs x86 version of managed assembly into GAC

[Setup64 - TargetPlatform: x64]
- Installs executables into ProgramFiles64Folder\App
- Installs x86 version of managed assembly into GAC
- Installs x64 version of managed assembly into GAC

[SetupSDK - TargetPlatform: x86]
- Installs copy of x86 version of managed assembly and related XML into
ProgramFilesFolder\App for VS.NET "Add Reference" and intellisense
- Adds a key under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders for
VS.NET "Add Reference". *Note: SOFTWARE\Wow6432Node\ if installed on
x64 machine.

Make sense? Thanks.

Jason Newell
www.jasonnewell.net
 
That makes sense to me. You're not installing a GAC assembly for product use
as well as for development with an SDK, and IMO that's the right thing to
do.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


Jason Newell said:
Phil,

Thanks for the feedback. I agree with your points about "in general...".
I'd like to try and explain my approach and why I need to have the x64 &
x86 version of the managed assembly installed.

I'll end up with 3 setup packages for my product.

[Setup32 - TargetPlatform: x86]
- Installs executables into ProgramFilesFolder\App
- Installs x86 version of managed assembly into GAC

[Setup64 - TargetPlatform: x64]
- Installs executables into ProgramFiles64Folder\App
- Installs x86 version of managed assembly into GAC
- Installs x64 version of managed assembly into GAC

[SetupSDK - TargetPlatform: x86]
- Installs copy of x86 version of managed assembly and related XML into
ProgramFilesFolder\App for VS.NET "Add Reference" and intellisense
- Adds a key under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders for
VS.NET "Add Reference". *Note: SOFTWARE\Wow6432Node\ if installed on x64
machine.

Make sense? Thanks.

Jason Newell
www.jasonnewell.net

It's not just Visual Studio that gets confused, it's other tools too.
Internally in the MSI file all files to be installed have entries in the
File table and directories in the Component table. This defines their
location. All files except (you guessed it) files going to the GAC. If
they're going into the GAC this is marked by a null entry in the
File_Application field of the MsiAssembly table. That's rather weird, and
tools generally don't pick it up because dammit the Directory table is
how you say where files are being installed. This is one of several areas
where .NET stuff doesn't behave normally in the MSI world (another
example is that every installed file is actually on the system at the
same time except assemblies in the GAC, not available until the end of
the install, Commit).

Enough of my rambling - if it works then it's ok, but in general it's
recommended to have separate install packages for different
architectures.

http://blogs.msdn.com/heaths/archiv...ed-for-different-processor-architectures.aspx
Click to expand...
Click to expand...
 
Back
Top