Hi,

I've a WCF application which works fine. Today I've created a nunit test and got the error below when executing the code. This *only *happen when running the code in a unit test. When the code run via WCF it works fine. I do NOT use injection mechanism at all, so it's strange. The code fail on a IIdentity component. I've found several subject that have the same problem (i.e. https://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=15411&HighLight=1) but didn't find any solution.

GetNextActorsForTemplateEntityTest_T1 has failed: System.TypeInitializationException : The type initializer for 'SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton' threw an exception. ----> System.Runtime.Serialization.SerializationException : Type is not resolved for member 'DF.MyApp.Authentication.CompanyIdentity,DF.MyApp.Authentication, Version=2.0.0.0, Culture=neutral, PublicKeyToken=1eb1c673988515c1'. c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\Core\EntityCore.cs(1429, 0) : SD.LLBLGen.Pro.ORMSupportClasses.EntityCore`1.PerformDependencyInjection() d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(1178, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity.InitClassMembers() d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(1409, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity.InitClassEmpty(IValidator validator, IEntityFields2 fields) d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(148, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity..ctor(IEntityFields2 fields) d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\FactoryClasses\EntityFactories.cs(852, 0) : DF.MyApp.Datalayer.FactoryClasses.DfUserEntityFactory.Create(IEntityFields2 fields) c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\Core\EntityFactoryCore.cs(284, 0) : SD.LLBLGen.Pro.ORMSupportClasses.EntityFactoryCore2.Create() c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\FastSerialization\EntityFactoryCache2.cs(109, 0) : SD.LLBLGen.Pro.ORMSupportClasses.EntityFactoryCache2.GetEntityFactory(IEntityFactory2 factory) c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\FastSerialization\EntityFactoryCache2.cs(137, 0) : SD.LLBLGen.Pro.ORMSupportClasses.EntityFactoryCache2.GetEntityFactory(Type factoryType) d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(1018, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity.CreateEntityFactory() c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\AdapterSpecific\EntityBase2.cs(221, 0) : SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.CreateFields() d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(1407, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity.InitClassEmpty(IValidator validator, IEntityFields2 fields) d:\Project\trunk\MyApp\DF.MyApp.Datalayer\DatabaseGeneric\EntityClasses\DfUserEntity.cs(140, 0) : DF.MyApp.Datalayer.EntityClasses.DfUserEntity..ctor() d:\Project\trunk\MyApp\DF.MyApp.Tools\MailConvert.cs(324, 0) : DF.MyApp.Tools.MailConvert.Convert(UserData userData) d:\Project\trunk\MyApp\DF.MyApp.TestCenter\TestDataFactory.cs(275, 0) : DF.MyApp.TestCenter.TestDataFactory.GetMockForUserService() d:\Project\trunk\MyApp\DF.MyApp.TestCenter\TestDataFactory.cs(570, 0) : DF.MyApp.TestCenter.TestDataFactory.GetUserService() d:\Project\trunk\MyApp\DF.MyApp.TestCenter\Services\MailServiceTest.cs(2123, 0) : DF.MyApp.TestCenter.Services.MailServiceTest.getServiceForNextActorsTest() d:\Project\trunk\MyApp\DF.MyApp.TestCenter\Services\MailServiceTest.cs(408, 0) : DF.MyApp.TestCenter.Services.MailServiceTest.GetNextActorsForTemplateEntityTest_T1() c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\DependencyInjection\DependencyInjectionInfoProvider.cs(274, 0) : SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProvider.Init() c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\DependencyInjection\DependencyInjectionInfoProvider.cs(122, 0) : SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProvider..ctor() c:\Myprojects\VS.NET Projects\LLBLGen Pro v3.5\Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\DependencyInjection\DependencyInjectionInfoProvider.cs(54, 0) : SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton..cctor()

Passed: 0, Failed: 1, Ignored: 0 Duration : 1,18218362090722

The problem happen only if I use a Setup method for my nunit test :

        [SetUp]
        public void Setup()
        {
            Thread.CurrentPrincipal = new GenericPrincipal(
                new CompanyIdentity("nunit","DB", this.User, this.Company, true, true, null),
                new string[]{Role.Admin}
            );
        }

I've tried to disable NUnit Shadow Copy but it still fail. Using procmon, I see it's search the dll in the correct directory and found it. But then, later, it search again for this dll in the nunit's directory, and of course it doesn't find it. Then it search with same name and ".exe" extension, but still in the nunit directory.

I don't understand why the autodiscovery is used ? And why it trigger an error ?

Thank you for any help

Which LLBLGen Pro runtime library version are you using?

SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll is version 3.5.12.601

Could you show us your .config? Just to make sure there is nothing for DI in there that is triggering the auto-discovery.

I've searched on the keyword "autoDependencyInjectionDiscovery" in the whole solution without success. I never used auto-discovery

Here is the App.config used by nunit

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="sqlServerCatalogNameOverwrites" type="System.Configuration.NameValueFileSectionHandler, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" restartOnExternalChanges="true" />
  </configSections>
  <sqlServerCatalogNameOverwrites>
    <add key="DF_DB" value="DF_DB" />
  </sqlServerCatalogNameOverwrites>
  <connectionStrings>
    <add name="Main" connectionString="Initial Catalog=DF_DB;Data Source=(local);Integrated Security=SSPI;"/>
  </connectionStrings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

I also tested with an almost empty config file (db connection is only needed for a few specific tests)

<?xml version="1.0"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

But same problem [

I guess this was set in the NUnit's config file. Please check these posts: http://danintouch.blogspot.com/2007/10/nunit-configuration-woes.html http://stack247.wordpress.com/2011/03/02/nunit-error-the-type-initializer-for-threw-an-exception-and-app-config/

I tried all suggestions proposed in these 2 posts: - Config in the same directory and same name than .nunit project file - Config DF.MyTests.dll.config in the same directory than my DF.MyTests.dll (VS already copy App.config there)

I even tried to manually copy my config content in the C:\Program Files (x86)\NUnit 2.6.2\bin\nunit.exe.config, but I still have the same error...

Could you please post a repro solution that we can test on NUnit? Alslo provide the NUnit version used.

I'll try but it'll be hard and take some time because I need - A db (northwind) - Generate de code - create a custom IIdentity - wire all together and create a nunit Chances that this repro will be very different from the original

You don't have any code source I could use in debug ?

Fab wrote:

I'll try but it'll be hard and take some time because I need - A db (northwind) - Generate de code - create a custom IIdentity - wire all together and create a nunit Chances that this repro will be very different from the original

You don't have any code source I could use in debug ?

Yes the full sourcecode of the runtimes is available in the customer area -> downloads menu -> v3.5 -> extra's section.

What I wonder is: 'DF.MyApp.Authentication.CompanyIdentity,DF.MyApp.Authentication', is that used somewhere in your tests? We have a feature called Dependency Injection scopes, which are objects which you can use in your code to specify injection types for an area of your code. Perhaps the problem lies there? (i.e. you start a scope in the Test fixture setup?)

I'll try to debug

I don't use DI at all for llblgen (my app use Castle windsor for this) as I never put the config file. As I use the subclasses template, I simply override the CreateValidator to use my custom validators.

I indeed use the CompanyIdentity, it's used in the nunit Setup method:

   [SetUp]
        public void Setup()
        {
            Thread.CurrentPrincipal = new GenericPrincipal(
                new CompanyIdentity("nunit","DB", this.User, this.Company, true, true, null),
                new string[]{Role.Admin}
            );
        }

If I put these line in comment, I don't have the error any more. The CompanyIdentity is in a separate dll, but I've checked that this dll is in the same directory than the nunit dll ProcMon show that this separate dll is correctly loaded once, but then it search again for this dll but this time in the nunit.exe directory (and indeed it doesn't find it)

I've upgraded to the latest llblgen version and downloaded the source code (so that I'm sure both match).

But I've some problem to debug using the source code - If I open the source code solution and attach to my app, it say no symbols have been loaded. My app is in debug and pdb are there. I even tried to config the debug to add a symbol path to the directory where are stored latests llblgen files (dll+pdb) - If I build the code source solution (I've to remove all signed stuff to make it compile) and then my app doesn't recognize the dll (I suppose the PublicToken is modified) and I can't build my app anymore.

Do you have any tip for me ? Thank you

I finally succeed to use source code in debug

The exception is thrown on this line

Frameworks\LLBLGen Pro\RuntimeLibraries\ORMSupportClasses\DependencyInjection\DependencyInjectionInfoProvider.cs:278

        // we now need to see if there are assemblies defined in the config or in the discovery information in memory. 
        // If so, traverse these as well for instance types, and add these types to the list we already have. 
        DependencyInjectionConfigInformation diInfoFromConfig;
        if(DependencyInjectionDiscoveryInformation.ConfigInformation != null)
        {
            diInfoFromConfig = DependencyInjectionDiscoveryInformation.ConfigInformation;
        }
        else
        {
            **diInfoFromConfig = (DependencyInjectionConfigInformation)ConfigurationManager.GetSection("dependencyInjectionInformation");**
        }

I've found a post on msdn describing exactly the same problem: http://social.msdn.microsoft.com/Forums/da-DK/vsunittest/thread/b73fea8f-2071-4cf5-b23c-a790dc7b4f07

This is not a llblgen problem (but if you have any idea on how to fix it ... because I didn't find anything on google yet)

Thank you for the support.

Did you try some of these suggestions? http://stackoverflow.com/questions/7539557/type-cant-be-resolve-in-unittest-after-migrating-project-from-vs2005-to-vs2010 http://finite.mikeandcorinne.com/2010/03/c-type-is-not-resolved-for-member-serializationexception-in-connection-get_localip-resolved/

No I didn't find this post in my search (but I was focusing on a VS2012/ .NET installation problem as said on msdn)

And indeed IT WORKS !

Inheriting my custom IIdentity from MarshalByRefObject fix the problem, but I don't know why it's needed ! Maybe as NUnit is loading stuff in another domain, the custom IIdentity must be marshalable

Thank you for your help !

It indeed loads it into a different appdomain, though I never had any problems with this in our own tests (we use nunit as well).

But I'm glad the issue is finally solved!