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?
Related
I have a published website and I need to change only the ViewPage(.aspx) code that is giving me an error. If I change that viewpage will it be ok or will I have to publish the website again? If there is no need to publish the website, does it work for css, javascript/jquery files?
If you are only changing visual elements (or in line code that don't rely on a new Project.dll being created) then there is no need to publish the website as long as you are updating the files on the server. If you want VS to send the files to the server for you then you will need to re-publish it.
Publishing is an easy way to build your project, package it and send it to the server so you don't have to mess about with individual files. If you just want to change one file, be it .js , .css or alike then you can just change it.
Depends on what you're changing...
If you're changing elements that have a direct impact with the codebehind in the aspx.cs, then you'll get a runtime error. For instance, suppose you have an aspx textbox and you change the textbox to a radiobutton, or you change the textbox's id field then you'll have to compile the solution and publish the visual page along with the dll to the server.
If, on the other hand, you're just changing css, javascript, or html, and you're sure that does not have an impact on the codebehind, then you can just publish the visual page.
If you change the code of views, then you don't need to publish the site again. If you change code behind then you must publish the dll. When you change the code the dll of your project changes.
We have legacy code to maintain and, to solve a specific customer customization problem, we want to route calls to some files to other files. That is, when the app calls a particular ASPX, it will end up hitting another ASPX.
If you call:
www.foo.com/admin/admin.aspx
It will actually hit:
www.foo.com/customizations/customer1/admin/admin.aspx
This is not a good design but this is legacy code. We just want to solve this.
We are using the System.Web.Routing framework to solve it. This works fine when you set RouteExistingFiles to true, except for static files (CSS, JavaScript and Images).
When I first tried it, it retrieved this error:
There is no build provider register for the extension '.css'.
So I did register a build provider in the web.config file for the .css extension. I used this build provider: PageBuilderProvider because someone recommended it in the internet.
It works! But the CSS is being served with text\html content type.
How do I achieve this?
TL;DR: I want to use routes in ASP.NET Web Forms to make a call for a specific CSS file to actually retrieve another one. A customer needs this for customization.
Try coding a HttpHandler. I had to do something similar but for PDF files, I coded a custom HttpHandler in the end - works very well. You can even set the content type in the HttpHandler code and have a pattern matched path the handler will be used for in the web.config. You can also configure it in web.config not to execute if the path does not point to an existing file e.g. so a 404 is returned without having to code that in the handler itself. I can't post my code (VB.NET) ATM because I'm using a tablet but google search for tutorials. You will also probably need to use the TransmitFile function to actually write out the css file. Is it a web forms project or web site? If its a web site there is a special way of registering the HttpHandler in the web.config.
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 have a website which uses a web user control... well, basically all over the place. It's even included in other web user controls.
So I thought I could just upload the new source and it would recompile on the fly and be fine, but instead every page or control that uses it complains about a type mismatch. Because it is used in so many places, it very quickly becomes easier to just update the entire website. (Or at least it would if I didn't need to go through our change management process for that...)
So is there something I'm missing? Isn't there any way to upload a web user control and have it recompile like when you update a single web page?
I think it is recompiling, it just takes a bit and you have a conflict with the mismatched .ascx and .ascx.cs files in Temporary ASP.NET Files while it recompiles. I could be wrong about this. Personally, I've had better success if I always upload both the .ascx and .ascx.cs files together.
I would think that if you pushed these items you should be good... any less and you might have issues:
bin contents - this will include your code changes to the user control and if the assembly version changes you will want to include any .dll that use it, I have run into issues to many times by trying to push just a single .dll that is in the bin.
.ascx file
I don't think you would need to push any other .aspx or .ascx files.
Simple question. If you have a compiled and published ASP.NET web application running on a server and you need to update, say, a line in one of the codebehind files. Do you shut down the entire site, republish, then load the site back up? Or do you publish straight to your live site with users still using it?
For myself, place an app.offline app_offline.htm file into the site, then overwrite the entire website with the latest published build.
there are a few options when building a site -> one dll for the site or one per page. if u just updated one line in a code behind, and you have chosen the build option for one per page, then you can just copy/paste that new page dll.
i don't like that method personally. I find it simple to app_offline.htm the site.
If it is a single file and a simple site that uses that app_code folder to store the code behinds, I simply xcopy up the new files. If I use http expiration headers I may need to do some better scheduling to make sure things like javascript files and css sheets match the rest of the site that was updated.
For emergency patches:
If its just a codebehind file, I copy the entire /bin/ out and replace all DLL's (mostly out of habit)
If its an aspx, I just copy the aspx.
For actual deployments, I have an automated system that checks out the code from source control, builds a clean release build, takes the site offline, and then robocopies it out to the deployment target. Its a one click process (Thanks CruiseControl!).