I have an ASP.NET WebApplication (not Website) that was written with C#.
I want to publish and deploy this application for more than 50 sites in my server.
I would prefer to make some dlls and put them in GAC of my server so all sites will use dlls from GAC and then I can update all my sites just with replacing some dlls in GAC.
When I publish my application I get a single dll for all .cs files but all .aspx files remain.
I want to merge .aspx files to single assembly too.
Is there any way?or any other idea for my case?
in your web project properties:
package/publish web
check - precompile this application before publishing
advanced - merge all output to a single assembly
When you go to the publish settings there is an option to 'make site updatable', if you untick that all the cs code will be merged into the app_web.dll.
You will still have all the seperate aspx pages, since those define the entry point into the code. To my knowledge the only way to merge those would be to copy/paste all the seperate aspx pages into the default.aspx, and wrap them in <asp:Panel ID="HomePage" Runat="Server" Visible="False"> and then set the right panel visible in the Page_Load depending on the QueryString. You can use URL rewriting to still get nice URLs.
Depending on how many pages you have, and how big they are in code, I would probably not do this myself. But if you find the result of having 1 page outweighs the rest, it is technically possible.
Download IIS Module: http://www.iis.net/downloads/microsoft/url-rewrite
Making rules: http://www.iis.net/learn/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module
Another option, maybe, is to just host the application on a subdomain and iframe it where it is needed. This might not be possible due to cross-origin problems, depending on your setup, but it would be a 'cleaner' way to work.
Hope this helped.
Related
I've been trying to understand the different types of compilation involved in ASP.NET and have come to seek some clarification regarding dynamic compilation of .aspx files. Specifically referencing the following statement from Microsoft's Understanding ASP.NET Dynamic Compilation:
"By default, ASP.NET Web pages and code files are compiled dynamically when users first request a resource, such as an ASP.NET page (.aspx file), from a Web site."
My question is simple, yet doesn't seem to be discussed anywhere.
Is it an HTTP GET or POST request that compile .aspx page? Or does it not matter?
and
If I can see requests (both GET and POST) to the .aspx page but there is no .dll or .compiled file created, is there a problem? The content of the .aspx file is correct.
Any help in understanding this aspect of ASP.NET compilation would be greatly appreciated. Thanks!
The compile is a one time event. And it depends on what kind of project you created.
if you create a asp.net web site, then pages are compiled on the fly - but ONLY the first time they are used - use by anyone. So you don't have to care or worry about this issue. But to answer your question? They are only compiled one time. Not each time.
If you create a asp.net web site application? Then when you deploy the site, all code and pages are compiled at deploy time. No runtime compile on the fly (that one time, first time) occurs. and I belive that you can deploy without a pre-compile for a web site application - and you notice quite a delay the first time the site is used as a result. But in this case - only one .dll for the site is created. This is really simular to a desktop application. You compile the project, and you get one .exe or one .dll. You may well see/find some addtional .dll's from libraries that you referenaced in the project also included in the bin folder.
As for the .dll? As noted, it depends on the type of site you created. If you created a asp.net web site application, then everything (most) is compiled into ONE .dll that resides in the bin folder. So each compiled page thus does not have a separate .dll.
The site is thus pre-compiled (or only compiled one time). For a asp.net web site (not a web site application), then you should/would in theory see a new .dll for each web page if you created a asp.net web site in place of a asp.net web site application. Some prefer a web site, since then you can update ONE page without a whole site re-compile.
But, if you have your own IIS server, then choosing a web site application is preferred. One big difference is that you can create custom logon and authentication providers with a web site app, but you can't with a web site. You can still have and create logons for that web site, but a web site application allows you to over ride and build your own authentication providers.
You as a general rule only want to create a asp.net web site application if you have your OWN IIS server. For most hosting plans (say low cost ones), then you have to use a asp.net web site - not a asp.net web site application - and in that case, then .dll's should appear for each web page in that case.
But as noted, in either case - once the page is compiled, it does not re-compile over and over each time such pages are used.
I need to ensure that when some individual pages are updated/modified, the time required to load the other pages to the Web site remains unaffected.
A. Create the application as a Web site project.
Copy the entire application to the deployment server.
Copy only the updated files to the deployment server when a page is updated.
B. Create the application as a Web site project.
Pre-compile the application by using the update able option.
Copy only the updated files to the deployment server when a page is updated.
is Pre-compile option available for web site or its available for web app?
I can simplify this question by some ifs that contains your answer.
If you update just the ASPX files and rarely you change the code files : then
Use Website and publish it using
Allow this precompiled site to be updatable
Using this option you can change ASPX files
Use fixed naming and single page assemblies
Using this option you can change code files, and replace them with their friendly name
Update required published dlls and ASPX files when ever you need.
Note: any changes to bin folder contents may cause application restart and that means all sessions will be lost, so in this case you must consider using other session state modes like SQLServer and StateServer and once you do you need to annotate all your session classes with Serializable attribute
If you will update just the ASPX files : then
Use Website and publish it using
Allow this precompiled site to be updatable
Using this option you can change ASPX files
Else if you just need to update the ASPX HTML content : then
You might reconsider your application scenario
because you need to use data-base to rectify the update problem as any body else do
And finally if you will update web-site code-files very rarely or your changes are at application level rather than page level : then
Use web-application build or publish it if you like.
Using this option you still have the ability to change the ASPX files
Say I have this url:
http://site.example/dir/
In this folder I have these files: test.ascx.cs and test.ascx
Just to be clear, I am not a .NET developer.
From a security point of view - why can't I access http://site.example/dir/test.ascx.cs and how secure is it to keep those files there?
I assume IIS filters out request that query these kind of files, but can someone explain me this?
Thank you.
You just explained it yourself. IIS won't serve those files.
When you register ASP.NET with IIS (aspnet_regiis.exe) it will add common extensions and associate them with the ASP.NET handler. As far as the .cs extension is concerned it is filtered and not served by IIS. It is absolutely safe to have these files there, but I would recommend you to use an ASP.NET application project (in contrast to ASP.NET website) which is precompiled and you don't need to deploy source code files on your server.
(source: wewill.cn)
With Asp.net web sites and ASMX web services, can some explain what can change once an application has been deployed.
For web sites, I can see that the you can change the aspx files but for web services, I am not sure what can be changed. Any real-world examples of where changing files and dynamic compilation is useful?.
JD.
After deploying the application you can change anything you want to in there. You can change .aspx pages, you can add / remove dlls from the bin folder, you can add / remove code files from the app_code folder, you can add remove stuff from the app_data folder, you can obviously add remove the .asmx files for the web service. I don't see any reason why you cant change anything. go ahead and try changing these things. When you run the code after changes the website will compile again automatically. The things i wrote are written considering that you have deployed the whole code for the website and not a published site !
We would like to have several internal web applications which use the same master page. Is there a way to store a master page in a common library referenced by all projects?
You can do this, but it is difficult and has quite a few drawbacks.
This process is similar to packaging up user controls as well. Basically you have a web application project that contains your master page. You can precompile this into a set of dlls using aspnet_compiler.
then you can use ilmerge.exe to put them all into a single dll that you then reference from your other projects.
You still need to have the markup in order for your pages to render properly in the designer, so you'll probably have to investigate VirtualPathProviders as well.
It's a kludgy solution and it has many drawbacks.
I've heard this works, I haven't tested it.
Create a separate project to house your master pages, since all master pages are like user controls and built into their own separate assembly. Run the build and try referencing the assembly of the master page.
Again, not tested, just something I've read before.
G'luck with it!
Given that these modules are part of the same web application, you should look at this approach:
Basically, you have one root web, which is set up as the(only) IIS web application.
You may plug in new web modules by creating ASP.NET Web Application projects and place under the root web, physically.
Set the build directory to root web's bin, eg. "..\bin". Don't create a IIS application/virtual directory.
Thereby, each web module compiles into its own DLL, which is itself a good thing.
When compiling, it is "merged" with the root web.
It is a great way for sharing master pages and user controls, and have different parts of the web site in different projects/assemblies.
Master pages and user controls will even work in design mode.
Hope this helps
Sharing master page across the application
Enjoy.. :)