GAC 32bit vs. 64bit

Question

I've been searching for a while trying to understand this better, but am not finding any straight-forward answers on this.

I have a component that I need to add to the GAC. I'm running Windows 7 64-bit, and in an effort to troubleshoot an issue (SSIS 2005 isn't recognizing the DLL), I'm trying to make sure I have the DLL (.NET 4.0) registered in the proper GAC.

So here are my questions:

1. Where are the physical locations in Windows 7 for both 64bit and 32bit GACs? I know of C:\Windows\assembly, but not sure which one this is, and where the other one is.

2. Which version of gacutil do I use to add an assembly to 64bit GAC? 32bit GAC? I know of C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC, and I'm assuming this is for 32bit, but not sure where 64bit gacutil is.

3. What determines which GAC an application looks in for the assembly? I'm assuming this is determined by whether the app is 64bit or 32bit, but am wondering if there is more to it than that.

Thanks in advance.

Update:

After digging into this following ShaneBlake's answer, I remembered that .NET 2.0 and .NET 4.0 GACs are in different locations. So:

.NET 2.0 GAC:
c:\windows\assembly (32bit and 64bit?)

.NET 4.0 GAC
c:\windows\Microsoft.NET\assembly\GAC_32 (32bit only)
c:\windows\Microsoft.NET\assembly\GAC_64 (64bit only)
c:\windows\Microsoft.NET\assembly\GAC_MSIL (32bit & 64bit?)

Prefrontal

Note that you can't use gacutil on client machines if you're distributing your app. VS installer/deployment projects will let you install the assemblies in the correct location. – Bingle

Answer 1

The gacutil.exe should install the .dll to the right location depending on how it was compiled. You should be able to find the file here : %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\

.NET 4 has it's own Assembly folder (c:\windows\Microsoft.NET\assembly) which has a \GAC_32 and \GAC_64 directories within... This is where you will find your files once they're installed.

Hope that helps...

Secrest

Is gacutil available on client machines? I seem to remember that it's only available if you have the SDK installed. – Bingle

@David : Yes. It is considered a developer tool, so you must have the SDK installed. – Secrest

@Secrest thought so. I've used deployment projects to get the assemblies in the correct place, though the GAC is not high on my list of favorite places. – Bingle

@David I agree. In our web apps, I prefer to just put them in \AppLocalResources so they get deployed in the \bin and I always know which version I'm using... – Secrest

Thanks to the both of you. I typically avoid dealing w/ the GAC, but SSIS requires custom components are installed in the GAC. – Prefrontal

@Secrest - I looked into this, and C:\Windows\Microsoft.NET\assembly has three folders: GAC_32, GAC_64, and GAC_MSIL. It looks like GAC_32 & GAC_64 have only a few assemblies. GAC_MSIL looks more reflective of the actual GAC, as it has several more (400 vs. 20 & 30), and it has the one I added. However, I'm still not sure if GAC_MSIL is considered 32bit or 64bit. – Prefrontal

@Jerad My understanding is that GAC_MSIL contains .dll's that can run under either 32 or 64. – Secrest

I believe these GAC_MSIL assemblies must be compiled for "Any CPU" so they should be able to run as both x64 and x86 – Onfre

In my case, it was under C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64, and %ProgramFiles% went to C:\Program Files. – Maxson

@Bingle It looks like it might be possible to just copy/paste gacutil.exe (and its dll / config file) to a client system, I might try this for a quick test. – Step

@Step Well, I haven't messed with this in 7 years. BUT, yeah, gacutil doesn't have many external dependencies. Good luck! – Bingle

@Bingle just coming back to report, yes, it definitely works to copy/paste both the x86 and x64 versions of gacutil to a testing PC. – Step

Answer 2

For Windows 10:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

Worried

One thing that I have been wondering for a while, is there any reason to not use the absolute latest SDK that you have? Confusingly, I have v7.0A on Windows 10, and v10.0A on Windows 7; does the SDK version have any effect at all? Maybe backwards compatibility? Additional features? – Step

@Step while we're reviving zombie threads: yes, backwards compatibility is the chief reason to not use the latest SDK. If you need to deploy to Win7, using an RS5-specific SDK will not make you any friends. – Bingle