Pinvoke in .NET core


I read on can pinvoke in .NET core, to access platform specific implementation of common functionality.

What if my platform specific functionality is in .NET already, how do I use it?

Say I have a .NET core library that expose GPS functionality. Though it obviously doesn’t work on its own since .NET core has no GPS support, it depends on the OS.

Say I include that in a .NET Core app.
And I deploy that .NET core app (NOT a platform specific app) on Android phone and iPad tablet.

And say I can write (thanks to Xamarin) some GPS common interface in plain .NET for iOS and Android with common interface.

How do I pick up this module on each platform?


As far as I know, .Net Core does not support Android or iOS, only Windows, Linux and macOS.


Alright I am not explaining myself very well… let’s try again…

What if you want to extend the .NET Core?
i.e. introduce a new functionality, for example kill remote process. As a .NET core API.
(Process class might already exists in .NET core, let’s pretend it doesn’t)

You should of course implement it on Windows, Linux, MacOS.
How do you make your new platform specific operation available on all platform as a .NET Core API?

It’s probably 6 line of code on all platform… but how do you make those 6 line of code available to .NET Core app?


Well, PInvoke works the same as it always did and you can use RuntimeInformation to find out on what OS you are. So I think something like this should work:

public static extern void WindowsFunction();

public static extern void linuxFunction();


if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
    throw new NotSupportedException();       

Did I understood what you’re looking for correctly?


You understood perfectly and it would work fine.
However what if there is a platform .NET library available. Is there a way to do better than pinvoke?


Well, another way is to use client/server architecture through named pipes or any other way to IPC where your C/++ part can act as the server/dealer and the C# can act as the client/consumer and vice versa but what does better really mean? do you need better performance? do you need modularity? there’s no silver bullets here so you should be more specific to get much better answers.


What are you talking about eyalsk?!
I just want to call a local platform specific DLL from my .NET Core app. client-server is completely out of topic!
Ideally this DLL is a .NET Dll and I would like a simple way to use it. Simpler than DllImport, if possible. One which expose .NET object instead of C function, whose declaration is also error prone.


No, it’s not out of topic! it’s right on topic! but to answer your question first, no there’s no simpler way to do it.

Client/server architecture can be used and is used to solve cross-platform problems when you want to have more modular and/or decoupled system where each part can change independently! or when independent programs in your system wants to communicate.

In fact, that’s what happening when you use P/Invoke… in brief when you make a call to a C function the CLR goes to this function, makes a call to it in an unamaged context, serializes the data and finally deserialize it in a managed context, all this happens under the hood again this is brief and really simplistic explanation but that’s definitely a client/server architecture in work! the loaded DLL acts as the dealer and your application is the consumer, the only two things that are different between what I suggested and P/Invoke is the mechanism and the actual protocol.

.NET Foundation Website | Blog | Projects | Code of Conduct