Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NETStandard support? #1190

Closed
snickler opened this issue Nov 3, 2016 · 45 comments
Closed

.NETStandard support? #1190

snickler opened this issue Nov 3, 2016 · 45 comments

Comments

@snickler
Copy link

snickler commented Nov 3, 2016

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:

  • monoandroid (MonoAndroid,Version=v0.0)
  • monomac (MonoMac,Version=v0.0)
  • monotouch (MonoTouch,Version=v0.0)
  • net45 (.NETFramework,Version=v4.5)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • win8 (Windows,Version=v8.0)
  • wp8 (WindowsPhone,Version=v8.0)
  • xamarinios10 (Xamarin.iOS,Version=v1.0)
  • xamarinmac10 (Xamarin.Mac,Version=v1.0)
    Package Splat 1.4.0 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Splat 1.4.0 supports:
  • monoandroid (MonoAndroid,Version=v0.0)
  • monomac (MonoMac,Version=v0.0)
  • monotouch (MonoTouch,Version=v0.0)
  • net45 (.NETFramework,Version=v4.5)
  • netcore45 (.NETCore,Version=v4.5)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • wp8 (WindowsPhone,Version=v8.0)
    Package Rx-Interfaces 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Interfaces 2.2.5 supports:
  • net40 (.NETFramework,Version=v4.0)
  • net45 (.NETFramework,Version=v4.5)
  • portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
  • portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • sl5 (Silverlight,Version=v5.0)
  • win8 (Windows,Version=v8.0)
  • wp71 (WindowsPhone,Version=v7.1)
  • wp8 (WindowsPhone,Version=v8.0)
    Package Rx-Core 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Core 2.2.5 supports:
  • net40 (.NETFramework,Version=v4.0)
  • net45 (.NETFramework,Version=v4.5)
  • portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
  • portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • sl5 (Silverlight,Version=v5.0)
  • win8 (Windows,Version=v8.0)
  • wp71 (WindowsPhone,Version=v7.1)
  • wp8 (WindowsPhone,Version=v8.0)
    Package Rx-Linq 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Linq 2.2.5 supports:
  • net40 (.NETFramework,Version=v4.0)
  • net45 (.NETFramework,Version=v4.5)
  • portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
  • portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • sl5 (Silverlight,Version=v5.0)
  • win8 (Windows,Version=v8.0)
  • wp71 (WindowsPhone,Version=v7.1)
  • wp8 (WindowsPhone,Version=v8.0)
    Package Rx-PlatformServices 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-PlatformServices 2.2.5 supports:
  • net40 (.NETFramework,Version=v4.0)
  • net45 (.NETFramework,Version=v4.5)
  • portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
  • portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
  • portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
  • portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
  • sl5 (Silverlight,Version=v5.0)
  • win8 (Windows,Version=v8.0)
  • wp71 (WindowsPhone,Version=v7.1)
  • wp8 (WindowsPhone,Version=v8.0)
    One or more packages are incompatible with .NETStandard,Version=v1.1.
@snickler
Copy link
Author

snickler commented Nov 3, 2016

Oh , I just read #1132. I'm assuming this and #1134 will eventually result in achieving the request?

@shiftkey
Copy link
Contributor

shiftkey commented Nov 3, 2016

@snickler we've been working through getting all the dependencies for ReactiveUI supporting netstandard before we can talk about netstandard support in RxUI. You can see the original notes here: #1132.

Lots of these projects have preview packages available with netstandard support, but I'll defer to @ghuntley on whether netstandard support is still in scope for ReactiveUI 7 - as mentioned in #850

@snickler
Copy link
Author

snickler commented Nov 3, 2016

@shiftkey Thanks for the reply! I'll definitely keep following to see what is decided.

@oliverw
Copy link
Contributor

oliverw commented Dec 4, 2016

I'd be interesting as well in the latest story regarding NETStandard support for RxUI?

@SuperJMN
Copy link

I have tried to install RxUI to some .NET Standard libs and it didn't support it yet :(

@ghuntley
Copy link
Member

ghuntley commented Jan 23, 2017

@snickler, @oliverw, @shiftkey and @SuperJMN. I've put this on hold until v7 stabilises as migration to netstandard at this stage will create a rift of those who can migrate and those who cannot. I (as in personally) specifically do not want to be concurrently supporting v7 (rx2) and v8 (netstandard/rx3) at the same time.

  1. I would like to see the following investiged/closed out before switching to netstandard only:
  1. Check out the netstandard branch on GitHub if you would like to help with progressing v8; let's talk.

  2. We would <3 to and intend to grow our team in 2017. Additionally there's some open-pull requests and GitHub

@snickler
Copy link
Author

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.

@ghuntley
Copy link
Member

ghuntley commented Jan 25, 2017

Off the top of my head.

  • Xamarin Forms is still PCL.
  • There are users that have dependencies that have not upgraded to RX3 yet. If we goto RX3 too soon it creates a python2 vs Python 3 adoption situation. I'm ready to do the jump once all of the above issues are investigated and at least one other maintainer signs off that the timing is right. This should involve looking at other dependencies commonly used such as Akavache and Lager (at min) but also includes @kentcb's genesis libraries. PR the ecosystem up and then make the jump has been the strategy so far.
  • Tooling is still rough; that branch was done in 2015 and a bunch of hacks/approaches are used to make it work. Best explained on video chat. Would be keen to migrate to pure VS2017 and the new csproj format now at AppVeyor has a build template. The Xamarin Studio story of compatibility needs to be checked as forcing RxUI source debugging to be only possible with VS2017 if XS doesn't support it is a no-go. Thus there's a research task you could do immediately. File new in project vs2017 and then try compiling that class library in XS/VS Mac.

Come join us in Slack and make yourself known; would love some additional help.

@ericsink
Copy link

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.

@snickler
Copy link
Author

snickler commented Jan 25, 2017 via email

@clairernovotny
Copy link
Member

Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles.

@snickler
Copy link
Author

snickler commented Jan 25, 2017 via email

@clairernovotny
Copy link
Member

clairernovotny commented Jan 25, 2017

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.

@snickler
Copy link
Author

snickler commented Jan 25, 2017 via email

@ghuntley
Copy link
Member

ghuntley commented Jan 25, 2017

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?

@ericsink
Copy link

"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.

@clairernovotny
Copy link
Member

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.

@clairernovotny
Copy link
Member

@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?

@snickler
Copy link
Author

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.

@clairernovotny
Copy link
Member

clairernovotny commented Jan 25, 2017

I would say that XS is pretty much dead with VSfM. Why would you have both? (I have no knowledge though in this area)

@snickler
Copy link
Author

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.

@clairernovotny
Copy link
Member

That's fair, but that's a point-in-time thing. VSfM will come out of preview at some point :)

@snickler
Copy link
Author

snickler commented Jan 25, 2017 via email

@ericsink
Copy link

@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.

@clairernovotny
Copy link
Member

@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 project.json with csproj in 2015 can help, but it's not a total fix.

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 :)

@PureWeen
Copy link
Contributor

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

@snickler
Copy link
Author

@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.

@PureWeen
Copy link
Contributor

@snickler .......
http://pertobello.files.wordpress.com/2012/06/radiohead-fry-squinty-eyes.jpg

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

@snickler
Copy link
Author

@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.

@ghuntley
Copy link
Member

ghuntley commented Feb 9, 2017

@kentcb
Copy link
Contributor

kentcb commented Mar 6, 2017

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.

also includes @kentcb's genesis libraries

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.

@shiftkey
Copy link
Contributor

shiftkey commented Mar 6, 2017

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.

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.

@ghuntley ghuntley added this to the 8.0.0 milestone Mar 6, 2017
@oliverw
Copy link
Contributor

oliverw commented Mar 14, 2017

@ghuntley

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.

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?

@ghuntley
Copy link
Member

ghuntley commented Mar 14, 2017

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)

@snickler
Copy link
Author

VS for Mac Preview has supported it. I doubt they will add it to Xamarin Studio.

@oliverw
Copy link
Contributor

oliverw commented Mar 14, 2017

@snickler @ghuntley Considering that Xamarin Studio is most likely dead after the arrival of VSfM and VSfM supporting the VS2017 Project Format, I'd say it's time to move on.

@PureWeen
Copy link
Contributor

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 :-)

@glennawatson
Copy link
Contributor

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/ :
Visual Studio for Mac is now generally available as announced at the Microsoft Build conference. It is the recommended environment for Xamarin developers on Mac moving forward. To get started with Visual Studio on Mac, download and run the Visual Studio for Mac installer. It will install Visual Studio for Mac as a new app alongside Xamarin Studio.

@ghuntley
Copy link
Member

ghuntley commented May 30, 2017

netstandard merged a couple days ago into the develop branch and is now available from our MyGet feed. Visual Studio for Mac and Visual Studio 2017 are now min IDE targets.

@glennawatson
Copy link
Contributor

Awesome, what are the details for the myget?

@DevEddy
Copy link

DevEddy commented Jun 4, 2017

Awesome - thanks!

// EDDY

@1iveowl
Copy link

1iveowl commented Aug 9, 2017

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:

Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'ReactiveUI, Version=8.0.0.0, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile?
File name: 'ReactiveUI.dll'

The project compiles and work with UWP.

Also, the preview-release link above is broken.

@shiftkey
Copy link
Contributor

shiftkey commented Aug 9, 2017

@1iveowl please open a new issue with details about your setup and repro, so we can dig into it.

@ghuntley
Copy link
Member

ghuntley commented Sep 1, 2017

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.

@ghuntley ghuntley closed this as completed Sep 1, 2017
@lock lock bot added the outdated label Jun 24, 2019
@lock lock bot locked and limited conversation to collaborators Jun 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests