.NETStandard support? #1190
Comments
|
@snickler we've been working through getting all the dependencies for ReactiveUI supporting Lots of these projects have preview packages available with netstandard support, but I'll defer to @ghuntley on whether |
|
@shiftkey Thanks for the reply! I'll definitely keep following to see what is decided. |
|
I'd be interesting as well in the latest story regarding NETStandard support for RxUI? |
|
I have tried to install RxUI to some .NET Standard libs and it didn't support it yet :( |
|
Thanks @ghuntley . I'll check out that branch and see if there's any way I can help. Is there any documentation on what specifically will break for those who would run into issues that would prevent the migration, or even a quick outline anywhere? Either way, I'd love to help out after I get a good look at it. |
|
Off the top of my head.
Come join us in Slack and make yourself known; would love some additional help. |
|
Has there been discussion about the viability of "adding support for netstandard and keeping PCL support too" instead of "switching from PCL to netstandard"? The nupkg would still contain what it does now. But it would also contain netstandard builds. There would be TFM-specific dependencies, so that each build would get the right version of RX. This worked out well for SQLitePCL.raw, so I'm curious if it could work here too. I wish the entire .NET world could all be on PCLs on a Friday and then all be switched over to netstandard on Monday, but it sure looks to me like the transition is going to be more gradual than that. So realistically, there will be a period of time when both need to be supported. |
|
That would actually be very nice to have both PCL and netstandard support. All I want is to be able to use either or, but eventually move all of my projects to fully embrace netstandard. If there's a way we can have both in the meantime via NuGet packages, then I wouldn't mind that. It's up to everyone else though.
|
|
Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles. |
|
Wouldn't this help to resolve the upgrade issues, though? There has to be a way to hold on to both PCL and NetStandard versions without generating more issues. If Rx30 isn't supported on Xamarin, then shouldn't try to install... right? If the PCL still meets all the dependencies then shouldn't it be the one to install or isn't there a way to force it to look at PCL only for the platforms that don't have all dependencies? Sorry if this mash of text is confusing.
|
|
Rx 3 is supported on Xamarin, not sure where that came from. Xamarin fully supports netstandard up to 1.6. Furthermore, the dependency resolution rules are that netstandard > portable-, so if both are in the package, you'll get the netstandard version. There's really no benefit to keeping portable around anymore; the tooling finally all supports netstandard. |
|
Oh, okay. That makes sense then. So, it would just be pointless to keep supporting both. Sorry about the confusion with my previous message, I misread one of the other issues and for some reason thought of Xamarin and Rx3. I'm all for just doing whatever we can to move towards .NETStandard then.
|
|
Ya; Rx30 is fine on Xamarin. The research task is what happens when you create a brand new class library from 2017 for netstandard using the new project system and then try to.open and compile on Xamarin Studio and Visual Studio for Mac. Can those products handle the changes to csproj introduced in 2017? |
|
"Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles." Interop between PCL and netstandard seems to be something that works much better in theory than in practice. And as far as I can tell, when a package attempts a black-and-white transition to netstandard, we end up with a bunch of edge cases that no longer Just Work. At the risk of going off topic, here's an example or two: Last week-ish, the maintainer of sqlite-net-pcl tried switching to netstandard. A bunch of his users had troubles of various kinds. I didn't look at the situation that carefully, so I don't know the details, but he ended up adding PCL support back in. I assume that was just the easiest way to get back to a Just Works condition. Here's the example from my current situation: I work on a project called Csf20 (a codename). It is a mobile app which supports iOS, Android, and UWP, and it has ASP.NET server elements as well. We have some developers on Visual Studio, and some on Xamarin Studio on Macs. We use Xamarin Forms, but also have some native UI stuff for Xamarin.Android and Xamarin.iOS. The solution has 19 projects in it. Our dependencies include Rx, ReactiveUI, SignalR, Newtonsoft.Json, SQLitePCL.raw, Xamarin Forms, a couple of Xamarin plugins, PCLStorage, modernhttpclient, and that's about it. We have a core library called Csf20.Common, which is very basic stuff used by both client and server code. This one has no dependencies. And we have another library called Csf20.Core, which is the bulk of the client code. This one depends on most of the packages mentioned above. Right now, we are on packages.config and PCL profile 151. Roughly every 4 weeks, I make an attempt to switch Common and Core to project.json and/or netstandard. I have hit some kind of an obstacle every single time. I try different levels of netstandard. I try different settings for the "imports" section under the framework in project.json. It just never quite works out. At one point, I realized that SignalR is one of the most problematic libraries. Its PCL profile is troublesome, and it is basically no longer being maintained because a rewrite is happening. So I took that one out of the mix by building it myself and referencing the assembly directly instead of using the nuget package. That gets me further, but the transition still fails every time. I usually assume that this has something to do with my skill level on issues related to PCLs and netstandard. More specifically, I assume that you ( @onovotny ) might be able to get all this working. The problem here is that even though my knowledge is well below yours, I'm pretty sure I am way above average. And that's kinda my point: Something that doesn't work unless you have the knowledge of @onovotny is a nearly perfect definition of something that works better in theory than practice. Unfortunately, Csf20 is not open source, or even publicly announced. So, asking for help is a bit tricky. I could post the specific errors I am encountering. But I would be asking someone (probably you) to assist in a context where you can't see the code. That's always tedious. If I were more confident that seeking help would be likely to result in some kind of benefit to the community, I would do so. So anyway, I've done this exercise 4 or 5 times now. Every four weeks I go through it again. Maybe I will learn something new. Maybe the tooling has improved. Maybe the packages I use have been updated to resolve some kind of issue. I have to believe that in practice, many developers who try to move to netstandard are experiencing problems. |
|
Not sure, but it is the way forward. project.json is gone. I imagine VSfM will get the full support of the sdk csproj because it has to. The bigger question is how it handles the Xamarin build targets, but there's a fairly easy answer there too -- can you open a Xamarin.Android/iOS project created on VS today in XS/VSfM? If yes, then things should continue to work. Essentially, what I've done to get Xamarin working with the SDK-style builds is to set the LanguageTargets import to the same thing the iOS/Android projects did individually. Of course, if you use UWP, then that cannot be built on Mac. |
|
@ericsink sorry to hear about your troubles, and I do agree that the tooling and experience today is hard. It really is with a mix of VS 2015/CLI/project.json, etc. Having used VS 2017 a lot lately, I do think it's getting better. Things like PackageRef to replace packages.config/project.json will go a long way towards unifying things. They will require people to be on either VS 2017 or the latest XS/VSfM though. For your case, I'd be happy to help if I can (sign an NDA if you want)/access a private repo. Perhaps if we can get you migrated, you can blog about it to share your learnings? |
|
I know Visual Studio for Mac will at least handle it. I haven't tried in Xamarin Studio at all. If it DOES work in Xamarin Studio, I'm assuming it will have to be one of the alpha builds. |
|
I would say that XS is pretty much dead with VSfM. Why would you have both? (I have no knowledge though in this area) |
|
I know some people that won't migrate to solely using VS for Mac because it's still in preview and since the Xamarin lib are running alpha. Me on the other hand, I ONLY use VS for Mac when I'm on it. |
|
That's fair, but that's a point-in-time thing. VSfM will come out of preview at some point :) |
|
Oh, I agree. For the most part VS4Mac has been pretty darn stable. VS2017 is stable enough for me now also. That's why I wanted to hop right into using .NETStandard with RxUI.
|
|
@onovotny Thanks. First, your offer of help is too generous to refuse, so I intend to take you up on it. I'd like to start by processing in the open as much as possible. Probably I should just begin another attempt, and then contact you with details when I get stuck. We can resort to giving you access to our project if that becomes necessary or if it becomes the best way to be considerate of your time. Hopefully this would result in a blog entry that is beneficial for others. I'll get back to you. Second: I love that my sob story caused you to offer help, but that's not really why I posted it. To review, you said: "Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles." And I replied with: "Interop between PCL and netstandard seems to be something that works much better in theory than in practice." And I was tempted to stop there, but I wanted to give more substance. The intent of sharing my story was to give one example of a situation that I think is probably common. Why would I want both PCL and netstandard? Because even though I love where things are going, it seems to me that netstandard mostly doesn't work yet, and PCLs still do. That's what I see. But your remark seemed to come from a different perspective. (begin digression about lack of civility in the .NET community) I see an enormous amount of frustration in the .NET community right now. And a lot of that frustration gets expressed as negativity and complaining and whining at Microsoft people. I cannot imagine how the .NET Core and the EF Core people maintain their patience with the kind of unconstructive and rude feedback they get every day. I could nominate a few Microsoft employees for some kind of sainthood. I know you are not a Microsoft employee, but I bet you get some of this junk thrown at you as well. The reality is that all this stuff right now is a mess, and a lot of the community frustration is very understandable. And yet, I still think this is the best time ever to be a .NET developer. A lot of .NET developers are upset and angry all the time. I'm just not. But if I were, I might have responded to your remark differently. Frustration plus PerspectiveDifference often equals VentedEmotions. (end digression) Anyway, like I said, your remark seems to come from a different perspective than mine. I wanted to communicate that difference and express my interest in understanding it better. |
|
@ericsink totally fair and welcome. Stuff has been moving really fast in this area over the past 18-24 months and it's really easy to see how people get frustrated. None of it was intentional on either side; I don't think any one on the Microsoft side would have predicted two years ago where we ended up today. A lot of it was trial-and-error and learning in the open. I think that process itself has been fascinating to observe as traditionally these things all happened behind closed doors. As to theory-vs-reality, I am genuinely curious to see how/why/where things fall apart because I really do feel peoples pain there and I don't want people to be in pain when working with .NET. I'd like to understand and help get people past that so they can get on with whatever it was they were trying to do. If there are actual blockers, that's when I try to raise issues with the appropriate teams to help ensure things are fixed. I think one of the major issues so far with .NET Standard libs being pulled into PCL's are the packages.config mess -- the fact that it puts tons of effectively "blank" entries in the file is annoying. That's where some band-aid's like using Anyway, the more I can capture from real-world scenarios, pain, good/bad, etc, the more I can relay things to the teams and help make sure that scenarios aren't overlooked and that things do "just work." That's really my end goal, to have this stuff "just work" without having to get into the weeds. Not quite there yet :) |
|
NETStandard 2 and once the tools for moving out of the project.json files is supposed to smooth a lot of this out isn't it? This doesn't really apply directly to ReactiveUI and the mobile world but the place with all this I've ran into the most issues is keeping my CI stuff working inside VSTS. For one of our current ASP.NET websites if I add a single netstandard library to it the entire VSTS thing just breaks. I can build in VS (with a csproj hack I found) but I can't get VSTS tools to work. I've seen similar complaints around github as it relates to msbuild so really just kind of hoping that once VS 2017 build tools are all more official that it will "just work". Right now a lot of those PCL libraries we use both places so if I switch my mobile stuff over to netstandard there's some up stream fall out with the websites right now It seems like waiting for VS 2017 official and maybe netstandard 2 will limit the hacks and refactors? I really hope XS isn't dead. I'm a big fan of just light weight specific IDEs these days. VS Code for all web and XS for all mobile. Hey look at that while typing this my VS crashed for some reason :-( Though to be fair I haven't tried VSfM so I should try it before I knock it... I'm curious how heavy it is given that I'm just using a little mac mini for all things XS |
|
@PureWeen You should really try VSfM. It's the same as XS and MORE. I haven't opened XS since (well I did and happened to accidentally install an XS update which blew up MSBuild for me lol). It's been very stable for me. |
|
@snickler ....... Well it's good to hear that... I'll give it a try :-) I've never quite been able to get the Xaml Previewer stuff to work right so be neat if that's a bit better over in VSfM world. Also over in the slack channels there always seems to be lots of grumblings around problems with VS 2017 so it's just made me cautious overall with these things. The last standup I watched they talked about how VS 2017 would mess up x64 targeting and you had to go in and modify some targets to fix... So yea.... Cautious I've been :-) If it's not broke don't fix it right? But I guess then you miss out on all the new fun :-p |
|
@PureWeen the only issues I've had with VS2017 were fixed in the latest preview. I had some REALLY messed up issues with it crashing to hell and back. I still have some issues where VS2017 gives up caring about the iOS build server connection and doesn't want to build anything anymore, requiring a restart of the app. Other than that, things have been very usable for me. |
|
Am I right in saying that assembly redirects (as a stopgap) are not feasible? That is, swapping in the Rx 3 DLLs whenever the 2.2.5 DLLs are requested. I did a quick look into this and promptly came to the conclusion that this won't work because the public key has changed, but never actually validated. This seems a major bummer because otherwise people could have forced the usage of whichever version they like.
Frankly, I'm ready to make the jump as soon as the surrounding ecosystem does. In fact, I've left all relevant genesis libraries in alpha purely because I intend jumping to Rx3 before releasing them proper. |
Yeah, we had to change the public key because it was shared with the .NET Framework. See also dotnet/reactive#205 which discusses versioning changes due to netstandard. |
That's totally reasonable. Would be declaring the 7.x series as legacy and moving more aggressively towards .netstandard and System.Reactive 3.x an option? |
|
re: when Now that VS2017 is stable. I'm wondering if Xamarin Studio supports the new VS2017 project format yet? If so; it's time to start aggressively moving towards netstandard + dropping legacy platforms which don't work in VS2017 (such as Windows Phone/Store etc) |
|
VS for Mac Preview has supported it. I doubt they will add it to Xamarin Studio. |
|
I'm currently in the middle of converting some stuff over to the netstandard/vs2017 formats and just wanted to confirm that XS on Mac and Windows does not support the new VS2017 format As the others mentioned I wouldn't hold your breath :-) |
|
I believe VS for Mac which is now released supports the new VS2017 formats. It's not the official replacement for XS for Mac. As mentioned here https://releases.xamarin.com/category/visual-studio-for-mac/ : |
|
netstandard merged a couple days ago into the |
|
Awesome, what are the details for the myget? |
|
Awesome - thanks! // EDDY |
|
What is the current state of ReactiveUI Preview 8.0? I'm trying to use it in a Xamarin Forms project but is getting this error when trying to compile for Android:
The project compiles and work with UWP. Also, the preview-release link above is broken. |
|
@1iveowl please open a new issue with details about your setup and repro, so we can dig into it. |
|
Closing out this issue. We have started pushing V8 prerelease builds to NuGet.org. Please open a GitHub issue for any friction you experience (if at all). Thankyou. |
Hi all,
I recently decided to switch PCLs of a project I'm starting on to target .NETStandard v1.1, as I wanted to get on the future bandwagon. As you can guess, it failed due to dependencies (although the RX libraries that are used as dependencies have updated .NETStandard versions). Are there any plans for the future to move add in .NETStandard support? I can easily revert back to my previous PCL profiles to move forward, it's nothing that's stopping me, just wondered.
Thanks!
For reference:
Package reactiveui-core 6.5.2 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package reactiveui-core 6.5.2 supports:
Package Splat 1.4.0 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Splat 1.4.0 supports:
Package Rx-Interfaces 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Interfaces 2.2.5 supports:
Package Rx-Core 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Core 2.2.5 supports:
Package Rx-Linq 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Linq 2.2.5 supports:
Package Rx-PlatformServices 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-PlatformServices 2.2.5 supports:
One or more packages are incompatible with .NETStandard,Version=v1.1.
The text was updated successfully, but these errors were encountered: