A company I'm working with has a reasonably large web forms app ( >300 pages, albeit nothing especially fancy - just basic CRUD screens). The fact that they're doing new web forms in 2022 aside, one thing that baffles me is that they deploy the whole project without precompilation - just bulk copy pages and codebehinds to the production server and call it a day. I've worked a number of places with large web forms apps and have never seen this done for anything other than a quick-n-dirty web page, and I've always been told it's a best practice to go Application over Site for anything large.
Their senior dev says it's important for flexibility, since they can deploy changes on the fly. But I've worked with much larger, more mission-critical apps in larger organizations and never once have I seen that used as a justification.
Unfortunately it's been so long since I've even had to think about this sort of thing that I am terribly inarticulate about why this seems like a bad idea for a site this size. I can guess that having the compiler running on he server every time a page is first hit can't be great for overall performance, but I can't back that up with anything more than instinct.
So, gentle readers, how can I explain why precompiling a largish web forms app is a good idea?
CodePudding user response：
By default, ASP.NET Web Forms projects are deployed non-precompiled, with all code files (markup, scripts, code-behind, class files).
This is only suitable in a development workstation or development server environment where performance or security is not an issue.
For a production environment, the ASP.NET Web Forms projects should be precompiled.
Advantages of pre-compilation of ASP.NET Web Forms include:
- faster response time (when loading pages)
- error checking (before deployment)
- source-code protection (only binaries and markup deployed)
- efficient deployment (fewer source files combined into binaries)
So, say you have a server on-site, and that site is the public exposed web server.
Well, you can open the site directly. Now, you can say open up a web page (say markup) - edit some text, change some text on that web page - hit ctrl-s.
You are done!!!
So, in fact you point Visual Studio "directly" to the inetpub\wwwroot folder.
So, now you have ZERO deployment. You can edit the pages (and yes even code behind) directly. All you have to do is hit ctrl-s, and you are done. There is zero deployment here.
As noted, in some cases, after editing, you can manually copy the change page (and code behind page) to the site. But often, you don't even do that - you just edit the whole site directly in VS, and thus you don't even have to deploy.
This is what we call a asp.net web site.
No, you can also use what we call a asp.net web site applcation.
Note the VERY slight different name - the word "applcation" is used here.
In that case, then you build the web site - probably local on your dev box. Come deploy time, then you have to publish the web site. Even publish to a local folder called say c:\mytestweb\ is possible.
Once done, then you have to copy or ftp or whatever, and OVER WRITE the WHOLE web site for that upgrade. In this case, then ONLY the source markup pages, and the WHOLE pre-compiled code is to be sent to the web site. This can often be painful, since you might have say made a bunch of changes to code, not ready to publish, but now your production site has a bug, or issue.
So, with a web site, you can go modify the ONE page, a bit of code, and simple copy the markup page the code behind page, and you are done.
I 100% hands down prefer using a "web site applcation". (and thus a project "sln" file is opened used). However, deployment time is painful, since you often have to stop the web site, deploy, and then re-start the site for changes to take.
And a web site applcation quite much assumes the WHOLE web site and server is yours and you have 100% control of the server. In fact some of the "low cost" hosting planes will not work using a web site applcation. And even more important, say you have another whole site that does some other web site feature set - that can in most cases be deployed in a sub folder ONLY WHEN using a "web site", and NOT a web site applcation.
And of course a web site applcation has and lets you do more things. So, for example, you can build use says a custom logon provider. With web site you can NOT do this, but with a web site application, you can. In effect, with a "applcation", the WHOLE site, the start page, and base root of the site is 100% under your control. Your applcation then quite much becomes the whole web server upon publish.
But, yes, using a web site is REALLY nice, and especially for larger sites, since you can go change one page - edit, then save, and you are done.
The big down side is that any such page will cause the site to re-compile, and this can introduce quite a delay. but often, developers after doing that simple save or change to a given page?
Then they go to the public page and type in that url or "load" that page - it will crunch away, compile, and once done, then any further use of that page should run work without further efforts on your part. And to my knowledge, this does cause a app-pool re-start (and if using memory based "session", then those sessions are lost by current users on the web site. However, memory based "session" never been reliable , and thus we turn on sql server based sessions - and thus even a app-pool re-start (which occurs here) does not matter.
While a web site "application" is VERY much preferred, come publish time, it much more difficult, since you have to re-publish the whole site and applcation - and that can often be painful. And in most cases, it means the site has to be taken down during such a upgrade (or at least re-started). And if you have a rather large site? Then up-load time of the all the pages again can often take some time. (you re-up load the WHOLE site each time).
So, yes, this "web site" choice and setup is and was common, and it is VERY nice from a developer point of view. And as noted, while not recommend, I know of developers who actually open the production web site directly from VS to make their changes, and a simple ctrl-s is the ONLY thing required to have updated the site.
The other down side of an "applcation" is that you in most cases can't publish as a sub site or sub folder - since an "applcation" is assume to have things and "over all" events like session start, applcation start - and most of these features and events and "base site" features cant be used with web site publish, but can with web site applcation publish. And this often includes authentication providers.
In effect, a "applcation" publish is like up-grading a desktop program. You have to over write and re-deploy the .exe (or in this case the .dlls) each time you upgrade.
So, it not ONLY a pre-compile, but a web site gives you QUITE a few more features and abilities then the difficult web publish. I don't believe that web publish say allows you to write and build say a custom logon provider. (since it applies to any site and any sub site (folder) that exists on that web server. And same goes for some features like building your own.
Other issues (in favor of applcation). Class library references. Since your whole project is pre-compiled, then class placed outside of say app_code are pre-compiled. You get MUCH better references resolution when using applications.
Forced compile to a given version of .net. When you develop and write to a code standard, if you pre-compiling, then you can be REALLY be sure that all your code will run correctly. Letting asp.net ON THE web server compile your code? Gee, are you SURE you have the same version of .net that compiling?
Roslyn compiler. I started using Roslyn - mostly for "free sql text" in code, and especially for sql commands. However, I noticed that some of my code (in app_code) folder was failing "after publish". So even with a "applcation" you find that app_code will be compiled by the web server AND NOT DURING development. So, I just created my own folder called mycode, and put classes and other junk in that folder. Since I am compiling on my dev box - no surprises when deployment.
So, if the web site not been updated, the compiler on the web site might not match the behaviors on your development box. With an applcation, then you can be 100% sure your code will work at publish time (or 100% not work - there not a gray area and a hope on a wing and prayer that your code is NOW to be compiled on a different box with a different compiler then what you developed with.
The Rosslyn compiler issue I had is one such great example. The web site does not have the Rosslyn compiler - so some of my code was breaking. And that was with ONLY ONE possible folder (app_code) that EVEN does get re-compiled with web applications. the instant that issue came up? I 100% dumped using app_code - NO WAY am I going to allow the web site to re-compile for me - code started breaking.
So, for additonal .dlls, and class references, a "applcation" is much more robust, and will not only catch compile errors better, but MUCH better is resolution of other class and code libraries with a applcation.
By letting the web site compile - and compile all the time? Then you can wind up with multiple copies of .dll's all over the place - often with the same class name. This also means that EACH web page on the site has it own .dll, and own assembly. and it has to resolve references for those gazillion .dlls.
And other advantages exist for application. I can say for example, "exclude" some class or folders from the project - they don't compile nor are used. You don't have this option with a web site - all files and even source code exist on the web site. And will be compiled (or attempted to compile).
And what if you need some post-build compile options? (or pre-build steps) during compile? Again, you can't use web site for that.
And debugging? Things like edit and continue, unit tests? again applcation wins. So debugging is another huge in favor of application.
Use of stand alone classes, they are much better with a applcation. (external referenced projects and assemblies).
You want to "share" some class library projects you already built. Again, you can't really do that with a web site - since all code (source) MUST be on the web site. I have a number of shared project library code right now - I can't thus use web sites - those external libraries and class objects would have to be INCLUDED in the source code. Right now, I just reference and include that external assembly, and I can now use those class objects and library code when ever and where ever I like in code - not so with web site. and such code can be freely used even in one code behind page.
And even just control over assembly names, and version number of classes and object I use? Again not possible with web sites.
And do you really want to put all your source code on the web site server? I don't like doing that. If that web hosting gets some kind of upgrade - they might well upgrade to a newer asp.net compiler - and code will break or work different (like what occurred for me in regards to the Roslyn compiler).
So, if you have 100 pages, you going to wind up with a 100 assemblies - and that going to stress the server to resolve references. (and as noted, references are far more flaky anyway).
So explicit namespaces are added to pages, controls and classes by default with a applcation. With web site - they are not. So I think the "resolution" of code, library's and pre-compile of everything is the greatest advantage of applications - but you pay a higher cost at publish time, since it is a "all or nothing" kind of deal. One small change, and you are faced with a full site re-publish. I suspect this reason is why web sites are still often preferred.
However, the fact that I am including other .net projects into my web site applcation? That is VERY difficult with a web site - since now all the source code of those libraries often has to be included - and where do you put that stuff?
However, having stated the above, web site has a lot going for it, and one is REALLY great ease of updating a simple page or a wee bit of code - all can occur without a full site re-compile and full site re-publish.
So, their are pros and cons - but I hands down prefer the applcation model - despite the heavy price at publish time.
There is no "one is better then the other", and your current development environment often will dictate which choice is better for you. In most cases, we not writing the next Facebook, so the performance issues are not huge - but debugging, and having "more" control over the build process is something I as a developer value more then the ease of publish. But, that choice of mine does have a high cost at publish time. it not a slam dunk in favor or one or the other. But, to be fair, the ease of publish for web sites no doubt is "often" the reason for webs site choice.
For example, just today, I saw some web site errors. (I have a global error handler that sends me a email for any code errors). I want to fix this error in code - but I am in the middle of having added quite a bit of new code - I can't now address that error I am seeing until I finish up the current code changes.