GAC Local copy problem

[fabrice.bernier]

I am currently working on a C# .Net project and I am facing big
troubles with dll and GAC.
Until few days ago, everything was working correctly, but it is not
anymore, and I don't see what could have cause that.

Here is my problem :

In my .Net project, I am using a dll that I put as reference.
My project works if I use Local copy attribute to true.
If I put it to false, it does not work.
I put the dll in the GAC, check it over and over. I made new versions,
using new sn keys... I clear the GAC cache, I looked into it directly
(c:\windows\assembly\GAC) to remove old things...
I made several versions of the dll so that I thought it could come from
a weird thing due to this, but I think I clean it up (even the registry
as I created tlb...), I check my drives to remove other version of the
dll...

As you guess, the problem is still here.

One strange thing is that, setting local copy to false does not tell me
the dll is missing : VS finds it in the GAC (I think) but may use an
old version as It does not work correctly.

I hope I made my self clear !

Any help would be appreciated... thanks !

 

[Carlos J. Quintero [VB MVP]]

Hi,

For background information, I recommend to read:

How the Runtime Locates Assemblies (MSDN)
http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp

Now:

In my .Net project, I am using a dll that I put as reference.

File (binary) reference or project (source code) reference? File reference,
I suppose.

My project works if I use Local copy attribute to true.
If I put it to false, it does not work.

Correct. If the run-time don´t find it in the GAC, it uses the probing
mechanism. If you don´t use LocalCopy, the dll is not found. To locate the
dll in its original location your app config file should use a codebase to
avoid the probing mechanism.

I put the dll in the GAC, check it over and over.

The GAC is a deployment mechanism for the final users of your app if you
decide that the DLL is shared with others. It is not a development mechanism
and you should NOT use it during development, only when you create the setup
for your app.

I made new versions, using new sn keys...

You or your company should use always the same key... if you want make a new
version which breaks the backwards compatibility, change the AssemblyVersion
attribute. If it does not break the backwards compatibility (a bug fix, for
example), keep the AssemblyVersion attribute value and change the
AssemblyFileVersion attribute (in VS.NET 2002/2003 you must add it by hand
since it does not appear in the assemblyinfo file).

I clear the GAC cache, I looked into it directly
(c:\windows\assembly\GAC) to remove old things...
I made several versions of the dll so that I thought it could come from
a weird thing due to this, but I think I clean it up (even the registry
as I created tlb...), I check my drives to remove other version of the
dll...

One strange thing is that, setting local copy to false does not tell me
the dll is missing : VS finds it in the GAC (I think) but may use an
old version as It does not work correctly.

Use the tool FileMon (http://www.sysinternals.com/Utilities/Filemon.html) to
spy the disk activity and find out where the dll is loaded from.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com