"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?????
