I'm looking for an article that will dive deep into how ASP.NET works and how it renders controls from XML markup. For example, under the hood, how does ASP.NET take the following markup and have it produce the results we see?
<asp:Label ID="MyLabel"><%= myObject.Text%></asp:Label>
Does anybody know of any article that will dive deep into the inner workings of ASP.NET?
What happens "under the hood" is that each ASP.NET page is compiled into a .NET class, just like any other. Controls (ASCX) are compiled the same way. There is a compiler for ASP.NET markup just like there is a compiler for c# and VB.NET - you can think of the ASP.NET markup as "yet another" language which compiles to native MSIL.
The native ASP.NET markup is handled by the PageParser. You may notice this class has one interesting and very useful method - GetCompiledPageInstance. As it implies, it compiles the page to a native .NET class. This can be overridden (e.g., you could come up with your own markup and write your own parser/compiler). Spark is a popular alternative to ASP.NET markup.
Each class ultimately inherits from Page or Control. Both of these classes have Render() methods which, at the end of the class's executing its custom functionality you have implemented, write HTML to an output stream.
The big difference is that the compilation often happens at a much different time than the c# or VB.NET code. This is not really a technical requirement so much as it is a feature that permits decoupling the presentation .NET language from the functional .NET language. ASPX and ASCX pages are compiled by the ASP.NET runtime when they are requested in the context of a web server. The compiled assemblies are then held in memory until a) the web application shuts down or b) a filesystem change is detected in one of the ASPX files, triggering a recompile.
It is possible to compile your ASPX pages alongside your c#/VB.NET/whatever, so you can deploy the entire application as a single assembly. This has two advantages - one, the obvious ease of deploying a single DLL. Second, it eliminates the LOOOONG wait time that so often accompanies a "first hit" to an ASP.NET web application. Since all the pages are precompiled, the assembly simply needs to be loaded into memory upon first request, instead of compiling each file.
Reflector -> Expand System.Web.UI -> PageParser Class -> decompile -> Enjoy
(Sorry, not trying to be snarky; this is the only way I was able to get a grasp of it myself)
I always like this site...
https://web.archive.org/web/20210304122759/https://www.4guysfromrolla.com/articles/050504-1.aspx (overview)
https://web.archive.org/web/20210411013534/http://www.4guysfromrolla.com/articles/011404-1.aspx (more in-depth)
I need a LMBTFY (Let me Bing that for you). ;P
Anyway, here are some pages:
Compilation and Deployment in ASP.NET 2.0
Inside the ASP.NET 2.0 Code Compilation Model
Related
I'm working on an straight ASP.Net application. (no additional frameworks).
I've got several user controls (not custom controls) which I'd like to be able to package into a DLL for reuse/redistribution across several other applications. Ideally, we'd like to have everything self contained in (.ascx and source files) a DLL which could be added to the target project's references.
When embedding the user controls into .aspx pages, we'd like to be able see those controls in Visual Studio design view.
I've been looking around and seen several possible solutions for this.
Can anyone point me to a clear tutorial/example which will help step me through this process?
John, as far as I am aware, what you are asking is not possible, at least not out of the box with the .net Framework. When you build a UserControl in ASP .NET app and compile the solution, as you may have realized, the UserControl would be included in the dll of the project to which it belongs; it won't have a separate dll of its own. Since the UserControl won't have a dll of its own, you won't be able to make it available in the design view/toolbox.
For what you are asking, you might want to consider creating ServerControls instead. Server controls are harder to create than UserControl, if I recall correctly, you have to code it entirely, wont have designer available, but when you are done and compile, ServerControl will have it's own dll, which could be made available in CustomControls under Toolbox.
If you want a starting point for ServerControl, I would highly recommend watching the video from KudVenkat. His explanation and demos are second to none.
Link to the tutorial
I would like to know what, why or when it is better to choose cshtml and what, why or when it is better to choose aspx technologies? What are these two technologies intended for?
Thank you,
As other people have answered, .cshtml (or .vbhtml if that's your flavor) provides a handler-mapping to load the MVC engine. The .aspx extension simply loads the aspnet_isapi.dll that performs the compile and serves up web forms. The difference in the handler mapping is simply a method of allowing the two to co-exist on the same server allowing both MVC applications and WebForms applications to live under a common root.
This allows http://www.mydomain.com/MyMVCApplication to be valid and served with MVC rules along with http://www.mydomain.com/MyWebFormsApplication to be valid as a standard web form.
Edit:
As for the difference in the technologies, the MVC (Razor) templating framework is intended to return .Net pages to a more RESTful "web-based" platform of templated views separating the code logic between the model (business/data objects), the view (what the user sees) and the controllers (the connection between the two). The WebForms model (aspx) was an attempt by Microsoft to use complex javascript embedding to simulate a more stateful application similar to a WinForms application complete with events and a page lifecycle that would be capable of retaining its own state from page to page.
The choice to use one or the other is always going to be a contentious one because there are arguments for and against both systems. I for one like the simplicity in the MVC architecture (though routing is anything but simple) and the ease of the Razor syntax. I feel the WebForms architecture is just too heavy to be an effective web platform. That being said, there are a lot of instances where the WebForms framework provides a very succinct and usable model with a rich event structure that is well defined. It all boils down to the needs of the application and the preferences of those building it.
Razor is a view engine for ASP.NET MVC, and also a template engine. Razor code and ASP.NET inline code (code mixed with markup) both get compiled first and get turned into a temporary assembly before being executed. Thus, just like C# and VB.NET both compile to IL which makes them interchangable, Razor and Inline code are both interchangable.
Therefore, it's more a matter of style and interest. I'm more comfortable with razor, rather than ASP.NET inline code, that is, I prefer Razor (cshtml) pages to .aspx pages.
Imagine that you want to get a Human class, and render it. In cshtml files you write:
<div>Name is #Model.Name</div>
While in aspx files you write:
<div>Name is <%= Human.Name %></div>
As you can see, # sign of razor makes mixing code and markup much easier.
While the syntax is certainly different between Razor (.cshtml/.vbhtml) and WebForms (.aspx/.ascx), (Razor's being the more concise and modern of the two), nobody has mentioned that while both can be used as View Engines / Templating Engines, traditional ASP.NET Web Forms controls can be used on any .aspx or .ascx files, (even in cohesion with an MVC architecture).
This is relevant in situations where long standing solutions to a problem have been established and packaged into a pluggable component (e.g. a large-file uploading control) and you want to use it in an MVC site. With Razor, you can't do this. However, you can execute all of the same backend-processing that you would use with a traditional ASP.NET architecture with a Web Form view.
Furthermore, ASP.NET web forms views can have Code-Behind files, which allows embedding logic into a separate file that is compiled together with the view. While the software development community is growing to be see tightly coupled architectures and the Smart Client pattern as bad practice, it used to be the main way of doing things and is still very much possible with .aspx/.ascx files. Razor, intentionally, has no such quality.
Cshtml files are the ones used by Razor and as stated as answer for this question, their main advantage is that they can be rendered inside unit tests. The various answers to this other topic will bring a lot of other interesting points.
can i have some general advice on converting a classic asp site to asp.net? i've never worked with classic asp before and have only worked with asp.net 2.0 for the past 6 months or so, so this is completely new to me.
i noticed that this site i'm wokring on uses a few 'include' files. i know i should probably take the code from the include files and copy them into their own class files. i've notice that there is no code behind file, that each page is written in it's own file (markup and code). also, and this is kind of throwing me off, there are no event handlers. are there any other helpful nuances between classic and .NET you can mention?
one more question: i've notice in each file in my project that there is some code that is written above the markup, and some more below the markup. it seems it would be better if ALL the code was written above or below the markup, for organizational/readability purposes. unless, there's a reason for this. ???
thanks.
You certainly have a challenge on your hands. As far as comparisons are concerned, MVC is probably closer to classic ASP as it doesn't attempt to abstract the web into an event based structure - but that would just be another thing for you to learn.
Classic ASP is a completely different beast to ASP.NET as you're finding out. Basically each URL resolves to a parent ASP file. That in turn includes other ASP files (they can have different extensions if developer felt like it i.e. ".inc"). These in turn can include other files. It is entirely possible to have the same file included several times - generally ASP engine copes with this however. It is important to remember that all includes are processed to make one big document before any actual ASP processing starts. So once all the includes have been processed, you have one big document. The ASP engine then starts at the top and processes the code line by line. You'll probably have HTML and ASP code all inter-twined, with calls off to proceedures.
If you can program C# or VB then reading an ASP file with that in mind shouldn't be too difficult. At that stage you can begin to tackle the functionality one page at a time. Just remember that in ASP there is also no "post back" or view state concepts. Again this is ASP.NET trying to abstract web programming to represent an event based approach.
Sorry one last thing - some commands such as option explicit in ASP must be the first thing in the parent ASP document, so that must always appear before any other code or markup. After that code and markup can be mixed intogether - resulting in the infamous "tag soup" that ASP will be remembered for.
Take your includes and categorize them:
1) Code functions
2) Template functions
All code functions should be dropped into business object classes or modules. The template functions should be placed into user controls and sequently master pages. I strongly suggest the use of master pages in controlling the templated look of your new project as it will save you a lot of time in managing the site and transferring all of the actual page functionality into the new pages.
ASP is a scripted language where as Asp.Net can be either scripted or compiled. I would recommend choosing a Website Project because this will give you the greatest flexibility in deploying the minutae of the code. A Web Application project will compile everything into a singular .dll file which is easy to deploy, but it leads to a lot of regression testing if/when page code intertwines.
Once you have a templated structure, common classes, data access layer and masterpage/usercontrol structure established, it just becomes a task of going page by page and converting it over to the new code.
I have an ASP.NET web app which is growing.
It is done in traditional web forms. While I would like to convert it WCSF to improve testability, this is time-prohibitive. I have taken the action to only make method calls in ASPX code behind which call the appropriate methods in the classes in App_Code so the spaghetti code is gone, which is good.
What else could I do to improve testability without any fundamental rewrite?
Thanks
Is this a Web Site project? I find Web Applications are more structured and easier to maintain. I'm not sure if they are more testable. Then do use namespaces where a web site does not.
Have you considered using a UI pattern such as MVP? You also might get partial coverage with creating interfaces for your code-behinds and testing against the interface. Watch out for hidden side-effects (changing the state of a dropdown within a method, it hidden behavior).
A book I found helpful was 'Working Effectively with Legacy Code' by Michael Feathers.
After reading the answer here, I understand that, if I register a user control (I guess I'm really trying to use it as a custom server control) like this:
<%# Register Assembly="MyDLL" Namespace="MyDLL" TagPrefix="myDLL" %>
Then only the codebehind is used, and the markup (.ascx) page is ignored. Why is this the case (it seems arbitrary), and how can I get around this problem without having to specify the Src="..." attribute in my Register directive? All I want to do is build a user control into a single assembly (a DLL) and hand that DLL off to another web site or web application project in such a way that the web site/app can use my user control. This should not be that hard, but apparently it is...
I am working in Visual Studio 2008, if it makes a difference.
Edit (prompted by the links in Rex's M's comments): it seems like most of the instructions for doing this kind of thing are applicable to VS2005, even the stuff on MSDN. My question is pretty much exactly stated here; is the answer provided on that thread correct
Is there any reliable, recent documentation describing this sort of thing for ASP.NET 3.5 and VS2008? I feel like using the latest versions is causing more confusion and difficulty than benefit.
The thread you linked to is indeed correct. The information which originally addressed .NET 2.0 and VS 2005 is still very applicable. .NET 3.5 does not actually change .NET 2.0, just adds extra stuff. For things that are already in .NET 2.0, they are unchanged in 3.5.
It sounds like you want the functionality of a Custom Control. In a normal user control situation, the website needs an .ascx and that cannot be placed in a DLL.
I strongly recommend to take a look at custom server controls. Since for the purpose of sharing controls over multiple projects they are better suited in my opinion than user-controls. User controls are better for internal reuse, within the same web application (i.e. on multiple pages).