I have a problem with an old application in asp.net.
This application runs on a server with windows server 2012 and is used by hundreds of people at the same time (same app but which is pointed to by different domains).
The problem is this: every time I modify an .asp file, the page takes a lot of time to "recompile" the code and this causes damage to the users who use it.
This problem does not occur with the exact same application but running on another dedicated server used only by one user.
I've been researching for days, the only noteworthy thing found is that, in the server iis, if I recycle on application pool -> select the application, it has exactly the same effect.
I don't know much about windows server so I ask you for help.
Thank you!
You have two types of deployment models.
First is what we call a asp.net web site,
and then second, is what we call a asp.net web site application.
They sound the same - but they are not.
So, while most perfer using a "application"? The ONE down side is that you have to re-publish the WHOLE site if you say change some code behind. This is good, and bad. The good part is that your code is re-compiled BEFORE you publish. (and in fact, you might even want to re-name "app_code", since that does re-compile by the web site.
However, for the most part a web applcation is "harder" to make a small update, since when you publish, you have to re-publish the whole site. But, the good part is that all code tends to be compiled down to ONE .dll. In effect the the site is pre-compiled before publishing. And with a applciaton, then you can add/change and do more things. In effect, the web site "applcation" allows you to do things like create say a custom logon provider. In most cases, this means the WHOLE site is under your developer control. It also means that code behind (source code) is NOT pushed up to the site.
Then you have what is called a asp.net web site. This allows you to say modify the code (code behind) of one page and then push that one page (and code) up to the site. The web site will thus re-compile that one page. You will note the "delay" that you experiance - but it ONLY occures the first time that page is published.
So, for a "application", you will in Visual Studio open up the project (and a sln file) is used.
For a web site, you from Visual Studio go open->web site.
I hands down prefer web applications, but they are MUCH harder to deploy a small change, since as noted, you have to re-publish the whole site.
However, the two different choices would thus explain the "difference" and as to why the other site don't experience the delay as much as you are. However, usually on first load - there can be a one time delay after a re-publish. And this quite much means the site is down for this time to re-publish.
Also, do keep in mind that if you do modify some files (such as web config), then this WILL cause the app-pool to re-start. (and if you not using sql server sessions, but in-memory sessions - they get blown out when you do this).
It also somewhat possible that the server with one user has more memory, more CPU and a much lighter load - so the reduced delay after making changes might well be the light load on that server.
However, the above two different publishing models and types of asp.net sites would be the first thing or at least the first issue to be aware of.
First, you need to determine if it is a website or web application project (https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1). Default for web application is rebuild for single page changes while default for website does not force recompilation except if special folders or files are modified. You may check to see if any settings for the app pool differ-- in particular "Disable Overlapping Recycle". You may also check the web.config as there may be a setting that is forcing rebuild. You want also want to look at Explicit Complication/pre-compilation option.
You may want to reference the following resources: https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/determining-what-files-need-to-be-deployed-cs
https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1
Optimization setting
https://learn.microsoft.com/en-us/archive/blogs/davidebb/a-new-flag-to-optimize-asp-net-compilation-behavior
Related
Good day
I moved to another company from a previous one, they task me to modify a existing system with a horrific code, but with patience and dedication, I managed to update the system, but I was shocked that they told me to put the source code on the system and it will be the one that the app in IIS will read. It will read the debug folder of the project. On my previous employer what we do is to publish the file, and that be one to read, but on my current employer,they put the whole source code on the web server.
Is this okay? Or am I right it's a bad practice, well other frameworks put the whole file on the server, so it should be good? Is it?
Thanks and regards
As pointed out, this was a common set.
And after all, why bother to do some whole big publish when you JUST need to modify say a bit of markup in a web page.
So, for those who have the web server "on site", then often they would point VS to the site, and open it directly.
So, to manage/use/work with such a project?
You don't use from vs file->open project, but in fact use file->open web site. At this point, it is assumed you browse directly to the folder that holds the web site - often the live web site.
There are several significant issues to be aware of.
the app in IIS will read. It will read the debug folder of the project.
That is a not a correct assumption, or even correct view. There is no such thing as a "debug" folder. Then again, be it a console app, desktop, or whatever? Sure, when you COMPILE code, it goes to the bin/debug or bin/release folder.
But, you failing to grasp that by using the "web site" option, VS does NOT do the code compile!!! (IIS does!!!). While testing in vs, then vs will do the compile, but if you are modifying the web site directly, then all you have to do is open a web page, and when you hit ctrl-s, you are done - it is now live. And this ALSO applies to code behind.
So, you can open up say the code behind page. Modify one line of code and hit ctrl-s - you are done!!!
So, yes, as you note, a lot of web site(s) were managed this way.
So, the upside is no real deployment is required. And for a larger site, this actually can be a benefit.
However, the downsides are significant, and you VERY much need to be aware of these issues.
First up, careful if you adopt Rosyln extensions. That means your testing/debug/playing/developing code using and allowing VS to compile the code.
however, when you deploy (or edit "live"), then VS is NOT doing the code compile anymore. And this ALSO means then that the web site has both aspx pages, and ALSO the source code pages MUST ALSO exist!!! But often the web site and version of IIS will for example not know about Rosyln extensions etc., so you HAVE to be VERY careful, since it not VS that compiles the code, it is IIS that does this!!
In fact EVEN with a web site application, the "app_code" can and will be compiled by IIS. (I had simple code break when IIS re-compiles that code - it was not aware of say free form text strings that Rosylin allows). So, for a web site application, I actually create my own folder called MyCode and for each code module/class inside, then I right click and choose "compile" for the build options. That way IIS NEVER gets to compile my code!!!).
Now, of course the other option is what we call a "asp.net web application".
In that case, when you publish, then the code is compiled for you, the code behind pages is stripped out, and only the aspx pages remain (and are copied/deployed) to the web site. While this is more "pain" since even a tiny one-line change of code requires a WHOLE web site re-compile and re-deploy.
However, while there is this "increased" pain, there are also significant advantages.
You can have multiple projects in the one project.
you can add and reference other projects assemblies - not have to move/copy the assembles into the bin folder.
So, with better skills, then of course you often build code libraries and systems - systems that ALSO the web site requires. So, a asp.net "web site application" is a far better choice (compared to the "asp.net web site").
So, coming from a traditional software background, then hands down, I prefer the ability to have multiple projects in the one and same web project. And hands down I prefer the runtime compiling and management of external libraries of code and references being managed by the vs as opposed to "hoping" you setup and managed references correctly with a web site.
So, even those starting out say with PHP, or many other systems? Yes, they run a web server all the time, and then go edit the source files - and a simple "save" of the file you just edited means then a browser refresh, and you are done.
however, you lose a lot of control over referenced libraries, and KNOWING the build + compile is the same one you be running on the web site after a publish.
And note that a web site publish in effect will be just the SAME copy of the existing web site and files - there not really a "compile" process for publishing, and hence no "debug" folder really exists. It also means that each page launched on the site can out of the blue cause code to compile.
(Whereas with a asp.net web site application, there is a small startup delay the first time - probably due to JIT's running, but other than that, each additional pages and parts of the web site will not then have significant delays. With a web site re-publish, then huge delays can occur (but then again, often you never really have to re-publish do you - you are editing the live files!!). But, if you are working on a test copy, then yes, you are going to re-publish everything (actually copy the files - since nothing more is required). And as such then the web server really will be slow to start up, and slow to open pages that have not yet triggered compile of the code-behind pages (and you get a gazillion little .dll's as a result).
So, the only real issue here?
MAKE SURE you open the web site using file->open web site as opposed to file->open project. In theory and practice, such "web sites" thus don't have a .sln and project file. (it really is just a folder of files). As noted, many love this setup, especially for larger sites, since then little changes here and there are very easy. However, from an overall software management point of view, using git and source code, and things like writing unit test code, shared libraries, using multiple projects in one vs project file? You give up most of this with the web site option. So, yes, that setup is quick and dirty, but it not all that great if you more formalized in your software development approach.
I prefer strong references, and strong typing during the development process. I also prefer having VS manage my references. So, these abilities are worth more than a simple ctrl-s to update some code. However, if some bug crops up, while it can often be fixed by a simple edit of some code file and ctrl-s, and you are done? it will be harder to track down and find that bug in the first place!!!
To be fair, once a code project is created, then changes and fixes are often rather small - and this again actually favors that simple edit and ctrl-s deployment model.
it can often be painful to have to do a full re-publish of a whole big web application for JUST one little, tiny change of code, or even markup. And in most cases, when I deploy, I stop the web server services, publish, and then re-start the IIS web services.
So, it can "often" be hard to make a case that this deployment model (well, it doesn't really have a deployment model!!!) is bad, since it oh so easy to update bits and parts of an existing running site.
However, in the long run, I really can't endorse this way of development. I MUCH prefer using a web application. It is more git friendly, it allows things like testing code (unit testing), far better use of external class and library code, and you have a MUCH better control of compile and build of your code. Letting IIS compile the code base has increased risk, since you can't be sure during development that your final code and project will run the same when you deploy. (or least be far surer!).
It would be a history lesson.
More than two decades when Microsoft designed ASP.NET 1.0, the developers were using classic ASP which is simply Visual Basic code running on IIS. Thus, ASP.NET 1.0 has the mode of "ASP.NET Web Site" (used by your current employer) that you put source code on IIS and compile on the fly to mimic classic ASP.
It was after a few more years that Microsoft realized how bad that mode is, and introduced "ASP.NET Web Application" mode (used by your previous employer).
Microsoft has urged "ASP.NET Web Site" projects to be migrated to "ASP.NET Web Application" (or simply ASP.NET Core) for more than a decade, but unless IIS stops supporting those projects, many will not migrate at all.
"Is it okay" is impossible to be answered. Your current employer seems to enjoy that very well.
Reference
https://en.wikipedia.org/wiki/ASP.NET_Web_Forms
I have several projects in asp.net and in all of them I have the same problem. The first time I access an aspx page the load is very slow. Once I close the page and reopen it, the load is very fast. Why is the first load so slow? Can I change any settings in IIS?
Thanks
I have read a lot of documentation but I am not an expert in this and I have not gotten any progress.
By default, asp.net web pages and code files are compiled dynamically when users first request aspx page from a Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
More information about asp.net dynamic compilation:
Understanding ASP.NET Dynamic Compilation.
How to: Precompile ASP.NET Web Sites for Deployment.
Ok, so several issues here.
You don't mention if you are talking about your developer computer - say hitting f5 to run the site.
next up, are you deploying a asp.net web site, or a asp.net web site application?
With a application then the compile of the code and pages occurs on YOUR computer, and the .dll's are built by Visual studio (VS). So, at deploy time, then there is a first-time delay, but it not all that long - maybe 5 seconds, and that's as app pool etc. spools up.
However, if you deploy a asp.net web site? Then unlike an "application", the source code (vb, or c#) pages for code behind are included, and deployed to the web site. And this means that IIS does the compile of pages - and often on the fly. This deployment model is often preferred by many, since you can open even the live files on the server, edit one line of code behind, hit save. On next page use, it will re-compile.
If you use an application, then as noted, IIS does not do the code compile, and in fact not even the source code is deployed during a publish. Of course, while there are many benefits to an "application", the ONE big downside is of course that you require a full site re-publish EVEN if you change just one line of code behind.
So, while an application has "some" delay for the first site use, it tends to be considerably less of a delay compared to when using/deploying a web site. (Since then, IIS has to compile the code, and in fact has to compile each page used).
You don't mention/note which deploy model and approach you are using here.
As noted, while the web site option is certainly less efforts to make a change to one page or a bit of code, I still far prefer the "application" approach, since things like "referencing" additional class library and code, and even being able to say use the Rosyln compiler (which may well not be on the server and available to IIS). As a result, I prefer and use an "application" despite the extra efforts required come publish time, but the benefits at developer time far outweigh the downsides.
And of course, one benefit of the "application" approach, is you do as a general rule get far faster web start up times.
I always prefer using a ASP.NET Web Site over ASP.NET Web Application, as defined here: ASP.NET Web Site or ASP.NET Web Application?
It is suggested that only use 'ASP.NET Web Site' projects if you really need to (stackoverflow's tag says this); I would love to move away from this type of project, but the need to debug effectively and not waste time constantly recompiling projects for trivial changes makes me regret choosing the latter every time.
This is down to two key reasons.
Whenever you make a change to a back-end file or code-file, you are forced to rebuild the project before the change is available. With the 'ASP.NET Web Site', back-end files would be available immediately, and code-files within the 'App_Code' directory would trigger an automatic background rebuild enabling changes to be available within the next request with no developer input.
Because of this constant requirement to rebuild, you cannot make a change while debugging without stopping/starting the debugger (unless you perform an attach-to-process with a few tweaks). This is very frustrating, especially when the project gets to a certain size where the compile time makes this completely impractical. Not only that you lose all your debugging states, objects which were loaded in memory have been cleared, etc.
I'm pretty sure I am missing something, as if Web Applications are the preferred project type by the majority, how can this be with such limitations? Are there solutions for this or suggestions on how to perform a series of small changes while debugging without stopping the debugger then manually performing a rebuild each time? And is there a way to prevent back end files from needing a rebuild of the whole site? (I guess this is why 'ASP.NET Web Site' has a dll for every file or directory)
It is not a limitation, it's just how it works without the on-the-fly compilation of the WebSite template.
You can use the Edit and continue feature of Visual Studio, but not every type of change is supported.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
ASP.NET: Web Site or Web Application?
I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.
1) Why do we have these two different project types?
2) Which do you prefer?
3) Why would I choose one over the other?
4) What's the deal with the *.aspx.designer.cs files?
They have different purposes.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.
1) The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).
2) It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.
3) See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.
4) The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."
MSDN Article describing the differences
Similar stackoverflow question
I won't duplicate the definition of the 2, since that just got answered.
So why use one over the other?
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
Pros
You can make tweaks to the site right on the web server
Deploying is as simple as copying the folder
Cons
If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page
Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.
Pros
Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.
Because you compile it on your machine, everything gets syntax checked at that point*
Cons
Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*
*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.
The simple answers are as follows:
New Web Site - creates code behind pages that are compiled at the server when page is requested.
New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.
Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
For more information:
Introduction to Web Application Projects
3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.
THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.
You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.
Nich
Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.
Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.
The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.
You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.
At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.
I -- and my workplace -- prefer the Web site project
We like that the files of the website are the files in the file system (no need to add them manually)
No idea
Here's two articles I found about both:
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
Note: A lot of the issues with Web sites have been resolved with the Web deployment project
Update: Fixed the point 1, Web application was there first
If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.
There is very little difference, and I would highly recommend using the Web Site model.
The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.
If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx
I have been programming in php for a while, and recently I started a new job ago where I am now programming in c#/asp.net.
While asp has decent performance when deployed, there is one thing that has been bugging me for the past few months. After any code change it takes about 30 seconds for the page to reload for testing.
I guess it is doing the JIT compiling or something. But it can be REALLY frustrating, especially if I am concentrating, and want to test out several incremental changes as quickly as possible, only to have to stare at a blank page for 30 seconds.
Does anyone have any tips to speed this process up?
In Visual studio 2005 every reference you add adds a .refresh file that makes sure the reference did not change since last time and if so brings the new version - if your references stay the same, you can just remove it!
also see here for more tips for VS 2005
Two things I have found:
Try alternating between the "User Visual Studio Development Server" and "Local IIS Server" in your project properties / Web tab. Depending on your project, one may be faster to start and attach to than the other.
If you have projects in your solution, such as CLR-based SQL procedures, they take a few seconds to deploy to the SQL server. If you can afford to remember to turn them back on, or make a separate project config, disable them in the build so they do not get deployed every time you press F5.
Doing those cut my "F5 to live" time from about 20 seconds to 4.
I guess that can be frustrating coming from PHP.
Thirty seconds sounds far too long though. Ensure the basics like free ram etc..
A couple of tips.
1. You do not have to run the debugger in order to run the site. Once you have the site up with the built in VS web server or IIS, you can make your code changes, build and just refresh the page in your browser. No need to hit play and have VS start the whole debug process. If you actually want to debug though, you don't have a choice.
2. Changes to an aspx page do not require a rebuild. I make changes and simply refresh the page to see the result instantly.
Check out the web tab in the project settings to configure how you want VS to handle serving the site. There are some options in there to hopefully help you suite it to your style. ex. I don't let VS launch a browser for me whenever I want to debug. I set the option for it to just wait for a request. Then I can just use the browser of my choice to get started.
Good luck
I feel your pain.
Personnaly I like the ASP.NET website project better for speed of developing.
I don't know if you have that possibility though..
In visual studio do file->new website.
For this project type you don't need a rebuild all the time and you can just refresh a page in your browser when you have changed it. (no rebuild/debug necessary)
I've had similar experiences, it can be slow to recompile at times, but varies based on where and what code is being changed - ie if it is app_code or just page specific.
What sort of hardware are you running on? VS can be a memory hog, and anything less than 2GB seems to make it slow.
Our website has a very long load time due to actions which only occur during the Application Start phase (when the ASP worker process starts). In particular loading commonly used objects from a database into memory was causing a significant delay. We found that using compilation symbols to disable some features when debugging eg security and user roles, helped a lot.