NUnit has a P/Invoke whose native function doesn't exist on all platforms

[rolfbjarne]

Repro project: nunitlite-3.12.0-c582df3.zip

To reproduce, download and extract, and then execute msbuild /p:Platform=iPhone /r

This results in a few errors:

  Undefined symbols for architecture arm64:
    "_GetVersionEx", referenced from:
        wrapper_managed_to_native_NUnit_Framework_Internal_OSPlatform_GetVersionEx_NUnit_Framework_Internal_OSPlatform_OSVERSIONINFOEX_ in nunit.framework.dll.o
  ld: symbol(s) not found for architecture arm64

MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetVersionEx. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/rolf/Projects/nunitlite-3.12.0/nunitlite-3.12.0.csproj]

Full build log

This is the P/Invoke in question:

nunit/src/NUnitFramework/framework/Internal/OSPlatform.cs

Lines 201 to 202 in 35242d4

	[DllImport("Kernel32.dll")]
	private static extern bool GetVersionEx(ref OSVERSIONINFOEX osvi);

This is clearly a Windows-only P/Invoke, since GetVersionEx is a Windows-only function.

For Xamarin.iOS apps it's highly recommended to not have P/Invokes to functions that don't exist on the platform, because otherwise we have to apply a workaround that has a performance impact on the application.

Would it be possible to rework this code somehow so that the NUnit assemblies that are used for Xamarin.iOS (and tvOS/watchOS) don't have this P/Invoke?

[rprouse]

I'm surprised that whole class isn't surrounded in an ifdef for. NET Standard. The classes that call it probably are. Should be an easy fix.

[rprouse]

Looking at the code, this is going to be a bit harder. I've always hated the way we do platform detection and believe we should limit ourselves to what can be determined through .NET directly, but we've maintained this code for legacy purposes. That said, we should be able to get rid of the two pinvokes in that class for the .NET Standard build of NUnit.

[jnm2]

@rprouse I usually take the approach that #3610 took.

[rolfbjarne]

@jnm2

@rprouse I usually take the approach that #3610 took.

That doesn't work in this scenario. The problem is that the AOT compiler emits a reference to the native function (which happens at build time, whether the P/Invoke is called or not), and then the native linker complains when it can't find that native function. Surrounding the P/Invoke with a try/catch doesn't change anything.

[rprouse]

@rolfbjarne we are only using that PInvoke to get if it is a Windows Server or Client/WorkStation, so I can just get that from the registry if we are on Windows in the .NET Standard build of the framework.

My plan is;

• Leave the PInvoke for the full framework builds (.NET 3.5, 4.0 and 4.5)
• Switch to a registry lookup if on Windows for the .NET Standard 2.0 build
• Leave the PInvoke on Mac to "libc" for "uname" alone. I assume it isn't causing you a problem?

Will this work for you?