search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.08k stars 9.9k forks source link

WebForms in Asp.NET Core #1961

Closed maddymi closed 7 years ago

maddymi commented 7 years ago

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?

BillJones50 commented 7 years ago

I would also like to see this. MVC also has a big learning curve for beginners. MVC can get very complicated for large apps. Here is a related link about big sites like facebook avoiding MVC: https://www.infoq.com/news/2014/05/facebook-mvc-flux

https://www.quora.com/Do-big-websites-like-Google-Facebook-or-Twitter-use-MVC/answer/Steve-Cook-49

davidfowl commented 7 years ago

No there is no plan to port webforms to ASP.NET Core.

john2014 commented 7 years ago

From my understanding, MVC (on .Net standard framework) sits on top of WebForms. If you disable viewstate in web.config, it removes a lot of unwanted data (if you dont want to save state on page load). Microsoft recently ported SQL Server to Linux OS by providing a shim and thus were able to use most of the original SQL server code (instead of complete rewrite).

Since Microsoft .NET team is currently working on .NET Core 2.0 release, they can provide a similar "shim" to allow code written in "WebForms" to run on ASP.NET Core 2.0. This could be possible since many things are now modular.Because of shims, the LOE may be lower.

davidfowl commented 7 years ago

Mvc does not sit on top of webforms...

john2014 commented 7 years ago

Sorry I mispoke. I mean MVC, Webforms and WebPages sits on top of .Net Framework.

katie20 commented 7 years ago

Does Asp.Net Core have something equivalent to PHP, Pyhton, etc? Many people do not always have time/patience to deal with MVC.

Heck even Scott Hanselman mentioned few days ago in Community standup that he doesn't want to deal with models, view, controllers in his website blog. Here is a link: https://youtu.be/qlVE5iDjBIg?t=18m30s

It would be great to have something similar to WebForms or WebPages which is quick to start and finish. Lots of developers would be very happy with that.

The only other current alternative is to move to another programming languages/frameworks.

davidfowl commented 7 years ago

See https://github.com/aspnet/Mvc/issues/494

LeoCheung777 commented 7 years ago

I thought it is impossible to port webform platform in technical issue. I would suggest try mono-project if you want run webform as well as MVC5 in Linux.

tomasherceg commented 7 years ago

Have you seen DotVVM?

It is not Web Forms on .NET Core, but:

Disclaimer: I am one of the authors of DotVVM. This post is not meant to advertise the project, I just believe it responds to the question because the main motivation to build DotVVM was the fact that Web Forms are not ported to ASP.NET Core. We didn't want to just port Web Forms, we wanted to build a framework which is conceptually similar and which avoids the things Web Forms were criticized for (viewstate, testability and ugly HTML output).

StingyJack commented 6 years ago

@davidfowl - Does this constitute the official EOL statement from MSFT for WebForms?

ststeiger commented 5 years ago

Does Asp.Net Core have something equivalent to PHP, Pyhton, etc? Many people do not always have time/patience to deal with MVC.

@katie20: If you don't want MVC, use NancyFx for .NET Core. https://github.com/NancyFx/Nancy

Really just like Sinatra for Ruby. No annoying controllers & actions, and yet it uses routing. Not like WebForms, though - but that is a good thing.

MgSam commented 5 years ago

With .NET Framework now essentially deprecated, it is really not ok for Microsoft to not offer any upgrade path for the tons of WebForms code out there, especially given that WPF and WinForms are making the leap to Core.

The result of this is that you're going to bifurcate the .NET ecosystem like never before. The web is many times bigger than the last time you did this (classic ASP -> ASP.NET). You're going to end up having tons of websites sitting on WebForms and an ancient version of .NET for decades.

poke commented 5 years ago

@MgSam The .NET Framework is not deprecated and will continue to get support and updates. It will just evolve slower compared to .NET Core. As a result, WebForms is still fully supported and that will continue to be the case for quite a while. See the blog post for more details.

Having WebForms support on .NET Core for the purpose of offering an upgrade path doesn’t really make sense anyway since WebForms simply wouldn’t run in a fully compatible way on .NET Core. So you would have to migrate your application anyway. And and that point, you’re better of migrating off WebForms since that’s the actual ancient thing in the combination WebForms & .NET Framework.

MgSam commented 5 years ago

@poke Major platform features that are required for C# 8 are not being added to the .NET Framework and will never be added. Microsoft can call it whatever they like but in the rest of the world we call this being deprecated.

It is disingenuous of you to suggest otherwise. Silverlight and Flash also might technically still be getting updates in the form of security fixes but you'd be hard pressed to find anyone who says these platforms are not deprecated.

ststeiger commented 5 years ago

@poke Having WebForms support on .NET Core for the purpose of offering an upgrade path doesn’t really make sense anyway since WebForms simply wouldn’t run in a fully compatible way on .NET Core. So you would have to migrate your application anyway. And and that point, you’re better of migrating off WebForms since that’s the actual ancient thing in the combination WebForms & .NET Framework.

Could you elaborate on this ? Not that I wish webforms back, but @MgSam is right when he says that full-framework's non-depreciation is disingenuous.

@MgSam You might want to have a look at Blazor, that might well be the future of Web-Forms/Silverlight/WPF. https://blazor.net/

Note: Google might not be able to index blazor-sites - so this would be bad for SEO for the time being. But if you offer WebApplications that are sold OnPremise or SaaS, that might not matter for you, and it might even be a good thing, security-wise.

Blazor looks like it is WebForms, Silverlight & Flash all-in-one.

poke commented 5 years ago

@ststeiger Just like ASP.NET MVC is not forward compatible to ASP.NET Core MVC, you shouldn't expect that a theoretical ASP.NET Core WebForms would be able to run your old code. It would be very likely that you need to adjust large parts of your application just to allow to run it on the new version.

So it does not really make sense to ask for a new WebForms just for the sake of having a compatible upgrade path.

And if you think about it, with WebForms on .NET Framework, it's not the framework that's the ancient technology but rather WebForms itself. Today, there's little to no reason to build new stuff in WebForms; there are approaches like MVC that are superior in every way.

So basically what I am trying to say here: If you currently have a WebForms app on .NET Framework, then the real reason to look for an upgrade path would be to get rid of WebForms. But having the slowly evolving framework there is not the problem.

@MgSam The big difference with Silverlight and Flash is that there is almost no platform left where they can run on. Browsers stopped supporting Silverlight, and the few browsers that do support Flash only do this as a specific exception.

The .NET Framework however will continue to have Windows as its platform and will also continue to ship with it. Maintaining compatibility is key here for Microsoft. That is the reason, the .NET Framework is now moving slower; it is not the other way around. They are prioritizing compatibility of existing applications over innovation. That is generally a good sign for anyone running older applications.

StingyJack commented 5 years ago

Maintaining compatibility is key here for Microsoft. That is the reason, the .NET Framework is now moving slower; it is not the other way around. They are prioritizing compatibility of existing applications over innovation. That is generally a good sign for anyone running older applications.

A good sign would have been to just start updating netfx in place with the parts they have been adding as netcore. Unless its trival, rebuilding something from scratch is almost always the worst choice due to the amount of effort required vs fixing something existing. The only other reason to do it is because the existing thing cannot be salvaged or repaired, which is what the outward impression is for me.

Microsoft seems to be turning its back on everyone who has invested in netfx applications. I agree with @MgSam except that its not a bifurcation, its a shattering.

JosephRufft commented 5 years ago

.Net Core is useless to my company without Web Forms. We must have Web Forms in .Net Core to get our work done efficiently.

poke commented 5 years ago

@JosephRufft Feel free to stick with WebForms on .NET Framework then.

samjones3 commented 5 years ago

@JosephRufft My team has a LARGE asp.net project, with several hundred aspx forms. We converted the entire project to razor (cshtml). We built some tooling to do it. It does feel very good to get to the other side.

ststeiger commented 5 years ago

@ststeiger Just like ASP.NET MVC is not forward compatible to ASP.NET Core MVC, you shouldn't expect that a theoretical ASP.NET Core WebForms would be able to run your old code. It would be very likely that you need to adjust large parts of your application just to allow to run it on the new version.

@poke: Yea, and it's not just that. When you look at WebForms in a broader view, the point seems to have been that you could port a WinForms application to the web, and all you needed to do was to create a aspx page or an ascx control with the same controls with the same name as in the WinForms designer, and then you could port your WinForms application code to the web without changing it much.

There are broadly 5 major problems with that idea: A) WinForms is stateful, while HTTP is stateless B) VB/C# cannot be run in the browser (keyboard control, mouse, oninput, onchange) C) With using PostBacks on actions such as button-clicks and posting the entire ViewState, the execution of the idea was totally botched. Had they used or introduced Ajax/WebSockets for that purpose, it might have turned out better. Also, testability was totally botched with that approach. D) WinForms is usually single-threading, so usage of static variables might be fine, while in a multi-threaded environment as the web, using such code would be fatal E) Security - things like CSRF-protection are not easy to get right, and don't implement themseves, plus the browser can't do all the things a WinForms-app can do (which is a good thing).

So any reincarnation of the WebForms-concept today would be well-advised to use WebAssembly to run VB/C# on the client, and WebSockets to trigger actions on the server, and get rid of the ViewState altogether. State handling might remain a problem, since storing data for every client on the server needs too much memory, and you don't know when "a state" can be discarded.

Given that you would most-likely have to re-write much of the code anyway, it wouldn't make much sense the have the old WebForms implementation back anyway.

It would be nice however, to have a framwork where you can do databinding, e.g. something like a table-control that can be async/await data-bound to a rest/JSON-data-source where you can fix the header and some columns on the left or right, with responsive display, virtual rendering/scrolling/paging including the combination of all 3 virtuals to simply display huge datasets with good performance, dynamic row height, with the capability to handle and search/sort large datasets out of the box, with a dynamic number of MOVABLE columns, multilingual titles/hints including right-to-left languages including rotate270°, edit controls including USABLE date/time pickers, and to export to Excel, PDF, CSV, json, xml, print, etc. where databinding and searching/sorting for huge datasets with virtual rendering/scrolling/paging also extends to other controls, such as dropdown, data-lists, multi-select dropdowns, auto-complete, etc. and all in a coherent, stylable fashion, without using Angular/React/jQuery/jQueryUI or any of that crap.

And WebForms definitely is not that kind of framework.

VAchris commented 5 years ago

I thought it was important to highlight a couple of things for those who use IIS as your web server.

  1. You can run ASP.NET Core using the .NET Framework
  2. You run Web Forms using the .NET Framework
  3. You can deploy a single site that contains an ASP.NET Core and Web Forms stack together
  4. Important detail! Out of the box the ASP.NET Core and Web Forms do not share internal processes. To illustrate, if you have a static int field called counter in a class and say you have an ASP.NET Core controller that allows you to increment and view the counter then when you use Web Forms to view the counter you'll see that they will not match.

(The reason I know this - I needed to deploy an ASP.NET Core site using IIS that could embed the SSRS Report Viewer Web Form Control in a Web Form)

Also related - please vote on the SSRS ASP.NET Core need!

https://feedback.azure.com/forums/908035-sql-server/suggestions/33241936-develop-a-ssrs-reportviewer-for-asp-net-core

ststeiger commented 5 years ago

@VAchris: I have ReportViewer working on .NET Core on Windows, and partially on Linux. Note: still some trouble with custom code. Nothing that can't be worked out... https://github.com/aspnet/AspNetCore/issues/1528

joehanna commented 5 years ago

Another Microsoft fail that leaves its loyal devs out in the cold. Happened with VB6 and Windows Mobile. The platforms were just dumped/abandoned/deprecated/put-out-to-pasture/choose-your-own-verb. We have a massive web application that was built on Webforms and the @DamianEdwards framework: https://github.com/webformsmvp/webformsmvp (which creates a bridge to testability and separation of concern). We are happy with the architecture - it works and is fast. What do we do now? Convert this massive app to a new architecture on .NET Core, so in another 10 years, it too can be deprecated with no migration path and we have to do it all over again? Stay on .NET Framework? With no momentum for improvement or innovation? When we mention we are on the .NET Framework rather than Core, our stack is frowned upon, despite its functional and performance capabilities. If we are going to have to rewrite it, why bother with Core at all? We might be better jumping ship (where we have loyally been since .NET 1.0) and see what else is available. It will be a full rewrite after all.

samjones3 commented 5 years ago

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

ststeiger commented 5 years ago

@joehanna: Yea, I kindof agree. I would say it was a big mistake to not make .NET Cross-Platform (at least the non-ui part) from the beginning - but hey - MS called it the Windows strategy tax. Now that strategy backfires here.

Overall, you just can't make a framework multiplatform, improve performance, and make it overall more maintainable without breaking a few things here and there (dependency injection and system.web.httpcontext.current for example).

Other frameworks have done similar things.

For example Python when moving from v2 to v3. PHP when it moved from PHP 4 to 5, 6 and 7. And Ruby is a nightmare, especially if you have a lot of dependencies (try getting redmine to run on MSSQL-server - it can be done btw, with a little hacking). Golang seems to be better, but it lacks classes, abstract classes, generics, sane nullable support, strong interfaces, functions whose name are self-explaining (os.is for example checks if a file exists...) And there is no good reporting solution for Ruby, Golang, Python, etc.

Now NodeJS would be a thing, but overall, maintaining JS is a nightmare, and due to the NPM repository, it can break at any time (e.g. when the trim package is removed), and unless you use TypeScript or Babel with Flow, it's gonna be a mess with large projects (and unfortunately, TypeScript and Babel/Flow are not perfect either)..

So jumping ship is not a good option either, because you'll have to re-write everything, while re-writing a little C#/VB.NET shouldn't be an impossible task.

After all, it's not like your old application will suddenly stop working, it's gonna be supported for a long time. Try running a ten year old Linux binary on a current Linux system - good luck, you'll need it. Usually no problem on Windows. And you can change the project to MVC, and start removing the webforms stuff interatively, piece by piece, writing new stuff with MVC, which should be compatible. You can then use the old ReportViewer (on Windows), and then you can upgrade your project over a longer timespan. At the company I work for, we're for example still using .NET 1.1 and .NET 2.0 (not Core) in our projects. We do new stuff with JavaScript and rest, and one day we will finish removing all the WebForms stuff, whose usage was never a good idea in the first place.

So you have an upgrade path, and a compatibility path. Choose wisely, and you can hopefully dodge a COMPLETE re-write.

As for ReportViewer, this is not all that easy. It kindof works with HTML/MHTML, XLSX and DOCX, and with a little tinkering, XLS and DOC support can be added. But for PDF and images (and PPTX), it uses a lot of stuff that is very windows-specific (windows-APIs). For example it uses GDI+ handles to create the multipage-tiff, GDI+ to write letters, GDI+ to get font-data (which has no corresponding 1:1 translation on Linux, not to mention Mac/Android). It also uses USP10 to get unicode data, determine glyph-length, kerning, line-breaks, text-measuring, etc. And I haven't even tested HTML extensively.

Then SSRS in all it's wisdom chose VB.NET as its scripting language. VB.NET support on .NET-Core/Roslyn, which has only just come not even a month ago (and I don't yet know how complete). It also uses the Windows-C# compiler toolchain for that (.NET 4.0), that you need to switch to Roslyn.

Then comes Windows authentication, missing APIs in System.Drawing (that have only been filled with 2.2), etc. etc. etc.

So if you want to switch the ReportViewer not just to .NET-Core (on Windows, where I have it largely working - some minor issues with the VB.NET compiler for expressions), then you need to remove all the GDI-stuff, and you need to replace all the calls to USP10 with something, and then you need to replace the font-API with corresponding calls to FreeType, which not only don't exist 1:1, but also the freetype C# port needs different data-types on Windows and Linux, so you need an operating-system specific FreeType assembly on Windows and Linux.

Then with all that, you need to retain RDL backwards-compatibility (reports, custom code), and you still need to be able to use the new ReportViewer in WinForms (and WPF?) applications. Which means that couldn't be done before .NET Core 3.0. And if your new reportviewer then runs on the latest iteration of the .net and .net core framework, then it won't work on older frameworks, which is a bit of a bummer, as they need the new version, too... Then comes the fact that reportviewer used WebForms, and that doesn't exist anymore in .NET-Core... Now you need to find a way to put images into that html (probably background-image base64 to the rescue). And probably some more things I didn't think of, or that I forgot or didn't yet notice.

So this is a rather monumental task, and will not be finished à la quick'n'dirty.

I recommend that instead of complaining, you use the time to focus on making your application .NET Core (ASPNET-5) ready, so you can go about putting the new ReportViewer in when the time comes. Oh, and yes, due to missing WebForms, the ReportViewer will most-likely not be backwards-compatible to old stuff you had. Just FYI, and my 0.05 US-$. In the meantime, you'll just have to live with the full .NET framework - which should be sufficient for the corporate world to date.

Things could always be better, but you just have to work with the tools you have, not the tools you'd want to have - the tools that we'd all want to have. That's life. Plus if you chose the wrong framework for the wrong reasons, that's your fault, not Microsoft's.

Just complaining and whining will get you nowhere.

steveisok commented 5 years ago

I've got a repo that is running 4.6 reference source WebForms on Mono (just got it running on kestrel btw). If anyone wants to help, it's here - https://github.com/steveisok/mono/tree/webforms-system.web

I've also tried to port what I had to core, but that's been a mixed bag... I think it's possible, but I've been tripped up shuffling projects around (e.g. System.CodeDom) and not fully grasping how the build works. Certainly a longer road w/ core - no question about it. Would love to pick anyone's brain who can shift it around at will, otherwise I'm probably giving up there...

Anyway, WebForms on Mono probably is the last best chance to get it cross platform in my opinion.

Having worked w/ it for a while, I can understand why they ditched it... But at the same time, I think if you dedicate a handful of resources, it's certainly possible to produce something worthwhile for the community.

MgSam commented 5 years ago

Now that .NET Framework is (officially?) deprecated and the pretense of it still being a valid choice has been dropped I hope Microsoft takes another look at this. The vast majority of companies using ASP.NET do not have teams of extra developers sitting around just waiting to port old WebForms code to .NET Core.

The exact same reasons you guys ported WinForms to .NET Core apply to WebForms.

brettpostin commented 5 years ago

Following recent announcements regarding the future of the .NET Framework, we are currently looking to slowly migrate our existing WebForms application over to asp.net core. Scott Hunter talks about developing new things in core and leaving existing web forms to run side by side in a recent .net rocks podcast.

What we would like to do is migrate over to asp.net core razor pages in a piecemeal fashion over time. Our app runs on IIS, full .NET Framework 4.7.2/8 (for now) and ideally we would like the core razor pages and WebForms to live within a single project and site.

However attempts to bring in the Microsoft.AspNetCore.Mvc.Razor packages into an existing web app have been unsuccessful. This package has a target for full .NET Framework so we (naively) assumed it should be possible to run alongside.

Couple of questions...

Edit: @danroth27 I just read your advice here. Are you able to provide any further input on the above?

tomasherceg commented 5 years ago

I am not sure if ASP.NET Core can be run side by side with classic ASP.NET stack.

However, if you are looking for a way to slowly migrate Web Forms apps, you can try DotVVM:

After you migrate all pages in DotVVM and get rid of ASP.NET stuff (forms authentication etc.), you can then switch the project to .NET Core.

Here is a sample repo demonstrating the migration process.

SkyeHoefling commented 5 years ago

I can confirm that you can run ASP.NET Core libraries in a ASP.NET WebForms website. I have been working with the DNN Community on migrating the platfrom from WebForms to .NET Core and this is an approach I have taken to solve the incremental stages.

I would recommend configuring Dependency Injection so you can abstract away your System.Web components and then get everything working in .NET Standard 2.0 which will make the migration easier. I just submitted a PR for DNN that uses the Microsoft.Extensions.DependencyInjection library which is the same used in ASP.NET Core. This would be the exact same approach I would recommend to anyone still on WebForms looking to migrate.

Here is a blog I wrote over the weekend that talks about how I see this migration working and how we got the same Dependency Injection library that ASP.NET Core uses working in DNN.

As far as getting them to work side-by-side. I don't have any production code to share, but you can leverage Razor Pages for example and get the same rendering engine to produce html code. This code can then be used by the WebForms rendering engine. This is important so you can migrate your code to Razor Pages while still working on the bigger architectural puzzle.

brettpostin commented 5 years ago

@ahoefling Thanks for the info. Your blog mentions Razor 3 pages, which I believe are different to the new asp.net core razor pages.

We have managed to run the old asp.net WebPages (with razor views) side-by-side with WebForms, but not the new asp.net core razor pages. Could you clarify if you have managed to successfully run the new core razor pages side by side?

davidfowl commented 5 years ago

ASP.NET Core cannot trivially be hosted in a System.Web application without doing somehow bridging the two things. You effectively are trying to run the old stack next to the new stack in the same application and that isn't really possible today (without doing some sort of Katana OWIN bridge). The first thing you need to do to start a slow migration is to make a new ASP.NET Core project and decide what functionality you want to port over, then host 2 different sites on IIS (in different app pools) and pick one based on the incoming URL (using URL rewrite or something similar).

tomasherceg commented 5 years ago

@davidfowl And create a mechanism for single sign-on so the user identity is shared between the two apps.

brettpostin commented 5 years ago

@davidfowl your suggestion was actually our fallback solution. Thanks for the clarification on running in a single site.

@tomasherceg thankfully we have already solved this problem with identity server as our existing application is comprised of two separate sub apps. It looks like we may now have a third :)

SkyeHoefling commented 5 years ago

@brettpostin you are 100% correct as that blog is all about Dependency Injection and not Razor Pages.

I have a proof of concept working on my local fork of DNN using ASP.NET Core Razor Pages inside of System.Web. Something I am going to be blogging in more detail in the coming months as I finish implementing it.

@davidfowl in my example for DNN we have a custom rendering pipeline built into System.Web that allows me to inject the output html very easily as a Web Forms Control. To get ASP.NET Core Razor Pages working in DNN I built a custom IServiceCollection that manually built up all the required ASP.NET Core dependencies to render a Razor Page and then return the HTML. Once I had the HTML I was able to pass the raw string into our Web Control rendering pipeline that returned it to the page.

The idea for us, is once we get this flushed out we have a module pattern that allows us to perform a soft migration to ASP.NET Core. We will be able to create modules that are built on Razor Pages technology that is independent of any System.Web code

davidfowl commented 5 years ago

@davidfowl in my example for DNN we have a custom rendering pipeline built into System.Web that allows me to inject the output html very easily as a Web Forms Control. To get ASP.NET Core Razor Pages working in DNN I built a custom IServiceCollection that manually built up all the required ASP.NET Core dependencies to render a Razor Page and then return the HTML. Once I had the HTML I was able to pass the raw string into our Web Control rendering pipeline that returned it to the page.

The idea for us, is once we get this flushed out we have a module pattern that allows us to perform a soft migration to ASP.NET Core. We will be able to create modules that are built on Razor Pages technology that is independent of any System.Web code

Very cool, I look forward to seeing it 😄. Bare in mind ASP.NET Core 2.1 is the last long term supported version that runs on .NET Framework, but it sounds like you were able to get the entire MVC pipeline running (or maybe I'm missing something). Anyways I look forward to the post!

mitchelsellers commented 5 years ago

@davidfowl the long term plan is implement the fun stuff in 2.1 plus regular .net to start transition then a hard cutover to 3.0 so we can provide an upgrade path.

davidfowl commented 5 years ago

@davidfowl the long term plan is implement the fun stuff in 2.1 plus regular .net to start transition then a hard cutover to 3.0 so we can provide an upgrade path.

👍

davidfowl commented 5 years ago

If anyone has experience porting an application feel free to share it here as that advice can come in handy for others trying to port. It'll also be an opportunity for us to beef up our docs in this area https://docs.microsoft.com/en-us/aspnet/core/migration/?view=aspnetcore-2.2#aspnet-to-aspnet-core

ststeiger commented 5 years ago

If anyone has experience porting an application feel free to share it here

Yea, erm, about that... I don't think you'll like that.

We have a large legacy ASP.NET web-forms web-application (originally website-project - thus no namespace), written in VB.NET. As the software runs at the customers, we are at the whim of them for updates., which is why we are still on (full) .NET Framework 2.0 (that and the fact that our sysadmin is a BOFH).

Worst practices employed, copy-paste all over the code, some former "programmer" clearly hated JS, and did all he could to avoid it, consequently everything is done in postbacks, no ajax. Copy-paste everywhere, not even a class for managing db access, and the use of session is so tightly integrated that it makes it impossible to remove or replace even small fractions of code. Making matters worse, jQuery-UI is used for datepickers. In short, worst practises . The additional use of WCF complicates things.

But worst-practises besides, .NET Core 2.1 (and 2.2, too) does not really support VB.NET. So my advice for anybody with a VB.NET legacy web-forms application is to go with a full re-write in C#, and use the telerik-converter to translate VB.NET to C#, where code can be salvaged.

That means

Bonus caveat:

If I use these stats as my base for an examination of the costs of porting... Let's assume trans-best-case:

In other words: this is a death-trap - and porting is not even feasible at this time (no capacity & no rdl). Fortunately, not my company. Been here for almost 10 years (anniversary in 1 week) - time to move on to greener pastures.

If anybody wants to estimate the costs for their project, here's the file-indexer I used (and wrote).

brettpostin commented 5 years ago

@davidfowl Going with your suggestion of running separate apps in IIS and routing accordingly, we can do that and it works ok. However the development experience / feedback loop is really poor in having to publish locally anytime a change to the core app is made.

Running the core app in isolation in IIS express, the change-refresh feedback loop is fine. However in order to do the migration piecemeal, the two apps need to run together in IIS during development in order to work as a single application.

Do you have any suggestions to smooth that over?

ststeiger commented 5 years ago

@brettpostin: You can use nginx or caddy as reverse proxy. Then you can run app1: in visual studio http://localhost:xyz/Virt_Dir_X app2: in visual studio http://localhost:uvw/Virt_Dir_Y

and nginx reverse proxy both, and put them on 1 domain: 

http://localhost:666/Virt_Dir_X
http://localhost:666/Virt_Dir_Y

Now you can debug with Visual Studio as usual. If you don't want to debug, you can also uncheck the edit-and-continue field in the web-section of the project-properties, for the .NET-Framework project.

Bonus: Doesn't require admin rights, unlike IIS. Caveat:

Note: nginx can re-write urls (in cookies, ajax calls, responses, etc) so you can route http://localhost:/Virt_Dir_X to something like http://localhost:xyz/Not_Virt_Dir_X

Works with https as well.

Since I once setup Redmine with RoR and MSSQL via IIS, I know IIS is (barely) capable of reverse-proxying, too, so if you have too much time to spare, you can also try to setup the appropriate web.config file inside a virtual directory.

Here, an example:


<?xml version="1.0" encoding="UTF-8"?>

<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->

<configuration>

  <system.web>
    <compilation debug="true" targetFramework="4.0" />

    <globalization culture="de-ch" uiCulture="de-ch" requestEncoding="UTF-8" responseEncoding="UTF-8"/>
    <httpRuntime maxRequestLength="2048000" executionTimeout="86400"/>

  </system.web>

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>

    <!--
    <modules runAllManagedModulesForAllRequests="true" >

    </modules>

      -->

    <security>
      <requestFiltering>
        <!-- 2 GiB-->
        <requestLimits maxAllowedContentLength="2147483648" />
      </requestFiltering>
    </security>

    <rewrite>
        <rules>
            <rule name="ReverseProxyInboundRule1" stopProcessing="true">
              <match url="(.*)" />
              <action type="Rewrite" url="http://127.0.0.1:3000/Servicedesk/{R:1}" />

              <conditions logicalGrouping="MatchAll">
              </conditions>

            </rule>
        </rules>
    </rewrite>

  </system.webServer>

</configuration>
FatClientHub commented 5 years ago

There is really no excuse not providing WebForms on Core, given that Mono has WebForms support.

So there is nothing Windows specific in WebForms that can't be made cross-plattform. Mono is proof of this. And it was made by a far smaller team than the .NET team at MS.

It's really preposterous that MS is asking everyone to port their WebForms applications to core (causing MASSIVE work for everyone else), instead of porting their System.Web to Core. And again, given the existence of Mono, IT CAN BE DONE. IT HAS BEEN DONE!

ststeiger commented 5 years ago

@FatClientHub: In defense of Microsoft - that really makes no sense. Besides, mono's WebForms implementation has never worked satisfactorily.

However, porting over > 1'200 ascx and > 700 aspx is out of the question as well. We'd need some form of interop, so that WebForms pages could be ported over incrementally. At least so that new stuff wouldn't need to be created in WebForms, so the pile of technical debt at least doesn't increase ... I don't see that right now, not with VB.NET anyway.

davidfowl commented 5 years ago

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

steveisok commented 5 years ago

I'd argue it's more of a grind porting a compatible one to mono, but nonetheless difficult.

davidfowl commented 5 years ago

WebForms is part of the issue but there's all the infrastructure to make a compatible system web. Mono works based on the old classic pipeline model (IIS 6 non-integrated mode) and that's where a large part of the incompatibility comes from.

steveisok commented 5 years ago

I hear what you're saying. Guess a webforms port means potentially a bunch of different things to different people and that would be part of the problem.

davidfowl commented 5 years ago

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. There's much more than the runtime pieces though:

IMO any port would just look like a new thing on top of ASP.NET Core (like what WCF did), where the very top of the application model is pretty much the same (like the service contract in WCF) but a bunch guts have been rewritten which will result in subtle incompatibilities for some applications.