GAC Madness

Using FxCop when I try to analyze projects that rely on Patterns and Practices, Enterprise Library Data (among others) 2.0.0.0. FxCop complains that it can’t “Locate Assembly Reference,” even though the application dll being analyzed was complied against this version, and it’s in the GAC. If I browse to the GAC and try to select the same assembly (I’ve checked version and public key token), FxCop won’t allow me “open” it. The application succeeds in running and definitely makes use of the problem dll.

OS: Seen on both Vista and Windows XP.
Versions: Visual Studio 2005 and 2008. FxCop 1.36

I have the same problem if I try to browse the application dll with Reflector.

Clearly, it doesn’t think this is the same version of the assembly it’s compiled against. Does anyone know why? Any suggestions for a solution? What am I missing?

Solution (via StackOverflow): “In FxCop, you can select Project – Options… – Spelling & Analysis – (check) Search Global Assembly Cache for missing references.”

Related posts:

  1. Eclipse Madness – Why do fragment plugins work for some Developers and not others?
  2. 12 Easy steps for generating Index Cards from your Sprint Backlog
  3. Eclipse 0, YourKit 1
  4. Visual Studio vs. CCNET as Service
  5. Remote Desktop Pain
TwitterFacebook Google Plus Stumbleupon Delicious Reddit Email

About

ScrumMaster Trainer

2 Comments

  1. Ruben Bartelink May 11, 2009 at 11:30 am #

    Somre random ideas…

    You sure it’s got the same public key token (strong name) ?
    Esp with EL, you have the option to recompile with a differnt SN.
    You could remove everything from the GAC, and re-register the ones you definitely want to use.
    use SN -T to find out the token on a DLL
    look in the csproj to see what token is referenced
    read Box’s .NET book
    use exploring to %windir%\assembly to see whats in the GAC

  2. Mark Levison May 11, 2009 at 11:40 am #

    Ruben – thanks for the quick reply. As it stands I’m certain that the public key token is the same. I’ve checked them and they’re the same. I will check both the dll and the csproj to find what strong names they have.

Post Comment