Migrate Web Forms applications to .NET Core

As the .NET ecosystem is moving from .NET Framework to the .NET Core runtime, application owners face increasing pressure to port their applications to the new runtime.CoreForms allows you to maintain and run your existing Web Forms code as a .NET Core applications, without any dependencies on .NET Framework.

CoreForms - run your Web Forms application on .NET Core

While Microsoft eventually ported most .NET technologies to .NET Core, it's very clear that Web Forms will not be available. This is a problem for many line of business applications that might still have a bright future if it were not for their dependency on Web Forms. This is in many cases not a matter of just adapting the application code: the Web Forms framework is deeply entrenched in the architecture and design of many applications, often to the point where it's inseparable from the actual application code.CoreForms now provides this critical technology for .NET Core applications. CoreForms enables both direct updates to .NET Core, and incremental migrations to new Core technologies such as ASP.NET Core MVC or Razor Pages.

Discover the features of CoreForms

CoreForms provides the System.Web namespace to .NET Core applications and includes the accompanying client components (JavaScript and other resources).

Access to all .NET Core features

  • Modern frameworks and classes

  • Current C# features

Pick your third party libraries, Open Source or commercial

  • Up-to-date .NET Core libraries

  • Existing Web Forms libraries, including control collections

Mix Web Forms code with other UI technologies

  • Use Web Forms code and MVC or Razor pages in a single application

  • Seamlessly share in-memory state

  • Incrementally migrate your application to a current web framework

Host your application on Microsoft Windows in any of the standard ASP.NET Core hosting models...

  • Kestrel web server

  • IIS using ASP.NET Core Module (in-process or out-of-process)

  • HTTP.Sys web server implementation

Increasing pressure to port existing applications to .NET Core

Microsoft will support .NET Framework 4.8 for many years to come, but this support is limited to security issues and critical bugs. This presents many problems, including the following:

No support for current C# language versions
The last version of C# with full .NET Framework support was C# 7.3. C# 8 through 11 are only partially available for .NET Framework.
This leads to the following consequences:

  • Modern C# code cannot be used, including code snippets but also entire libraries.

  • Development tools such as IDEs and refactoring tools might cease to support these limitations.

  • Developers might be frustrated not be able to use the latest language features.

  • It gets harder to hire new developers, and top developers might even consider quitting.

No library updatesMany libraries, especially those from the Open Source community, will no longer be maintained for .NET Framework.
This leads to the following consequences:

  • You might have to pay premium support fees for commercial vendors.

  • You might have to maintain old versions of Open Source libraries yourself.

  • You might experience situations where critical bug fixes, or even worse, security fixes for your libraries are no longer available. This would force you to replace entire libraries and frameworks, and it would make your software vulnerable in the meantime.

  • APIs and SDKs for other products that you depend on might no longer be available.

No new libraries and toolsMost libraries and tools created today are only provided for .NET Core.
This leads to the following consequences:

  • It will become increasingly hard, costly and frustrating to support new technologies in existing applications.

Are there constraints?

Is CoreForms compatible?

Get in touch with CoreForms!

Our support team is eager to answer all your questions! Don't hesitate to write us any of your requests via form or email to
Or contact us via phone: +43 1 533 25 55 0

Note on naming: Microsoft has renamed .NET Core to just .NET, starting with .NET 5. to avoid confusion with .NET Framework, .NET is often still called .NET Core, or sometimes modern .NET. This web site refers to it as .NET Core.

Are there constraints?

Currently not available in CoreForms

The following features are currently not available in CoreForms, but might be added in future versions depending on customer feedback:

  • Localization: Localizations for UI components (e.g. input validation and labels), error messages and diagnostic output are currently only available in English

  • Linux

Unavailable in CoreForms

The following features are unavailable in CoreForms, and will probably remain so:

  • Visual Studio designer user interface

  • Thread-Abort semantics

  • Integration of IIS modules in the HttpApplication / Global.asax: ASP.NET in .NET Framework supported the integration of IIS Modules directly in the request processing of the web application. With ASP.NET Core, this integration has changed.

  • ASP.NET Request Tracing

  • Out of Process Session State (ASP.NET Session State Server)

  • Windows Performance Counters

  • WMI Events

  • WebSockets based on IIS -> Can be replaced with ASP.NET Core WebSockets

  • Settings in web.config based on IIS -> Can be replaced with ASP.NET Core features

  • Customization options for ASP.NET code generation

  • ASP.NET WebForms features that rely on the following .NET Framework components: depending on System.EnterpriseServices or on Active Directory Integration (e.g. Active Directory-based authorization models in the web application) or based on Linq to SQL, e.g. LinqDataSource

  • "Web Site" project type

There might be additional edge cases that are unknown today. Note that we cannot guarantee full portability of any specific application.

CoreForms compatibility with applications and third-party libraries

Thread-Abort semantics

.NET Core no longer supports the automatic rethrow of ThreadAbortException. Web Forms uses ThreadAbortExceptions for control flow. Application code that catches these exceptions and fails to rethrow them will not work in these situations. A typical issue would be a catch-all block.Any code path that may rely on HttpServerUtility.Transfer or ThreadAbortException must be reviewed with respect to the use of catch-all blocks. Catch-all blocks must then be updated to explicitly rethrow ThreadAbortException:

CoreForms Compatibility Thread-Abort semantics

This applies to applications as well as to 3rd-party libraries.

Application Life Cycle Events

ASP.NET Core does not provide support for the IIS Integrated Pipeline. Therefore, the events of the ASP.NET Application Life Cycle for IIS 7.0 are now executed as part of the ASP.NET Core request handling.CoreForms acts as an Endpoint in the ASP.NET Core Middleware order. Integrated Pipeline events will therefore be executed

  • within the middleware pipeline

  • outside of CoreForms page execution

This might work for some event type, especially those that closely interact with application code. Other event handlers, especially those that work on an infrastructure level and/or should be shared with other Endpoints such as MVC, must typically be ported to the new middleware infrastructure.

Changes to HttpApplication / Global.asax

CoreForms uses ASP.NET Core for hosting and startup of the application. Code in the HttpApplication / Global.asax related to application-wide behavior (e.g. Authentication) must be updated when porting an ASP.NET application to CoreForms if the existing implementation is either not compatible with ASP.NET Core or ASP.NET Core-native endpoints should also be integrated into the application.

General note on 3rd party library compatibility

CoreForms provides basic runtime support for libraries that are compiled for .NET Framework. Depending on the library you are using, this might work flawlessly or not at all.Generally speaking there are two broad categories:

  • Control libraries can work if they don't use any unsupported features and use clean exception handling (see thread-abort semantics above)

  • Infrastructure-level libraries, such as authentication handlers, should probably be replaced with .NET Core versions

Privacy Policy

We consider your privacy and the security of your personal data as of great importance. The following sections inform you about the personal data we process when you use our website.

Who is responsible for the processing of your personal data?

When you visit our website, your data is processed by:
Gonzagagasse 16
1010 Vienna
E-Mail: datenschutz@rubicon.euCompany ID: FN 216900x
Commercial Register: Handelsgericht Wien
UID: ATU53027200

What data is being processed?

The following sections provide an overview of the personal data we process when you visit our website and the legal basis for the processing.
Contact forms
If you use the contact form on our website to ask more about our products, we process the data you submit in the contact form in order to process your inquiry. If your inquiry also concerns our partner products, your data may be forwarded to these partners. The processing is based on Art 6 para 1 lit b and f GDPR, because it serves to initiate a contract with us and is in our legitimate interest. Your data will be stored for as long as necessary to process your request.

Your rights

When we process your personal data, you have the following rights under applicable European and Austrian data protection laws:
• Information
• Correction
• Deletion
• Restriction
• Data portability
• Object
If you believe that the processing of your data constitutes a violation of data protection laws, you are free to contact the Austrian data protection authority (Barichgasse 40-42, 1030 Vienna, telephone: +43 1 52 152-0, email: