Installing this library in a .NET Core 3 project causes a compile-time warning NU1701: Package 'WindowsDevicePortalWrapper 0.9.5.1' was restored using '.NETFramework,Version=v4.5.2' instead of the project target framework '.NETCoreApp,Version=v3.1'. This package may not be fully compatible with your project. In addition, it looks like the most recent commit depends on a .NET Framework-only API for System.Net.Configuration.
For WDPW to properly support .NET Core tools, this project should be upgraded to create a .NET Standard package, so consumers don't get warnings and developers get access to new APIs related to HTTP and WebSockets such as
ClientWebSocketOptions.RemoteCertificateValidationCallback.
I went ahead and made some changes to replace the UWP project with a standard multi-target library, and I've confirmed the unit tests and samples work now in .NET Core 3.1. I wasn't sure if the current "shared project" approach would work with this, so I just merged them all into the main project.
Installing this library in a .NET Core 3 project causes a compile-time warning
NU1701: Package 'WindowsDevicePortalWrapper 0.9.5.1' was restored using '.NETFramework,Version=v4.5.2' instead of the project target framework '.NETCoreApp,Version=v3.1'. This package may not be fully compatible with your project.In addition, it looks like the most recent commit depends on a .NET Framework-only API for System.Net.Configuration.For WDPW to properly support .NET Core tools, this project should be upgraded to create a .NET Standard package, so consumers don't get warnings and developers get access to new APIs related to HTTP and WebSockets such as
ClientWebSocketOptions.RemoteCertificateValidationCallback.I went ahead and made some changes to replace the UWP project with a standard multi-target library, and I've confirmed the unit tests and samples work now in .NET Core 3.1. I wasn't sure if the current "shared project" approach would work with this, so I just merged them all into the main project.