If I have pages having server-side code in code-behind, then I know that the code-behind for all such pages will get compiled into a single intermediate language dll, when using a Web Application type of project.
But, if I have some single file aspx pages (i.e. pages with inline server-side code) in the same Web Application project, I am thinking that the server-side code for these inline aspx's will not be part of the single dll that is generated for a Web application project. Is this true?
My impression is that single-file aspx pages are always compiled on-the-fly and never pre-compiled.
Yes. It will be compiled on fly if it is inline in the ASPX file itself. But this will happen only once. After that it will be cached until the ASPX file is changed. So from the second request onwards both will be treated same.
You can read this
It is advisable to use single file when you expect the code to be changed frequently and you do not need to recompile the entire code.
Also here is the MSDN link for more details.
Note: You can have a single DLL with all code or you can have different DLLs for each page.
Related
Background
I have an ASP.NET Web Forms app that I want to localize using .RESX files. I already know how to do this using .ASPX files. However, my application uses some .ASPX files... as well as some plain .HTML files.
(I am doing a lot of KnockoutJs, where the app retrieves the reusable HTML templates and injects them into the DOM as needed.)
I can't take the following approach in the HTML files, since the <%$ code would not be executed.
<%$ Resources:Main, WelcomeMessage %>
The Question
Is it possible to use C# code to process a plain HTML file against a RESX file to generate an HTML file that has been localized?
(I NEED A SOLUTION WITHOUT USING AN .ASPX FILE)
If this is possible, then I might be able to create a web service that will apply a RESX file to an HTML file and return the resulting HTML string.
Answer
I think the answer.... is No.
There does not seem to be an easy way to do this with ASP.NET Web Forms. So instead I switched my project to use ASP.NET MVC.... where this problem is more readily solved.
In case you are interested... here's what I did in MVC:
I changed the HTML files to .cshtml files (which support syntax that works with .RESX files). I created a controller I call HtmlController with a GetHtml action. The GetHtml method takes a URL as a parameter, and renders the contents of the requested .cshtml file, which is returned as a PartialView.
Now right after my page loads, I can fire Ajax requests to retrieve some shared HTML templates by calling that GetHtml action on HtmlController. The HTML content of my requested .cshtml file is localized against my .RESX file and then returned as the result of my Ajax call. I can then bind it on the page.
This works particularly well for shared HTML templates that I reuse across various pages, but I still need to have them localized for the currently selected Culture.
In retrospect
I still feel moving to MVC was the right decision.
However..... I suppose after having switched to MVC.... it might have been simpler to just directly render partial views (for each of those shared templates) on each page that needs access to them.
Then I could have avoided making separate Ajax calls to pull this stuff down when the page loads.
[FacePalm]
I am quite new to .NET development and I am just wondering how does it work?
My undermentioned points are:
While developing ASP.NET application, under the project we have files like:
pagename.aspx
pagename.aspx.cs
pagename.asp.desiger.cs
After adding certain functionality to pagename.aspx page, assuming I have the development required web application (this is not my concern, what is developed)
Now I'm going to deploy this application, I use web deployment MSI which creates the required files in the one folder called folderdelopyed.
This folder contains the files required to support this application but interesting does not contain pagename.aspx.cs and pagename.aspx.designer.cs files.
My question is if folderdelopyed does not contain .cs file, then how does it work to run the segment of code which I have written in this file called PageName.aspx.cs?
The code in your cs files gets compiled into a dll.
For Web Application projects this is one dll
For Web Site projects, this is a dll per page.
All of the code is now in the dll's in the bin folder of the website.
You can use a tool like ILSpy (http://wiki.sharpdevelop.net/ILSpy.ashx) to look inside the dll's and see your code.
In the old days, for classic ASP, the script used to be embedded in your page - a mix of code and HTML, and was interpreted at runtime.
I like the new way more :-)
ASP.NET code is compiled into Dynamic-link library files, also known as DLL files.
The code you write in your code behind, which is the files with .cs extension, is compiled and put into whole new file, with .dll extension - and that file is copied to the server, to the BIN folder of your site.
Depending on what project type you choose, it's possible to have several DLL files for the web application, changing in every build - see dash's answer for more details.
On every .aspx page you have referece to what DLL file to use, as the very first line. For example:
<%# Page Language="C#" AutoEventWireup="true" CodeBehind="pagename.aspx.cs" Inherits="MyNameSpace.pagename" %>
In this example, the Inherits part determines what DLL to use. How? By the namespace, which is also the name of the DLL file.
When the above .aspx is requested by a browser, the .NET engine will go to the BIN folder, look for MyNameSpace.dll and in there look for class called pagename that inherits from the base Page class - all the rest is typical life cycle of ASP.NET page.
let me to say you something more Amazing.
you can hide your aspx file too.and put their content in to dll as same as your cs file put in dll.
you can make k aspx that just contain an address to the ddl file and no html body :D
that was greate!!! not only you can hide your cs file, you can hide you aspx file too :D
Let me just start by saying, if anyone knows of a good article that talks about this subject, please point me towards it.
Does code in an .aspx page (in between <% %> tags) get compiled in a web application or is it treated like markup where you can just change it without recompiling the solution? Does compiling only compile the code behind code in the .cs and designer.cs files ?
If you're developing in a 'Web Application Project' (as opposed to 'Web site') then any change to class (.cs), code-behind file (.aspx.cs), designer files, etc (basically anything that isn't markup or static files like .htm) would require a rebuild in Visual Studio.
All code within a .aspx file, in or out of code blocks (<%%>) gets compiled.
Changing an .aspx file will cause IIS to recompile it on the next request.
See MSDN - ASP.NET Dynamic Compilation.
Update (following comment):
As for development work - pretty much the same happens when you use the dev web server to view the page. You do not have to recompile the solution/project, but the page will get recompiled dynamically.
I have a classic ASP style #include from a ASP.NET file as:
(!-- #include file= "../../maininc.aspxinc" --)
(Guess it is actually an IIS server-side include?)
It is some strange caching going on. It seems like the original file is cached so that changes in maininc.aspxinc has no effect.
IIS6
Expiration headers off as far as i can see
Asp.NET 3.5 (plain, not Web Form).
What is going on? What can i do? Should a dynamic type be different?
(I know that in ASP.NET this would normally be a control :-)
Consider using a Web Server control instead of an #include. See http://msdn.microsoft.com/en-us/library/3207d0e3.aspx
There isn't any strange caching going on but there is compilation going on. A page is only compiled once when it is first accessed and the resulting assembly is stored in temporary folder. Subsquent requests for the same page are simply passed to the HttpHandler in the assembly.
If you modify the page then ASP.NET detects that the existing assembly no longer matches and rebuilds. I strongly suspect the #includes are not taken into account in this mechanism.
You would be better off with one of:-
a UserControl (an file with then .ascx extension) if the include represents a set of HTML controls.
Use a master page if the include is for common navigation markup for use by many pages
A source code file (.vb or .cs) in the App_Code if you want to include some common classes.
A separate library project that builds a dll for the bin folder.
I'm using a web deployment project in order to precompile my ASP.NET 3.5 web project. It creates a single extra DLL for the code in aspx and ascx files. And, for every aspx file there is a placeholder aspx file (empty) which needs to be copied to the server.
I'd like to simplify the deployment process. Is there a way (configuring the IIS site and adding some sort of http handlers etc.) to get rid of these aspx placeholders?
Also, I'd like to know if there is a way to get rid of the .compiled files in the bin folder. It would make the deployment process smoother.
Thanks!
I discovered it by myself. It is much easier than I thought (IIS 6.0):
In Internet Information Manager go to the property page of the site, then chose the tab "Home Directory" and click on the button "Configuration...".
Click "Edit..." for the .aspx ISAPI extension and uncheck "Verify that file exists". At this point, no aspx file is needed anymore.
Update
One important thing: I had to create an empty "default.aspx" file in the root of the application in order to allow the default document for requests like "http://www.example.com/" (without calling an aspx).
Update 2
Another very important thing: if you're using ASP.NET Ajax PageMethods, then you have to keep the aspx placeholder of that page. If you're omitting the file, a javascript 'PageMethods is undefined' error will be thrown on the browser.
IF it is possible, then it will require, at the least, the mapping in IIS of all possible requests to the asp.net engine. Not very difficult. Then, a HttpHandler should be possible to intercept all incoming requests. That handler should then be able to dynamically load compiled page classes and render them. You'd basically have a single engine DLL that serves page content.
But as you might have noticed from all the should's, it's not a simple thing to accomplish, and I doubt that it's really worth the trouble. What exactly is wrong with these placeholder files being present?