ASP.net dealing issues with production system

Question

First time i am going to work on (maintenance project) application that is already in production.The application was developed in ASP.net 3.5/C# 3.0(web forms) with jQuery,Ajax,Sql server 2005 and microsoft enterprise library 4.0.,WCF services.

Questions (bear with me if my question is wrong)

1) Is it possible to use Visual Studio (2008 with SP1) to debug the remote application (i.e already in production)?.What are the tools do i need to use in order to keep
track the things in case something went wrong?

2) Simply looking into Log file ,will solve the issues?

3) After having done with enhancements,is it possible to directly deploy the DLLs into production server.Won't it affect the running application?

Please guide me what are the procedures i need to follow.Client is ready to provide any tools for my support.(What are the area do i need to aware to handle production system)

Thanks in advance.

Answer 1

1 you should not debug the running application in production, at least not when there are active users online. every time you start the debugger you will restart the application which will cause an exception message to every user which is currently loading a page

I would NOT recommend remote debugging the production site, I'd rather you backed up the databases and restored them to your local machine and set up the site on your own machine and reproduced the bugs locally and debugged there. If the client has sensitive data they don't want you to see then get them to anonymize the data before setting up your DB, 99% of all bugs can be reproduced locally which is a LOT easier to work with. (if you were to deploy a fix directly to production which had a bug in it, very likely if you cannot run it locally, then all hell would probably break loose)

2) it depends, if the application has been coded with good logging setup using for example using Log4Net you can read a good deal out of the log file, just be sure to check the logging level configured. If no logging has been coded then nothing will be written to the application log file.

3) yes, you can xcopy the dlls directly to the production server (you probably want to deploy the .aspx and .ascx files at the same time if there are any changes in those). (there are tools to help you with this, I just can't recall the names at the moment) NB! when you do this the website will reset itself causing errors to any active users, so this should not be done when there are active users online.

I would recommend you reading up on how asp.net works from http://www.asp.net before you go ahead and take over responsibility for a running production site, there are a lot of pitfalls for someone not familiar with the framework, not to mention not familiar with the application code on your particular site.

Answer 2

I think the standard (or close to it), is to have Development, Test, QA and Production environments. Develop and debug in Development. When you are done with your changes bring down a copy of Production to Test. Run the scripts, etc., to change Production into Test. Apply you change packet to Test... and test that the build worked and the changes worked.

Once the changes are solid and done, someone else - not you - migrates them to QA where testing by others is done. As the developer, you shouldn't have any rights to QA or Production. Once the business signs off on the changes in QA then the migrator deploys it Production.

Someone takes care of informing the users that there will be maintenance done and at what time, etc.