TypeLoadException and its error message

Hi all,
I have a perfect build

1>------ Build started: Project: Toolbox, Configuration: Debug AnyCPU ------
1>    Toolbox -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\Toolbox_1\bin\Debug\Toolbox.dll
2>------ Build started: Project: DATLIB, Configuration: Debug ------
2>    DATLIB -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DATLIB\bin\Debug\DATLIB.dll
3>------ Build started: Project: WORKSPACE, Configuration: Debug ------
3>    WORKSPACE -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\WORKSPACE\bin\Debug\WORKSPACE.dll
4>------ Build started: Project: P2CSMOD, Configuration: Debug ------
4>    P2CSMOD -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\P2CSMOD\bin\Debug\P2CSMOD.dll
5>------ Build started: Project: FMS_FUNKTIONEN, Configuration: Debug ------
5>    FMS_FUNKTIONEN -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\FMS_FUNKTIONEN\bin\Debug\FMS_FUNKTIONEN.dll
6>------ Build started: Project: IO_FUNKTIONEN, Configuration: Debug ------
6>    IO_FUNKTIONEN -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\IO_FUNKTIONEN\bin\Debug\IO_FUNKTIONEN.dll
7>------ Build started: Project: DATMOD, Configuration: Debug ------
7>    DATMOD -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DATMOD\bin\Debug\DATMOD.dll
8>------ Build started: Project: DIA_FUNKTIONEN, Configuration: Debug ------
8>    DIA_FUNKTIONEN -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DIA_FUNKTIONEN\bin\Debug\DIA_FUNKTIONEN.dll
9>------ Build started: Project: SRV_MODUL, Configuration: Debug ------
9>    SRV_MODUL -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\SRV_MODUL\bin\Debug\SRV_MODUL.dll
10>------ Build started: Project: DatmodOxyTest, Configuration: Debug ------
10>    DatmodOxyTest -> E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\DatmodOxyTest.dll
========== Build: 10 succeeded, 0 failed, 2 up-to-date, 0 skipped ==========

No: 10, DatmodOxyTest is a VS Universal Unit Test Project: The source is:

namespace DatmodOxyTest;

interface
uses
  System,
  Microsoft.VisualStudio.TestTools.UnitTesting,
  Toolbox,
  DATLIB,
  DATMOD,
  SRV_MODUL,
  SpezPlaDBSACC;

type
  [TestClass()]
  BasisModulTest = public class
  public
    [TestMethod()]
    method DB_Connect;
    [TestMethod()]
    method DB_Disconnect;
  end;

implementation

method BasisModulTest.DB_Connect;
begin
  FKT_INIT('');
end;

method BasisModulTest.DB_Disconnect;
begin
  FKT_BYE('');
end;

end.

I can set a breakpoint at FKT_INIT(’’); and it breaks
as soon as like to step into, or also just running all I get a type load excepetion.

Now; LTKONZ_Op is implemented, with many other Procedures in LTKONZ_MODUL.PAS which is one of the many pas files making up the DATMOD project, which you can see, builds perfect. Datlib.pas is a Interafce and type declaration file. All declared procedures are attributed external.

i.e.

(******************************************************************************)
(* Tabelle LTKONZ                                                             *)
TYPE
  LTKONZ_Type = public RECORD
            public // this makes all fields below public
                     KONZNR      : String;
                     ZSTEIN      : Datumtyp;
                     ZSTAUS      : Datumtyp;
                     KNAME1      : String;
                     KNAME2      : String;
                   END;
PROCEDURE LTKONZ_Op( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;
PROCEDURE LTKONZ_Select1( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;

Regarding LTKONZ_Op the interface is, as you can see declared in the file datlib.pas which has some common type’s, some common vars and many interface to procedures declared but no implementation.

All interfaces wear the ‘external’ attribute, because the implementation is done in a more relevant module, for LTKONZ_Op that is in file LTKONZ_MODUL.PAS which is a member of the DATMOD project.

We have to do so do avoid circular references among the many DLL’s

So what can I do ?

To mention is that LTKONZ_Op is the very first procedure interface declaration in the datlib.pas file. (see code above)
That means there is some generic error; I can swap the two and make LTKONZ_SELECT1 the first interface declaration in this interface consisting datlib.pas file and the error message is now

pointing to LTKONZ_SELECT1 as the non implemented in question.
But they are all implemented, because how else would I have a error free build.

maybe that one is of help too !

'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities\11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities.Sync\11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\SpezPlaDBSACC\SpezPlaDBSTest\bin\Debug\SpezPlaDBSTest.vshost.exe', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Xml.Linq\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.Linq.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Data.DataSetExtensions\v4.0_4.0.0.0__b77a5c561934e089\System.Data.DataSetExtensions.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.CSharp\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.CSharp.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_64\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Deployment\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Deployment.dll', Symbols loaded.
'SpezPlaDBSTest.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll', Symbols loaded.
The thread 'vshost.NotifyLoad' (0x12d4) has exited with code 0 (0x0).
The thread '<No Name>' (0x2778) has exited with code 0 (0x0).
The thread '<No Name>' (0x2260) has exited with code 0 (0x0).
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Microsoft.VisualStudio.TestPlatform.TestExecutor.Core.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Microsoft.VisualStudio.TestPlatform.ObjectModel.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Microsoft.VisualStudio.TestPlatform.Core.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089\System.ServiceModel.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.Serialization\v4.0_4.0.0.0__b77a5c561934e089\System.Runtime.Serialization.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\SMDiagnostics\v4.0_4.0.0.0__b77a5c561934e089\SMDiagnostics.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel.Internals\v4.0_4.0.0.0__31bf3856ad364e35\System.ServiceModel.Internals.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.Diagnostics.ServiceModelSink\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Diagnostics.ServiceModelSink.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.IdentityModel\v4.0_4.0.0.0__b77a5c561934e089\System.IdentityModel.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Microsoft.VisualStudio.TestPlatform.Utilities.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.Transactions\v4.0_4.0.0.0__b77a5c561934e089\System.Transactions.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Diagnostics.Measurement\11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Diagnostics.Measurement.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.GenericTestAdapter.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.MSAppContainerAdapter.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.UnitTestFramework.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.OrderedTestAdapter.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.TfsLogger.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.TmiAdapter.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.Common\11.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.Common.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.TrxLogger.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestTools.CppUnitTestFramework.ComInterfaces.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\Extensions\Microsoft.VisualStudio.TestTools.CppUnitTestFramework.CppUnitTestExtension.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ComponentModel.Composition\v4.0_4.0.0.0__b77a5c561934e089\System.ComponentModel.Composition.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_32\System.EnterpriseServices\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.EnterpriseServices.Wrapper.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\DatmodOxyTest.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\SRV_MODUL.dll', Symbols loaded.
The thread '<No Name>' (0x204) has exited with code 0 (0x0).
The thread '<No Name>' (0x1808) has exited with code 0 (0x0).
The thread '<No Name>' (0x1588) has exited with code 0 (0x0).
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\DATLIB.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\Toolbox.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\FMS_FUNKTIONEN.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\DATMOD.dll', Symbols loaded.
'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'E:\Users\C770817\SW-PROJEKTE\Spezpla-ISS-Root\DatmodOxyTest\bin\Debug\DIA_FUNKTIONEN.dll', Symbols loaded.
A first chance exception of type 'System.TypeLoadException' occurred in DatmodOxyTest.dll
Step into: Stepping over method without symbols 'System.Environment.GetResourceStringLocal'
Step into: Stepping over method without symbols 'System.Reflection.TargetInvocationException.TargetInvocationException'
A first chance exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestMethodRunner.DefaultTestMethodInvoke'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestMethodRunner.RunTestMethod'
A first chance exception of type 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestFailedException' occurred in Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.dll
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestMethodRunner.ExecuteTest'
A first chance exception of type 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestFailedException' occurred in Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.dll
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestMethodRunner.ExecuteInternal'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.TestMethodRunner.Execute'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.UnitTestRunner.RunInternal'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.MSTestFramework.UnitTestRunner.RunSingleTest'
Step into: Stepping over method without symbols 'System.Runtime.Serialization.ObjectCloneHelper.GetObjectData'
Step into: Stepping over method without symbols 'System.Runtime.Serialization.ObjectCloneHelper.GetObjectData'
Step into: Stepping over method without symbols 'System.Runtime.Serialization.ObjectCloneHelper.PrepareConstructorArgs'
Step into: Stepping over method without symbols 'System.Runtime.Remoting.Messaging.LogicalCallContext.LogicalCallContext'
Step into: Stepping over method without symbols 'System.Runtime.Serialization.ObjectCloneHelper.PrepareConstructorArgs'
Step into: Stepping over method without symbols 'System.Threading.ExecutionContext.ExecutionContext'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.ExecuteTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.ExecuteDurontoTestsInternal'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.ExecuteDurontoTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.ExecuteTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.ExecuteTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MixedModeExecutor.RunTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Extensions.VSTestIntegration.MSTestExecutor.RunTests'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Core.TestExecutionManager.RunTestInternalWithExecutors'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Core.TestExecutionManager.RunTestsInternal'
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Core.TestExecutionManager.RunTests'
A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.VisualStudio.TestPlatform.TestExecutor.Core.dll
Step into: Stepping over method without symbols 'Microsoft.VisualStudio.TestPlatform.Core.TestExecutionManager.RunTests'
Step into: Stepping over method without symbols 'System.Threading.ExecutionContext.RunInternal'
The thread '<No Name>' (0x1fb8) has exited with code 0 (0x0).
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.Internals.dll
A first chance exception of type 'System.IO.IOException' occurred in System.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.Internals.dll
A first chance exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in System.ServiceModel.Internals.dll
A first chance exception of type 'System.InvalidOperationException' occurred in Microsoft.VisualStudio.TestPlatform.TestExecutor.Core.dll
The program '[8160] vstest.executionengine.x86.exe: Program Trace' has exited with code 0 (0x0).
The program '[8160] vstest.executionengine.x86.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).
The program '[7944] SpezPlaDBSTest.vshost.exe: Program Trace' has exited with code 0 (0x0).
The program '[7944] SpezPlaDBSTest.vshost.exe: Managed (v4.0.30319)' has exited with code -1 (0xffffffff).

And it is as it is. small code / programs run fine.

Sounds like a bug. Can you send a compete project that shows this? Thanx!

We have reported the following to Sparx, the vendor for Enterprise Architec

The following Registered Bug report was submitted by Josef Stadelmann (mailto:josef.stadelmann@axa-winterthur.ch)


ENVIRONMENT DETAILS

EA Edition: Systems Engineering

Build: 12.0.1209

EA Extensions:

VS Integration

SysML Technology

Eclipse Link

3rd Party Extension:

Repository: .EAP

Operating System: Windows 7 64bit


ISSUE DETAILS

Subject:

no class created for some name spaces

Details:

We have 39 Oxygene Pascal Files compiled using RemObjects Oxygene into ONE
larger DLL. Each .PAS starts with a unique namespace i.e.
DATMOD. i.e. DATMOD.LTBATCH, DATMOD.LTCODES, DATMOD.LTUSER,
etc.

Oxygene allows for types and classes. In our legacy code we have no defined
classes.

Oxygene however includes an implicit __Global class under each namespace. This
allows to call procedures and functions on a global scale.

At Run-Time, the type library initializer, a part of the CLR, instantiates each
__Global call. That happens implicit when ever a call is made to one of the DLL
procedures.

For the import of this DATMOD.DLL we have selected to create a package for each
name space. After the import we can see for each source file a package created.
But we see the global class only for about half of the created packages.

Our issue is: we have type load exceptions calling same of our procedures. i.e.
when a unit test code in VS 2012 attempts to call it. It can be that the
Oxygene compiler did not compile a __Global class into the DLL for each
namespace. Or it can be that EA has a problem with it’s used disassembler.

Also we have no clue why working procedures do not show up with their implicit
created __Global class. It is a confusing issue but it matches perfectly the
overall found confusion regarding this type load exceptions. Google is full of
it, but real working solutions where not found so far.

The second issue we see is: When we import the same DLL more then one time, we
can select to overwrite or synchronize existing classes. Here, we have very
random results. For some of the namespaces the class __Global exists even after
the second and third binary import only once, while for others either no class
is created as described above or the class is created once for each import
running. How EA can handle many classes with the same name under the same
namespace is in our mind an error as well, at b est, total confusing.

Steps to Reproduce:

Up on request we can deliver our DATMOD.DLL and we would be very happy if one
at Sparx can tell us that a) EA is perfectly showing what is in the DLL even
the absence of some classes named __Global b) and come up with an explanation
why multiple imports behave as said above.


If you have any attachments, please reply to this message to send to support

can RemObjects verify up on sending in our DATMOD.DLL that for each namespace defined a __Global class is defined with it’s constructor ? If any anomalies are found we are glad to make a DATMOD.ZIP and send the project. IN which case we need your e-mail address or we deposit it at a server where you can access it using FTP.

Every __Global class has a (private) constructor yes. If you think there’s something wrong with the project feel free to mail me (ck@ remobjects.com)

Using the Sparx EA (our CASE tool which allows for round-trip-engineering)
For the binary import of i.e. DATMOD.DLL we have selected to create a package for each name space.
After the import we can see for each source file a package created.
But we see the _Global class only for about half of the created packages, in the worst case only for two namespaces.

This seams to be a Sparx EA issue ?

BUT:

(******************************************************************************)
(* Tabelle LTKONZ                                                             *)
TYPE
  LTKONZ_Type = public RECORD
            public // this makes all fields below public
                     KONZNR      : String;
                     ZSTEIN      : Datumtyp;
                     ZSTAUS      : Datumtyp;
                     KNAME1      : String;
                     KNAME2      : String;
                   END;
PROCEDURE LTKONZ_Op( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;
PROCEDURE LTKONZ_Select1( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;

This code shows a snipped of an external interface file where TYPE and F/P’s are declared.

QUESTION: Is something wrong with that regarding Oxygene?

When we implement the F/P’s and have ;external; declared, in the same code file we receive an Oxygene compilation error. So we think, doing it the way it’s shown is correct but leads to TypeLoadException “implementation … not found”

Using this external IF File, we run into TypeLoadException during Unit Testing in VS as explained above.

Declaring this Interface twice, a) in the external interface file using ;external; as shown and in the interface section of the PAS file implementing the F/P’s, we receive a “ambiguous call to F/P error message” during compilation of the caller.

Then we have to decide where to remove the F/P declaration.

Since we removed this F/P Interface declarations and move it back into the interface section of each PAS file implementing this F/P?s, we do not see any longer TypeLoadException when we do VS 2012 Unit Testing, when such DLL F/P?s are called for testing. However, we still have TypeLoadException when we call F/P?s in our DLL’s from a IIS 7.5 WCF Web Site Web Service.

What is the difference ?
This to fix is our main GOAL. Subject of this Forum Topic.

So Oxygene has an issue with ;external; for sure, in that CLR Loader comes to the conclusion that no implementation exists. (See above)

PROCEDURE LTKONZ_Op( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;
PROCEDURE LTKONZ_Select1( VAR Op: Op_Type; VAR Data: LTKONZ_Type );external;

So we have two types of TypeLoadException:
a) One which occurs when we have an F/P declared as external and
b) one which occurs when DLL’s load correctly as shown by the fuslogvw.exe but fails to initialize __Global

I am thinking what I can pass to you because our code base is quite large and uses an Oracle DB. AND even for the smallest we pass, you would need to setup an IIS 7.5 and be able to deploy a WCF Web Site Service to demonstrate our main issue.

Why are you using external at all without combining it with pinvoke or something else?

Maybe I have an understanding problem !!!

;external; in my mind and understanding tells the compiler that the implementation of the procedure is somewhere else at a different source file.

The statement lines shown are used in a file called DATLIB.pas
which compiles and builds into its own DATLIB.dll.

In a DATMOD project, under the implementation section we just implement the procedures as shown in the code snipped above, AND we add a reference to DATLIB.dll and all makes it into a DATMOD.dll !

In a next DLL project called DIALOG.pas we add a reference to DIALIB.dll and one to DATMOD.dll, then add required use’s, and we call procedures in DATMOD.dll. ALL is fine for the compiler.

The difficulties are are explained in deep in previous replies / and the initial topic.

We where using this kind of writing to avoid some DLL CIRCULAR REFERENCES, because telling the compiler about the signature of a procedure makes em happy. Later when the dll with the implementation exists, all gets loaded fine according to FUSLOGVW.EXE but fails with the reported TypeLoadException telling us that we have not implemented the procedure. So the compiler is happy but the CLR is not happy. And changing just the order of the declarations and the CLR reports via TypeLoadException that we have not implemented the other procedure. What ever is declared first makes the CLR fail. See above in my main topic.

Why shall I use pinvoke or something else if the compiler is happy ? I don’t know how and why to use pinvoke !

But as I said:
we moved this interface declarations back into the file where the P/F’s are implemented.
At the moment we have only TYPE definitions in this external DATLIB.pas file. So we have this TYPES at a central place and we can use it where ever we like as long as we add a reference to the DATLIB.dll.

Not having this ;external; declarations makes all our DLL’s running in VS Unit Test Suites !
But even if the run there, they all fail when we DEPLOYED it to the web server and cal it as WCF web site service.

Josef

Oke so that’s not what external does. External makes a method external to the runtime. This is usually used for pinvoke (which you don’t want to use here). Recursive dependencies are tricky, which really the best is to avoid them all together.

As for the other failure when you don’t use external: I need more information on that to be able to give a better reply.

Carlo, can you tell me why we I used ;external; and only had the interface part of this P/F’s declared in DATLIB.pas, the compiler was happy and created me a DATLIB.dll?

And when I did the implementation of P/F’s and had the P/F’s declared in the same file but attributed with ;external; the compiler claimed that I have to implement the procedure somewhere else?

So joint as we saw it all the years in older PASCAL compilers.

and yes; at first we tried it that way, but as it did not work, we rearranged code and then we where able to move the interfaces back into relevant pas files without CIRCULAR REFERENCES. It’s tricky as you said. And having such an ;external; interface file would allow that in case of complex code structures.

So back to TypeLoadExceptions

As reported:
we have now configuration which runs all DLL’s down and into the Oracle DB and
I can use this from Visual Studio Ultimate 2012 Unit Test Framework.
All fine NO TYPELOADEXCEPTION. All green lights after the test.

But then I deploy my SpezplaWebService project to the IIS

SpezplaWebService has

AppCode has

bin has

Do you know when TypeLoadExceptions are triggered ?

And doing that, the web server compiles the two C# on the fly and loads it and initializes a first instance of FKTmapManager. Then with this configuration, we use Reliable Transactions we get an FKTmapManager Instance for each user session. Long lasting what we need.

In this configuration I can step into and I see a TypeLoadException telling me that the Toolbox.__Global Class could not be initialized.

But looking at Toolbox using fuslogvw.exe I can see that this DLL was found and loaded.
But what means loaded ?
What means loaded when the CLR after that claims that it was unable to initialize the Toolbox._Global class.

Maybe as a hint: Sparx has reported that some of our F/P’s loose there parameters when they look at DLL’s with disassembling and other tools which I don’t know yet.

Carlo, I am still somehow new to IIS and I don’t know if we need to use strong naming and signing our DLL’s if we intend to use them from a web server?
I have read today
http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/
I went through this examples and it works as the author said. Good explaining.

How would you explain that P/F’s of all our DLL’s run under VS Test as Unit Tests and stand alone testes, but fail with TypeLoadException as soon as one routine is called by the FKTmapManager, which is the root DLL of our web site service project. FKTmapManager is only called by the IIS w3wp.exe (the wwww work processor.)

Because it’s valid code for some rare usecases, it just doesn’t do what you said it should.

Usually when the type is first used. Either as a field in another class or a method call.

TypeLoad exceptions don’t have anything to do with strong naming though. They’re usually a sign of bad codegen or an exception in the class constructor. (If you break on all exceptions, Debug/Exceptions/CLR Exceptions [check]) you can see those.

Thank you Carlo.

what you say is simply true!
They’re usually a sign of bad codegen or an exception in the class constructor.

That is exactly what we have. But as our problem belongs to the Toolbox._Global class, AND we do not write a single line of Toolbox._Global class constructor code (cctor code), where do you think we have to start investigation at?

But anyway: I have to spend more time one CAS, Code Access Security! I am just reading about CAS Basics at
https://msdn.microsoft.com/en-us/library/33tceax8.aspx

Just-in-time (JIT) compilation performs a verification process that examines code and tries to determine whether the code is type-safe. Code that is proven during verification to be type-safe is called verifiably type-safe code.
Code can be type-safe, yet might not be verifiably type-safe because of the limitations of the verification process or of the compiler. Not all languages are type-safe, and some language compilers, such as Microsoft Visual C++, cannot generate verifiably type-safe managed code. To determine whether the language compiler you use generates verifiably type-safe code, consult the compiler’s documentation. If you use a language compiler that generates verifiably type-safe code only when you avoid certain language constructs, you might want to use the PEVerify tool to determine whether your code is verifiably type-safe. Code that is not verifiably type-safe can attempt to execute if security policy allows the code to bypass verification. However, because type safety is an essential part of the runtime’s mechanism for isolating assemblies, security cannot be reliably enforced if code violates the rules of type safety. By default, code that is not type-safe is allowed to run only if it originates from the local computer. Therefore, mobile code should be type-safe.

very interessting, the last bolded text: I do not yet run my code on a local IIS 7.5 but on a host, a virtual host. Now I will install a IIS 7.5 on my development machine. And if it runs local under IIS 7.5, I am a bit further. That would then explain (maybe) why code running under a test suite of VS 2012 does not run after deployment on a remote installed IIS 7.5.

Further to that, I will try to see with the PEVerify tool if the code from Oxygene is verifiably type-safe code.

Then I will go to see what permissions my code needs. Permissions maybe granted or denied by a policy or in the worst case, by a set of interfering policies; policies which I don’t know yet, and which I don’t trust.

Then I will think how I can find all possible exceptions triggered by any type of CAS and or policy and report and handle them when we get out of bound.

Oke. I’m not saying the cctor causes the typeloadexception, if it does it would have an innerexception you can see in the debugger, but Oxygene only generates a cctor if there is an explicit class constructor, or if there is initialization code, like global vars with an initial value.

in our Toolbox.pas and many other .pas files we have global vars, constants and types, all defined in the interface section many with initialization! Will investigate closer the TypeLoadException’s inner message.

That looks an awful lot like the one from last time? Any chance you can extract this so I can run it locally?

I hope that gives you a bit more insight;

Why the class not registered message ?

I have temporary enabled the flag for COM visibility for Toolbox.pas but it makes absolute no difference.

Are we missing some registration if we deploy it by the web site deployer to the web server?

EXTRACTING:
I think what you would need to have the same effect as we have is
an IIS 7.5 web server in remote location
and then best you tell me which DLL’s I shall pass to you or which DL’s source code

Given we pass the full solution you will have a lot work stubbing out or commenting out calls.

Here’s the servers component diagram, for now, all except a few is 3GL spaghetti code.

It looks like anything that calls Toolbox’s MAXI will cause this?