The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop

[kevinchalet]

Edit: the "no .NET Framework support for ASP.NET Core 2.0" plan has been officially cancelled and running ASP.NET Core 2.0 on .NET Desktop will be supported in the next previews. For more information, read Announcing ASP.NET Core 2.0.0-Preview1 and Updates for .NET Web Developers or watch .NET Standard 2.0 and .NET Core 2.0.

I'd like to thank everyone for taking the time to participate to this thread ; no doubt it helped make the Microsoft heads realize that they couldn't silently adopt such a major breaking change at the last minute without consulting their community or measuring the actual impact of their unilateral decisions on the entire ecosystem.

Even though we all had different opinions, the most important thing was to have a real discussion about this change. It's clearly a huge - and unprecedented - success (>150 participants and more than 700 messages, woot!)

It's amazing to see such a great community in action, I'm so proud of being part of it 🤙

---

Original message: earlier today, most of the ASP.NET Core 2.0 packages were updated to target netcoreapp2.0 instead of netstandard1.* and net4* (e.g aspnet/Security#1203 and aspnet/Mvc#6234), making them totally incompatible with .NET Desktop and Mono.

Although this major breaking change is likely to have a huge impact on the entire ASP.NET ecosystem, it was neither discussed nor announced publicly (demonstrating once again that the ASP.NET team is not very good at communicating and is not really willing to discuss such important changes with its community, but that's another story).

In this thread, @Eilon partially mentioned the reasoning behind this decision, but didn't say whether less extreme options have been considered or not (e.g cross-compilation, introduction of a netstandard2.1 TFM, etc.):

Yes, for ASP.NET Core 2, most of the libraries will target .NET Core 2 in order to use new APIs that are not yet available in a .NET Standard TFM. Code that needs to target multiple platforms, such as Microsoft.Extensions.*, Entity Framework Core, and a few other libraries, will continue to use .NET Standard.

My question is simple: are you going to amend/revert these changes at some point before RTM, so people can use the ASP.NET Core 2.0 packages on .NET Desktop, or is ASP.NET Core 2.0 on .NET Desktop definitely dead? (which would be a major blocker for many people, including me).

Thanks.

[gulbanana]

This would be an extremely weird and bad change to make. I have written a lot of netfx-only asp.net core code and do not want to see that investment wasted. More generally, .NET customers are going to need to be able to interoperable between ASP.NET Core and Desktop code for the foreseeable future - imagine webapps which use Active Directory, or Office COM automation, or which do thumbnailing using some System.Drawing based library, or share code with a WPF app. It's trivial to think of a lot of scenarios like this and I hope we've simply misunderstood what's going on.

[ctolkien]

We're currently on AspNetCore 1.1.1 - i.e, the "current" support branch. If we cannot move to 2.0 due to dependencies on Net4XX, does that mean we'll be unsupported when 2.0+3months drops?

[MJomaa]

We use a combination of WPF and ASP.NET Core and target in both cases the full framework.
So I guess no 2.0 in the foreseeable future?

[aL3891]

But full framework 4.6.1 will support netstandard 2? am I missing something? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

isn't this that the current tooling isn't updated?

[gulbanana]

it would be totally fine and expected to see asp.net core running on netstandard 2. the alarming thing is this prospect of moving to netcoreapp2.0, which would imply no longer being able to use legacy code inside of asp.net core websites

[aL3891]

oh, that's an issue.. I suppose though that its mitigated a little by the compat shims in netcore2 that allows you to reference old assemblies, but still, it means porting all projects to the new project system and a lot of other work..

Would be nice to hear the teams reasoning on this

[gulbanana]

oh, so you think that netcoreapp2.0 projects will simply be able to reference netfx libs thanks to type unification? that would explain a lot. my question, if so, is how much code will actually work when run on windows but on the core CLR..

[nphmuller]

Wow. This would be totally blocking for us and basically make sure we could never update these packages for the far foreseeable future. We even might need to migrate our MvcCore project back to Mvc, because we currently cannot get around targetting net462+.

[NickCraver]

I'm extremely curious about this as well. I'm really hoping this in an intermediate (and short lived) step or a big miscommunication. It would certainly be a blocker to adoption for most of our applications as well.

Moving everything to Core is just too much for a large existing codebase (without stopping dev to do it), moving to the new ASP.NET Classes (HttpRequest, controllers, etc.) as an intermediate step has to happen for our main projects.

Perhaps @DamianEdwards or @davidfowl can comment on plans here? I'm also having trouble finding any additional reasoning.

[shanselman]

I can see why this is initially a scary WTF moment. Let me explain because it’s less freaky than it seems.

• You said .NET customers are going to need to interoperate. Totally agree.
  • We can share netstandard libraries between ASP.NET Core 2.0 and EVERYWHERE.
  • We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20
• You said WebApps may need to use:
  • AD – Totally, this is a gap IF you want to call LDAP directly. You can certainly auth against Windows Auth NOW. We plan to have specifically the DirectoryServices namespace for Core 2.0 around summer timeframe
  • Drawing – Totally, this is a gap. We plan to have this for Core 2.0 around summer timeframe. Until this, these netstandard options also exist ImageSharp, ImageResizer, Mono options, etc
  • COM Automation – This has never been possible under Core 2.0, but you can certainly PInvoke if you want to hurt yourself. You could also local WebAPI to a net461+ process if you really want to hurt yourself.
  • Sharing code with WFP Apps – YES. Totally possible with netstandard2.0.
• This is a weird change to make.
  • Feels like it but…

Think about it this way. WPF isn’t netstandard2.0, it knows it’s on net461+ and that’s OK. It’s optimized, but it can reference netstandard libs. ASP.NET Core 2.0 is optimize for Core 2.0 but it can reference shared libraries. Xamarin is the same.

.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.

NetCore > Net Standard > NetFx when it comes to development speed and innovation.

Point is, if you are doing new work, netstandard20. If you have older net461+ libraries, MOST of those can be referenced under ASP.NET Core 2.0.

ASP.NET Core 1.1 which runs on .NET Framework will be fully supported for a year after we release 2.0. That workload is fully supported thru at least July of 2018.

The remaining large gaps missing in .NET Core 2 are System.DirectoryServices and System.Drawing. We are working to have a Windows compat pack which would enable both of those on .NET Core on Windows this summer.

What we need from you all is a clear list/understanding of WHY you think you need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those gaps and let everyone be successful.

[mythz]

I thought .NET Standard 2.0 was all about compatibility and interoperability which bridges the gap between .NET Core and .NET fx that everyone is waiting for - this seems to kill that.

For whatever reason there's going to be lots of customers who will have dependencies that require .NET 4.x whether it be custom external dependencies, commercial components, legacy lib dependencies, etc.

Is it the intention that Customers wont be able to create ASP.NET Core 2.0 apps running on Desktop CLR so they can reference their existing .NET 4.x deps?

[NickCraver]

@shanselman Thanks for the reply - lots of good examples in there.

A follow-up about libraries:
Will all of the abstraction libs remain as cross-compiled? For example if I'm using HttpRequest, maintaining a 1.x and 2.x builds on which version of ASP.NET Core you're using (which now cleanly map to a TFM at least) would be something I'd prefer to avoid...so I'm hoping the abstractions will remain on netstandard. Is that the general plan?

We're already maintaining multiple variants for things that depend on ASP.NET/MVC because System.Web's HttpRequest is totally different, so that's another library entirely (e.g. MiniProfiler vs. MiniProfiler.AspNetCore). I just want to make sure we're keeping in mind the number of variants we're loading up on maintaining for any lib authors if their dependencies move off netstandard...and hopefully just avoid that headache all together.

[daveaglick]

I'm very happy this doesn't seem like as big a deal as it appears, thank you for the detailed clarification.

I do have two questions/concerns:

• It sounds like consuming .NET Framework libraries from ASP.NET Core should have minimal friction. That's great! What about the other way around? There are probably .NET Framework or netstandard libraries and applications out there that are embedding parts or components from Mvc and other supporting ASP.NET Core libraries (I know because I have a couple). Those will break, correct? Are there any tips for how to work around that scenario? If netstandard libraries can no longer consume ASP.NET Core libraries, that seems like a big deal for embedded ASP.NET Core scenarios.

• From a non-technical perspective it seems like this will cause a lot of confusion. Outside of the folks who are active on GitHub, follow along on Twitter, etc. there's already a great deal of confusion surrounding the different platforms, etc. I can see developers who've only been partly following along or who are just now getting up to speed getting very frustrated when they go to use ASP.NET Core (perhaps following an outdated tutorial) and can't get it to work on their .NET Framework platforms. Not sure what, if anything, can be done about that.

[kevinchalet]

We can even reference many net461+ assemblies from ASP.NET Core 2.0 because of typeforwarding and netstandard20

Unfortunately, this doesn't mean that a library compiled and designed for the full framework will work on .NET Core (the risk is high things will blow up at runtime!).

Many of the "old" APIs re-introduced in .NET Core 2.0 are stubs that will never (functionally) work. Not to mention that there are still many missing APIs, and even entire areas that were deliberately excluded from .NET Core (IdentityModel, WCF server, remoting, complete AppDomain support, etc.)

Trying to convince people that they can "safely" migrate their ASP.NET Core 1.0 w/ .NET Desktop apps to ASP.NET Core 2.0 w/ .NET Core is - IMHO - a lie.

.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.

I don't believe that's what (most) people are looking for. Many people don't need fast-moving libraries, they need stable stuff that can gracefully integrate into their older stuff without taking the risk of breaking everything.

[DamianEdwards]

@daveaglick

• Correct in that there's no implicit ability to reference netcoreapp2.0 from net461 or even netstandard2.0. The bridge goes one way. You can always work around it by specifying TFMs for package fallback, but that's obviously an escape hatch, not a supported scenario (although it will be enough to unblock many people). It's a non-trivial amount of work for us to support sub-systems of ASP.NET Core outside of the larger stack (which is what targeting netstandard is implying).
• The potential for confusion goes both ways. E.g. we've had lots of feedback that the fact that "ASP.NET Core" can run on .NET Framework (which isn't .NET Core) is confusing. This change effectively makes ASP.NET Core part of the .NET Core stack meaning if you're using ASP.NET Core, you're using .NET Core.

[kevinchalet]

@shanselman BTW, you didn't say why cross compilation was not an option. ASP.NET Core components that could benefit from netcoreapp2.0-only APIs could have both net46/netstandard1.x/netstandard2.0 and netcoreapp2.0 TFMs and make the new cool/fast stuff .NET Core-only.

[DamianEdwards]

@NickCraver currently the plan does not include leaving the *.Abstractions packages targeting netstandard. The separation simply isn't as clean as that across the board. For the purposes of someone attempting a migration like what you're suggesting however, using package target fallback should get you there anyway (but I might be misunderstanding you).

Also you're point about the clean TFM split is correct, and is an advantage of this plan, in that a single package can now target ASP.NET Core 1.x and 2.0+ simultaneously using the TFM as a pivot.

[ap0llo]

I've toying around with the idea of "mixed applications". E.g. a WPF application exposing a Web API or a Server offering both a REST API and WCF endpoints (this might be for compatibility with earlier clients). These scenarios are made impossible with this change and makes ASP.NET Core only suitable for new applications rather than being "just a library".

[DamianEdwards]

@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly. Our work with customers in this boat so far has indicated that System.DirectoryServices and System.Drawing and the No.1 and 2 blocker and we have a plan to address that. Beyond that, we're looking at the feedback and we'll assess.

Cross-compiling is an overhead that must be balanced with customer and product needs. This is why we want to get this feedback so we can more concretely define what the landscape looks like for both our customers and us as we continue to evolve ASP.NET Core moving forward.

[daveaglick]

@DamianEdwards Thanks for the further clarification. The netstandard -> ASP.NET Core libraries are kind of a big deal for me. I embed Kestrel (which also looks to be moving to netcoreapp) in several netstandard libraries. I also embed Razor in several places, and I know you're working on the new more modular version, but if that only targets netcoreapp too it'll hurt. There's also tons of libraries that are "part" of ASP.NET Core but that have lots of utility outside of it.

In other words, I'm much more concerned about removing the ability for netstandard libraries to consume ASP.NET Core packages than I am about the reverse. It seems like this is removing an entire class of use cases from consideration.

[DamianEdwards]

@daveaglick Razor itself (the engine) will continue to target netstandard. Again, there's a cost involved in supporting particular sub-systems of a large complex graph (like ASP.NET Core 2.0) on different platforms. For things like embedding there are other options (source embedding, copying, etc.) but of course they come with their own trade-offs.

Definitely hear you on the different classes of use cases front, we indeed have different customer groups to consider when designing and shipping a stack like ours.

[NickCraver]

I share @daveaglick's concerns here: ASP.NET Core wanting to use the latest APIs is totally understandable, but for everything else downstream to require the same gets a little messier. You don't get any choice after 1.0 of stable or upgrading, you're on the fastest train available with netcoreapp2.0 and that's the only choice. If all of the bits (even the basic abstractions) can't be consumed without making users consume netcoreapp2.0, that means there is effectively no netstandard2.0 for that entire line of libraries...and everyone that depends on them.

I get the core application stack moving, but I don't necessarily agree with the abstractions in particular moving. One of the major points of the abstractions was to avoid the tight coupling like this, at least from my view as a consumer. I'd be very curious to see some examples where netstandard2.0 doesn't have the APIs needed for them but netcoreapp2.0 does - are there some examples out there? Is this mainly around new types in method parameters? I don't doubt there's ample reasoning, I'm just very curious - seeing examples would help show the maintenance cost which we don't have nearly as much daily insight to.

The Kestrel case is more complicated, but I certainly see the arguments for having it on the latest API set. I'd imagine new APIs will continually be created for Kestrel given the work it's driving.

[kevinchalet]

@PinpointTownes as @shanselman stated, we're very interested in the specific requirements and blockers that customers have with regards to needing to continue to target .NET Framework directly.

As a consultant, I helped a bunch of clients move their apps to ASP.NET Core and I often had to target .NET Desktop to be able to use third-party (closed-source) libraries depending on IdentityModel/WCF or relying on AppDomain support.

Not having these things in ASP.NET Core 2.0 would be a major blocker for them.

There are also libraries that wouldn't work on .NET Core even if the APIs were there, because they'd be functionally different. Here's a concrete case I've seen many times:

On .NET Core, RSA.Create() returns a RSACng instance on Windows, but on .NET Desktop, a RSACryptoServiceProvider instance is returned. Yet, many libraries - including the BLC itself - try to cast RSA to RSACryptoServiceProvider, which will always fail on .NET Core, as RSACng can't be cast to RSACryptoServiceProvider.

[davidfowl]

@NickCraver which abstractions in particular? The problem with moving just the abstractions is that next you'll end up wanting everything that builds upon those abstractions as well (unless you're literally saying that you only need Microsoft.AspNetCore.Http.Abstractions and nothing else)

[NickCraver]

@davidfowl Yep, only the abstractions: e.g. HTTP, Hosting, HTML, and Logging. It looks like Microsoft.Extensions.* are covered by earlier comments, which is most of these. Those are the ones I'm interfacing with today.

For a concrete example: the MiniProfiler Middleware doesn't reply on anything but abstractions (link)

If you're using MVC and such on top, well then you're on netcoreapp2.0 anyway, and that is what it is (and IMO, that's just fine). But currently I have freedom to split up APIs logically where shared and do so easily because they're abstractions. I'm very much a fan of the current split, please don't lock that down unnecessarily.

[khellang]

Heh. As a consultant, I've definitely heard the "What? ASP.NET Core runs on desktop .NET Framework!?" question quite a few times. The fact that "ASP.NET Core" literally has ".NET Core" in the name is really unfortunate.

Anyway... Just as I was a fan of dropping obsolete/legacy/broken APIs when .NET Core started out (a "fresh" start), I'm also a fan of this change in order to get a faster, leaner framework with more features and a higher rate of innovation.

With that said, I'm also sympathetic to all the devs out there that can't, for some reason, migrate all their code to .NET Core before June next year.

This includes my current client, which has an insanely big legacy library/framework, targeting .NET Framework, consumed by multiple ASP.NET Core projects currently being developed in parallel. By the time these systems goes into production, there will be little to no time to either a) port everything to .NET Core, or b) move everything to full framework ASP.NET, before ASP.NET Core 1.x is unsupported.

Is one year of support really enough here? I can imagine there are other similar cases out there...

[DamianEdwards]

@khellang as previously stated, they'll be able to continue referencing libraries/frameworks targeting .NET Framework, and that will work just fine assuming the APIs they call are part of the closure of netstandard2.0. Do you know if they rely on things outside of that space? That's what we'd really love to get feedback on so we can assess the priority of porting those APIs (like System.DirectoryServices and System.Drawing).

[Ponant]

@PinpointTownes , we the community should also clean our communication on our side, and that is not easy. The rate at which issues, comments and so on are posted on GitHub is so high that it is hard for a smaller aspnet team to handle and keep track of everything. This asymmetry in number between us and the people behind .net core is well represented in the asp.net community standup, which is an almost exclusively unidirectional flow from them to us. Perhaps we could think of an inclusion of an extra layer between some community members and the .Net team where suggestions etc would be forwarded on skype meetings or standups. That would be hard to implement I assume but perhaps a direction to consider because the community is quite big.

[FransBouma]

@Ponant: that's the equivalent of what we had before, namely you report to some person and hope that person will pass it along. No, the community should be able to post their issues as-is and the team can then pick the ones they want to proceed with. If that is a lot of work, they (and not the community) should make sure they can handle it, e.g. by looking into using better tools than github issues (as it's not ideal: the set of questions how things work or why things don't work is mixed with the set of bug reports), add a layer for themselves which weed out the questions vs. the issues they have to work on. IMHO that's the most transparent as the community can see which issues are picked up and give feedback on other people's issues as well. If it is passed to a black box we have no control over it's IMHO a big step backwards.

[benaadams]

Don't forget, you can also make PRs, contributions and bug fixes. Clearly know where to find the repos now 😉

[Ponant]

@FransBouma , I agree with you as for transparency and I admit that adding a layer is generally a bad idea. But we need to understand the team if they get overwhelmed with info from the outside because we cannot dump info into GitHub and then complain if they take different directions. A better tool than GitHub would be welcomed and which would work in conjunction with it and more modern than the user voice.

[oldrev]

Why did you MS guys never learn the lessons? A break-everything-update will be killing the .NET Core's reputation and market, just like what happen in WP 7.x to 8.

The migration from ASP.NET 4 to ASP.NET Core is a hard and long-term painful progress, please do not make it even harder.

[markrendle]

they buy the MSDN licenses, the big Azure enterprise agreements, the giant Office subscriptions, and the large SQL Server deployments that fund the creation, development, and maintenance of these tools to begin with

So this is like the first-class passengers blocking improvements from being made in economy. OK.

[chadwackerman]

@markrendle Microsoft is currently pulling in over two billion dollars a week in revenue. They can afford to do a better job managing their engineering projects.

For $400 million each workday I'd expect more than having the entire .NET team use the legendarily crappy NuGet to pull daily builds off an overloaded server in Belgium outsourced to a company named Tech Tomato. Which currently requires 200MB of metadata to install a 78k DLL. NuGet/Home#4448

Perhaps it's the way Microsoft is choosing to use GitHub, but end-user communication is awful and communication between teams turns into a race to prematurely close bug reports and split issues before they gather enough community attention.

But if Microsoft is going to ignore the top UserVoice requests, and everything that doesn't seem fun to work on gets tagged as "backlog", what's the point of doing things in the open? Yeah, you're busy, we get that. You were busy before. Now you're busy, plus busy dealing with public community brigades, too.

Like any poorly-run 1990s web forum, stressed out admins react predictably. Comments mysteriously disappear from old threads. And senior management makes promises to tamp down the community outrage but does not deliver:

https://github.com/dotnet/cli/issues/5328
https://github.com/dotnet/corefx/issues/17522

Some Microsoft employees have embraced GitHub, many decided the time required just isn't manageable, others turned into GitHub addicts who do nothing useful but post polls and promote their Twitter accounts, asking "the community" how best to name a Factory method or providing rave reviews of Logitech mouse scroll wheels.

So I fix things by emailing internal contacts, just like I have since 1992. And the first reply inevitably mentions how this GitHub stuff is totally off the rails.

Edit for @PureKrome who didn't believe me about the mouse wheels.

Incidentally when Hanselman showed up in this thread defending the decision I knew it would be reversed. If you want to know what Microsoft is doing, just read his blog then wait six months for the technology to go the exact opposite direction.

[khellang]

FYI: Some info on 2.0.0-preview2 and .NET Framework; aspnet/Announcements#243

[markrendle]

@chadwackerman I don't think they get to spend the whole two billion dollars on developing .NET, actually. Some of it probably goes on stupid-but-essential stuff like toilet paper, caffeinated beverages and Azure data-centers.

[AlperenSarac]

@oldrev

Why did you MS guys never learn the lessons? A break-everything-update will be killing the .NET Core's reputation and market, just like what happen in WP 7.x to 8.

Maybe they did. Otherwise there would have been even more breaking changes.

The migration from ASP.NET 4 to ASP.NET Core is a hard and long-term painful progress, please do not make it even harder.

I totally agree the progress is hard, painful and going to take a while and I'm sure the MS folks are aware of that as well (whether they will make the progress easier is a different story)

Stepping back a little bit, my team did evaluate the possibility of switching from ASP.net to something else other than ASP.NET core but the decision is a no-brainer as we've so many dependencies on MS tech. At the end of the day, we've to accept the reality.

[alexvaluyskiy]

MS trying to repeat their own mistake and to drop support for the full .NET in Microsoft.Data.Sqlite repository aspnet/Microsoft.Data.Sqlite#370

Without any discussions with the community and without any announces.

[MartinJohns]

@alexvaluyskiy Not sure what you're on about. They're replacing net451 with netstandard2.0, so they're not dropping .NET support. netstandard2.0 is supported by .NET 4.6.1.

[alexvaluyskiy]

@MartinJohns every change of TFS is a big breaking change, and I think it should be announced and discussed first.
.NET 4.5.2 is still supported by MS, and Microsoft.Data.Sqlite could be run on top of it. Why MS drops the support of it and forces users to update to net4.6.1 or netstandard2.0?

[MartinJohns]

Because it's a reasonable expectation that you update your .NET version. This reduces maintenance cost, as they only have to support .NET Standard 2.0, and not multiple target runtimes. It's not that they're dropping .NET - they're still supporting it, but just a more recent version.

[irwiss]

Are you implying microsoft has to support all packages down to .NET 1.0?

Stuff has to converge to netstandard at some version

[MartinJohns]

@irwiss That comment is not really helpful. Nowhere did he imply that packages should be supported down to .NET 1.0. But he did mention "is still supported", which is right. .NET 4.5.2 is still an officially supported version as of 3rd May 2017 with no scheduled end of lifetime (https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework).

Supporting supported .NET versions is not a far fetched request.

[willdean]

@MartinJohns Neither party is being terribly helpful to be honest - the initial link to the sqlite issue was based on a false premise, and trying to reshape the hole (into what would be a trivial 4.5.2 vs 4.6.1 debate) with a bit of extra digging wasn't a good idea.

[smithaitufe]

I really don't know what is happening. Why do have many dotnet this and that. This is really crazy. How do we have keep tracks of this?

No proper documentation on migration from one to another.

[GiorgioG]

First we had DLL-hell, and we now have Package-hell...the more things change.... ;)

[MaximRouiller]

Any way to lock this thread? This looks like it belongs in a chat format rather than a GitHub issue.

[smithaitufe]

@MaximRouiller If only you know the hell I have been through since yesterday just to upgrade from netcoreapp1.1 to netcoreapp2.0.

If you know a link that can make it easier for me, please refer me to it.

Thanks

[MaximRouiller]

@smithaitufe

https://weblog.west-wind.com/posts/2017/May/15/Upgrading-to-NET-Core-20-Preview

[Rutix]

@smithaitufe That's kinda offtopic to this issue. Open a new issue instead.

[MaximRouiller]

@PinpointTownes @Eilon

Any way to lock this thread? Everyone that comment something sends 100+ emails to notify of new activities while they may belong in a new thread.

[smithaitufe]

@MaximRouiller I have gone through that and it didn't help.

For example, did you read this in that blog?

Overall this framework update provides a relatively smooth upgrade path aside from a few breaking changes.

But one thing that is extremely frustrating is the proliferation of SDKs, Runtimes, Tools and all the different versions that they incorporate. Especially when those things end up not quite lining up because they are all in different stages of preview.
*
I decided to create a new project just because I could not get it to work.

[smithaitufe]

@Rutix Thanks. I will figure a way out

[Eilon]

Per some of the discussion here, and given that this issue is fixed for the upcoming Preview 2 release, I'm locking this issue. For any additional questions about ASP.NET Core changes or issues, please file a new issue in the appropriate repo. If you're unsure where to file, please log an issue in the Home repo and tag me (@Eilon) and I'll help you find the right place.

Thanks!