Best Practices for ASP.NET Web Site Hosting
I have looked through the related questions and none of them have provided me with the information I am looking for.
Currently, the team I am working on is deploying separate .aspx (and .aspx.vb) files for bug fixes / improvements. I am trying to influence the changes, as I do find that deploying "whole compiled site" is less error prone. Since this is a significant change from how everything was done, my proposals met with considerable resistance.
Since my google-fu hasn't been around lately, I was hoping that the SO community could either tell me that I left my rocker and that there is nothing wrong with moving individual files or actually point me to good resources that would allow me to make a stronger case.
Edit:
This was all great information and reinforces the arguments I already made, can anyone argue the other side?
source to share
For me personally, rollback is the most important one right away. Once again, website designs are very heavy when it comes to tracking changes.
you can find a good detailed comparison here . I will reproduce the article here.
1) Deployment. If you need on-site deployment, this model is ideal. However, this is not recommended as you are exposing your logic to clear text. This way, anyone with access to the physical server can mess up your code without you ever realizing it. You can try to make a precompiled website, but you will end up with a lot of DLLs and almost untouchable aspx files. Microsoft has recognized this limitation and released the Project Web Deployment Project tool.
2) You need to keep track of what you have changed locally and what you have uploaded to the production server. No version control. Visual Studio has a Web Copy tool, but this tool doesn't help. I had to create my own tool that tracked changes based on Visual Source Safe.
3) When you press F5 to debug, it only takes 2 minutes to compile and execute the whole project. You can of course attach a debugger to an existing thread, but this is not an obvious solution.
4) If you ever try to create controls on the fly, you get the first unresolved constraint. How to link to other pages and controls. Page and check compilation takes place in each directory. At best, you are going to build an assembly for each directory, at worst, each page or control will have its own assembly. If you need to refer to another page from a control, or to another page, you need to explicitly import it using the @Reference directive.
So for <
customControl = this.LoadControl ("~ / Controls / CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all the relevant @Reference directives? Or What if you are creating a server control and it doesn't have an ascx file, so you don't have a place for @Reference? Since each control has its own assembly, it is almost impossible to do reflection.
Web Application Projects that reappeared in Visual Studio 2005 Service Pack 1 (SP1). They solve all the problems mentioned above.
1) Deployment. You only get one DLL per project. You can create redistributable packages and reusable assemblies. You can have scripts for versioning and building.
2) If you change the code after the change, you can only load one DLL. If you have changed aspx, you can only load the change aspx.
3) Execution takes 2-3 seconds.
4) The whole project is in one assembly, which helps to reference any page or control. Output. For any serious work, you should use web application projects. Special thanks to Rick Strall for his awesome article "Compiling and Deploying with ASP.NET 2.0".
source to share
Deploying separate files for bug fixes and deployment is not a smart strategy. It sounds like you need a comprehensive build and deployment process. This does not mean that it should be difficult, as there are good tools nowadays.
Build and deployment can be granular, so for a minimal start, try taking a look at the Microsoft Web Deployment Tool ( http://www.iis.net/extensions/WebDeploymentTool ) Install the tool on your build server and install it on your deployment server. Build your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to sync the entire package to the deployment server. I like this approach because it can be completely automated. When building and deploying, aim for full automation to reduce potential errors.
This is the minimum, but at least you can be sure that when certain files change, they ALL sync up on the deployment server.
source to share
I agree with Rich.
Additional Information:
-
Deploying your SOURCE ala.vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy direct source. Imagine an attacker gaining access to the system. They can easily change your code, and you may never notice it. Yes, you can use a tool like reflector to decompile. But it is very difficult to decompile the complete site, make the changes you want, and put them back into production.
-
Deploying a single file can very much cause the cause of the problem in the linked module. I'm assuming you guys don't really do QA. Tell them it's time to grow up.
-
Compiling your site will reduce JIT compilation (just in time). Think about performance.
-
I will also assume that almost everyone has access to the production server. This is bad from a company standpoint because you have no control. What happens when an employee decides to cause some havoc before leaving?
-
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue, but this style often blows everything up.
source to share
This is bad for rolling back. If you are deploying a website or web application, yes, you can do one or two quick fixes, but what if you ever need to revert to a previous version? Good luck keeping track of all the files that have been updated to make the new version. I prefer the "version" concept for organizational reasons, and the compiled web application is much more in line with this than the "website" project.
source to share
We had this dilemma and ended up with a compiled version mainly for security reasons. If your site is an external entity, you can compromise your security by allowing vb files in cleartext. I understand that it is still possible to get the code if they really want to, but that will be an additional hurdle they will have to go through. If you are using Visual Studio as your development environment, you can publish a pre-compiled site and check the publishing of named assemblies when publishing, and this will essentially create a dll for each aspx page so that one page can be modified if needed. This was a great feature that we found as we were constantly updating the entire site and there were times when something was updated that shouldn't.After using this feature, we didn't have any more pushed updates that shouldn't. As far as rollback is concerned, I hope you are using some type of source / version control system. Team Foundation Server is great for source / source control, but it's quite expensive.
source to share
What is the best deployment strategy depends a lot on what environment you work in and what developers you work with.
Visual artists who started with graphic layout and worked on programming are much more fine-tuned to create and release individual pages. Also .aspx.vb files are just server side scripts, not programming.
Programmers typically run on the command line and fork in environments like the Internet, and understandably believe that good programming practices should be applied on the Internet as well, including the standard test and release cycles (and compiled code).
If the site is in constant flux, the individual pages will make more sense, but if you need to provide an installation package to your production team then msi files are the way to go as they can be easily reversed if needed.
If you value what your groups need, including the diverse experiences of everyone in your group, you should be able to convince yourself or the group. It is not a question of which is better, but which provides the best business model.
source to share