Cached assemblies cause me grief

[Alex]

Hello.

I am having a bit of a problem with my C# Word add-in.

I noticed that my assemblies are cached in several places
under C:\Documents and Settings\<user>\Local Settings\Application Data\assembly\dl2\...
and under C:\Documents and Settings\<user>\Application Data\Microsoft\VisualStudio\7.1\ProjectAssemblies\...

When Word loads my add-in, some of the assemblies will be taken from the above caches.

Normally, it isn't a problem as the caches seem to be in sync with the actual assemblies.
However, when we change the version numbers (say, from 1.0.0.5 to 1.0.0.6), the synchronization breaks and Word will load the older versions from the cache.

Usually we exit all instances of Visual Studio, manually clean the two directory trees above and rebuild the project.
This works but it is a bother.

Is there a way to disable the caching?


Best wishes,
Alex.

 

[Peter Huang [MSFT]]

Hi

Based on my test, it load the dll from the compiled directory.
e.g.
You run the winword.exe, and now you change some in the Addin and compile
in the IDE, now the IDE will tell you can not copy the dll into ... because
it is in use.
Also based on my test, every time I change the version and recompile, the
Word will load the recently compiled one.

Can you give some sample to reproduce the problem?

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Alex]

Hello Peter,

Based on my test, it load the dll from the compiled directory.
e.g.
You run the winword.exe, and now you change some in the Addin and compile
in the IDE, now the IDE will tell you can not copy the dll into ... because
it is in use.
Also based on my test, every time I change the version and recompile, the
Word will load the recently compiled one.

Can you give some sample to reproduce the problem?

Can the strong name have something to do with it?


Best wishes,
Alex.

 

[Peter Huang [MSFT]]

Hi

I think that is not the problem. Because if .NET Runtime load an
strongnamed assembly it will check the full qualified name, including the
culture, version, name, strongname ......., if any item is not match, the
load will failed.

So have you tried from a very simple addin, and just change the version to
see if the problem can be reproduced.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Alex]

Hi Peter,

I found that other people have been having this "shadow cache" problem as well:

http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx
http://blogs.msdn.com/ptorr/archive/2004/11/07/253442.aspx
http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx


Best wishes,
Alex.

 

[Peter Huang [MSFT]]

Hi

Thanks for your information.
So far based on my test with an addin, it is loaded from the debug dir but
not the cache dir.
In an AppDomain, we have a property ShadowCopyFiles to check the setting.
Based on my test, by default the ShadowCopyFiles is False.
You may try to check it in your addin to see what is the value in your
scenario.

MessageBox.Show(AppDomain.CurrentDomain.ShadowCopyFiles.ToString());

BTW: For ASP.NET application, this ShadowCopyFiles is enable by default.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Alex]

Hi

Thanks for your information.
So far based on my test with an addin, it is loaded from the debug dir but
not the cache dir.
In an AppDomain, we have a property ShadowCopyFiles to check the setting.
Based on my test, by default the ShadowCopyFiles is False.
You may try to check it in your addin to see what is the value in your
scenario.

MessageBox.Show(AppDomain.CurrentDomain.ShadowCopyFiles.ToString());

It is False, but the code still gets cached.

Here's a reply I got from Jamie Cansdale:
: Ah, that problem. You have two choices. Ether don't strong name your
: assemblies or bump up the version number on each release. Once an
: assembly has been shadow copied it has been copied somewhere very
: similar to the GAC (except you can't unload it!). Apparently this has
: been fixed in .NET 2.0.


Best wishes,
Alex.

 

[Peter Huang [MSFT]]

Hi

So far I can not reproduce the problem.
And I think you may try to use the workaround your refer to in your last
issue.
I will keep researching the issue, if I have any new information, I will
update you with new information ASAP.,
Thanks!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang [MSFT]]

Hi

Based on my researching, I did not find any new information.
Since I can not reproduce the problem it is hard to troubleshooting.
If you do have concern with the problem, I think you may try to contact
MSPSS directly maybe there have other ideas.
http://support.microsoft.com

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.