How do I add a custom type?

Topics: Validation Application Block
Aug 22, 2008 at 1:47 PM

I'm trying out VAB and I can't figure out how to add a custom type to add validation to. I have created a class library with one class:

    public class Customer
        public string Name { get; set; }

I go to my other project and in my config-file I right click the Validation Application Block node and choose Type. My project is not in the Type Selector - System.Object dialog so i choose Load an Assembly, browse to my ValidationTest.dll containing the Customer class and adds it. The error message i get is:

No Types Found In Assembly.
There were no types found in the assembly 'ValidationTest' that implement or inherit from the base type 'System.Object'.

I guess I'm missing something banal...
Aug 22, 2008 at 3:47 PM

Does your ValidationTest.dll assembly contain public types?

Aug 25, 2008 at 10:48 AM
Edited Aug 25, 2008 at 10:49 AM
Yes, only public types.

I found out that if I add the assembly to the GAC it works, and the assembly is shown in the Type Selector - System.Object dialog. Do I have to add every assembly I want to use with VAB in the GAC (to be able to use the Entlib configuration tool)?
Aug 25, 2008 at 1:37 PM

No, adding the assembly to the GAC is not necessary.

I tried to repro this and could not get the failure you're getting. Please try the following and post your results: create a new "Class Library" project with Visual Studio, build it as it is and try to load the new assembly in the type picker; this simple repro works for me, showing the node for ClassLibrary1.Class1 in the tree view.

Btw, which version of EntLib are you using?

Aug 25, 2008 at 2:08 PM
It works! :) Don't know what's wrong with my ValidationTest project. I removed the project, created a new one and moved my old classes to the new one and it worked! Thank you for your help!  (I'm using EntLib 4.0)

Aug 25, 2008 at 3:06 PM
Hi Lina,

That's weird; I'd like to take a look at your original project's binary, if you still have it and can share it.

Aug 25, 2008 at 3:35 PM
I deleted my old project but i figured out how to recreate it.

  1. Create a new Class Library
  2. Go in to Class1.cs and delete public 
  3. Save and build
  4. Add an App.config
  5. Add the VAB in App.config
  6. Add the Class Library you created by loading the assembly in the type picker 
  7. Watch it fail 
  8. Go to Class1.cs and add the public 
  9. Rebuild the project 
  10. Try to add the Class Library again in the type picker 
  11. It will fail again and forever(?)

Aug 25, 2008 at 4:03 PM
I see. You're probably using the tool integrated to Visual Studio, and the problem with that is once you have loaded an assembly you can no longer load a new version of it until you restart Visual Studio (please try that). That's the way the .NET framework woks (you cannot unload an assembly) and the same happens with the stand-alone tool, but with the stand-alone tool you can easily start a new copy which is not as inconvenient as restarting Visual Studio itself.

Aug 25, 2008 at 9:34 PM

I also had this issue and noticed that you state that "you cannot unload an assembly".  Actually, this is not true.  I've created several applications using a hot-pluggable system.  If you care to look into it, I can send you my sample code when I get home tonight.  It derives from (enhances) this article:

There are several articles stating a hot-pluggable solution; but that article is the one I know for a fact works.  The aforementioned code I've created allows for generics too.

Aug 26, 2008 at 2:37 AM

I'm afraid my statement wasn't as precise as it could have been. You cannot unload an individual assembly from an AppDomain without unloading the entire AppDomain (you can look at the details at and, and even more attempting to load from a dll file corresponding to an assembly with an identity matching an already loaded assembly will return the existing assembly even if the files are different (details again available from Suzanne Cook at The configuration tool works looks for types in the assemblies loaded in the tool's AppDomain, and loading an assembly literally loads it to this AppDomain. When the tool runs inside Visual Studio, the tool's AppDomain is really Visual Studio's root AppDomain, which the tool doesn't own and cannot unload, so there is no way for the tool to see a new version; even if you try to load it again the CLR will keep returning the version that was loaded the first time. An implementation that relied on separate AppDomains to load types could alleviate some (but not all) of the assembly-load-related problems, but the tool is just not implemented this way.