Talk:ASP.NET

comment

~~Someone has vandalized this page. I tried to revert it back to an earlier version, but unfortunately I don't know how. Can someone please revert it? I came here to learn more about ASP.net and found that someone has inserted his name all throughout the article. —Preceding unsigned comment added by 24.3.221.226 (talk) 05:44, 18 September 2008 (UTC)

asp.net

is ASP.net a compiled language?

Yes --WayneMokane 07:47, 19 Dec 2004 (UTC)

Yes and No. ASP.NET must be compiled by the server (aka IIS) to a .NET common language runtime, from which it will be interpreted by the server machine. But you don´t need to compile an ASP.NET file to run it on the server, the server does it for you. In this case, the answer is No. --Cedric.graebin 23:42, 12 July 2005 (UTC)

To expand on that, the assembly that is created from your pages is indeed compiled to MSIL, however, the JIT then kicks in during runtime and the corresponding machine code is cached and used on the next invocation.

NO -- The ASP.NET Portion is not compiled, but interpreted by the IIS web server. The parts that are compiled are written in a compilable language such as C# or VB.NET. These parts of the application are compiled on the server.

I beg to differ. Check your %WINDIR%\Microsoft.NET\Framework\%DOT_NET_VERSION%\Temporary ASP.NET Files folder. You'll see the end-result of the "ASP.NET Portion" translated to code (C# in may case) as well as the DLL that was generated. The end result is a compiled page, even if you don't do code-behind. - Chris 00:00, 16 March 2006 (UTC)

First, ASP.NET is not a language. Second, YES, all parts that made up an ASP.NET application are compiled, including plain-text .aspx files (they are compiled as the first request come into a .NET assembly ("dll") which is stored somewhere in a temporary folder). —The preceding unsigned comment was added by 62.168.95.194 (talk • contribs) .

This "article" is absolutely pure Microsoft marketing hype. Where is the balance that an encyclopedia is supposed to bring to a subject? I suspect the person who wrote it makes their living promoting Microsoft products. Microsoft is well know for “planting” people and marketing articles like this on the web.

I completely agree. I just entered the discussion page to see if im the only one feeling "uncomfortable" with this article- esp. the "common misconceptions" section... unfortunately i dont know the subject material enough to validate. plz if someone feels the same, maybe a neutrality warning is in place here... —Preceding unsigned comment added by 88.152.170.12 (talk) 21:19, August 26, 2007 (UTC)

Would asking for full disclosure about the author be asking too much? 70.162.248.198 02:40, 8 December 2006 (UTC) JustBoo

Minimo?

Just a hunch, but could "Minimo" be a Microsoft trademark for servers it sells, and the statement intended to say "alternatives to Minimo"? Unfree (talk) 16:05, 4 November 2009 (UTC)

"Valid" XHTML?

Are you kidding? If it sends standard XHTML per default, MSIE support is broken -- MSIE 6.0 and earlier don't support XHTML 1.0 because they don't understand the MIME type and parse it as XML/HTML tagsoup. I don't think Microsoft would be that stupid.

If they send "valid" XHTML 1.0 (as in "source code validates", not as in "standards compliant") with a HTML MIME type, they are effectively violating the standard no less than if they continued to send proprietary HTML instead. -- 134.95.141.104 11:37, 19 January 2006 (UTC) (Ashmodai)

Please, tell me exactly WHERE in the XHTML standard is written down which MIME to use? —The preceding unsigned comment was added by 62.168.95.194 (talk • contribs) .

Look in the abstract section of http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/. However, that says that it SHOULD use application/xhtml+xml not MUST. A more definite violation is that all JavaScript blocks that ASP.NET internally generates are improperly escaped and won't work under true XHTML clients. Developer38 22:34, 11 May 2006 (UTC)

ASP.NET does NOT serve XHTML properly, the javascript blocks are commented, if served properly these will be commented out (because it's xml) and no javascript can be used. Please note that if marked as cdata this blocks work just fine. It's thesame for the inline css blocks. You can test if your browser is using xhtml properly by not closing a tag for example. If you are serving xhtml properly the browser will give an error, if served incorrectly it will display the page. See http://www.liquid-internet.co.uk/content/dynamic/pages/series1article1.aspx for some more info. After a lot of work i was able to get ASP.NET pages served as 100% correct xhtml, but it wasn't easy. IE not supporting xhtml by mimetype made it a lot more work. i think the ASP.NET team did not serve proper xhtml because IE7 does not support it out of the box (it does have a full blown working xhtml renderer, which does even support mathml). Why IE7 does not support xhtml as it should is totally unclear to me, it is fully implemented but IE does not listen to the mimetype. Should something about this not be added to the critisism section?

Problems in the produced HTML code should not be attributed to ASP.NET as a whole, but to the current (pre 4.0) ASP.NET Web Forms implementation, and especially to certain controls in it. The new ASP.NET MVC is an officially supported alternative way for generating HTML views using ASP.NET 3.51 SP1+. In MVC, there are no control declarations. Pluggable MVC views are directly responsible for generating output. The MVC Framework borrows the .aspx file form only as a text templating language. In ASP.NET MVC, it is 100 % up to the developer if the markup is valid or not - the library does not generate any extra HTML tags, viewstate codes etc. ASP.NET MVC is going to be packaged into the next ASP.NET 4.0 version as a standard feature - at least this is the current plan. It will not replace Web Forms, however. This article needs a major refresh by the time ASP.NET 4.0 is released, if not sooner! Harri J. Talvitie (talk) 07:20, 6 June 2009 (UTC)

"comprised" and "composed"

Warrens, you're correct in your definitions of comprise and compose and I'm not arguing using "comprise". However, the original text ("composed of") was correct. "comprised of" *is* incorrect. If you insist on using "comprise" (when the original is fine), use "comprises", not "comprised of". - Chris 20:32, 16 March 2006 (UTC)

Correct, but the language is changing. So many people say "comprised of" that it's becoming acceptable. Personally I find it grates, but that's a sign one is growing old! ;-)

84.9.71.116 07:49, 30 April 2006 (UTC)

Microsoft promotion?

"The numerous .NET controls, classes and tools can cut down on development time by providing a rich set of features for common programming tasks" -- sounds straight out of some Microsoft marketing blurb. A bit more neutrality please and more mentions of competing technologies. Not all readers are fans of the wondrous M$.

84.9.71.116 07:49, 30 April 2006 (UTC)

The Wikipedia article on ASP.NET is not an appropriate place for a discussion about competing technologies, any more than the article on PHP or Ruby on Rails are. Warrens 08:13, 30 April 2006 (UTC)

What? The Wikipedia article on ASP.NET is probably the single most appropriate place to discuss competing technologes, just as it is for PHP or Ruby on Rails. It's supposed to be a fair balanced review of ASP.NET, which must include how it compares to other alternatives. You wouldn't know it from this article, but it's not an advertising platform. This can be seen in the Criticism section - is anyone here really trying to say the only criticism of ASP.NET is that prior to .NET 2.0, the controls didn't generate perfect markup? —Preceding unsigned comment added by 94.5.13.206 (talk) 12:11, 22 November 2010 (UTC)

I agree. It's not just that it's highly pro-MSFT, with all of the benefits listed ( and no context about how important they might be ) - it's also tiresome to read. I'm doing my part to improve the article, as a person who programs against ASP.NET every day. My goal is to bring a more neutral point of view, but also to make the content in this article more useful. As such, I'll be adding an article called Criticisms or Gotchas or something to that effect, of common mistakes or problems and how to deal with them. This could be seen as anti-MSFT ( which I'm not, since I choose to work with their technology ) but I'm doing it to make the page useful to ASP.NET users, not marketing people. DigitalEnthusiast 20:34, 14 December 2006 (UTC)

Could you folk be overreacting to the word "rich"? Simply deleting "a rich set of" would remove the appearance of "marketing" rhetoric, wouldn't it? Unfree (talk) 16:14, 4 November 2009 (UTC)

ASP.NET 2.0 does not generate valid XHTML

This article is inaccurate in saying that "in version 2.0, all controls generate valid HTML 4.0, XHTML 1.0 (the default), or XHTML 1.1 output". The XHTML generated is not valid even in version 2.0. For example, all generated JavaScript is wrapped in HTML/XML comments (<!-- -->) rather than XHTML CDATA blocks. This will pass the W3C validation tools, but the JavaScript code just won't work.Developer38 22:39, 11 May 2006 (UTC)

If that's the case, there should be a good, citable source that supports that claim. Citing such sources helps prevent reversions of such claims. The Rod (☎ Smith) 00:16, 4 May 2006 (UTC)

You can test this out for yourself. Create a simple ASP.NET page with one button and look at the generated source. You will see this error which Wikipedia lists as a common error on the XHTML page. I've seen other blogs point this out and I can prove it with the software. What exactly constitutes a valid citable source?

Developer38 18:54, 10 May 2006 (UTC)

This guy says what I said. Is this a citable source? http://lachy.id.au/log/2005/05/script-comments

Developer38 19:12, 10 May 2006 (UTC)

Wikipedia requires reliable, published sources to back up what's written in the articles. That you or I can fire up Visual Studio and recreate this situation (or are even so much as expected to in order to confirm anything written in an article) isn't good enough. This is a core tenet of Wikipedia:Verifiability. Warrens 02:06, 12 May 2006 (UTC)

Even if blogs were valid sources, the one cited above does not say that the output is invalid XHTML. It merely discusses how the style of the XHTML causes problems in the way various UA's treat scripts or expect scripts to be treated. Neither does the "XHTML" article here say that the output of my ASP.NET page is not well-formed. The Rod (☎ Smith) 06:07, 12 May 2006 (UTC)

I'd assume that output from a ASP.net page built using MS delivered components with a DOCTYPE specifying XHTML that *fails* the W3C validation processors would count as a verifiable source. So, if anyone can produce such a page... AnimalFriend 20:23, 7 September 2006 (UTC)

andyf says: It is wrong to speak in terms of ASP.NET producing or not producing valid XHTML. It's a design framework and developers can use it to write compliant XHTML, as they can write garbage and stick an XHTML DOCTYPE on the top. In the latter case the framework cannot magically render it as valid XHTML and it is not logical to extrapolate that situation to a general claim of non-compliance. Writing valid XHTML is a skill of the developer, not a shortcoming of the framework —Preceding unsigned comment added by 217.37.94.241 (talk) 15:01, 18 April 2008 (UTC)

Comparison to other platforms

The comparisons section is either misnamed, or has wrong content in it. These are criticisms of asp.net, no other platforms are mentioned. Further, these are criticisms of some of the asp.net controls, not the asp.net platform itself. Gaijin42 01:24, 10 August 2006 (UTC)

How about we rename the section to "Criticism of stock control rendering"? Is there a better phrasing? Rod (A. Smith) 20:58, 10 August 2006 (UTC)

Gaijin42 is right, the section should be merged with the preceeding "Advantages over ASP", since it only discusses how ASP.NET varies from ASP.old. AnimalFriend 10:45, 2 September 2006 (UTC)

Wikipedia Defines What Microsoft Won't

Once again I am astounded that I can find definitions and relationships of and between Microsoft technologies that are absent (or present who knows where mixed in with who knows what) from Microsoft's own downscale, deprecated, paper and ink documentation. Yay, Wikipedia.

Wikipedia is open to everybody to contribute. Please feel free to do so. -- Szvest 18:46, 21 August 2006 (UTC) User:FayssalF/Sign

merge ASP master pages into this article

ASP master pages should be merged into this article -- timdew (^Talk) 13:54, 9 December 2006 (UTC)

Strong Disagree Are you crazy? Master pages are a part of ASP.NET, but hardly the same thing. In fact, many, probably most, ASP.NET developers never use master pages. ( That seems enough of a reason to keep the articles sperated! ) This suggestion is a lot like the idea of merging the articles on USA and Wyoming - B is a part of A, but A is not B. —The preceding unsigned comment was added by DigitalEnthusiast (talk • contribs) 18:37, 14 December 2006 (UTC).

you made my point and never realised, that "... many, probably most, ASP.NET developers never use ASP master pages" and therefore ASP master pages doesn't warrant a page of it's own. please try not to be rude in your reply, i'm not crazy. -- timdew (^Talk) 19:11, 14 December 2006 (UTC)

Sorry if that sounded rude - wasn't my intent. I just don't think "strongly disagree" conveyed my feelings strongly enough. While I see your point that master pages could be notable enough to mention but not for their own article, there are any number of developers who do use them ( myself included ). To many it's as if "master pages" didn't exist, even aren't a part of ASP.NET, however, they are a subset, and only of version 2.0, so I really think it makes sense to keep the two articles seperate. Also, I'm rewriting much of the ASP.NET page, and while I'm removing some content ( that's either confusing, or simply untrue ) it will be longer when I'm finished. If necessary, I'll do the same for the Master Pages article, and point out a lot of the specific issues their use brings up. ( PS - Obviously you're not crazy if you can understand this highly technical stuff. ) DigitalEnthusiast 20:25, 14 December 2006 (UTC)

I also disagree with the merge suggestion ASP master pages are a large enough part of ASP.NET that it does indeed warrant a separate article. That said, the current article needs to be significantly expanded. I will try to work on it, but no guarantees! (P.S. - Thank you, DigitalEnthusiast, for your contributions; I am new to Wikipedia and appreciate your corrections to my recent updates) --Jimmytharpe 17:04, 19 January 2007 (UTC)

Strong Disagree. Master pages are a very important part of ASP.NET, there's a whole lot to be said about them (as you can see in this page), and they're a recent development, as opposed to a feature that always has been native to ASP.NET. Thomasmallen 15:08, 31 January 2007 (UTC)

red riya

Disagree I agree that master pages are a part of ASP.NET, but they existed through 2 releases (1.0 and 1.1) without being implemented. Master pages are an important concept in and of themselves. The concept of template-based web-programming was changed from a simple server-side include model to an object oriented approach. //BankingBum 06:24, 24 February 2007 (UTC) ^$$

Disagree For reasons cited above, and because they're only part of ASP.NET 2.0, not all versions. —The preceding unsigned comment was added by 68.144.124.143 (talk) 16:34, 16 March 2007 (UTC).

"Unhandled exceptions force the ASP.NET worker processes to shut down"

Maybe I'm missing something here, but I don't understand the relevance of this statement, or at least how it can be used as a criticism of ASP.NET. Say have this code in my Page_Load, which will cause a runtime division by zero exception:

int a = 0; int b = 1/a;

If I don't catch this exception myself then the ASP.NET runtime will catch it and show an error page. The application will not be restarted and sessions will not be lost. All exceptions are eventually caught by the runtime, meaning that there is really no such thing as an "uncaught exception" in ASP.NET (at least in theory).

If somehow an exception was thrown that was not caught by the ASP.NET runtime, then by definition the process must be terminated, as there is no way to continue after this point. This is the same with any application on any platform, so I don't see how this can be a criticism of ASP.NET. If we assume that there could be an exception that isn't caught by the ASP.NET runtime, then surely the criticism should be "ASP.NET contains a bug that prevents it from catching all exceptions".

Googling for information on this yields nothing. I'm sure my understanding of the way these things work is lacking, however, so maybe someone can enlighten me. Straussian 00:19, 6 February 2007 (UTC)

You are correct - that sentence is wrong. However, are you sure about session states? I haven't tested it, but I thought that session states get lost when unhandled exception occurs. DLX 13:44, 7 February 2007 (UTC)

DLX asks a good question. This really depends on the severity of the error and the configuration of the session state. If the ASP.NET application uses an out of processes session option (such as the ASP.NET session server or SQL Server session), it doesn't matter what the severity of the error is. The session state will stay alive. In the case of an in-proc session option (the current default in ASP.NET), a severe error will kill the worker process and therefor, the session state. Going to the root of the statement, most unhandled exceptions do NOT crash the worker process and are caught by the default ASP.NET generic exception handler (which produces the "yellow screen of death"). All of this said, its hardly a practical criticism to say that "Unhandled exceptions force the ASP.NET worker processes to shut down" since any application that doesn't handle exceptions cause a process exit. //BankingBum 06:32, 24 February 2007 (UTC) ^$$

(updated) I've modified the criticisms section and added a bit of accuracy and grammatical changes. The criticism was written a little more like a rant than an encyclopedic criticism. //BankingBum 06:55, 24 February 2007 (UTC) ^$$

No, uncaught exceptions does not cause the ASP.NET worker process to shut down. Every single exception is caught by ASP.NET which will then display the error page. Hence, no exception can cause the session state to be lost, even if that session state is kept in-proc. It is true that some conditions will cause IIS to recycle the worker process and hence throw away in-proc session state. E.g. if a worker process consumes an abundant amount of memory (60% of available) it will be recycled to proactively prevent a memory leaking site from disrupting services for other sites.

Actually, the current ASP.Net (2.0) catches and handles all exceptions in the Page Requests process via HTTPException processing and prevent the app pool from recycling. Background threads, however, are not handled by the primary HTTPException process. Examples of background threads include call-backs by AJAX requests. With more and more asynchronous calls being implemented, you will see more of this type of recycle. See this KB for details: [1] Christopher G Lewis (talk) 18:12, 30 January 2008 (UTC)

I have deleted that "criticism" as it was fraught with errors as discussed above. What was left was hardly a criticism. If anyone would like to reintroduce this criticism, please quote sources. —Preceding unsigned comment added by 212.242.89.162 (talk) 04:23, 18 February 2008 (UTC)

Code Behind and/or Code Beside

I was thinking shouldn't it be mentioned somewhere that ASP.NET 2.0 now uses Code Beside instead of Code Behind files. While not a huge significantly life altering thing it does change things a bit. I would add this but Don't know where would be appropriate.percent20 11:55, 16 May 2007 (UTC)

When an exceptions occurs in the main thread (example page_load event), the exception is thrown up and can be handled in the global.asax event for example. However, even if not handled, the application does not shut down. However, if a separate background thread throws an unhandled exception the application will shut down in asp.net 2.0 (not in earlier versions). This should normally be prevented by the programmer (prevent unhandled exceptions in background worker thread, or catch add an implementation IHttpModule and catch such exceptions in a special event) —Preceding unsigned comment added by 84.73.50.235 (talk) 21:14, 26 September 2007 (UTC)

Pro-MSFT

Pro-MSFT, article is not neutral discussion based on programmer experience

This article definitely seems to have been written by the vendor (MSFT) in a biased manner. Even the criticisms section does not really contain criticisms. If you scan the blogs of real programmers out there, you'll find that the majority of them are having major issues with the ASP.Net technology. As these are the realities facing most people trying to actually use the technology, they definitely belong in this article. Some of these issues include:

1. Poorly written auto-generated HTML coming from the Microsoft drag and drop web server controls.

2. Non-workability of the "web page as a windows app" paradigm that the development environment (VS) forces on the developer. Only a very small minority of web sites (1%?) actually behave similar to a traditional windows app. For these, the .Net model of Postback and the entire "web forms" idea may work. However, most web pages are interactive hyper text mark-up. Most user skip from one page to another all the time, and do not expect every page to behave as an "application".

Comment- ASP.NET 2 no longer pushes you down the "windows app" route (sometimes loosely referred to as the Single Document Model). The whole point of Master Pages is to allow multi-page apps more akin to trad. ASP3, but with the benefits of a sophisticated template to encourage consistancy of look/function. Similarly the ability to post to different pages supports this. You can have SDM for intranet apps, multi page for web sites. You can do whichever you like...

3. Many top programmers are writing on their blogs how to work around or "exorcize" the code-generation tools in VS that try to "help" us. Also, many developers have criticized ASP.Net for decreasing productivitiy as it is aimed at a certain class of web sites that represent a minority of actual projects going on. Thus, for the average web site it is considered by many to be an overkill technology that takes more time to develop in to get the same result as compared to classic ASP.

You can of course, with usually very little modification, run ASP3 pages under the .NET framework. There are significant advantages in doing so, so if you reckon you can write ASP3 faster than ASP.NET then there is still a case for running it under the .NET framework. There is no real downside to doing this.

4. Classic ASP already offered object oriented technology through the 3 tier model: front-end scripting, middle-tier compiled components and data-tier data storage. ASP.Net attempts to bring OO to a front-end hyper-text textual formatting language. This presents numerous challenges as presentation and reading a textual document in general is very subject to subtle needs of designers and developers, and is nearly impossible to encapsulate in an OO environment without constraining developers to a rigid agenda in terms of what the final presentation layer will look like. Many developers are compaining aboutt he straight jacket ASP.Net puts them in when it comes to delivering customer satisfaction and trying to tweak the presentation layer to eactly where their customer and users want it.

ASP3 was not OO by any measure imaginable. A 3 tier model does not make it OO. It fails on Polymorphism Inheritance and Encapsulation, the three tennants of an OO language.

A fair article should discuss these challenges currently faced by thousands of ASP.Net developers, work-arounds, and any efforts by MS to fix these issues.—Preceding unsigned comment added by 24.16.65.75 (talk • contribs)

Care to give reliable sources about the criticism? Note that blogs are not that. -- Sander Säde 17:16, 29 September 2007 (UTC)

The "Drag and Drop" functionality to which you are referring is actually not a part of ASP.NET at all. It is a part of Visual Studio and should be added to the criticisms section of that article. -- Benrick 18:04, 26 October 2007 (UTC)

I don't know about you folks but this guy sounds like this is more of a MSFT tech bashing complaint. He does have some points but he seems to blow them out of proportion —Preceding unsigned comment added by 12.105.86.68 (talk) 03:15, 25 November 2008 (UTC)

Common Misconceptions

That whole area reads like some kind of ad. The format of "setence - FACT - reason" is the sort of thing I expect to see in advertisement. While I'm sure they may be true, it doesn't seem like it belongs here.----66.92.12.26 10:28, 14 October 2007 (UTC)

Per WP:V, I've removed the whole section. It doesn't meet Wikipedia's verifiability or neutral point of view requirements. -/- Warren 20:41, 27 October 2007 (UTC)

Unauthorized account making

This site will make an account on some PCs called "ASP.NET Machine A..." (Limited account, Password protected). Microsoft has acknowledged this. Shouldn't we, too?— Supuhstar * § —Preceding comment was added at 03:07, 20 December 2007 (UTC)

The .Net framework is not the same as ASP.Net. ASP.Net is a class library part of the .Net framework --> System.Web (see http://en.wikipedia.org/wiki/Framework_Class_Library) Your criticism should therefor be added to the .Net framework article -- 94.210.224.69 (talk) 14:50, 9 June 2009 (UTC)

Proposed merger

A new article, ASP.NET Web User Controls, contains a small amount of information relating to ASP.NET and I propose that, rather than keeping the separate article, its useful content be merged into the “Other files” section of this article. —Travis^talk 22:39, 23 January 2008 (UTC)

There were several such articles that contained a small amount of information. I've merged them all into this article. -/- Warren 18:54, 20 April 2008 (UTC)

Inline code

Can someone please cite a source for the comment on inline code: "but this practice is generally frowned upon by Microsoft except for the purposes of data binding since it requires more calls when rendering the page."? This is the first I've heard of it, there are no exceptions, the only reason that inline code is used for backwards compatibility with ASP and it makes tutorials shorter to explain. —Preceding unsigned comment added by 82.44.98.49 (talk) 23:11, 6 February 2008 (UTC)

It looks like the inline code statement has been removed. This 'section' of the discussion is now resolved. —Preceding unsigned comment added by 194.201.25.22 (talk) 14:24, 3 November 2008 (UTC)

It's still there. I have tagged it with a {{fact}} tag. I would like to see a source explaining that "more calls" thing. --Enric Naval (talk) 13:11, 27 November 2008 (UTC)

link spam

In an attempt to combat link spam, I've added the substituted template {{subst:NoMoreLinks}} to the external links section as per Wikipedia:Spam#Tagging_articles_prone_to_spam Christopher G Lewis (talk) 20:56, 15 February 2008 (UTC)

Sample ASPX page

I like the sample ASPX page, but does anyone know if ASP.Net is a valid MediaWiki SOURCE tag? I've tried <source lang="html4strict"> and <source lang="csharp">, but neither really work... Christopher G Lewis (talk) 19:07, 1 March 2008 (UTC)

I think no, Media wiki works with pure html. Or maybe i didnt understand your question.  A M M A R  02:24, 2 March 2008 (UTC)

See http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

What is ASPX?

I searched for aspx and it linked me to this page, but this page only explains what ASP.net is, NOT what ASPX is.64.180.188.6 (talk) 21:38, 19 October 2008 (UTC)

ASP stands for the classic version (ASP 1.0), while ASPX stands for ASP.NET (2.0, 3.0)  A M M A R  00:08, 20 October 2008 (UTC)

there's also an ASP.Net 1.x version, which is not the same as ASP 1.0 -- 94.210.224.69 (talk) 14:54, 9 June 2009 (UTC)

Web Forms

Why does the "Web Forms" link redirect to the ASP.NET?

Perhaps this redirect should be changed to something a little more neutral? —Preceding unsigned comment added by 194.0.197.200 (talk) 13:56, 3 November 2008 (UTC)

CICST STATE vandalism

What does "CICST STATE" mean? Google shows nothing relevant. Perhaps we should change this heading to "Session State" instead. Tonyfaull (talk) 18:48, 16 November 2008 (UTC)

It seems CICST is a computer school in India. I traced the vandal's IP to India too. So the mystery is resolved and I have reverted the vandalism. Tonyfaull (talk) 11:19, 28 November 2008 (UTC)

User Controls Vs Custom Controls

User Controls as generally derived from the System.Web.UI.UserControl. And when user uses User controls that time user has to use ascx file of the user control which does have scripting and markup text. Custom Controls are inherited from the existing server control provided in framework. or it can be derived from the System.Web.UI.WebControls.WebControl.Custom control is compiled control. user enhance the existing controls provided in framework. —Preceding unsigned comment added by Jigarrpatel (talk • contribs) 09:36, 26 February 2009 (UTC)

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.[18]

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? --85.130.3.78 (talk) 11:23, 23 March 2009 (UTC)

Is it secure, and how would I know if it is?

I recently ran across a site where the extension was .aspx with a form where a credit card number, and expiration was all being displayed in plain text. Granted that a person using some sort of sniffing software could get all the info anyway, not recognizing the extension I immediately backed out, discontinuing the transaction before entering all the required data.

Is it secure, and how would I, or any normal user know if it is indeed secure or not? —Preceding unsigned comment added by Kittyrinn (talk • contribs) 04:44, 15 May 2009 (UTC)

There is no way to be sure a page is secure. There is a way to be sure your data is send in a secure manner by using Https, this will however not say anything about waht the page itself does with the data. The ASPX itself is as secure as the programmer is able to make it, as is the same with .php and other serverside script pages. -- 94.210.224.69 (talk) 15:01, 9 June 2009 (UTC)

Clean code

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:

• http://msdn.microsoft.com/en-us/library/ms972976.aspx
• http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

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.

Vdboor (talk) 09:42, 10 December 2009 (UTC)

WHY WE USE ASP.NET,WHY NOT USE PHP OR JAVA# —Preceding unsigned comment added by 220.226.191.107 (talk) 03:51, 9 January 2010 (UTC)

Faulty Criticisms

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 97.102.228.141 (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 99.224.141.81 (talk) 17:29, 10 July 2010 (UTC)

Surely there should be a lot more in Criticism than there currently is. The only item in there at the moment has more to do with IIS than ASP.NET, but there are plenty of criticisms regularly levelled against ASP.NET - the viewstate becoming ridiculousy huge, the javascript requirement for many of the controls, the way it messess around with your HTML id's, the fact that even basic validation is done on the server, loss of control over the source, the noticable delay when doing a first compile, relatively high server requirements, the desktop style model is actually rather unsuitable for most websites, and the fact that many of the methods pushed by Microsoft are only required due to this odd development style in the first place. Of course, some of these thins are more of a problem with the way Visual Studo handles ASP.NET solutions, but that hasn't seemed to have stopped anyone using such things as supposed benefits. Half of the benefits listed are only benefits if you don't know how to do it yourself in the firs place. Also, you can get around many of these problems by not using feature X or Y, but if you have to do that for most of the features, you have to ask if you're using the right tchnologies in the first place. Horribly unbalanced shill articles like this are why no-one believes anything they read on Wiki any more. —Preceding unsigned comment added by 94.5.13.206 (talk) 12:34, 22 November 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 74.176.210.68 (talk) 03:28, 16 May 2011 (UTC)