We faced an issue sometime ago, which put us into a very tight situation. The issue was when a Crystal Report file is loaded through .NET code, it threw the following error. This is the first of a series of errors which lead to another and so forth.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.TypeInitializationException: The type initializer for
'CrystalDecisions.ReportSource.ReportSourceFactory' threw an exception.
---> System.TypeInitializationException: The type initializer for
'CrystalDecisions.Shared.SharedUtils' threw an exception.
---> System.IO.FileLoadException: Could not load file or assembly 'log4net,
Version=1.2.10.0, Culture=neutral,
PublicKeyToken=692fbea5521e1304' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)
File name: 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304'
at CrystalDecisions.Shared.SharedUtils..cctor()
And the confusion grew even further when we checked the GAC (Global Assembly Cache). Because we could see that in GAC, the mentioned assembly (log4net) is being registered with the version 1.2.10.0 and with the correct ‘PublicKeyToken’ (692fbea5521e1304).
And we didn’t really worry about the ‘Processor Architecture’ column, since our development environment is 64-bit and all the Crystal Reports development pre-requisites were there in the development environment and Crystal Runtime was already installed (version 13 – 64-bit). And in our application code, we were using the same log4net and it was already presented in the bin folder.
Then when we Googled the issue, we would be able to come across similar incidents, where the majority of the people were able to resolve the issue by installing the Crystal Runtime. But it was sort of a puzzle to us since we already had it installed. But later, we tried by un-installing the runtime and re-installing it again, assuming some corruption might had occurred during the previous installation or afterwards. But the result was the same.
Then we came across the following article which gave us some kind of a hint of the issue we are facing:
And it occurred to us that even though we had the same assembly which the error is pointing installed in GAC, still the Crystal assemblies were expecting some other log4net assembly to be presented in GAC.
Therefore, we installed the Crystal Runtime version 13 for 32-bit. Afterwards, the GAC was having both the assemblies registered.
And this resolved the issue. And we came to a conclusion that even our development environment is 64-Bit, we need to have the log4net assembly for 32-bit since crystal is referring to that internally.
Hope this would help you if you are facing the same problem.
