llblgen 2.6 C# asp.net .net 3.5

Error:

The type initializer for 'SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton' threw an exception. System.TypeInitializationException: The type initializer for 'SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Quartz, Version=1.0.2.3, Culture=neutral, PublicKeyToken=f6b8c98a402cc8a4' or one of its dependencies. The system cannot find the file specified. at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes) at System.Reflection.RuntimeAssembly.GetExportedTypes() at SD.LLBLGen.Pro.ORMSupportClasses.TypeDiscoverer.GatherInstanceTypes(MultiValueHashtable`2 instanceTypes, Assembly toExamine) at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProvider.Init() at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProvider..ctor() at SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionInfoProviderSingleton..cctor() --- End of inner exception stack trace ---

I have a new website on a new server and decided to reference an assembly from another server/website. This assembly has several types decorated with llblgen's dependency injection properties. The assembly works fine in the original website, but on the new website, it returned the above error.

Note that the above error is due to not being able to find a "Quartz.dll" assembly which, while its members are referenced in my assembly, the Quartz assembly does not have any DI decorators and is a 3rd party dll. (The Quartz assembly members are used in a separate part of my assembly, unrelated to the how the new server will use my assembly)

The solution is to add the Quartz.dll to the GAC of the new server, but this reduces my assembly's portability and in general doesn't seem to make sense why llblgen reflector would need access to that dll. To add to my confusion, my assembly references several other 3rd party dlls (like Telerik) in addition to Quartz which are not on my new server, but only the absence of the Quartz.dll throws the error.

For reference, the following is my web.config settings:

<configuration>
    <configSections>
        <section name="dependencyInjectionInformation" type="SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionSectionHandler, SD.LLBLGen.Pro.ORMSupportClasses.NET20, Version=2.6.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27" />
    </configSections>
    <dependencyInjectionInformation>
    <additionalAssemblies>
      <assembly fullName="MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1c575b3f6954807b"  />
    </additionalAssemblies>
  </dependencyInjectionInformation>

    <appSettings>
        <add key="markSavedEntitiesAsFetched" value="true" />
        <add key="ConnectionString" value="my connection string" />
        <add key="autoDependencyInjectionDiscovery" value="false"/>
    </appSettings>
</configuration>

Again, I have a workaround by manually adding the unrelated dll to the new server's GAC, but this really bugs me and I'd be interested in finding out why this might be happening if anyone has some clue. Thanks!

You set autoDependencyInjectionDiscovery to false, so I should eliminate the possibility of an auto discovery trying to reach your 3rd party dll.

Did you set DependencyInjectionDiscoveryInformation.PerformAutoDiscoveryDependencyInjectionInformation to true somewhere in your code?

And, Why is that the error didn't happen in the old website? Did you register your 3rd party dll in the GAC in your old server?

Hi daelmo, thanks for the reply! I do not have DependencyInjectionDiscoveryInformation.PerformAutoDiscoveryDependencyInjectionInformation set anywhere in my code. Regarding why the error does not occur on my old website, that's b/c it had Quartz.dll registered in the GAC. For the new server, I hadn't bothered registering it at first since the part of the assembly I was using didn't need to use that. After all, quartz is a scheduling service that can run jobs in the background. My dependency injected types are separate.

The only thing I can think of is that the llblgen reflector that looks-up the DI types is seeing the unrelated references to the quartz assembly and trying to scan it as well. (Even though autodiscover is not on and I only specified my assembly for DI)

Odd...

Are you sure you don't have another web.config lower down in your site on the new server which may be overriding the top level one...?

Matt

No other web.config. I even created a brand new site on dev server w/ new web.config to isolate the problem and the error was still occurring.

I second the say that this seems to be caused by auto Discovery.

DI Auto-Discovery is turned off by default, so could you please remove the following tag from the config file and try again:

<add key="autoDependencyInjectionDiscovery" value="false"/>

Walaa, thanks for the reply. I only set the autoDependencyInjectionDiscovery property b/c I originally got the error w/o the property. I know that this is the default value, but thought to set it just in case. I can confirm that the problem happens with the property set to false, or if I leave it off.

I appreciate all the input. If there's a resolution, that would be great. But as I mentioned before, I can just register the quartz.dll assembly and get around the error. If no one else has reported this error before, I'd consider my situation an edge case not meriting a lot of effort troubleshooting.

Thanks!

luciusism wrote:

Walaa, thanks for the reply. I only set the autoDependencyInjectionDiscovery property b/c I originally got the error w/o the property. I know that this is the default value, but thought to set it just in case. I can confirm that the problem happens with the property set to false, or if I leave it off.

Mmm

luciusism wrote:

I appreciate all the input. If there's a resolution, that would be great. But as I mentioned before, I can just register the quartz.dll assembly and get around the error. If no one else has reported this error before, I'd consider my situation an edge case not meriting a lot of effort troubleshooting.

As a matter of fact there was a weird similar scenario posted in a private thread (so I can't post the link) two years ago. The conclusion was: We don't know what is going on , also the problematic dll was a 3rd party tool.

Anyway it's good you have a workaround for this. Please let us know if you find some clues in the future.

We'll look deeper into this issue on monday.

The problem is that the assembly referencing your Quartz dll has to be loaded for discovery for types which have the DI attribute. This won't work if Quartz isn't loadable/not found. The point thus is: where does the assembly loader look? We pass AppDomain.CurrentDomain.RelativeSearchPath to the new appdomain in which we discover types of loaded dlls (and we load all dlls). This might not be the folder you'd expect, as asp.net websites might have their appdomain local path pointed to a temp folder.

This is the main reason why we stated in the docs that autodiscovery doesn't work for websites, in the note: http://www.llblgen.com/documentation/2.6/hh_goto.htm#Using%20the%20generated%20code/gencode_usingdi.htm

I.o.w.: specify the assemblies which contain types for discovery using manual registration, and don't use auto-discovery.

Hi Frans, er Otis. I don't mean to belabor this problem, I already have a work around. I understand your point about how autodiscovery might not work with a website, but I am not using autodiscovery and my assembly is explicitly referenced w/ strong name. (And I confirmed that there are no other conflicting config files turning autodiscovery on, and that the assembly fullname is correct).

At this point, I'm assuming its just an edge case and I'm not worrying about it. The solution was to register the Quartz.dll assembly on the new server.

Thanks to llblgen staff for all your help!

Lucius

My bad, I assumed you did use auto-discovery. Anyway, it is indeed an edge case, and you can always register the assembly it relies on also as assembly to discover (it won't find anything but it will load it, so no more load conflicts ).