Iot: PlatformNotSupportedException is raised when access PinValue

[maxim-tkachenko]

I'm getting PlatformNotSupportedException when access PinValue:
var value = PinValue.High;

System.PlatformNotSupportedException: Operation is not supported on this platform. at System.Device.Gpio.PinValue.get_High()
Why does it happen? PinValue doesn't have anything platform specific. I'm running the code on Mac.

[joperezr]

Hey @maxim-tkachenko, currently we only have implementation for Linux and Windows of all the libraries types, but for mac we have a tool that will automatically generate all the code that throws platform not supported exception for all methods in all types. This includes property getters like the one you are seeing. The reason why we have this is because we didn't expect our library to run in mac yet, as we are not aware of Gpio Access in OSX. What are you trying to use PinValue.High for when running in MAC? Is what you are trying simply to write your code on mac but run it in a device like a raspberry Pi?

[maxim-tkachenko]

hi @joperezr, thanks for the answer, didn't know about the tool for mac. Yes, I have a dev environment on mac but run on the raspberry. I've mocked GpioController for debug builds, but since another base library types (like PinValue) doesn't implement any specific interfaces, there is no way to do it. The only way currently I see is to create some adapter class which will work with all library specific types. Is it possible do not throw the not supported exception for the common types of all platforms? Maybe I'm not the only one who develop on the mac :)

[joperezr]

I see, yeah you are definitely not the only on developing on mac, but most consumers of our library won't try to run their app on the mac while developing as for most cases, the app is very dependent on the actual hardware they are running in so it doesn't make much sense to run in an environment that lacks all the hardware requirements (like Gpio Pins). Unfortunately I don't believe there is an easy way of customizing the tool we use today so that it won't generate PNSE methods everywhere and selectively implement methods like properties. What this tool basically does, is to take an existing assembly (which in our case it just takes our linux implementation assembly) and it decompiles and generates c# code for it which will have PNS Exception on all methods. All that said, PinValue is a struct which has implicit converters for bools, so I'm not sure how is it that you are using it in your code but technically you could do something like:

c# PinValue value = true; // This is equivalent to saying PinValue.High PinValue value2 = false; // This is equivalent to saying PinValue.Low

[maxim-tkachenko]

unfortunately, operator overloads throw the same PlatformNotSupportedException

[joperezr]

I see, I checked and the tool that we use to generate the not supported code does have an argument that can be passed in order to not throw PNSE for some APIs, so we could in theory fixed this for few types like PinValue. That said, I suppose that PinValue is being read from a controller in your code which you already have to mock anyways since that one won't work on a MAC either, so as a workaround would it be possible to refactor your code so that wherever you are mocking the calls to GpioController you would also deal with PinValues so that your not-mocking code won't depend on PinValue?

[maxim-tkachenko]

yeah, that's what I meant when was writing about adapter class. And it's only way currently I see to achieve my needs.

[joperezr]

I see, we'll keep this issue open in order to explore if we can modify the tool we use today to generate the code to instead not generate platform not supported for certain types.

[DavidKarlas]

I ran into same problem today, with GpioDriver constructor...
If you don't care about what happens on macOs, why did you make tool that injects exceptions?

My use case is... I want to write custom GpioDriver that talks with Arduino(with custom .ino) over serial and expose Arduino pins, so I can do whole logic in C# on Mac/Linux/Windows...

[DavidKarlas]

For anyone who also runs into this issue, do cp ~/.nuget/packages/system.device.gpio/1.0.0/runtimes/linux/lib/netstandard2.0/* ~/.nuget/packages/system.device.gpio/1.0.0/lib/netstandard2.0/ as workaround and rebuild your project.

[pgrawehr]

@joperezr Maybe we could include a simulation implementation instead of the NotSupported implementation? In a first version, this would probably just act as a Null device, but could be extended up to something that reads diagrams and simulates them.

[madameczek]

I faced PlatformNotSupportedException as well. Target linux-arm platform Raspberry Pi 4 (Raspbian buster), .NET Core on Pi 3.1.301.
Firstly on OpenPin().
Then replaced System.Device.Gpio 1.0.0 to 1.1.0-prerelease.20276.1.
Now the exception is thrown on creating GpioController. It is detected by debugger, but doesn't fall into catch statement.
A pin can be opened and written, at least.

[Ellerbach]

@madameczek this is related to latest RPI4 raspbian update. This has been fixed few days ago.
Please use the lastest should be 20508.1 and that should solve your issue.

[madameczek]

Thx for info. After OS upgrade, issue is solved.

[Ellerbach]

Great, thanks @madameczek, so closing the issue!

[DavidKarlas]

@Ellerbach Original bug is about exception on macOs which is not fixed as far as I understand

[Ellerbach]

@DavidKarlas so reopening it!

[pgrawehr]

@Ellerbach : I have no mac, so I cannot verify, but I do believe the issue is solved with the removal of the platform dependent assemblies. The main problem was that for any unsupported OS, an assembly was used that consisted only of PNSE.
Applications such as the one mentioned above, with an Arduino on Mac or Windows are possible now (PR pending)

[joperezr]

What @pgrawehr says above is correct. The PNSE issue has been fixed post 1.0 when we removed platform specific implementations. Closing again 😄