Big problem with GAC and local

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

David Thielen - 07 Nov 2006 22:55 GMT

Hi;

We have another problem with GAC vs local.

We have a library that our users want to install with the libraries in the
GAC (as recomended by Microsoft). These are programmers only.

We have a Word Add-In where the libraries are installed locally with the
Add-In (as recomended by Microsoft). THis Add-In is used by both programmers
and non-programmers. This Add-In includes the same DLLs that are in the
library.

In the case of the programmers, then now have about 10 DLLs that are
identical in both the GAC and in the directory with the Add-In. And
sometimes, the DLLs are different versions between the two locations. All are
strongly named and signed.

What happens is when the Add-In runs, it cannot find some of the DLLs that
are in both places. How do we work around this?

Signature

thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

Reply to this Message

"Peter Huang" [MSFT] - 08 Nov 2006 02:28 GMT

Hi Dave,

Based on my understanding, I assume your scenario similar as below.
You have an Word Addin which will load a few Assemblies, A,B,C,D....
All of the assembly are strongnamed and signed.
And you put them into GAC, and put them in the same dir as Addin installed.

Now you find that sometime after the Addin load, it can not find the Addin
in both place.

If I misunderstand, please let me know.

Based on my knowledge, by design, the .NET FW will check the Assembly
binding request from the GAC first, that is to say, the Addin should always
load the DLL from the GAC.
Currently it will not load from both place, I wonder if you have rebuilt
the addin or assemblies.
Because once an dll is strong name, the .NET FW will check for its full
qualified name and load it. If any part of the full name did not match, it
will fail.
e.g. if the version changed, or signed key .....

Currently I think you may try to use the fuslogvw to log all the binding
process to see what is the Word addin is trying to bind, and how it is
failed.

Here are two articles for your reference.
Assembly Binding Log Viewer (Fuslogvw.exe) Legacy Documentation
http://msdn2.microsoft.com/en-us/library/e74a18c4(VS.80).aspx

How the Runtime Locates Assemblies
http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.80).aspx

Best regards,

Perter Huang
Microsoft Online Partner Support

Signature

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

Reply to this Message

David Thielen - 08 Nov 2006 06:23 GMT

I think that may be it - we have one version in the GAC and a different
version in the AddIn directory. How do I get it to look in the AddIn
directory first? These users need both installed on their system and the DLLs
in the GAC will be a different version sometimes.

Signature

thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

> Hi Dave,
>
[quoted text clipped - 36 lines]
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Ben Voigt - 08 Nov 2006 15:54 GMT

>I think that may be it - we have one version in the GAC and a different
> version in the AddIn directory. How do I get it to look in the AddIn
> directory first? These users need both installed on their system and the
> DLLs
> in the GAC will be a different version sometimes.

Change your add-in installer to put the DLLs in the GAC, it's required for
DLLs used by more than one product. Then the GAC will contain several
different versions, and you can bind to the one you need.

"Side-by-side" configuration would help too, but I don't think a plugin can
control it, only the main application.

>> Hi Dave,
>>
[quoted text clipped - 41 lines]
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.

Reply to this Message

David Thielen - 08 Nov 2006 17:10 GMT

Can't do that - the Word group at MS says you must not put Word AddIns and
their supporting DLLs in the GAC. (They also say you must not put anything in
word.exe.config. And you cannot have 1 Word AddIn using .NET 1.1 and another
using .NET 2.0. The Word group tends to not follow the .NET standard.)

Is there any other way to do this?

Signature

thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

> >I think that may be it - we have one version in the GAC and a different
> > version in the AddIn directory. How do I get it to look in the AddIn
[quoted text clipped - 54 lines]
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.

Reply to this Message

Ben Voigt - 08 Nov 2006 20:37 GMT

> Can't do that - the Word group at MS says you must not put Word AddIns and
> their supporting DLLs in the GAC. (They also say you must not put anything
> in

Is this documented somewhere?

That restriction equates to forbidding managed addins, because "supporting
DLLs" would include the BCL (System.dll, System.Windows.Forms.dll,
System.Xml.dll, etc.) which are certainly in the GAC.

I would understand that to mean that your addin's entry point should not be
in the GAC, but that it is free to use any number of shared libraries, which
should be in the GAC whether provided by Microsoft, you, or any other party.

> word.exe.config. And you cannot have 1 Word AddIn using .NET 1.1 and
> another
[quoted text clipped - 67 lines]
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.

Reply to this Message

David Thielen - 08 Nov 2006 20:45 GMT

I've asked that group to get an answer. They absolutely don't want the .NET
dll that is the AddIn interface to Word in the GAC. CLearly the system
libraries are in the GAC. So for the libraries used only by us - not sure.

There is definitely a disconnect betwen .NET and the Word AddIn system.

Signature

thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

> > Can't do that - the Word group at MS says you must not put Word AddIns and
> > their supporting DLLs in the GAC. (They also say you must not put anything
[quoted text clipped - 81 lines]
> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.

Reply to this Message

Ben Voigt - 10 Nov 2006 15:50 GMT

> I've asked that group to get an answer. They absolutely don't want the
> .NET
> dll that is the AddIn interface to Word in the GAC. CLearly the system
> libraries are in the GAC. So for the libraries used only by us - not sure.

Word can tell you to put AddIns in a private directory if they like.

Reusable libraries belong in the GAC, regardless of what
application/service/addin/gremlin uses them.

> There is definitely a disconnect betwen .NET and the Word AddIn system.
>
[quoted text clipped - 96 lines]
>> >> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> >> rights.

Reply to this Message

"Peter Huang" [MSFT] - 10 Nov 2006 05:12 GMT

Hi Dave,

Currently we can not control the assembly fusion policy to check the
private path first and then GAC unless we rebuild our own .NET Runtime.

Currently I just wonder why you need to keep multiple versions of addins,
one in GAC and the other in the private path?
Commonly I think once an addin is published, we can just maintain certain
version in the private path, once the addin is upgrade just replace the
existing version with a new one. Such an upgrade is applied.

If you have other concerns, please let me know.

Best regards,

Perter Huang
Microsoft Online Partner Support

Signature

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

Reply to this Message

Big problem with GAC and local

Free Magazines