2

I am using the namespace System.Windows.Forms.DataVisualization.Charting to create a Chart object on a form. This DLL is not a part of the basic Windows install, so I shall need to include it in my package when I distribute my application.

I am aware of the new version of GacUtil.exe and also that Gacutil.exe is only for development purposes and should not be used to install production assemblies into the global assembly cache. Let's just assume that I have no choice in the matter and have to do it this way due to the use of a proprietary package distribution system. =)

Edit/Update: In the 2.0 runtime, even though some PC's did not have GacUtil.exe present on the intended installation PC, I could drop GacUtil.exe (2.0 version) on the PC and I could then GAC whatever extra assemblies I needed. This appears to be a problem in the 4.0 runtime. Even though I have copied GacUtil.exe (4.0) to the destination PC, I get no feedback when running it against the needed assembly. End Edit/Update

Now, on my PC (the development PC), I can add the DLL to the GAC without any problems: Command Prompt On My PC

However, on a clean Windows 7 PC, with the same DLL and the same version of GacUtil.exe I get this: Command Prompt On Clean PC

Why the discrepancy? Does the new GacUtil.exe depend upon something that this PC doesn't have?

Community
  • 1
  • 1
Chris Barlow
  • 3,274
  • 4
  • 31
  • 52
  • It can't be a clean machine if gacutil.exe is available. The path you pass makes no sense, you are asking gacutil to install an assembly from the GAC into the GAC. – Hans Passant Feb 10 '12 at 01:20
  • @HansPassant Thanks for looking - and you're probably hinting at my ignorance of the new GacUtil/GAC (and you'd be right). =) I've updated my question (see Edit/Update) and changed the screenshot to reflect the current situation. – Chris Barlow Feb 10 '12 at 12:56

2 Answers2

3

Ok, I ended up having two problems, one of them being a moot point in the end.

Problem #1: GacUtil.exe (for the 4.0 CLR) has Dependencies

When i copy over the folder in which GacUtil.exe resides, the problem of adding the assembly vanishes: Successful GAC on Clean PC

This ended up being a moot point, however, because even though the file was in the 4.0 GAC on the client machine, I still had the crash. I realized at that point that the problem was that I am not targeting the 4.0 GAC - I'm targeting the 2.0 GAC. The file I was trying to add to the GAC this whole time was a 4.0 version of the file. This was the piece I wasn't understanding.

Problem #2: There are separate 4.0 and 2.0 versions of "GACable" DLL's, and they are not backwards compatible

I simply went back to my development machine and grabbed the 3.5 version of the DLL in question (System.Windows.Forms.DataVisualization), added it to the 2.0 GAC on the client PC, and crisis averted.

A. Wilson
  • 688
  • 1
  • 6
  • 15
Chris Barlow
  • 3,274
  • 4
  • 31
  • 52
0

You can run the 4.0 Gacutil from your own folder if you add a "1033" subfolder and include the file, gacutlrc.dll, which can be found in the same subfolder in the standard location.

Tony Zackin
  • 1