Custom TypeProvider not working

May 25, 2011 at 1:53 PM


i'm trying to change the default TypeProvider used by CCA with a custom one build upon Ninject.
I've changed the app.config section called Microsoft.Uii/Uii.TypeProviders, adding my custom Type Provider that implements both ITypeResolver, ITypeLoader and ITypeActivator interfaces.
The implementation of the methods inherited from the interfaces is the same that can be found into the Microsoft.Uii.Common.TypeProvider.DefaultTypeProvider class (thanks to Reflector).

This is an example of my configuration file:

<Uii.TypeProviders defaultProvider="ninject">
<add name="default" type="Microsoft.Uii.Common.TypeProvider.DefaultTypeProvider, Microsoft.Uii.Common.TypeProvider" />
<add name="ninject" type="MyDll.NinjectTypeProvider, MyDll" />

When i try to start AgentDesktop, i get a StackOverflowException (due to an infinite loop into the Microsoft.Uii.Common.TypeProvider.TypeProviderCache class).

How can I work around this? Has someone experienced my same problem?
Did someone ever tested that feature before the UII library release?!


May 25, 2011 at 4:44 PM

What are you trying to do?
As for if that component is tested, it is. However it’s not intended to be user overridden.


May 25, 2011 at 5:03 PM

I'm extending the features of CCA to match the requirements expressed by one of our customers. One of the improvements requires, if possible, the usage of a custom Inversion of Control container instead of the custom TypeProvider used by CCA.

I've found that configuration section into the app.config of CCA, so i thought that I could change the default type provider used by CCA... if it’s not intended to be user overridden, why does it stands into the CCA config file, with a comment that clearly tells that you can?! This is what i've found into the default CCA config file:

<Uii.TypeProviders defaultProvider="default">
        <add name="default" type="Microsoft.Uii.Common.TypeProvider.DefaultTypeProvider, Microsoft.Uii.Common.TypeProvider" />
        <!-- distinct types can be specified for ITypeResolver, ITypeLoader, and ITypeActivator if necessary -->
        <!-- the type="" attribute represents a convenience fallback value when the others have not been specified -->
        <!-- <add name="default" typeResolver="" typeLoader="" typeActivator="" /> -->

 I was able to figure out the reason of the StackOverflowException: it happens when the Microsoft.Uii.Common.TypeProvider.TypeProviderCache class tries to add, into it's inner cache, an instance different from the default one (statically set into the inner cache in the constructor of the class).

So the issue remains... how can i work around this? 

May 25, 2011 at 5:33 PM

I see, however what you are trying to do is not a supported modification of UII. As you have noticed, the system does not tolerate something other than the default provider. I will ask why the comment is still there, and that it be removed.

What exactly is the requirement you are trying to accomplish?
UII already provides loose coupling of components and a means to organize and work with them.

It very likely that you can do it another way in UII already



May 25, 2011 at 6:01 PM

It's very strange that it should not be modified... the whole Microsoft.Uii.Common.TypeProvider dll seems to be built to be a kind of Inversion of Control container.
If you cannot really modify that behavior (and, as i could see browsing the source code of that dll with Reflector), many classes of that DLL are actually useless. Indeed, the whole dll becomes useless, is just over-engineering.

What i see in reflector is it seems that whole infrastructure (the Microsoft.Uii.Common.TypeProvider.dll) was made just for that purpose... i'm sad that i cannot use an useful extension point just because of a simple bug in a single class. :(

Is there a way to signal this bug to the Uii team? Can i expect that bug to be fixed?


May 25, 2011 at 7:24 PM
Edited May 25, 2011 at 7:25 PM

UII itself is designed around those concepts, which we generally refer to as application composition.
That part of the system is a component of the low level UII functionally that supports that.

I did check with the development team mangement on this to make sure, it is not a bug , it is intentionally done that way.

I will pass your feedback along, however its highly unlikely that will ever change, as allowing 3ed party overrides of that area of the system would create a unsupportable environment.


May 26, 2011 at 12:24 PM

However, if you're interested, i can post the solution to the bug.
That solution has no impacts on the Uii infrastructure... the only effect is to effectively allow an useful extension point.

To fix the bug, you need to just modify the code of the SetDefaultProvider method of the TypeProviderCache class in the following way:

public static void SetDefaultTypeProvider(ConfiguredType defaultTypeProvider)
    var type1 = GetType(defaultTypeProvider.TypeResolver, _defaultResolverType);
    var type2 = GetType(defaultTypeProvider.TypeLoader, _defaultLoaderType);
    var type3 = GetType( defaultTypeProvider.TypeActivator, _defaultActivatorType );

    CreateOrGetProviderInstance<ITypeResolver>( type1 );
    CreateOrGetProviderInstance<ITypeLoader>( type2 );
    CreateOrGetProviderInstance<ITypeActivator>( type3 );

    _defaultResolverType = type1;
    _defaultLoaderType = type2;
    _defaultActivatorType = type3;

i tested it, but i cannot use it because of the signature of the original DLL (my custom Microsoft.Uii.Common.TypeProvider.dll has a different publicKeyToken, and it's not recognized as a valid reference by other Microsoft.Uii dlls).
Hope that someone will update, sooner or later, the Microsoft.Uii source code with this fix... 

"its highly unlikely that will ever change, as allowing 3ed party overrides of that area of the system would create a unsupportable environment." --> i still cannot figure out why there are many classes which the only purpose is to allow the configuration of that part, if the configuration of that part is not allowed.