While working on a quite big web application project, I decided that it could gain a little bit of fresh air by marking some of the pages and controls with the CompilationMode="Never" #Page attribute. So far so good, working as expected and then it happened. A corner case scenario that I am going to explain behaved unexpectedly to put it nicely. This scenario is nested master pages.
A quick teaser before continuing. How deep nesting do you think you could go if you mark the top master page as CompilationMode="Always", and all others beneath it with CompilationMode="Never"? No, its not infinite, or some internal number that ASP.NET has. Its 2. Why? - I have no idea, and I was hoping some of you smart guys could enlighten me?
I have attached a project with 5 nested master pages to demonstrate what I am talking about: Nested Master Pages Web Application Test Project.
Another corner case that is working unexpectedly as well - if you have 5 nested master pages, change the second to have CompilationMode="Always" and all others to have CompilationMode="Never". You will notice that the 3rd master pages is being applied twice!
Please help me understand if something I am doing is incorrect, or confirm the issue.
ASP.NET Runtime Version: 2.0, .NET: 3.5
EDIT:
The project attached has all master pages set to CompilationMode="Never". The ASPX page displays as desired. Change the first master (Site.master) to have CompilationMode="Always" to see what I am talking about.
UPDATE (1/21/2010): Good news: after more investigation, it turns out that this issue was fixed in VS2010. The fix was made post Beta 2, so it will be part of the next public build. I don't have an exact date, but it should not be too far out.
Yes, I seem to recall this coming up before, and indeed some scenarios involving nester master pages and CompilationMode="Never" are broken.
Looking at an old mail thread, I think it only happens for certain combinations. It looks like it’s broken for (where NoCompile means compilationMode=never):
NoCompile Page / Compile Master / NoCompile Master
NoCompile Page / NoCompile Master / Compiled Master
At the time, we did not fix this because the fix was non trivial and the scenario is not common.
Note that when it comes to NoCompile pages, most of the benefit is using it for end node aspx pages, and not master pages. Generally, NoCompile pages run a bit slower than compiled pages. Their benefit is that they don't have a first time compile hit, and they use less memory. Also, they can be fully unloaded under memory pressure. That's why they make good sense when you have a super large number of end point pages (Sharepoint uses them). But on master pages (where most apps only have a small number shared by many pages), that benefit would be minimal. And of course you can't have code in NoCompile pages, which is the main reason that few people use them.
So the quick summary is: you're right, it's a bug! :) And the recommended workaround is to avoid CompilationMode=never for master pages.
Related
We're building a Kentico 8.2 site using ASPX+portal model. Looking at the rendered HTML on my live site I can see a lot of unnecessary Javascript that Kentico has dumped into my page. What's more this is occurring at the top of my page at the top of the form element.
For example, it's rendering the ASP.NET __doPostBack JS function even though I'm not using any controls that require it. Other scripts are being added as WebResource.axd and ScriptResource.axd includes.
At a glance it would seem these scripts constitute the Microsoft AJAX framework used with UpdatePanel etc. My assumption is that they are there to add portal manager functionality when using the page in the Kentico UI. Presumably they are also used with certain built-in web parts.
However, I am only using custom web parts on my live site so all these scripts are doing nothing and are just slowing down my page and causing poor performance testing results.
I've tried hiding the <ajaxToolkit:ToolkitScriptManager /> and <cms:CMSPortalManager /> controls on my master page when rendering the live site, but this causes templates that have a <cms:CMSWebPartZone /> to break.
Does anyone know how to ensure this bloat is removed when not required? Or at the very least cause these scripts to be rendered at the end of the page so they don't interfere with performance too much?
Unfortunately, building sites within Kentico using ASPX and ASPX+Portal Pages will automatically generate additional markup such as __doPostBack, WebResource.axd and ScriptResource.axd.
I wouldn't recommend removing any of the default code in your Masterpage. This will cause things to break (as you've experienced).
However, having this markup in place shouldn't cause a massive issue in page performance. Understandably, this isn't ideal.
What I do to lessen the hit is the following:
Disable the ViewState wherever possible. For example, either at Page Template or Webpart/User control level.
Move the ViewState to the bottom of the page (in Kentico Settings), so the page is less "top heavy".
Ensure you are caching everything you can. For example, site furniture used by your webparts and templates (images/js etc) at IIS level and at Kentico level using their API.
Reading this article from the Kentico documentation provides some more information in greater depth: Optimizing website performance
If you really want "full control" over the HTML rendered, Kentico does allow you to create templates using MVC. But this won't give you the flexibility to modify Page Templates by moving around web parts within the CMS Administration. I presume you have chosen the Portal Page approach for this very reason.
I hope this helps.
In addition to #sbhomra's great answer I have a few questions, suggestions and comments.
How many seconds or milliseconds are you talking about with performance? If you think you'll gain a few milliseconds back, it's not worth your effort to try to rebuild all the functionality. If you're talking a second or two, there about 15 different things you can change within settings and your code to gain it all back. Think about how much code you're going to write, maintain and upgrade just to gain a second or less back?
The WebResource and SciptResource load resources that are compiled into libraries within the website. So if someone created an external library and that library was loading an image that was compiled into it, you'd get that WebResource.axd reference on your site. You'd have to physically remove those libraries from the Kentico instance.
Although I don't recommend it strictly because you lose so much functionality and have so much extra unnecessary code, MVC will give you the control you're looking for.
Can someone please let me know the pros and cons of registering user controls in web.config vs. on top of asp pages?
I am looking for performance issues in particular. Does having all the controls registered in web.config make the pages slower to load (even the pages that do not use these controls)?
Web.config Pros
Only 1 place to add extra bit of code
Web.config Cons
Sometimes, I forget to update web.config on production environment since I never copy the web.config from staging area to live site.
On every page pros
When you deploy/publish pages and/or copy pages from dev/test/staging to live server, you don't need to worry about updating web.config
One very page cons
Its on every page, so if something changes, it's a pain to go through every page and fix it
You have to add it manually to each page
I'd recommend doing it in the web.config. It's less work for you since you don't need to remember to add it to every page. Although, if you have a ton and lots are only used on a single page, then you could do a bit of both to keep your web.config a bit less cluttered. I usually put my controls in web.config, if I use them in more than one page. If it's just used on a single page, then I usually just declare it in my asp.net page.
Old question, but finally an answer on performance! There is no difference:
http://weblogs.asp.net/scottgu/archive/2006/11/26/tip-trick-how-to-register-user-controls-and-custom-controls-in-web-config.aspx#1056687
The good news is that there isn't any performance difference between
registering them in a web.config file vs. at the top of a page.
The runtime performance is exactly the same (they get compiled down to
the same instructions in both scenarios).
Compilation should also compile at the same performance.
Not a heck of a lot cons to putting it into the web.config. It just can't be done with a drag and drop, so many just don't do it. Keeps the page less cluttered and makes change easier in the long term.
The problem I'm having with writing a web application architecture is that I want separate components that work together. By this I simply mean, for example, a navigation bar and the actual page content (as well as a header, which is static) in ASP.NET.
Now, here's where it gets interesting:
There are no two pages the same
The navigation pages on every page have security on them on a user-by-user basis
The navigation has links to other locations
The problem I'm mainly having is that you've usually got to have a full web page in Visual Studio, and if you have portions i.e. excluding your <html> tags then Visual Studio will end up underlining everything as incorrect.
The way is this application is currently being dealt with is using frames (yes, frames) to keep everything separate, but working together. I want to move away from this, although the web system is very large, and very important in that it must be available 24/7.
Any ideas?
Have you looked at Master Pages in ASP.NET 2.0? These can be used in conjunction with User Controls, and the Site Map Navigation.
Master Pages Quickstart Tutorial
MSDN Overview
Master Pages: Tips, Tricks, and Traps
Example Template Set
There's a really good book you should check out that might shed some light on your problem. It's "ASP.NET 2.0 Website Programming: Problem - Design - Solution", part of the Wrox series.
Is it not possible to implement UserControls for this? for example a navigation user control that can handle the security for itself etc etc.
Hope this helps a little.
I'm looking for some help on my discussion. We're discussing two solutions to a customization problem. One uses (nested) master-pages. One master page per customized page. Plus there is a standard master page for all pages. The second uses a standard page, which redirects to the custom page if it exists.
My question is, which is more desirable? Having to Load 2 master pages every time OR only having to load 1 master page and sometimes redirecting (Response.Redirect or Server.Transfer) to the customized page.
I can't really find any information on master page performance. Should I just think of them as another (somewhat inverted) user-control or should they be used lightly?
Edit:
You can assume Response.Redirect for the transfer.
You can assume the Redirect occurs in the PreInit stage of the lifecycle.
Master pages are in a sense inverted user controls (they "surround" content as opposed to user control content that is pushed into the page). There isn't a rule of thumb that says use master pages lightly--a master page's performance cost is directly proportionate to how much code (HTML and otherwise) it causes to be pushed into the HTTP data stream.
For my money, I'd land on the side what makes for the most readable and maintainable code.
so, it's a webform application no matter what, right? Did you ponder Model View Controller perspective?
Regarding the nasted MasterPages, I did that on a client CRM application and I can assure you, you do not fell any problems loading unless the usual ones about the internet and server speed, for that, and if you think it's the best way to accomplish or objectives, go for it.
Each Master Page will fire their events and normally we think about ohh well, 2 master pages plus a content or several content pages could be a problem pointing the loading time, but this takes miliseconds performing all this, so... be safe.
the only thing that you need to take care is, don't fell up with all the javascript addons that you can find, choose a nice library and use only that, JQuery (now on version 1.3.0 would be the best choice).
at least that is my opinion :)
Although ASP.NET MVC seems to have all the hype these days, WebForms are still quite pervasive. How do you keep your project sane? Let's collect some tips here.
I generally try to stay clear of it... but when i do use WebForms, i follow these precepts:
Keep the resulting HTML clean: Just because you're not hand-coding every <div> doesn't mean the generated code has to become an unreadable nightmare. Avoiding controls that produce ugly code can pay off in reduced debugging time later on, by making problems easier to see.
Minimize external dependencies: You're not being paid to debug other people's code. If you do choose to rely on 3rd-party components then get the source so you don't have to waste unusually large amounts of time fixing their bugs.
Avoid doing too much on one page: If you find yourself implementing complex "modes" for a given page, consider breaking it into multiple, single-mode pages, perhaps using master pages to factor out common aspects.
Avoid postback: This was always a terrible idea, and hasn't gotten any less terrible. The headaches you'll save by not using controls that depend on postback are a nice bonus.
Avoid VIEWSTATE: See comments for #4.
With large projects the best suggestion that I can give you is to follow a common design pattern that all your developers are well trained in and well aware of. If you're dealing with ASP.NET then the best two options for me are:
o Model View Presenter (though this is now Supervisor Controller and Passive View).
This is a solid model pushing seperation between your user interface and business model that all of your developers can follow without too much trouble. The resulting code is far more testable and maintainable. The problem is that it isn't enforced and you are required to write lots of supporting code to implement the model.
o ASP.NET MVC
The problem with this one is that it's in preview. I spoke with Tatham Oddie and be mentioned that it is very stable and usable. I like it, it enforces the seperation of concerns and does so with minimal extra code for the developer.
I think that whatever model you choose, the most important thing is to have a model and to ensure that all of your developers are able to stick to that model.
Create web user controls for anything that will be shown on more than one page that isn't a part of masterpage type content. Example: If your application displays product information on 10 pages, it's best to have a user control that is used on 10 pages rather than cut'n'pasting the display code 10 times.
Put as little business logic in the code behind as possible. The code behind should defer to your business layer to perform the work that isn't directly related to putting things on the page and sending data back and forth from the business layer.
Do not reinvent the wheel. A lot of sloppy codebehinds that I've seen are made up of code that is doing things that the framework already provides.
In general, avoid script blocks in the html.
Do not have one page do too many things. Something I have seen time and time again is a page that say has add and edit modes. That's fine. However if you have many sub modes to add and edit, you are better off having multiple pages for each sub mode with reuse through user controls. You really need to avoid going a bunch of nested IFs to determine what your user is trying to do and then showing the correct things depending on that. Things get out of control quickly if your page has many possible states.
Learn/Grok the page lifecycle and use it to your advantage. Many ugly codebehind pages that I've seen could be cleaner if the coder understood the page lifecycle better.
Start with Master Pages on day #1 - its a pain coming back to retrofit.
Following what Odd said, I am trying out a version of the MVP called Model Presentation which is working well for me so far. I am still getting an understanding of it and adapting it to my own use but it is refreshing from the code I used to write.
Check it out here: Presentation Model
Use version control and a folder structure to prevent too many files from all being in the same folder. There is nothing more painful than waiting for Windows Explorer to load something because there are 1,000+ files in a folder and it has to load all of them when the folder is opened. A convention on naming variables and methods is also good to have upfront if possible so that there isn't this mish-mash of code where different developers all put their unique touches and it painfully shows.
Using design patterns can be helpful in organizing code and having it scale nicely, e.g. a strategy pattern can lead to an easier time when one has to add a new type of product or device that has to be supported. Similar for using some adapter or facade patterns.
Lastly, know what standards your forms are going to uphold: Is it just for IE users or should any of IE, Firefox, or Safari easily load the form and look good?