How to impliement custom DLL with interop

[Untitled86]

I don't know if this question is out of scope or not for this repo. But it's very useful to be able to add a bit of native code and invoke it from .NET. I think GHI did a great job with their OSHW library and I'm trying to use that as a template for myself.

I've added GHI's OSHW library from the community edition of v4.3 to my v4.4 code base. My .NET code runs fine, but there's something wrong with calling my native code via interop. Unfortunately whenever I call my DLL's methods with interop signatures I get...

Exception System.NotSupportedException - CLR_E_NOT_SUPPORTED (1)

What I have done is...

1. Copied in the DeviceCode\GHI files.
2. Modified TinyCLR.proj to include GHI's files (based on the v4.3 TinyCLR.proj)
3. Built the DeviceCode\GHI\Libraries\GHI.OSHW.Hardware\Managed project using v4.4
4. Copied the resulting stubs into DeviceCode\GHI\Libraries\GHI.OSHW.Hardware\Native
5. The generated cpp file for my custom class is basically empty, I only added "hr = S_OK;" just to test the functionality.
6. Run msbuild on the folder in step 4.
7. Rebuilt TinyCLR and deployed that to device.
8. Added reference to the generated GHI.OSHW.Hardware.dll in a new test project.
9. Deployed and executed my test project on my device which attempts to call a method of a custom class in the DLL I've made.

Even trying to just call GHI's methods with interop signatures results in the same error. I figure I'm missing some configuration step. If anyone else has ran into this problem I'm hoping they can save me the time of tracking down the issue. Otherwise I'll post back here once I've found it myself.

[piwi1263]

Maybe this might help a bit in finding a solution.

https://jsimoesblog.wordpress.com/2016/08/12/interop-in-netmf/

[Untitled86]

@piwi1263 Nice blog article, that sorted things out.

This was my problem, the generated featureproj file had this line...

<MMP_DAT_CreateDatabase Include="$(BUILD_TREE_CLIENT)\pe\$(ENDIANNESS)\GHI.OSHW.Hardware.pe" />

Hardcoding the path like this (following your blog article) fixed my issue...

<MMP_DAT_CreateDatabase Include="C:\NetMf44\DeviceCode\GHI\Libraries\GHI.OSHW.Hardware\Managed\obj\Release\$(ENDIANNESS)\GHI.OSHW.Hardware.pe" />

And then finally I fixed it so it wasn't hardcoded for my root...

<MMP_DAT_CreateDatabase Include="$(BUILD_TREE_CLIENT)\..\..\..\..\DeviceCode\GHI\Libraries\GHI.OSHW.Hardware\Managed\obj\Release\$(ENDIANNESS)\GHI.OSHW.Hardware.pe" />

[smaillet-ms]

Interop is something I'd like to do better in vNext. Some of the major goals I've been thinking through with this whole PAL/HAL rework covers interop - including:

1. Consistent interface for PAL components and interop
2. Reduce the number of assemblies that MUST be included in a NETMF image. Leave the rest to deployment time.
3. Dynamic discovery of native side (e.g. native side can be added to a device after the initial image is created and so can the managed side) with well defined failure cases.
   • while releasing a combined assembly seems like a good idea it doesn't work when considering that NETMF is architecture neutral. That said, theoretically at least, we could support multiple native code images bundled that are filtered at deployment time. However, that just seems like more work than is really needed. If we can treat native code like an assembly for deployment purposes a NUGET or other package with binaries for multiple targets could work just as well. If a binary doesn't exist for the attached target for deployment, then an error could be produced at deployment time.
4. Dynamic marshalling based on metadata in the assembly so there isn't a need for generating stubs or linking to them.

Number 4 is a big stretch goal and, even if implementable, might not be as performant as a pre-generated stub - some A/B testing will be required.