Re: nunit.exe and statically linked dgbhelp.dll

Hi,
 
ok, as requested, here is the smallest possible test environment to reproduce the error.
 
Prerequisites:
- Microsoft Windows XP, SP2
- Microsoft Visual Studio 2005, SP1
- .NET framework 2.0.50727.1433
- Microsoft Debugging Tools for Windows Version 6.8 (download from http://www.microsoft.com/whdc/DevTools/Debugging <http://www.microsoft.com/whdc/DevTools/Debugging>  and install the sdk)
- NUnit Version 2.4.6
 
Source:
- Create a new solution with 3 projects: core, test and nunit.
 
1.) Project "core" (this is the one to be tested):
- native C++ code (NOT /clr)
- target: core.dll, core.lib and core.exp (Win32 dynamic link library)
- compile with /D CORE_EXPORTS
- source file core.h:
 
#ifdef CORE_EXPORTS
  #define CORE_API __declspec(dllexport)
#else
  #define CORE_API __declspec(dllimport)
#endif
 
class CORE_API Core
{
  public:
    Core(void);
 
    int i;
};
 
- source file core.cpp:
 
#include "windows.h"
#include "core.h"
#include "dbghelp.h"
 
#pragma comment( lib, "dbghelp.lib" )
 
void init()
{
  HANDLE hProcess = ::GetCurrentProcess();
  ::SymInitializeW( hProcess, NULL, false ); // <<= from dbghelp.dll
}
 
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved )
{
  switch (ul_reason_for_call)
  {
    case DLL_PROCESS_ATTACH:
      init();
      break;
 
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
      break;
  }
  return TRUE;
}
 
Core::Core() : i( 3 )
{
}
 
 
2.) Project "test" (tests core.dll without nunit):
- native C++ code (NOT /clr)
- target: test.exe (console application)
- link with core.lib
- source file test.cpp:
 
#include <stdio.h>
#include <tchar.h>
#include "../core/core.h"
 
int _tmain(int argc, _TCHAR* argv[])
{
  Core c;
  printf( "c.i = %i \n", c.i );
 
  printf( "\npress any key...\n" );
  _getwch();
  return 0;
}
 
 
3.) Project "nunit" (tests core.dll with NUnit):
- managed code (/clr)
- target: nunit.dll (Win32 dynamic link library)
- compile with /clr
- link with core.lib
- source file nunit.h:
 
#using "nunit.framework.dll"
 
using namespace System;
using namespace NUnit::Framework;
 
namespace nunit
{
 
[TestFixture]
public ref class TestClass
{
  public:
    [Test, Description( "Demo Test" )] void DemoTest();
};
 
}
 
- source file nunit.cpp:
 
#include "nunit.h"
#include "../core/core.h"
 
namespace nunit
{
 
void TestClass::DemoTest()
{
  Core c;
  Assert::IsTrue( c.i == 3 );
}
 
}
 
 
Build solution:
- copy dbghelp.h (from Debugging Tools for Windows, usually C:\Program Files\Debugging Tools for Windows\sdk\inc) to source directory of project "core"
- copy dbghelp.lib (from Debugging Tools for Windows, usually C:\Program Files\Debugging Tools for Windows\sdk\lib\i386) to source directory of project "core"
- copy nunit.framework.dll (from NUnit) to source directory of project "nunit"
- copy NUnit (at least nunit.exe, log4net.dll, nunit-gui-runner.dll, nunit.core.dll, nunit.core.interfaces.dll, nunit.framework.dll, nunit.uikit.dll, nunit.util.dll) to binary output directory
- copy dbghelp.dll (from Debugging Tools for Windows, usually C:\Program Files\Debugging Tools for Windows\sdk\srcsrv) to binary output directory
- build project "core"
- copy core.dll to binary output directory
- copy core.lib and core.exe to source directories of projects "test" and "nunit"
- build project "test"
- copy test.exe to binary output directory
- build project "nunit"
- copy nunit.dll to binary output directory
 
 
Run tests:
- cd to binary output directory
- start test.exe: works fine
- start nunit.exe with nunit.dll: fails while loading dll (error message see below) !
- recompile core.dll and link with /DELAYLOAD:dbghelp.dll and DelayImp.lib
- start nunit.exe with nunit.dll: works fine, all tests pass
 
Error:
"System.IO.FileLoadException: Eine von nunit, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null importierte Prozedur konnte nicht geladen werden.
---> System.Runtime.InteropServices.COMException: Die angegebenen Prozedur wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007F)"
 
in detail:
 
System.Runtime.InteropServices.COMException...
 
System.IO.FileLoadException...
 
Server stack trace: 
  bei System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
  bei System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
  bei System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
  bei System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
  bei System.Reflection.Assembly.Load(String assemblyString)
  bei NUnit.Core.Builders.TestAssemblyBuilder.Load(String path)
  bei NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites)
  bei NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites)
  bei NUnit.Core.TestSuiteBuilder.BuildSingleAssembly(TestPackage package)
  bei NUnit.Core.TestSuiteBuilder.Build(TestPackage package)
  bei NUnit.Core.SimpleTestRunner.Load(TestPackage package)
  bei NUnit.Core.ProxyTestRunner.Load(TestPackage package)
  bei NUnit.Core.RemoteTestRunner.Load(TestPackage package)
  bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
  bei System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
  bei System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
 
Exception rethrown at [0]: 
  bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
  bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
  bei NUnit.Core.TestRunner.Load(TestPackage package)
  bei NUnit.Util.TestDomain.Load(TestPackage package)
  bei NUnit.Util.TestLoader.LoadTest(String testName)

 

If you desire, I can send you a zip file with the complete solution (about 500 KB). Please, let me know.

best regards
    Frank Rücker
 



________________________________

	Von: Charlie Poole [mailto:[email protected]] 
	Gesendet: Montag, 10. März 2008 18:59
	An: Ruecker, Frank, OPES44; [email protected]
	Betreff: RE: [Nunit-users] nunit.exe and statically linked dgbhelp.dll
	
	
	Hi,
	 
	Can you submit a bug report for this? It would help if you can provide the smallest possible
	test that reproduces the problem.
	 
	Charlie


________________________________

		From: [email protected] [mailto:[email protected]] On Behalf Of Ruecker, Frank, OPES44
		Sent: Monday, March 10, 2008 9:22 AM
		To: [email protected]
		Subject: [Nunit-users] nunit.exe and statically linked dgbhelp.dll
		
		
		Hello,
		 
		we are using NUnit version 2.4.6 with .NET runtime 2.0 build 1433 to test our native Win32 C++ components. One of our core components links statically to dbghelp.dll version 6.8.4.0 (installed by Microsofts Debugging Tools for Windows, currently available from http://www.microsoft.com/whdc/DevTools/Debugging <http://www.microsoft.com/whdc/DevTools/Debugging> ). Unfortunately, this doesn't work: NUnit procudes an error while loading the component to test (System.IO.FileLoadException ---> System.Runtime.InteropServices.COMException with HRESULT of 0x8007007F in NUnit.Core.Builders.TestAssemblyBuilder.Load). If we link dynamically to dbghelp.dll (with the linker option /DELAYLOAD), everything works fine.
		 
		Since dynamically loading dbghelp.dll is not acceptable for our runtime builds, we badly need NUnits support for this situation. Has someone any suggestions, workarounds, fixes or updates which targets this problem? If not, I would highly recommend the developers to build in support of dbghelp.dll in your next release.
		 
		best regards
		    Frank Rücker

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users