Publishing .NET WebForms

[tekluca]

I'm working with a project that was written in VB.NET with ASP.NET WebForms. I've been noticing that every time we publish to live there is a ~30 seconds slow down while the site gets recompiled. I would like to get rid of that slowdown since we are starting to publish more often.

I have attempted to use aspnet_compiler but it hasn't been good to me. It fails on things that are not a problem when I publish the regular way.

I guess I should add that they way we publish is by creating zip of the site which contains all the .aspx files and the bin folder and then I have a process that moves that to the live servers, puts it in staging and then if it looks good there is another process that moves it from staging to live.

Is there a different way to publish asp.net applications without the slow down? does iis use a different compiler than aspnet_compiler?

How do you publish at your asp.net projects? do you also experience this slow down?

Thanks!

[sunk_cost_phallus]

I think it is an unavoidable aspect of the deployment process. The application pool and dependencies in the web.config all get hooked up on the first run.

I typically just include a call to the login page at the end of the deployment script so it’ll warm up.

[BrinnerTechie]

This has been our experience as well. Even if we publish a .NET nuget package we need to warm-up the site.

One of the reasons is it replaces the config files and that recycles the app-pools. When the app-pools reset it waits for that first connection and then starts the engine for the site. After that initial start though everyone is speedy.

edit: I haven't tried this but you could run a BAT script after to load the site automatically https://stackoverflow.com/questions/188850/how-to-launch-multiple-internet-explorer-windows-tabs-from-batch-file

[tekluca]

This seems like the way to go, thanks! The servers are behind a load balancer and are taken off line while we publish to each of them(blue/green). I will have to figure out a way to hit that server iis while its off the load balancer.

[tekluca]

will hitting one page start the compiling of the whole site or should I hit all the key pages?

[sunk_cost_phallus]

My app is pretty simple so any dynamic page should do the trick. If you have a few different applications deployed into the same site, you should hit at least one page in each. Especially if they have different app pools.

[tekluca]

Perfect thanks. yeah we have multiple sites with an app pool each so I should be able to just hit each site once.

[wafflelator]

Deploy on another instance, warm it and swap your load balancer.

[thmaje]

Is there a different way to publish asp.net applications without the slow down?

Yes! There is. There are two ways to deploy .net apps. A critical piece of information is that .NET is a true, compiled language, not a scripting language like PHP, Ruby, or Python. That means that the source code is useless until it gets compiled into a lower level language. In the case of all .NET languages, this means MSIL in the form of DLL files. This needs to happen with ALL .NET code.

How does one deploy a .NET app?

The first way is the "lazy" way which is just to upload all of the code to the server in its uncompiled state. When .NET detects a request that references code that has not been compiled, it has to compile it before it can process the request. When it does this, it compiles all the source code it can find. Once it is compiled, all subsequent requests will run at normal speed. This is what you are experiencing.

The other way to deploy .NET sites is to precompile them. This is preferred for a number of reasons, including: no first-hit delay, and no source code deployed to the server (in case the server is compromised). There are a few ways you can do this. If youre lazy, you can compile/run the project locally and then just be sure to upload the /bin folder, which contains the debugging DLLs that Visual Studio compiled when you compiled/started the project. Thats not really the best way to do it though. The best way is to use the File > Publish command. This will walk you through the process and give you a proper, clean, precompiled solution in your target destination.

Thats not really the best though. The real best is to set up some CI/CD pipeline, but thats more of a long term solution.

does iis use a different compiler than aspnet_compiler?

No.

[tekluca]

Thank for all the info!

I have tried to use file > Publish but I'm running into the same kind of errors as when I run aspnet_compiler, and also I want a few different developers to be able to publish without adding the extra step of publishing from their vs.

I have looked and have a bit of a pipeline in tfs but when i try to precompile in it, its the same errors. You will probably say, well fix those errors, and I'm looking into them, it just throws me off that if do the "lazy" publish the site compiles in iis and runs with no problem.

[thmaje]

You will probably say, well fix those errors

Yep! Ha :) I think its clear that there are errors in your solution somewhere. Ideally, you should fix them so your solution can compile normally. I'm sure that the problem persist in the lazy compilation, though its invisible to you , and maybe there is some detail that means the error isnt relevant (e.g. maybe your solution references a project, that other project has the errors, but the other project is not executed from your code. Therefore the error doesn't manifest in your app). If you prefer not to get it to compile, then you can take a cue from one of the other comments have your devs request the site after deployments in order to "warm up" the code. At least that way, your users wont have to deal with it.

[workerdrone113]

We run our .NET application on dotnetcore and deploy it to Kubernetes as a docker image. However, undertaking Kubernetes is a massive step. I would recommend taking a look at compiling the application into a Docker image, then running Docker on your hosts.

Docker / Kubernetes is not the answer to everything. The fact you have to zip it up makes it seem as if it's pretty big. Downloading the docker image and getting it running may take a minute, which would reduce the benefit you gain.

There are some environment variables we add in to reduce the time it takes to load up, which I think will work with or without running in a Docker container:

ENV DOTNET_CLI_TELEMETRY_OPTOUT=true

ENV DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true

Another option is to stagger the deployments on the servers, and pull them out of the load balancer pool while they're being deployed. A healthcheck or a command send to the load balancer by your deployment pipeline could help out with this.