WebForms in Asp.NET Core

[maddymi]

Immo Landwerth asked me to post this here:

Are there any plans to port WebForms to .NET Core? Many companies, especially Fortune 500 have huge amount of code in Webforms. I think Damian Edwards mentioned Webforms could be ported to .NET Core. So I wanted to ask if .NET team have any ETA on this?

[StingyJack]

Making an incompatible webforms port isn't nearly as hard (like mono has) as making a compatible one.

Lest ye forget, the choice to make everything anyone has ever done with netfx require porting was not made by the existing customers.

[ststeiger]

Making an incompatible webforms port isn't nearly as hard (like mono has) as making a compatible one.

@davidfowl: truer words have never been spoken.

• Do controls need to be compatible? The 3rd party controls you bought from vendors years ago, they probably won't work.

We have exactly one 3rd party control, to which we have the source code, and it is an utterly superfluous grouped RadioButton. Exactly the same can be achived with plain HTML. Also, ILSpy has become pretty good, so decompiling and recompiling 3rd party controls is possible in case of doubt, if the need arises. Decompiling might not be legal, but who cares anyway. So no.

• The webforms designer? Do you expect that to continue working?

I couldn't care less about that piece of ****, that never worked correctly anyway. It's a menace - you open a control by mistake just once, and working markup is gone, and replaced with some bs.

• How much behavior breakages can your application tolerate?

not much - particularly in session/markup/ViewState/page-lifecycle space. Also the JSON returned by Microsoft-Ajax-Controls (system.web.extensions) should remain the same as on .NET 2.0. (no d.data when we had d in .NET 2.0).

• There's no more app domains, do you need to run multiple apps in the same process still?

not an issue at all. What's the recommended way to run multiple apps with routing in one virtual directory in IIS anyway ?

• The deployment tech to make it work (webdeploy, shadow copying?)

We deploy by hand, so utterly unimportant - shadow-copying is important only in the respect that I can copy a dll into the smb-share of the application and then it reloads/restarts, without needing the rights to iisreset, or to start/stop a service.

This is more a windows-issue than an ASP.NET issue. Linux can overwrite running binaries. If Windows could do that, shadowCopy would be unnecessary.

Right, so if your application can work on WebForms on mono then there's a good chance it might run without IIS on a hypothetical NET Core port.

Ah, not necessarely, if it uses windows-authentication. But it will continue to run with IIS, just as it always has, so not an issue. Not a fan of IIS, though. Also, if it creatively uses other virtual directories, that's an issue if the IIS-replacement doesn't support virtual directories. See https://stackoverflow.com/questions/36030121

[bproven]

@joehanna Dude, we have all been there. Everyone here has spent years building a huge, amazing app on a tech platform that eventually died. (We have an enormous, perfect, 1 million LOC app in Delphi...).

So first off, the place you are is normal. It isn't Microsoft, it is tech.

And if you got 10 or more years out of the stack, that counts as much (much much) better than average!

What we did is build a porting tool, to move 500+ aspx webforms to cshtml (razor). We put a dev on it for 6 months. His job was to build the tooling so that we could wake up one Monday, press Play, convert the app to cshtml. We spent that week doing the obvious cleanup (the tool wasn't perfect). 10 days after that Monday we were deploying cshtml/razor to production. We found another 20 or 30 issues over the next two months (rarely used areas that broke in conversion -- this is an app used by 2000 users).

It was a really big job. Our main driver is that we want to move off IIS (we are fine staying on Windows servers, what we really need is to drop the IIS dependency because it is messy to deploy via xcopy).

I am really glad we made the jump. It was probably 8-10 engineering months (on a team of 5 engineers).

But we could have stayed where we were, fully supported by MS, for another 5 or 8 years. It was our choice to jump when we jumped (the jump was in July 2017).

My two cents.

I'd love to "borrow" that tool ;P

[samjones3]

I'd love to "borrow" that tool ;P

We used this as a starting point: https://www.telerik.com/blogs/webforms-to-razor-view-converter-tool

And extended it to handle our needs.

[ststeiger]

@samjones3: Nice link. Wondering if this more-or-less works with our non-MVC pages in VB.

Anybody who doesn't want to read the boring blog-post, here's the direct link: https://github.com/telerik/razor-converter