Deprecate/drop `Windows.Devices` namespace in favour of `System.Device`
Closed this issue · 14 comments
This brings it inline with expected .netCore 5 namespaces and would aid compatibility towards .Net Standard support.
Mark old classes with something lke
[ObsoleteAttribute("This namespace is obsolete. Use System.Device namespace instead.", true)]
I second the change.
PR for DAC nanoframework/System.Device.Dac#24
PR for Gpio nanoframework/Windows.Devices.Gpio#134
And would be great if the API can aligned with https://github.com/dotnet/iot/tree/master/src/System.Device.Gpio. That would make it easier to switch and share some code between both nanoFramework and .NET IoT.
And would be great if the API can aligned with https://github.com/dotnet/iot/tree/master/src/System.Device.Gpio. That would make it easier to switch and share some code between both nanoFramework and .NET IoT.
That's exactly the plan. Now that we've decided to move away from the UWP API, that's the next one we plan to adhere to.
Are you willing to give us a hand with this?
This is not a challenging task, just that it takes time, has most methods just need renaming and others parameters tweaking. Not to mention the documentation comments.
Anything needed to be changed at the native end we can take care of it.
Let me know. 🙂
will you provide nano version of the System.Device.Gpio package (perhaps with some stuff stripped off)? I'm in favor of having IoT repo sharing some code with this if so (there are likely only few classes which need sharing) but we'd need to add some kind of CI to make sure we don't break anything by accident in the future. We're fine with adding some ifdefs in the code or something to make it easier for nano. Would be nice to be able to get Iot.Device.Bindings (or at least large part of it) to work on nano
Are you willing to give us a hand with this?
Yes and as @krwq mentionned, we need to decide what to keep and what to remove also the interfaces. A lot of the bindings we have in .NET IoT are using Span and the functions from nanoFramework are all byte[]. Later today as soon as I'll have a little bit of time I'll publish the work I've been doing with Span and simple wrapper over I2C and Gpio. So a large part of the work is already done as well.
@josesimoes so posted the last week evening and weekend work here: https://github.com/Ellerbach/nanoFrameworkIoT
@krwq @Ellerbach that's awesome! 👏
I just did a quick check on the GPIO classes on IoT Core and that's pretty much as I remember it. Which is good as most of it is the same or very close to what we have.
Here's my suggestion: baby steps. Let's start with GPIO before moving to others (I2C, etc) this can be a PoC and we can learn from the process what's the best way to tackle it.
Any changes required at the native end: we can accommodate that easily.
On the code sharing: that would be great. Let's find out what's the best and efficient way to make that happen. That doesn't prevent that work is started on the API migration.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Very much active
⚠️ ALL WINDOWS.DEVICES libraries will have one last stable release published on the next release cycle.
Following which the repositories will be archived and the libraries won't receive any further updates.
@josesimoes , before this issue is closed, we should also make sure there are no [active] samples that use it (or archive them)...
We also need to purge any documentation that relies on them, and (if necessary) let people know they need to update their cmake-variants.json files...
Note that the Can namespace is still behind...