We have both the Microsoft Exception Management and Data Application
Blocks, along with our own Custom Publisher, in the GAC. The files
include (all strong named):
Microsoft.ApplicationBlocks.Data.dll
Micorosft.ApplicationBlocks.ExceptionManagement.dll
Micorosft.ApplicationBlocks.ExceptionManagement.Interfaces.dll
Our own CustomPublisher.dll
These do access the config file, and they work fine the GAC. I did have
to add the assembly information to the config file. So the
configSection looks like this:
<section name="exceptionManagement"
type="Microsoft.ApplicationBlocks.ExceptionManagement.ExceptionManagerSe
ctionHandler, Microsoft.ApplicationBlocks.ExceptionManagement,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=5a37da41ea4ef235" />
And the exceptionManagement section looks like this:
<exceptionManagement mode="on">
<publisher mode="off"
assembly="Microsoft.ApplicationBlocks.ExceptionManagement,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=5a37da41ea4ef235"
type="Microsoft.ApplicationBlocks.ExceptionManagement.DefaultPublisher"
/>
<publisher mode="on" assembly="CustomPublisher, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=3f902dc01e5f15a6"
type="CustomPublisher.Publish" />
</exceptionManagement>
I had to do this for any item in the GAC that's referenced in the config
file. Also, if you haven't already, you'll want to add references to
the GAC'd assemblies in the machine.config's
system.web\compilation\assemblies section (I think this is only
necessary for .NET 1.0)...
Monsur
> -----Original Message-----
> From: Moderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bassler
> Sent: Wednesday, August 06, 2003 7:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] GAC'd assemblies cannot access
> application .config settings
>
>
> "It looks more to me like the error is related to the MS
> Exception block not being in the GAC or having some other
> error loading the MSEB classes after finding the config
> section in the config file. Could that be the case? I think
> GAC classes can only load assemblies with strong names."
>
> Thanks for the reply!
>
> Judging by the lack of response on this subject it appears
> that most developers are not attempting to use shared
> assemblies as yet.
>
> The 2 MSEB assemblies are installed in the GAC. You are
> correct. Any assembly that you intend to install in the GAC
> MUST be signed. This is .Net's form of versioning. Local
> un-GAC'd assemblies are not versioned.
>
> I'm not sure that I'm right but the error appears to me to be
> showing that when the run-time attempts to create the config
> section handlers it has nothing to load. i.e can't find the
> config file.
>
> As I said previously, the only thing that I'm changing
> between the MSEB functioning properly wrting errors to a
> non-default publisher and then throwing this internal error
> (when GAC'd the MSEB assemblies still successfully use the
> default, non config reliant publisher behavior) is that I
> install the assemblies in the GAC. So I'm not sure what's up
> here. The support docs suggest that you can install these
> assemblies in the GAC. Actually, you really would want to so
> that all your apps could use them to log errors. I hope this
> is not a design flaw. If it is it'll render shared assemblies
> fairly useless as they cannot use the config settings. I
> find no info on this subject anywhere.
>
> I guess I could trace to the point of failure to see if the
> GAC'd assemblies can't find some referenced component as you suggest.
>
> Does anyone have any examples of GAC'd assembly code reading
> a config file successfully?????
>
