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.
Related
I've inherited an ASP.NET project that uses a single Default.aspx file in the public_html root to do most of the work.
The changes I'm making are minor, but I can't seem to get them to stick. If I edit the Default.aspx file, the server will still serve the old version. Creating a new .aspx file will initially compile it and run it, but then it's stuck in its "original request" form.
I thought .aspx files were subject to "dynamic recompilation" if they were changed, but this isn't triggered in my case. I've tried updating the Web.config file but is has no effect.
I'm not using Visual Studio for this, yet. I'd like to be able to just edit and update the files, if possible (the changes are very minor and I don't have ready access to a Windows machine). The only access I have to the server is through FTP.
Seems the issue was with my host, who aggressively cache stuff. I have to do a "restart" from inside their control panel to have the changes reflected.
The host is Loopia.se, in case anyone else is using them. Use "Omstart av ASP.NET-applikationer" from inside the Customer Zone to restart things.
(Yes, I do feel kind of silly now)
If the site has previously been 'published' in visual studio as pre-compiled and not-updatable, then changing the aspx files will result in no change:
http://msdn.microsoft.com/en-us/library/1y1404zt(v=vs.80).aspx
In this case everything will have been pre-compiled into DLL's, and the aspx pages are just there as hooks for the .net runtime.
I've been trying to publish my Visual Studio 2010 project. I do this by accessing a hard drive which corresponds to a URL, so X:\Options\Forms\HD\ corresponds to /HD. Yet when I go to the URL, it says I don't have a default.aspx page. Yet when I look in the corresponding file directory the default.aspx page is right there. Why is the browser ignoring it? Another issue I have is that not all of the files are getting published when I select the option in Visual Studio; many are left behind including my default.aspx.vb file.
To make sure files get published, make sure that they have the correct Build Action set (check the Properties window for the file). Especially, if it is set to None or if the files are not part of the solution/project they won't get published. The "Content" build action is a good choice for any file that just needs to be published.
Extra tip: for files that VS doesn't know the default build action is None. You can however configure VS to use whatever build action you want.
I've written about it here: http://blog.andreloker.de/post/2010/07/02/Visual-Studio-default-build-action-for-non-default-file-types.aspx
Also, I've created a simple tool that generates the necessary configuration file: http://tools.andreloker.de/dbag
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.
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?
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!).