|This is the talk page for discussing improvements to the ASP.NET article.|
|This article is of interest to the following WikiProjects:|
|The content of ASPX was merged into ASP.NET. That page now redirects here. For the contribution history and old versions of the redirected page, please see ; for the discussion at that location, see its talk page.|
Session State sharing nowhere to be found
This part seems incorrect:
On IIS 6.0 and lower, pages written using different versions of the ASP framework cannot share Session State without the use of third-party libraries. This criticism does not apply to ASP.NET and ASP applications running side by side on IIS 7. With IIS 7, modules may be run in an integrated pipeline that allows modules written in any language to be executed for any request.
It seems there is no (easy) way to share session state between ASP.NET and legacy (or classic) ASP pages both placed in the same directory (hence in a same web application). There a lot of solutions involving databases and a lot of changes on both places (ASP.NET and ASP), but nothing working out-of-the-box. Is it possible this statement to be valid only for ASP.NET applications, say one that is 1.1 and another that is 2.0? --126.96.36.199 (talk) 11:23, 23 March 2009 (UTC)
The article refers to "clean code" without a link. Quotation marks are around "clean", but not "code". If this is a reference to Robert C Martin's concept of clean code, I recommend extending the quotation marks to surround both words, and making that a link, either to an article on clean code, or at least to the one on Martin. Unfree (talk) 16:01, 4 November 2009 (UTC)
Information about ViewState incorrect
The viewstate does not track form values, it's a source of confusion amongs a lot of ASP.NET programmers.
Form values are already sent with the postback data, so these don't have to be in the viewstate. See:
Viewstate only has to contain the state which changed from the defaults set in the ASCX files and OnInit() method. That includes:
- modifications by a event handler (e.g. showing an panel after a OnClick event -> the Visibility has to be tracked and restored)
- modifications by the `Page_Load()` event.
Programmers who fill the default Page_Load() method, end up with a huge ViewState. This state is transmitted back and forth with every page request, causing performance issues.
I believe the criticism section parts regarding session/state management was written by someone who did not fully understand the technology. What is being refered to here are inprocess sessions, one of the many ways ASP.NET/IIS can handle session data, and only a valid solution for the smallest of deployments. Session data storage is typically handled outside of the webserver that way a single site can be serviced by many web servers and gracefully handle server failures.
ASP.NET handles using sql as a session store, and comes with scripts to build these databases (except .net 1.0 which is located here. http://support.microsoft.com/kb/311209 )
There are plenty of valid criticisms to make about ASP.NET (Memory use, first hit compiling delay, inability to really just use the pieces you want, not embracing friendly/suffixless urls, etc) without traveling down such subjective criticisms —Preceding unsigned comment added by 188.8.131.52 (talk) 06:29, 25 February 2010 (UTC)
- Just come across this page and the criticism is mostly unsourced. I'm going to remove the unsourced material as original conclusions which don't appear to be coming from a third party source. Like you say, there is criticism out there which is citable, however the current criticism does not seem appropriate without sources. --Bill (talk|contribs) 10:31, 16 May 2010 (UTC)
"At the server side, the application may change the viewstate, if the processing requires a change of state of any control." Huh? This isn't a well formed sentence... —Preceding unsigned comment added by 184.108.40.206 (talk) 17:29, 10 July 2010 (UTC)
"Rendering Technique" section is terrible.
I defy anybody to tell me what this means:
"ASP.NET uses a visited composites rendering technique. During compilation, the template (.aspx) file is compiled into initialization code which builds a control tree (the composite) representing the original template. Literal text goes into instances of the Literal control class, and server controls are represented by instances of a specific control class. The initialization code is combined with user-written code (usually by the assembly of multiple partial classes) and results in a class specific for the page. The page doubles as the root of the control tree." —Preceding unsigned comment added by 220.127.116.11 (talk) 03:28, 16 May 2011 (UTC)
"Examples Inline Code" Vandalism
Someone with the IP address 18.104.22.168 of the example code on the page. I would revert this change but I'm not sure how to do it without affecting any other edits made to the article after that edit. aidilfbk (talk) 13:40, 5 December 2011 (UTC)