During my previous projects, any change that I would make to an aspx.cs didnt require building the entire solution. The changes would directly reflect in my IIS hosted server i.e in localhost.
the new web application has the same setup configured. The application has been added in IIS with a designated Application pool and when browsed the site opens. But in this project, I have to build the solution everytime I make change in aspx.cs page. The same doesn't apply to aspx changes.
Any help would be appreciated in letting know this difference in behaviour and solution of not building the entire solution if possible.
Thanks
I already have one existing website project which is in production. Now i want to have another different functionality with set of new pages. So i want to keep another web application project and refer the same in my existing website.
Button click in my website will call my webpage in seperate web application project.
Am not using M.V.C
Is this possible? Can i host my newly creating web application along with my website?
I have tried to call webpage from website to my web application. It is working. But is this the correct way?
what is the best way?
You can point your new domain to previously hosted website. Also you can use url rewriting to show whatever url you need to display to user.
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
I'm developing a Web application, and there is a page when user must submit files which are saved into temporary folder on the server. If everything goes well, I send ajax request to the server to remove users uploaded file. But, if user closes the browser or shutdown the computer, I can't detect that.
In this case, what is the best way to gurantee that unused files are not stored forever? The site is developed in ASP.NET MVC and will be hosted on II7. Does IIS7 provides some configuration to deal with temporary files? Or I need to implement some service, which will be executed in a background with low priority and periodically check if there are "old" files to be removed?
Any help is very much appreciated.
I would have a windows service in the background to delete old files at some interval.
I am trying to get a grasp on how to handle updates to a live, functioning ASP.NET (2.0 or greater) Application while there are users on the site.
For example, suppose SO is an ASP.NET Web Application project. The project code compiles down to the single .DLL in the BIN folder. Now, there are constantly users on SO, so what would happen to users' actions/sessions if you would use the Visual Studio .NET "Publish" feature (or just FTP everything again manually) while they are using the site?
Would creating an ASP.NET Web Site, instead, alleviate any problems that may or may not exist with the scenario above? I am beginning to develop a web site as a user-driven Web Application, and I want to make sure that my inexperience with this would not potentially annoy the [potentially] many users that I [want to] have 24/7.
EDIT: Sorry, I should have put this in a more exact context. Assume that this site is being hosted by a web hosting service with monthly fees. I won't be managing the server itself, just what the web host allows as a user of their services.
I create two Web sites in IIS. One is the production Web site, and the other is a static Web site with an HttpHandler that sends all requests to a single static "We're updating" HTML page served with an HTTP 503 Service Unavailable. Typically the update Web site is turned off. When it's time to update, we stop the production Web site, start the update Web site, and now we can fiddle with the production Web site all we want without worrying about DLLs being locked or worker processes needing to be spun down.
I started doing this because
App_Offline.htm really does not work well in Web Gardens, which we use.
App_Offline.htm serves its page as 404, which is bad if you're down for a meaningful period of time.
We can start the upgraded production Web site with modified settings (only listening on localhost), where we can do a last-minute acceptance/verification that everything is working before we flip the switch, turning off the update Web site and re-enabling the production Web site.
Things this does not solve include
Any maintenance that requires a restart of the server--you still have downtime where no page is served.
Any maintenance that diddles with the .NET runtime, like upgrading to the latest service pack.
Other approaches I've seen include
Having two servers. Send all load balancing requests to one server, upgrade the other one; then rinse and repeat. Most of us don't have this luxury.
Creating multiple bin directories, like bin-1.0.0.0 and bin-1.1.0.0 and telling ASP.NET which bin directory to use in the web.config file. (One advantage of this is that reverting to a previous binary is just editing a config file. A disadvantage is that it's harder to revert resources that don't end up in your binaries, like templates and images and such.) I don't remember how this actually worked--I think the application did some late assembly loading in its Global.asax based on its own web.config section (since you touched the web.config, the app had restarted, so it was okay).
If you find a better way, let me know!
Changing to the asp.net web site model won't have any effect, as the recycle will also happen, some of changes that trigger it for sure: web.config, global.asax, app_code.
After the recycle, user will still be logged in because asp.net will just validate the syntax. That is given you use a fixed machine key, otherwise it will change on each recycle. This is something you want to do anyway as other stuff can break if the key change across requests i.e. viewstate validation, embedded resources (decryption of the url fails).
If you can put the session out of process, like in sql server, you will avoid loosing the session. If you can't, your code will have to consider that. There are plenty of scenarios where you can avoid using session, and others were you can wrap it and re-retrieve the info if the session was cleaned. This should leave you with a handful specific cases that you know can give trouble to the users, so for those you do some of the suggestions others have already made.
One solution could be to deploy your application into a load balanced environment (web farm).
When deploying a new version you would use the load balancer to redirect requests to the server you are not deploying to.
App_offline.htm is great solution for this I think.
in SO we see application currently unavailable page when a deployment begins.
I am not sure how SO handles it.. But we usually put a holding page. So what ever the user has done (adding question or answering questions) does not get updated. As soon as he updates something he will see a holding page asking him to try after sometime.
And if I am the user I usually press the back button to make sure what I entered is saved in the browser history so that I can post later.
Some site use use are in clustered environment so I take one server offline and inform the load balancer that she will not be available and once I make sure that the new version is working fine I make it live.. I do the same thing for the next server.
Do we have any other option?
It is not a technical solution, but set up a scheduled maintenance window. You can annoucement in advance giving your user base fair warning that there is a possiblity that the application will not be available during that time frame.