ASP.NET WebSite Publishing vs. Copying?

Question

I have faced a lot of issues with Publishing like when you need to make small changes on the code, sometimes the generated DLL file (the dll file for example of default.aspx.CS when published) cannot be recognized by IIS saying the codebehind is wrong or something. Sorry for not remembering the exact error message. I am hoping you know what I mean at this point.

Therefore, I usually do a simple Copy Paste operation instead of Publishing.

Could you tell me what am I missing by NOT using the Publish method? How is Publishing better? Or which one do you prefer, why?

Basically its a pros and cons situation.

Thankyou

Hemihedral

Publishing is also effected by the type of application you choose to deploy; a Web Site application allows you to just publish a few files, vs the Web Application where you usually need to deploy the ASPX and the appropriate DLL to the correct folders. Read #398537 for more info. – Indicator

Thank you for the comment. But this doesn't help me exactly. For example, is there any performence difference ? Perhaps, it can be summerized as "Do web Application instead of publishing a web-site" – Hemihedral

Answer 1

Well, it depends on what you mean by "copy":

With Publishing you have options to pre-compile all or part of your application. You can publish to a local folder in your file system (instead of your target/host) and then copy the updated file(s) (only). If you are making "code behind" (c#/vb code) changes, this means you'll likely only need to "copy"/overwrite dlls. Goes without saying that if you've made "content" changes (html/razor/script/etc) changes, then you'd need to copy/overwrite those as well.

If you're new to deployment, you may find yourself simply copying/overwriting "everything" which is the safest way to go. Once you get more experience, you'll "recognize" which assets you only need to update (one or a few dlls and or content code, instead of "everything"). There's no magic to this, usually, its a matter of just looking at the timestamp of the dll/file after you've published (locally) or rebuild your web application.

I'd recommend doing a local publish so you can see what is actually needed on your server. The files published to your local file system/folder is what needs to be on your host/server. Doing so will visualize and remove whatever "mystery" there is to Publishing:

• you'll see what is actually needed (on your server) vs. what's not
• you'll see the file timesstamps which will help you recognize what files were actually changed vs those that weren't (and therefore don't need to be updated).
• once you get the hang of it, you will not need to "copy"/ftp "everything" and just update files that were actually modified (only).

So "copy" can mean the above, or if you are saying you will simply copy all of your development code (raw (vb/cs)html/cs/vb) to your host, then that means your site will be dynamically compiled as each resource is needed/requested (nothing is pre-compiled). Also "easy" but you do lose pre-compilation which means there is a delay when each of your web pages are requested/needed (ASP.net needs to dynamically compile). Additionally, you are also exposing your source code on the server. It may not mean much depending on your situation, but it is one more thing to consider.

Here's more info on pre-compilation and options.

Equivalent

your answer is a very detailed answer, which tells me that you understand clearly the deployment process. However, there is one thing I want to clarify: I think it is nice to know which file is actually needed to be updated; however, when my team update a website, I would update the whole site, not just replacing some DLLs... That way works, but is susceptible to human-error. I'd prefer upload the whole tested application to IIS, unzip it, then point IIS to the new folder. How do you think? – Agnesagnese

@HoàngLong IMHO, that is just like "ftp everything". Ftp everything would be less prone to other issues - e.g. application permissions on those new folders, web farm/replication issues, etc. Also, that approach seems only possible/feasible if you have direct/bare metal access to the server. Another approach is WebDeploy which does things in a "smart way" for you (figures out changes for you) . If it's available to you, that's something worth looking into. – Equivalent

yes, it is almost like "ftp everything" (except that it will not have redundant files, since the whole web application folder is replaced). WebDeploy seems to be an interesting choice though... I will play with it – Agnesagnese

FYI, I do more about Java Web Application before switching to Microsoft stack. In my old "way of work", the one-package deployment is preferred: the whole web app is put into one WAR file, just put it in the folder and you're done. The WAR files are easy to version and kept track. In case some error happen after deployment, the website could be easily reverted by replacing the WAR files. Just to give some background for my novice question :) – Agnesagnese

@HoàngLong Understood - whatever works/makes sense :) Did something similar in the past. "Package" sites into versioned msi. So, just like any software "update" (uninstall old version/install new version). If it became necessary to roll back, it's a matter of "reinstalling" a previous version. – Equivalent

Answer 2

Assuming we consider an aspx page and its aspx.cs code behind file, there are three alternative ways of deploying your site:

1. You can copy both to iis. The aspx will be compiled to .cs upon the first request and then both .cses will be compiled to a temp .dll
2. You can "publish" to iis, this will compile the code behind class to .dll but will copy the aspx untouched. The aspx will be translated to .cs and then to .dll upon the first request
3. You can "publish" the site and then manually precompile it with the aspnet_compiler. Publishing will compile the code behind to .dll as previously but then precompilation will clear out your .aspx files by removing their content and moving the compiled code to yet another .dll.

All three models have their pros and cons.

First one is the easiest to update incrementally but in the same time is the most open to unwanted modifications.

Second is also easy, can be invoked from vs, it closes the possibility of some unwanted modifications at the server but .aspxses still need time to compile upon the first request

Third takes the time and some manual actions but prevents any changes and also speeds up the warm up of the site as the compilation of assets is not necessary. It is great for shared environments.

Ainsley