Oh hey, we haven't talked about .NET Core in a while. We've been making some progress, here's what's been going on over at Stack Overflow...
- @marcgravell and I shipped SE.Redis v2.0
- I'm porting everything to EF Core (not 100% yet)
- @m0sa has been working on MoonSpeak (localization) and performance with Marc
- @deanward81 has been tearing out loads of old email code to finish the StackMail migration
- I'm porting everything to EF Core (not 100% yet)
- @m0sa has been working on MoonSpeak (localization) and performance with Marc
- @deanward81 has been tearing out loads of old email code to finish the StackMail migration
@marcgravell @m0sa @deanward81 - @kevinmontrose has been suffering through auth code to deprecate openid.stackexchange.com and move us to all-OAuth (and simplify things), allowing us to kill DotNetOpenAuth usage.
- The rest of the teams are progressing on other work while we advance the .NET Core initiative
- The rest of the teams are progressing on other work while we advance the .NET Core initiative
@marcgravell @m0sa @deanward81 @kevinmontrose - SRE is working on containers and Kubernetes planning to figure out our deployment options
- Everyone has been planning a lot
What have we been talking about and not quite doing yet?...
- Everyone has been planning a lot
What have we been talking about and not quite doing yet?...
@marcgravell @m0sa @deanward81 @kevinmontrose There's a transition period from #AspNet to #AspNetCore. We need as much code as possible to be runnable by both so the final web project cutover is a small and least disruptive as possible. That has a few challenges to solve:
@marcgravell @m0sa @deanward81 @kevinmontrose Namely, System.Web is gone. But, it can't be "gone gone" on day 1. We need to do things like implement IHtmlString for the transition (for things like already-encoded strings and localization). Okay, so how do we accomplish this sanely and without sprawl?
@marcgravell @m0sa @deanward81 @kevinmontrose First, we need to implement a type (we think, this is up soon) that's based on HtmlString (#AspNetCore) and implements IHtmlString (from System.Web). And probably IHtmlContent. If we change all usages to that type, we have a transition story that's online and workable.
@marcgravell @m0sa @deanward81 @kevinmontrose But that means our type has to be returnable from a new library (StackOverflow.Common) in the solution where most or all models and helpers are moving. So we've got a System.Web reference we don't want to have in the end. That's not netcoreapp2.1 that we'll need.
@marcgravell @m0sa @deanward81 @kevinmontrose To counter this, @m0sa has been adding to our in-house Roslyn analyzer suite simple yet very useful helpers for things like "you're using a type from System.Web". In this new project, we'll turn that into a compile error. "Don't do that!". That'll help prevent inadvertent sprawl.
@marcgravell @m0sa @deanward81 @kevinmontrose If you're curious, here are some tweets showing what that looks like:
@marcgravell @m0sa @deanward81 @kevinmontrose That tweet the other day asking about Twitter API libs? Currently we're using a thin helper on top of DotNetOpenAuth for that piece (since we already had the dependency). We'll need to replace that too. We also generate flair with System.Drawing today...that's gotta go.
Alongside all this, Roslyn analyzers are extremely helpful. For example, a few of us use Roslynator that find many issues as we convert more to async, etc. But, we have a few thousand info messages today with those. Some good, some we don't want to fix.
Analyzers are analogous to unit/integration tests. They are most useful when you're inbox zero by default. Few people fix changes that go from 2,345 to 2,346. But when they see 0 became 1 (or better yet: they're build warnings or errors now), hey: that's actually maintainable.
I'm paying down the few thousand of those we have quick as I can so that we have a clean slate we can actually use for the migration.
I also paid down some integration test tech debt taking down 120 failures (almost all invalid) down to 1. Doing this for EF Core, mostly.
I also paid down some integration test tech debt taking down 120 failures (almost all invalid) down to 1. Doing this for EF Core, mostly.
Anyway, a lot is happening. We've wrapped up a lot of long-standing TODOs as a team and we've got 4-5 devs working full time on .NET Core now. We've got a Trello board full of goodness for things to grab and do and it's an exciting time to work here.
I'll try to update as we go.
I'll try to update as we go.
If any of this resonates with you or you have questions: please ask away. As always, we love Q&A around here.
If some part of what we're doing would be very valuable to open source, let us know. We may not have the time right away, but we'll keep it in mind for sure.
If some part of what we're doing would be very valuable to open source, let us know. We may not have the time right away, but we'll keep it in mind for sure.
Oh and one more thing:
The #AspNet and .NET runtime teams have been fantastic here. We've been working with them on GitHub and in some calls to address any pain points we're hitting along the way (in hopes that others don't hit them later).
The #AspNet and .NET runtime teams have been fantastic here. We've been working with them on GitHub and in some calls to address any pain points we're hitting along the way (in hopes that others don't hit them later).
We're working with the #AspNet team on IIS behavior since that's our initial deploy model (later in-process). We're also working with the .NET runtime team to get them performance telemetry so we can help optimize .NET even further for us and everyone else.
The runtime team also owns some of the profiling things like PerfView and clrmd. One major blocker to production Linux (for us) is a great on-box, at-scale debugging and profiling story. We're going to help test and advance that story as it evolves as much as we can.
