.NET
Use CI/CD to Maintain Legacy Web Forms Applications
.NET 8 is now here, and we’re excited! But we’re also practical: .NET5+ (.NET 5 to .NET 8) isn’t right for every application.
We explained in an earlier article that .NET5+ deprecates popular .NET Framework technologies like ASP.NET Web Forms. But since .NET Framework lifecycle is tied to the operating system, your legacy ASP.NET applications could last another decade or more. It’s all about proper maintenance.
Your Web Forms application can’t port to .NET5+, but you can adopt the .NET5+ mindset. One of the best features of the new .NET is faster release speeds. Teams can begin adopting this faster, Agile release mindset even with legacy applications.
Just because your Web Forms application is legacy doesn’t mean you can’t maintain it with modern methods. You can maintain your legacy web application using Continuous Integration and Continuous Delivery (CI/CD).
That’s right: CI/CD is NOT just for new applications and microservices. It will work perfectly as you maintain your ASP.NET applications that will remain on .NET Framework. Not only will this method benefit your Web Forms teams in the present, but it also carries future benefits: your teams will have mastered the faster release cadence of the new .NET, making it a smoother transition when that time comes.
In this article, we explain how CI/CD works for legacy applications and then give a practical explanation for maintaining a Web Forms app using CI/CD.
CI/CD and ASP.NET Web Forms are a Great Match
There are three misconceptions about the relationship between CI/CD and legacy applications: that this method is only for new applications, that legacy Web Forms apps are too big for CI/CD, and that Continuous Integration (CI) will harm your web app.
CI/CD is NOT Just for New Applications
Although CI/CD is now one of the most common build-deploy methods for new applications, the principles of automating human actions work with any type of application, including legacy web apps.
CI/CD is the process of automatically building committed code (CI) and deploying it after testing (CD). These are all steps that you use to produce changes to your Web Forms application, but you’re probably doing them by hand.
Many Web Forms applications are currently maintained by manual processes that look something like this:
This method works just fine. But does it really?
Just because a manual process for maintaining your Web Forms application is working doesn’t make it the best method. There are in fact many problems that come with any manual process, including:
- time wasted building and deploying by hand
- time wasted watching to make sure a script runs properly
- time wasted contacting the colleague with proper approvals to run the deployment script
- deployments limited to human speeds
- human error introduced at any stage
- minimally viable or no data trail to facilitate rollbacks or auditing
The good news is that all these problems are minimized, even eliminated, by a CI/CD tool like BuildMaster. Unlike Blazor (Microsoft’s recommended alternative to ASP.NET Web Forms), using CI/CD isn’t creating a whole new thing. CI/CD is just doing your same work more efficiently with a new tool.
Legacy Web Forms Applications are NOT “Too Big” for CI/CD
ASP.NET applications are usually BIG applications. A lot of people imagine trying to use CI/CD with a Web Forms app as trying to move a huge, single-piece sofa down a skinny, twisting hallway. In other words, it will be very tedious if it will work at all (to quote Friends, “Pivot!”).
But in reality, there is no “hallway”: Even if your legacy web app is humungous, any CI/CD tool worth its name can handle it. Every day, BuildMaster customers deploy sometimes gigabyte-sized applications. The key is differential deployments.
It’s a fair assumption that deploying the entire Web Forms application every time would be very time-consuming. But with differential deployments, BuildMaster and other CI/CD tools scan the committed code for changes and builds, and deploy only the changed parts of the application. An action that would take perhaps hours from a human happens in minutes and with one click in BuildMaster.
Continuous Integration Will NOT Cause Problems for Your Web Forms Application
The textbook definition of Continuous Integration (CI) is one commit, one build. In other words, if three developers all commit at the exact same time, the CI server (like TeamCity) will kick off three separate builds. This would hurt large Web Forms applications: Because of their size, the CI server would quickly be overwhelmed with many, nearly identical, big builds.
But there’s no “CI Police” enforcing this definition: When using Continuous Integration, you don’t have to build on every commit. A CI/CD tool like BuildMaster does not monitor your repository by default. Instead, of instantaneously kicking off a build with each commit, you configure your CI/CD tool to pull code from your repository either on command or at given intervals. You control how often your CI server kicks off a build, and any commits since the previous build will be included then (one an hour, one a day, etc.).
Simply put: CI can be instantaneous, but it doesn’t have to be.
What CI/CD Can Do for Your Web Forms Application (and You)
The “point” here is that you can keep maintaining your legacy web app the way you always have, but this does not set you up for success going forward.
Even though it isn’t “new” technology, a Web Forms application is just like any other application, and any application can be maintained using CI/CD.
Maintaining your ASP.NET Web Forms application using a CI/CD tool like BuildMaster gives you many benefits:
| Benefit | How? |
| Faster deployments | Software moves faster than people can |
| More time spent developing | Software automates tedious tasks like watching a script execute |
| Higher-quality releases | Pipelines can be configured with as many automated checks as you want, run much faster and more accurately than humans could |
| Security at high speeds | Automated gates and in-tool approvals skip the email chain without skimping on security |
| Audit trails | Every action in the tool automatically creates an easy-to-access log |
| Easier rollbacks | BuildMaster stores previously successful builds and deployments, which can be immediately redeployed when necessary |
| The .NET5+ mindset | When you finally have to make the switch, you and your people will already be in the right headspace |
What about Technical Blockers?
Three concerns usually come up in conversations about using CI/CD for legacy ASP.NET Web Forms applications: automating ASP.NET builds, deploying ASP.NET to IIS, and security in configuration files. The good news is none of these are a real blocker!
All examples will use BuildMaster as the CI/CD tool.
Automating ASP.NET Web Forms Builds
The concern: Building ASP.NET applications is complicated and includes a lot of files you don’t want to be deployed.
Behind the scenes, Visual Studio uses MSBuild to build Web Forms applications. However, it doesn’t specify an output directory by default.
However, you can run MSBuild directly to build your web app, using a simple command, and the output generated will be put in a special subdirectory, with files that you only would want to be deployed to IIS.
All of this is even easier when automated in BuildMaster.
Deploying ASP.NET to IIS
The concern: Deploying to IIS often takes many tries before success, due to files in use. This leads to downtime.
There are two options for reducing this downtime. Web Forms applications served by IIS are comprised of the site, application pool (AppPool), and binding.
One way to get around the “files in use” problem is:
- stop the AppPool
- wait a few seconds
- deploy files
- start the AppPool
- retry then if any of those steps have an error.
- All this can be done automatically if configured in BuildMaster.
Another way is more complex but eliminates the downtime between stop and start. Deploying IIS sites typically occurs in two stages: stopping the AppPool to prevent conflicts and deploying the new files to a different directory, then swapping the home directory (a blue- and green-style of deployment).
Not only is this possible in BuildMaster, but it’s also actually faster because we have a pre-written plan for IIS. The tool can stop the AppPool, deploy the new files, and test everything for accuracy in a fraction of the time of a manual process. If you use the application template for ASP.NET, the template table will alert you to anything else you might want to configure before continuing your changes.
Configuration Files and Security
The concern: To use CI/CD with ASP.NET Web Forms, configuration (config) files must be included in source control, which may lead to security or compliance issues.
This is an important concern because compliance is critical these days.
BuildMaster provides configuration file assets, which store a multi-tabled editor to edit and compare the multi-instance configuration files it stores. Administrators can set config file visibility for Integration, Testing, Production, and any other environments you have in your pipelines to keep config files secure. In other words, your developers will see that BuildMaster deployed your Web Forms application, and they can even deploy those files on their own… but that doesn’t mean they can see the contents of your config files.
Using BuildMaster CI/CD Pipelines to Maintain ASP.NET Web Forms Applications
Now that we’ve addressed common concerns around maintaining legacy web apps with CI/CD, we want to provide a basic how-to for doing this inside BuildMaster. But to be clear: The best way to try this is to download a free-forever version of BuildMaster and try the ASP.NET application template yourself.
A deployment pipeline is used to get sources, build test artifacts, and deploy to a series of targets either on-demand or automatically once approval is received. Design your pipeline in BuildMaster with as many (or as few) stages, gates, and approvals as you need or want.
- Make your code changes in Visual Studio Code (or whatever your preferred tool is), and commit.
- BuildMaster will then grab the committed code at the defined interval and will kick off a build.
- If the build is successful, BuildMaster will then begin to run the build through your defined pipeline stages.
- If it spots any problems along the way, BuildMaster will stop running that build through until a human rectifies the problem or forces the build to continue. BuildMaster will also pause every time a human is required for approval or security gate.
- Once all approvals are met and all stages successful, BuildMaster will automatically deploy the Web Forms application (stopping the AppPool properly) to IIS for production.
.NET 8 Doesn’t Mean Ignoring the Future
Just because the new .NET is available doesn’t mean that your legacy applications must immediately target them. In fact, Web Forms applications that continue to be functional shouldn’t be rewritten on Blazor at this time.
But waiting doesn’t mean eschewing all these “modern” technologies. You can use modern methods to maintain your legacy apps. Web Forms and CI/CD are perfectly compatible. Using automation for building and deploying will help your teams keep your legacy web applications stronger for longer until it’s time to make the switch.
Get the .NET 6+ Migration Guide
Learning when to make the switch is one of the most important factors in the .NET 5/6+ migration process.
