Issue with CustomTraceListner EntLib 3.0

Topics: Building and extending application blocks, Logging Application Block
Apr 19, 2007 at 3:58 PM
I'm trying to create a debug trace listener. So i followed the Quick start example for custom trace listeners. Every time i try to import my assembly i get an error message that my assembly does not inherit or implement the ENTLIB customtracelistner.

I created a separate assembly that has the debug class. The class is a cut and paste from the quickstart. I have referenced common and logging entlibs.

In my main app i setup the configuration file and when i add the custom trace entry and load my assembly i receive the error. I have followed the walk through to the t. I still don't see or know whats missing. Any help would be appreciated.

Thanks
sal
Apr 19, 2007 at 5:38 PM
Hi Sal -

Are you sure you are referencing the same copy of the EntLib assemblies (Logging, Common, ObjectBuilder) that are used by the copy of the tool you are using? If the copies do not match (eg one is strong-named and the other not) than you may get these kinds of errors.

Tom
Apr 19, 2007 at 7:06 PM
Tom,

I must be missing something. I hace installed the source and ran the bat files: BuildAndCopyAssemblies and then i ran RegAssemblies. But when i go to add a refernce in my project i only see the assemblies located at C:\Program Files\Microsoft Enterprise Library 3.0 - April 2007\Bin. How can i unreg theese and reg the ones located in my src bin directory.

Sal
Apr 19, 2007 at 7:17 PM
The first tab of the References dialog lists assemblies in whatever paths Visual Studio has defined in the registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx. The EntLib installer automatically adds an entry for the strong-named assemblies at C:\Program Files\Microsoft Enterprise Library 3.0 - April 2007\Bin. If you want to reference non-strong-named assemblies, you can either browse to them directly, or you could modify the registry keys if you want them to show up in the first tab.

Tom
Apr 19, 2007 at 8:22 PM
Since quite a few people are having problems caused by mismatched copies of Enterprise Library assemblies, I just wrote up a detailed description of common problems and solutions at http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx

Tom
Apr 19, 2007 at 8:32 PM
Edited Apr 19, 2007 at 8:35 PM
Tom, could this be related to what I was talking about and the Type Selector not having the ability to determine if the user is running the Signed or None-Signed EntLibConfig?
http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=9240
As we can see he got the "Not Implemented" error and is now on the wild goose chase, when it is not that but having to do with strong named assemblies.

This was my point where 99.9% of the time the assemblies from VS2005 will not be sigend. Then the programmer uses EntLibConfig from with in VS2005 which is the signed version of EntLibConfig? Can't have signed and unsigned version? Tom, I noticed in your videos you did not have this issue? Was the version used in videos sigend even though I see you go to c:\program files to make references the sigend ones. But your project was not sigend, and yet you could get in to EntLibConfig with out a problem?

Sal, as a suggestion sign you projects, you can even use a GAX to do it. In the trace listener project right mouse click "Create a new Strong-Name key pair file", then right mouse click and choose "Sign Project" or the solution. It is not only an issue of referencing signed assemblies but may also be an issue of using the signed version of EntLibConfig. Did you install the source code and build that?

Tom, is both a signed and none-sigend installed in c:\program files\ and install if you do not choose to install source code. Or is the none-sigend in C:\EntLib3Src and only installed with source.

Bottom line and will be the push/default in the future is to build strong named assemblies (signed). Signed Everything.

-guy

P.S. Tom, the about box with the logic to show if the asseblie is strong-named would help with trouble shooting this. Along with the pop up message instead of not implemented.
Apr 19, 2007 at 8:52 PM
Thanks Guy.


y2k4life wrote:
Tom, could this be related to what I was talking about and the Type Selector not having the ability to determine if the user is running the Signed or None-Signed EntLibConfig?


Yes it's all related - I hope by blog post clears up some of the confusion. I agree with your suggestion to improve the error messages for common situations, but that will need to wait until a future release.


Tom, I noticed in your videos you did not have this issue? Was the version used in videos sigend even though I see you go to c:\program files to make references the sigend ones. But your project was not sigend, and yet you could get in to EntLibConfig with out a problem?


Yes I was using the signed DLLs in the videos. The Application Block Software Factory added the references by default.


Tom, is both a signed and none-sigend installed in c:\program files\ and install if you do not choose to install source code. Or is the none-sigend in C:\EntLib3Src and only installed with source.


If you don't choose to install the source code, you'll only get the signed binaries. We don't ship any unsigned binaries, but of course you get unsigned binaries if you compile the included source code.


Bottom line and will be the push/default in the future is to build strong named assemblies (signed). Signed Everything.


Agree that signing everything is generally the best option, however the problems people have been having can also occur if you mix up 2 different copies of EntLib that are strong-named with different keys, so this won't solve all of the issues. The sample code you shared won't help in this situation either (although I agree it would still be worth implementing).

Tom
Apr 19, 2007 at 10:00 PM
Edited Apr 19, 2007 at 10:03 PM
How does one mix up EntLib with two different keys? Are you saying that people will copy the entlib assemblies from there project that have a different key into the bin folder for EntLib. Now when EntLibConfig loads it loads with two different keys?

Or does this happen when I load my assembly into Type Selector and that then loads my referenced assemblies that are EntLib but with a different key?

I'm building a use case (based on your grid) and narrowing this down based on making an exception handler. If the EntLib was signed by MS the programmer, not sigend, was the Handler signed, is the EB (Excption Block) sigend and by who? I don't have the results but here it the control table I'm using if you think if a combo that is not here let me know. I post the results later.


EB EntLibConfig EH Results
Not Signed MS Signed MS Signed
Not Signed MS Signed Programmer Signed
Not Signed Programmer Signed Programmer Signed
Not Signed Programmer Signed MS Signed
Company Signed MS Signed MS Signed
Company Signed MS Signed Programmer Signed
Company Signed Programmer Signed MS Signed
Company Signed Programmer Signed Programmer Signed

EB = Exception Block
EH = Custom Exception Handler Written by Programmer
MS Signed = Is the stong-named assemblies from Microsoft (c:\program files\).
Programmer Signed = Is the stong-named assemblies from programmer (C:\EntLib3Src\Signed App Blocks).
Not Signed = None stong-named assemblies from the programmer in the (C:\EntLib3Src\App Blocks).

From this I'm hoping my to build a form to show which the loaded assemblies and the public key token and do a comparison.

But on a completely seperate note, I noticed in the videos that it looks like GAX/GAT has a similar Type Selector. During the GAX for building a designer one is asked which node to attache to, or what is the base class? That brings up a Type Selector, which is better and if one is better than the other is there a possability of the GAX/GAT team sharing that code ;)? If anything other than it looked prettier?

Apr 19, 2007 at 10:03 PM
Tom & Guy,

Thanks for your help. After reading Tom's blog, i set the solution value to EntSrc3Lib, deleted my current config file and recreated it. Then i recompiled my debug assembly, i was finally able to import my custom trace listener.

One point that has confused me, was in the QuickStarts, there is no mention of the different versions or that you could change the VS addin to point to a different config editor tool.

Thanks
Sal
Aug 8, 2008 at 3:30 AM
Hi Guys,
             Just an update on this with EL 4.0. I wanted to use the source code but not all projects are included in the source solution, once you add the extra ones you want, (I wanted the Azman dlls) I managed to get to the source code versions to work. I also removed the PublicKeyToken(s) for the EL in all my config settings. Now I can debug into the EL source code and I can extend/bug fix it, AWESOME.

<

 

section name="securityConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Security.Configuration.SecuritySettings, Microsoft.Practices.EnterpriseLibrary.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null" />

 


Regards,
              Alistair
Aug 8, 2008 at 4:57 PM
Hi Alistair,

Keep in mind that you don't need to build the source code to debug EntLib. You can grab the PDB files from http://www.codeplex.com/entlib/Release/ProjectReleases.aspx?ReleaseId=13498, extract the source code on a local folder, run your app built with the signed binaries and point the debugger to your local copy of the files when prompted. Of course, you do need to build your own binaries if you need a change.

Regards,
Fernando