System.TypeLoadException with current version 2014.1

[ganshorn.nils]

Hello,

we are trying to upgrade out Microsoft Prism based application to the current Reports.Wpf (2014.1) and are unfortunately getting a fatal exception at startup of our application.

We have included the following Stimulsoft DLLs, all from the current version 2014.1.
Stimulsoft.Base.dll
Stimulsoft.Report.Check.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Helper.dll
Stimulsoft.Report.Wpf.dll
Stimulsoft.Report.WpfDesign.dll

We have removed all Stimulsoft DLLs from the GAC. We cleaned the build directory and made sure only the right DLLs are copied there when building.

Here is the Stacktrace:
------------------------------------------------------------------------
System.TypeLoadException: Method 'GetImage' in type 'Stimulsoft.Report.Painters.StiContainerWpfPainter' from assembly 'Stimulsoft.Report.Wpf, Version=2014.1.1900.0, Culture=neutral, PublicKeyToken=ebe6666cba19647a' does not have an implementation.
at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes)
at System.Reflection.RuntimeAssembly.GetExportedTypes()
at Microsoft.Practices.Prism.Modularity.DirectoryModuleCatalog.InnerModuleInfoLoader.<>c__DisplayClassf.<GetNotAllreadyLoadedModuleInfos>b__b(FileInfo file)
at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at Microsoft.Practices.Prism.Modularity.DirectoryModuleCatalog.InnerModuleInfoLoader.GetModuleInfos(String path)
at Microsoft.Practices.Prism.Modularity.DirectoryModuleCatalog.InnerModuleInfoLoader.GetModuleInfos(String path)
at Microsoft.Practices.Prism.Modularity.DirectoryModuleCatalog.InnerLoad()
at Microsoft.Practices.Prism.Modularity.ModuleCatalog.Initialize()
at Microsoft.Practices.Prism.Modularity.ModuleManager.Run()
at Ganshorn.LFX.ApplicationShell.Bootstrapper.UnityAsyncBootstrapper.<InitializeModules>d__4.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\Bootstrapper\UnityAsyncBootstrapper.cs:line 196
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Ganshorn.LFX.ApplicationShell.Bootstrapper.LfxBootstrapper.<InitializeModules>d__5.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\Bootstrapper\LfxBootstrapper.cs:line 212
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Ganshorn.LFX.ApplicationShell.Bootstrapper.UnityAsyncBootstrapper.<Run>d__0.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\Bootstrapper\UnityAsyncBootstrapper.cs:line 118
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Ganshorn.LFX.ApplicationShell.Bootstrapper.LfxBootstrapper.<Run>d__0.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\Bootstrapper\LfxBootstrapper.cs:line 87
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Ganshorn.LFX.ApplicationShell.Bootstrapper.PrismAsyncBootstrapper.<Run>d__0.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\Bootstrapper\PrismAsyncBootstrapper.cs:line 54
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Ganshorn.LFX.ApplicationShell.App.<OnStartup>d__4.MoveNext() in c:\Users\nils.beckmann\src\ganshorn.lfx\src\ApplicationShell\App.xaml.cs:line 133

------------------------------------------------------------------------

Greetings

Nils Beckmann

[HighAley]

Hello.

We have met such problems recently.
Please, try to install Stimulsoft assemblies to the GAC.

Thank you.

[ganshorn.nils]

Hello Aleksey,

thanks for the answer. We need to deploy the Stimulsoft DLLs with our application and doing this via the GAC is out of the question for us. Can you provide another solution?

Greetings

Nils Beckmann

[HighAley]

Hello.

To help you we need to know if the installing of our assemblies to GAC solve your problem.

Thank you.

[ganshorn.nils]

When referencing the DLLs via the GAC the problem doesn't occur.

To check I re-installed Reports.2014 which led to the following DLLs being installed in the GAC.
Stimulsoft.Base
Stimulsoft.BusinessObjects
Stimulsoft.Report
Stimulsoft.Report.Check
Stimulsoft.Report.Helper

except for Stimulsoft.BusinessObjects which we don't use I changed the references in our Solutions to the GAC assemblies.

the DLLs Stimulsoft.Report.Wpf and Stimulsoft.Report.WpfDesign are not installed in the GAC and I continue to copy them in our build directory.

[HighAley]

Hello.

This improve our suggestion that our assemblies should be installed to GAC.
We don't know why they should be installed. We are working on this problem.

Thank you.

[ganshorn.nils]

Hello,

thanks for the answer. I found this question at stackoverflow dealing with the same exception: https://stackoverflow.com/questions/948 ... mplemented. Maybe this is of help.

Greetings and hoping to hear from you soon

Nils Beckmann

[ganshorn.nils]

Hello,

I managed to use Version 2014.1 without the DLLs being used via the GAC by compiling Stimulsoft DLLs from source. However I had to change the platform target for the Stimulsoft.Base.Dll and Stimulsoft.Reports.Dll (both have Targetframework set to .Net 2.0) from x86 to AnyCPU for it to work because otherwise I got a BadImageFormatException. So I have the questions:

- Is it safe to switch the platform target to AnyCPU for this 2 DLLs?
- What else can be different so it works now?
-- Do you compile from the exact same source code that you provide to us?
-- I compiled with VS 2013, what do you use?

Greetings

Nils Beckmann

[HighAley]

Hello, Nils.

thanks for the answer. I found this question at stackoverflow dealing with the same exception: https://stackoverflow.com/questions/948 ... mplemented. Maybe this is of help.

We use reflection to get attributes. Due to some restrictions Reflection doesn't work if the assemblies are not in GAC.
Here is the similar problem http://bytes.com/topic/c-sharp/answers/ ... g-expected

I managed to use Version 2014.1 without the DLLs being used via the GAC by compiling Stimulsoft DLLs from source. However I had to change the platform target for the Stimulsoft.Base.Dll and Stimulsoft.Reports.Dll (both have Targetframework set to .Net 2.0) from x86 to AnyCPU for it to work because otherwise I got a BadImageFormatException. So I have the questions:

- Is it safe to switch the platform target to AnyCPU for this 2 DLLs?

We compile our assemblies with AnyCPU platform target.

- What else can be different so it works now?

There should be no difference.

-- Do you compile from the exact same source code that you provide to us?

Yes, we compile from the same code.

-- I compiled with VS 2013, what do you use?

We use Visual Studio 2010 at development. Our builds are created with MSBuild.

Thank you.