I can't edit app.config from with in VS2005 using the GUI I get unable to load assembly...... and the configuration does not start. So I run the external one.

If I run the EntLibConfig from the source directory C:\EntLib3Src\App Blocks\bin, I can load the application config file. I then drill down to the custom error handler and walk through the steps to bring up the Type Selector to change/view the custom Exception
Handler. I then push the "Load an Assembly..." button find the .exe and load the assembly. I see the Custom Error handler.

BUT If I run EntLibConfig from the start menu and do the same thing I get:

"There were no types found in the assembly 'ExceptionHandlingWithLogginQuickStart' that implement or inherit from the base type '......ExceptionHandling.IExceptionHandler'.

If I load the Enterprise library source into VS2005. Choose the console as the start up and run the EntLibConfig in debug mode. I get the above error. But when walking through the code this is where I'm puzzled. I have not been able to get a debug session to
return back a possitive so during this line of code I don't know what the expected results should be and how they are derived. I get the concept is the object derived from this object. Looking at the code I would say true: public class AppMessageExceptionHandler
: IExceptionHandler

The test in the code then should return TRUE but return FALSE is this:
TypeSelector.cs line 162

valid = baseType_.IsAssignableFrom(selectedType);

I don't know if it is that or if issue is during the loading of the assembly and if there is a proxy in place instead of the acctual object?

How I came accross this was when I was trying to implement my own using GAX. After filling in the TODO's and stuff then compiled a simple Assembly with just the code produced from GAX and the modified TODO's. After that I built a Unit Test logic for the harness
and for that application I went to Ent Lib Config to use the custom error handler only to get the error above.

I knew this was flaky in 2.0, but is it any better in 3.0? Like not have referenced assemblies in the assemly you want to load the type from? If this is still an issue will this be address as a patch or something? It seams like very little has change and no
improvements in this area from 2.0. I know plug-ins, and loading external assemblies is a pain. With Orcas or something else MS is to come up with a plugin/addon name space to help with reflections and loading external assemblies (CLR Inside Out Feb/March
2007). Will this be address then if not now?

Sorry about the confusion. The issue here is that in EntLib v3 you essentially get two copies of EntLib - one signed (precompiled binaries) and one unsigned (that you compile from the source). Despite the fact that the code is identical in the two versions,
they are completely incompatible with one another as far as the type system is concerned, since the public keys differ. If you use the config tool from the strong-named version then the tool will write the public key to the files and will look for the strong-named
version of any assemblies it cares about (such as when using the type selector). However if you use the copy of the tool you compile from the source code, it will expect non-strong-named assemblies. The errors you are seeing are likely due to a mismatch between
the tool and the extension assemblies or config files with the wrong public key.

BTW when using the Visual Studio-integrated config editor, you also get the choice to use strong-named or non-strong-named assemblies. By default the tool will use the strong-named versions, but on each solution you can point it to the unsigned (or any other
set of) assemblies by setting the EnterpriseLibraryConfigurationSet property after selecting the root selection node.

FWIW we did try hard to make the config tool less flaky in v3 by ensuring it didn't need to load the assemblies for any custom providers every time you open a config file.

Yes, that is where I thought this might be going. But is that with trying to load an assembly in the Type Selector or trying to get the EntLibConfig to work in VS 2005 with or with out strong-named assemblies.

I'm not working with signed assembly, and correct me if I'm wrong but the Source Code when compiled is not signed. So when debugging there are no signed, and also when debugging I can get it to work with some but not others.

I startup a new app config add Exception Handling, add a policy, a custom handler. I load my Custom Exception Handler assembly and get the
"There were no types found in the assembly 'Your assembly here' that implement or inherit from the base type '......ExceptionHandling.IExceptionHandler'.

I load one from Sample Application ExceptionHandlingWithLogginQuickStart and depending on where or how I load it (debugging, start menu, integrated w/vs2005) I may or may not get the error. That is why I thought it might be with strong names.

Also regardless of how to fix it, is there a better way to report the error? Becuase of the incorrect or vague error message sends one on a wild goose chase trying to figure out why the error is telling them they did not Implement IExceptionHandler. When cleary
one has done so Your X does not equal X. Is there more pre qualification and/or refactoring that can be done?

Also, is there a way to do this validation for signed and if the user is using strong-names then validate if the loaded assebly meats the requirerments to be loaded in that version of EntLibConfig. Instead of the user trying to figure out if they are working
with signed or not.

I'll continue, is it strong-naming? is it multiple EntLib assemblies being loaded when they are already loaded one from EntLibConfig and one when loading the exception handler during the Type Slector dialog box? Is there some proxy object being built that does
not have the real implmentation of the object?

P.S. It is as if there are too many possible issues (flaky), so just assume they did not implement something and then show an error message to that effecct. How many possibilities could there be?

Yes, something with working on the signed versions of EntLibConfig and if you run from within VS 2005. Aslo if you reference sigend or none signed. I think EntLibConfig loads one type signed/none-signed then when loading my assemblie with reference entlib
it was the opposite. I have yet to figure out the matrix as to what works, what does not, how it works, and what combinations. Is it EntLibConfig standa alone? Integrated? Signed? None-Signed? Do you reference signed or none signed? Is your assemblie signd
on not signed?

Then I signed the project
1. Create the key and sign the application
2. Make references to the signed version c:\program files
3. Build
4. Run EntLibConfig with in VS 2005 add exception handling, add policy, add custom handler. Works.
5. Run EntLibConfig from c:\EntLib32src. No Worky

This test prooves your point and builds a basis for testing. Now what I need to do is create two source environments one signed and one none-signed. Do some debugging and mix and match.

But, again why such a bogus error message when cleary the issus is not becuase I did not implement something or add an attribute when cleary they are there? And if there is a know combination issues with signed and none-signed why not show a particular error
message for that along with the option that you pointed out EnterpriseLibraryConfigurationSet?

Why is there not a better intergation of what is going on with better error reporting? Am I the only one running into issues with Type Selector that where so obvioius in version 2.0 and continues over into 3.0? The same type of things existed in 2.0 where too
many posabilities so just report that the interface, class, and/or attribute was not implemented.

I'll be working on this and let you all know if I find anything. I will find which combination don't work, how to detect them and give warnin/error accordingly. To the effects if you are using signed EntLibConfig w/out signed assemblies, etc...

Got it, but all that one needs do is build an application to extend the application block by adding a handler or a formatter. All they want to do is install the binaries only c:\program files. Then all they would need to do is build an Exception Handler
(they could even use GAX). If there project is not sigend then all hell breaks loose when tyring to configure an app.config to use that Handler. Because if they either run stand alone outside of VS2005 "c:\program files\" or with in VS 2005 they will get the
error (using signed EntLibConfig with a none-signed Handler and/or formatter).

All they would need to do is sign thier application and they would be good to go. But what they get is some error message not even relating to a signing issue but one relating to not implementing the interface. Why because the error detection is flaky at best.
This only then sends the programmer on a wild goose chase trying to figure out what the requirements are to implement the Handler. The possiblity of logicaly figuring out the signing matrix is there and nothing is done to help the programmer in the right direction.

Here is some code to test for signed assmblies and to see if there is a mismatch (TypeSelectorUI.cs after line 293

Fair call, we really should have anticipated that this would be a common cause of confusion and provided more detailed error messages as you have done. Thanks for providing the snippet.

BTW even when using a strong-named version of EntLib, it should not be necessary to strong-name any extensions or custom providers. In general if assembly A references assembly B, then either both must be signed, both must be unsigned, or only B can be signed.
This last option is the case where an unsigned block extension references the signed EntLib binaries.

Thank You, I will continue my testing knowing that sandboxing/addons/plugins/refractoring is pain. I have the same issues with application I build and knowing how others do it/or don't helps me as well as them. This is why when I got EntLib 3.0 I went
right to the Type Selector to find improvements if any. I'll be continuing to build a simple guidence/template for an application where low level errors are being logged, but also show the error being rethrown only to be trapped in the above layer. This layer
being the application layer would use a custom handler to show a dialog box and interact with the user. Very simple stuff but shows how to piece together a low level policy, trapp an error and move it up to a higher level policy. This demonstrates how the
two policies handle the same error but differenlty based on which layer is handling the error. One policy (Data Policy) writes an event entry with all the guts of a stack trace, while the other policy (Application Policy) would show a user friendly dialog
box. This is a typical situation one would run into and the most typical reason for writing a custom handler and how to propery use the rethrowing of the error and how it bubles up to the surface.

I'm almost done with a dual source environment one Signed and one None-Signed. Another snippet of code I added was in the About Box. In case I'm communicating with a programmer about what version she/he has because I may not be involved with the install,
but may need to support after an install. I need a way to know if the EntLibConfig they are using is Signed or not and if helpfull show the Public Token. With this one can tell if it is signed and where it came from either inhouse or ms or some hack base on
the public token. There is a crude hex converter included that bloats the code a bit, but the lookup table is there for performance instead of doing a ToString on every byte. These are the required changes to code and the form.

The change on the AboutForm.cs is add a template {signed} in the linkLabel1.text:

*Test F-H, N-P, V-X Coppied just EAB dlls from the EH/EAB folder (signed or none-siged) into the bin folder of C:\program files

Each Test was first done by closing EntLibConfig before going to the Next.
Some tests where done with out closing EntLibConfig to see what effects of chaching and how that skews the test base on the path on chooses to load. That results into this:

If you load Test E then test D then D will work. Refernced libraries in EH/EB column are loaded during E and D does not reload them using the same from E working ones.
If you load Test D then test E then E will NOT work. Refernced libraries in EH/EAB column are loaded during D and E does not reload them using the same from D none working ones.

The only thing I see is where the code above does not check the referenced libraries by the project to see if they are signed, as we can see some combination still shows the vague message of not being implemented.

I just got these out of the oven and my head is spinning from watching it cook.

I wanted to post my results, but I'm still going through them.

You will noticed I broke out the dll into two areas (EH/EB and EB) the ones in the BIN folder of entlibconfig and the dlls in the refernces project therefore there can be two versions of EB, one that is loaded with EntLibConfig and the other is in the project
bin folder.

Clears as mud?

So not only is there a mix and match issue there is also the perception that it works based on the order of loading assemblies. I could one day load A then B, but the next day load B only to find out that this time it does not work, etc... Then to get the vague
message and figure out why it worked one day but not the next, why it is asking to implement something I alread did.

Yes, the confusing part is the referenced assemblies where one could refernce from folder A and then use tools from B. This is what I believe was going on in 2.0, because we signed the assemblie in-house but other programmers where referncing the binaries
from a download 2.0. Then they would run the in-house entlibconfig tool but not be able to load the handler becuase it referenced entlib with a different identity (downloaded). As you can see from my first prototype matrix it did not work becuase the programmers
project column is a matrix in of itself. Base on the identity of the programmers assemblie and the indentity of the entlib that is refernces. Is the assembly signed with none sigend references, none-singed w/singned, signed w/signed, etc..

But I still think the real issue is that the Type Selector/EntLibConfig does not do a good job of validating the assembly being loaded, comparing against the cache, etc.. and wether the identity of the assembly being loaded and all of it's referenced assemblies
are correct (w or w/out a strong-names). I did not leave out an identity test w/out strong names, so yes indirectly I was testing the idetntities of an assembly regardless of it has a strong name (sgined) or not.

There is an issue with validating, I have seen more and more posts on the forumn, the issue was also part of 2.0, and looking at lengthy blog explaining about. The assemblie identity validation is not in the EntLibConfig tool, but is left up to the one implementing
ABs in EntLib therefore making it a house of cards. And having no indication as to if you built your house of cards correctly. If you did not build correctly and there is a mix and match you get an error message to the effect of "You did not Implement the
code correctly by not extending XYZ or having atribute ABC."

Here are my arguments for make some improvement, please........

It is like the internet, full of rich contenct like movies, music, news, forumns, provided by the people using tools provided by vendors. But if my router, dns, isp, or some trival piece is flaky and the experience is not good what good is all that rich content?
And what if you got an error message saying "You can't connect"? With just a bit more knowledge you know damn well it was the router and if the system was smart enough it would tell ya. So, if the Application Blocks and extending them with my own Handlers,
Listeners, Validators is like the internet, and the TypeSelector is like my router or dns, the gateway to my content, then what good is EntLib and AB if when I go to get my content a vague error message pops up about my content not being correct? I can accept
the fact that it is wrong but I need more concrete error reproting to fix it. Based on my matrix I see that there are more configurations that can cause problems 12 out 15 that is 80% chase of something going wrong, but with a error message not telling them
the right thing. I know that you can't fix the 12 things but one could do a better job of validating and reporting the error. The user can take a path with confusing results, I loaded A then B one day then B the next day and it did not work. I would just hate
for people to not use ABs becuase of something as trival as the Type Selector not being robust. I know I stopped using dial up because of the bad experience. And as we can see just a add a bit of code above helps with one area of the matrix so it can't be
to difficult. The only challanging one is to intergate and validate against the chached pool to fix the "Load A then B one day and B works, next day load B and no worky." or the inverser revers of that where you Load B first and A does not work.

I have a solution, but am unable to implement at this time. The crux of the issue is that even though one get a "Not implemented error" or any other error it is too late and the assembly is loaded into the appdomain. A wrong assemblie is loaded into the
current appdomain with out being validated. Once that happens then the assembly cann't be unloaded. Then when you load another assembly with a good library it is too late, the referenced library is already loaded into the appdomain, but is bad and then causes
error.

My idea of a solution would be to first load the assembly (w/referenced assemblies) into a seperate AppDomain. Then compare all assembly identities in the TestDomain with the ones in the CurrentAppDomain. If there is a mismatch then don't load otherwise load
into CurrentAppDomain.

Of course this is where it all breaks down and I can see why this is not there and like others have asked, and one can see it coming is the Add-In namespace. Or something in regards to making reflections more usable than low level disconnected pieces like AppDomains,
Assemble, ShadowCopy, Proxy Object, Real Object, etc...

I will have a solution but I don't think it will be a snippet of code. I'm going to use code I have that does similar stuff with a Plug-In application. I will post it somewhere else and let you all know if you want it.

During testing I further proved the code above does help a little bit, some the issues take two steps to cause a problem, and having that code in place prevents one from taking the first step. Preventing them from taking that step, then step two can't be executed
which will then eliminate the Load A then B type issues.

Turns out to be a simple thing once I got the assembly to be loaded inside another AppDomain.

To start I needed to convert the local variables into fields and then add a new one for to hold the assemble for testing before loading into the AppDomain of the config tool.

Again knowing we can't fix the issue we can show a message showing the mismatch. From this one is better informed and knows now that it is an environment error with assemblies and not because of the lack of implementing something. Also because all this is done
in another app domain the assembly is not loaded into the primrary appdomain, no need to remove it if it was never added.

This also includes the code from before where we do the assembly test before checking referenced assmblies.

There are two help methods one is to load the assembly into the new AppDomain and to assign the assembly to the new field tempAssemblyForIdentityTesting. The second method is used to check the referenced assemblies in the tempAssemblyForIdentityTesting against
the assemblies already loaded in the primary AppDomain.

I'm testing this as I post tred little, but I think one could get the jist from these post that it can be done, but will it be done? Will there be improvements such as these in the tool other than "Not Implemented"?