search

jcurl / RJCP.DLL.SerialPortStream

SerialPortStream is an independent implementation of System.IO.Ports.SerialPort and SerialStream for better reliability and maintainability. Default branch is 2.x and now has support for Mono with help of a C library.
Microsoft Public License
639 stars 199 forks source link

The wrong depency issue with nuget package #45

Closed HobDev closed 6 years ago

HobDev commented 6 years ago

The nuspec has a dependency: dependency id="Microsoft.Win32.Registry" version="[4.3.0, )" . but it should be updated to 4.4.0 to work on Xamarin.iOS/Xamarin.Mac projects.

jcurl commented 6 years ago

Thanks, saw your message via NuGet. I don't have a Mac, don't know how to create a test case for this. Looking ta the GIST file you sent, the following error is present:

For adding package 'Microsoft.Win32.Registry.4.3.0' to project 'MacApp' that targets 'xamarinmac20'.
--
Install failed. Rolling back...
Package 'Microsoft.Win32.Registry.4.3.0 : Microsoft.NETCore.Platforms [1.1.0, ), System.Collections [4.3.0, ), System.Globalization [4.3.0, ), System.Resources.ResourceManager [4.3.0, ), System.Runtime [4.3.0, ), System.Runtime.Extensions [4.3.0, ), System.Runtime.Handles [4.3.0, ), System.Runtime.InteropServices [4.3.0, )' does not exist in project 'MacApp'
 
...
 
Package 'Microsoft.Win32.Registry.4.3.0 : Microsoft.NETCore.Platforms [1.1.0, ), System.Collections [4.3.0, ), System.Globalization [4.3.0, ), System.Resources.ResourceManager [4.3.0, ), System.Runtime [4.3.0, ), System.Runtime.Extensions [4.3.0, ), System.Runtime.Handles [4.3.0, ), System.Runtime.InteropServices [4.3.0, )' does not exist in folder '/Users/vince/Projects/MacApp/packages'
Removing package 'System.Runtime.InteropServices.4.3.0' from folder '/Users/vince/Projects/MacApp/packages'

Given that this works for the NetStandard that is targetting (it was the IDE itself that provided these versions), isn't this more a problem with Xamarin?

If I update the version, I'm concerned that other installations would break on Windows that don't have this problem. Are there any documented workarounds for Xamarin?

HobDev commented 6 years ago

If needed you can use my mac via chrome Remote Desktop or Team Viewer for development of this package.

HobDev commented 6 years ago

I think the development is stagnant on this repo. This can be upgraded with new tools and dependencies.

jcurl commented 6 years ago

Why should the tools and dependencies be upgraded? The target is NET 4.0 and early versions as this is what I need. Have you tried to provide the packages explicitly yourself? The NuGet package says that the minimum version must be 4.3.0, but no reason why you can't include 4.4.0 for your package. I can't help it if other repositories that I can't support are broken.

tmatthey commented 6 years ago

Just my 2 cents. I did a spike on the project file using new project definition to put all targets NET40 and .net15 into one project file.

It looks like that Microsoft.Win32.Registry initial & first support is 4.4 for Xamarin., Mono and .NETStandard 2.0. I'm not sure how the versions are resolved, but I cannot see that Microsoft.Win32.Registry 4.4 has any implication to the rest with 4.3 for the .net11 or .net15 targets (looks pretty selc-contained); NuGet update does also suggest to only upgrade Microsoft.Win32.Registry from 4.3 to 4.4, where as keeping the rest 4.3.

jcurl commented 6 years ago

So I read this comment here:

I don't think there is much we can do. The owner of the SerialPortStreamCore would be the one that needs to do some work to support this scenario.

This is not feasible. The code to actually use the registry is only being done in the Windows implementation. But because a single binary is being used for Windows as well as non-Windows (that's the whole idea of .NET, why should I build target specific solutions for .NET?) the reference to the registry is the same no matter the target.

What is different is that the classes in the Registry assembly are only being instantiated when the run-time is Windows.

The comment is not very helpful. First the exception shows it is being raised by the runtime, not by my code (there's no reference to my code in the backtrace).

A similar situation exists when running under Linux. Windows also pulls in Mono.Posix (which isn't Windows relevant), but works entirely as expected, so long as the Windows code doesn't execute anything from Mono.Posix. So why should it be different here for the Registry?

Note, alternatives by only loading the registry under Windows could be investigated, but for the NETSTANDARD 1.5, I still need to reference it else Windows clients under NetStandard1.5 using dotnet core would lose out (not acceptable), unless the reference to the registry is in NuGet, which is precisely your problem.

Hence, it must be solved in the implementation on Mac to provide a dummy Registry component so that a single binary can be deployed for all machines.

Closing this topic.