Home/ Questions/Q 7437687
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T10:26:16+00:00

I am using the namespace System.Windows.Forms.DataVisualization.Charting to create a Chart object on a form.

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0