Since all files in a web project are compiled into single assembly, then does this assembly maintain a directory structure? For example, if a file in a root directory references a file in a subdirectory, then how could this reference still be valid when the two files get compiled into same assembly?
Assume a web project has the directory structure shown below.
Since all of web project’s ASPX files get compiled into a single assembly WebProject1.dll, how is this assembly able to record/memorize the directory structure?
Thus, when you deploy WebProject1.dll to a web server and user makes a request for http://WebProject1/some_SubDir/default.aspx, how will WebProject1.dll be able to figure out which Page to render?
WebProject1\SubDir (where WebProject1 is a root directory)
WebProject1 -- contains several ASPX files
WebProject1\SubDir -- contains a file default1.aspx.
When we deploy the Web project, must we create the same directory structure on a web server (WebProject1\SubDir), even though we won’t put any ASPX files into those directories?
I assume that on Web server WebProject1.dll should be placed into the Bin directory?
thanx
EDIT:
Only the sourcecode is compiled into the assembly, you still need to upload the aspx files into a matching directory on the server.
My book says that when using Web project all web code is compiled into single assembly. I thought “all code” includes aspx files?!
Links are maintained between the page and it's code behind file through a class declaration which by default is in a namespace that matches the directory structure
So if I add a new aspx page via Project --> Add New Item, and store this aspx page in a subdirectory named Hey, then this page will reside in namespace WebProject1.Hey?!
But how do I do add new item into a subdirectory, since Project --> Add New Item doesn’t give me an option to browse and choose a directory I wish to save it in, but instead automatically creates aspx file in a root directory?
The relative path is kept when the compiler generate the dll.
I’m not sure I know what relative path you’re referring to?
thanx
Only the sourcecode is compiled into the assembly, you still need to upload the aspx files into a matching directory on the server. For example you project in Visual Studio may look like the following:
WebProject1 (The root project)
|
|- some_SubDir (A physical directory inside the project)
|
|-default1.aspx
|-default1.aspx.cs (assuming a C# project)
Once you have compiled the web app you'll need to upload the following to the server:
WebProject1 (The root directory for your website)
|
|-bin (The binary directory created by the build)
|
|-WebProject1.dll (The compiled source code of the web app)
|-some_SubDir
|
|-default1.aspx (The file that will map to the URL www.websitename.com/some_subdir/default1.aspx)
Compiled resources (non-sourcecode files that are compiled and stored inside the assembly) are different issue that are addressed in your other question
Edited to add direct answers to the questions:
Not all files are compiled into the assembly, only source code files are. Links are maintained between the page and it's code behind file through a class declaration which by default is in a namespace that matches the directory structure, but it doesn't have to be.
Your default1.aspx file will have in the header something like:
The inherits line tells the webserver that when a user requests this page it should be processed in conjunction with the source code that defines that class, which it will find inside the compiled assembly. The combination of the physical aspx file and the compiled class will generate standard html which is then passed back to the client.
Yes, you need to create the same directory structure, but you are required to put the aspx files in there.
Yes
(can someone please edit this if they know how to get the list items to number correctly, please?)
All those path information will be embedded as Meta Data/resource file, so, you can deploy it safely to the server. The relative path is kept when the compiler generate the dll.
I suggest you use Reflector to open the dll, and you can get a much more deeper understanding what is inside dll.
Notice how some_Subdir/default1.apsx has a 'Inherits' key/value pair in the page declaration?
What this means is that when you make a request for that resource IIS goes 'Ah ha! Asp.Net needs to handle this request! Hey asp.net please return me some html to send down'
Asp.net parses that aspx file and creates a proxy class on the fly that inherits from WebProject1.some_Subdir._Default1. This proxy class then parses out the control tree and html, and kicks off the page life cycle (this is overly simplified, and I'm sure I've missed some details).
So the WebProject1.dll is just the actual C# / VB of your web app, but in concert with the asp.net worker process and the markup you can render html back to a client.
Related
I can't find (by string search) any references to the files in my Pages/Shared folder anywhere in my project, but if I remove the folder and its files my test page stops loading correctly. Clearly some kind of implicit convention is at work, but I'm unversed on this matter. Where can I find the relevant information on this?
Files in the Pages/Shared folder are used for reusable parts. The reference, as it is shared throughout the app, is made only by filename or relative path from shared subfolder and without using extension.
You should have in shared folder _Layout.cshmtl and _Layout.cshtml.cs at least. That file is defining layout that is used by default on every page you create.
Once you search for "_Layout" in you project you should get at least one result.
Information about project files for Razor pages are available in Examine the project files and about the layout you can find in Layout in ASP.NET Core.
That might give you an idea how it works by default or what is purpose of said folder and file(s).
You can also read and follow instructions in Understand Searched Locations For The Razor View Engine And ASP.NET to get a bit more understanding how it all works by default.
I want to deploy my website with precompiled views, for performance reasons. So I have configured UseMerge and PrecompileBeforePublish.
This is part of my publishing profile:
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>False</EnableUpdateable>
<UseMerge>True</UseMerge>
<SingleAssemblyName>Conwell.Administration.Views</SingleAssemblyName>
<DeleteAppCodeCompiledFiles>True</DeleteAppCodeCompiledFiles>
In the UI this is reflected:
My Conwell.Administration.Views.dll gets successfull created. However after publishing, I have for each View an additional .precompiled file in my bin folder:
The content reads as following:
<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="2" virtualPath="/Areas/Bookings/Views/SepaDebits/Detail.cshtml" hash="fffffffff9d57aef" filehash="1737cd4f2d0e" flags="110000" assembly="Conwell.Administration.Views" type="ASP._Page_Areas_Bookings_Views_SepaDebits_Detail_cshtml">
<filedeps>
<filedep name="/Areas/Bookings/Views/SepaDebits/Detail.cshtml" />
</filedeps>
</preserve>
I tried to simple delete them, but then the website shows only a blank page. I don't like that many *.compiled files. They add up to more than thousand.
For what are they used? ViewEngine? Is it somehow possible to disable them? Maybe a custom ViewEngine?
I have only found this thread so far, but it doesn't give any pointers.
For executable files in an ASP.NET Web application, the compiler
assemblies and files with the .compiled file name extension. The
assembly name is generated by the compiler. The .compiled file does
not contain executable code. Instead, it contains only the information
that ASP.NET needs to find the appropriate assembly.
After the precompiled application is deployed, ASP.NET uses the
assemblies in the Bin folder to process requests. The precompilation
output includes .aspx or .asmx files as placeholders for pages. The
placeholder files contain no code. They exist only to provide a way to
invoke ASP.NET for a specific page request and so that file
permissions can be set to restrict access to the pages.
Source: https://msdn.microsoft.com/en-us/library/e22s60h9(v=vs.85).aspx
You will have to remove the pre-compile steps to remove them, or deploy the source code alone. Use build server to compile real time.
I would just leave them. They cause no harm.
I have a site that I'm about to publish and I want to know how to set it so it would not deploy the code behind?
Essentially i'm trying to find the difference between an aspx file that calls the code behind .cs file and another that calls a dll that's in the BIN directory?
The below explanation from the Microsoft ASP.NET documentation discusses the difference between explicit and automatic compilation.
In order for the ASP.NET engine to service a request for this page,
the page's code portion (the WebPage.aspx.cs file) must first be
compiled. This compilation can happen explicitly or automatically.
With explicit compilation you need to copy up the assemblies in the
Bin folder, but you do not need to copy up the ASP.NET pages' code
portions (the WebPage.aspx.cs files).
With automatic compilation you need to copy up the code portion files
so that the code is present and can be compiled automatically when the
page is visited.
When you publish a web project (from Visual Studio), the source code from code behind (.aspx.cs files) will be converted to a binary dll file named as [YourWebProject].dll and will be copied under the "bin" folder.
We are working on a website project which contains around 1130 pages. After compilation, all the .aspx.cs files are converted into AppCode DLLs that has random names.
Whenever there are any changes in single .aspx.cs file[like a hotfix], we have to recompile and deploy the entire project on the application host.
We want to update only those files that have been changed and not the entire package.
One of a solution we are aware is that, converting Website to Web application; but we cannot implement that change at this stage of the project.
Is there any other way to find an efficient solution for this?
Yup. Talking in Visual Studio 2010:
While publishing the website, Select the option: 'Use Fixed naming and single page assemblies', Also select 'Allow this precompiled site to be updateable'.
After website is published. Go to the published folder. Open any aspx page (not the dll or .cs).. Note the dll name in page attribute under inherits attribute. Than using ftp or any other way to upload, copy or upload tht dll under bin to your website.
Also, you can create a doc or txt file to list all Dll names with respective paths to your file to easily know which dll to upload next time if there is any change.
Hope it helps.
How can I get the path of a cs file in aspx?
Here's the issue: I've created a property class in a property.cs file which is used in an EPiServer admin module. Server.MapPath() will hence return the path of the executing file, which is in a totally different place than my code. I need to get the path of the property.cs file (from inside the property.cs file) in order to dynamically set some relative paths to css and js files. How can this be done?
I hence want to be able to include .js and .css files in this cs file, all files located in the same directory, but the cs file is accessed from the EPiServer UI.
I would highly recommend not doing what you are trying to do. You'll be constructing a brittle dependency on files that should not even by deployed with your project.
If you have web classes that rely on resources like javascript and css, you should use the ClientScriptManager (or ScriptManager for ajax apps) to register the script files onto the page, and the scripts and css should be deployed into their own regular web directory.
If deployment location is a problem, and you're creating some kind of reusable, redistributable module, then I would recommend that you embed the .js and .css files as WebResources in your assembly, and use the script manager to register the scripts to the page that way, with ClientScriptManager.RegisterScriptResource().
I think you should go with including your CSS, JS and other static files as embedded resources.
That will include the files inside the DLL, which makes deployment easier. You can then set up a HTTP handler which will serve you the contents of the embedded files - or use the aforementioned RegisterScriptResource() method.
By embedded the files you don't have to know any file paths.
ASP.NET is compiled, you should never need to read settings from source files at runtime, you should read from configuration files (*.config), if they need to be dynamic, these too can be injected during the page lifecycle via a variety of methods.