.Net Web Application and compile/deployment

I took over a web application project that reference dlls. The solution has the actual proje开发者_如何学Pythonct as well as the class libraries used to create the DLL. I need to make changes to the web application and deploy to production. I'm use to deploying asp.net website as well as classic asp which was very straight forward, Just copy the files.

I need help to understand the compilation and deployment process. Here is some questions: 1) Class library(DLL) changed; do I just compile that class library project and move the Dll only. 2) Web application project changed and the dll stayed the same; what files do I move.

Also, if someone can clarify how DLLs version are handled when deployed. I'm use to the old way of unregistering /registering the DLLs and this is not the case right now. I'm worried about having multiple copies of the DLL on the same box.

Any help or reading reference would be appreciated.

Jamal

When you are manually deploying in that fashion it is very easy to make a mistake (forget to copy a related file). It's happened to me before.

I recommend that you make use of the publish feature in Visual Studio. You can right click on the web app and from the context menu select 'Publish'. I normally publish to a local folder (You could publish to your server directly) and then use an FTP client such as FileZilla to actually deploy ( I've had some issues deploying directly from Visual Studio).

When you upload using FileZilla you can specify how you wish to handle existing file overwrites. I use the option: 'Overwrite if source file newer'. That way deployment is fast (only the files that have changed are depoyed) and safe as we cannot miss a file.

To answer your questions: 1) yes, it is sufficient to deploy the class library but only if it remains binary compatible with the old one (Easy to make mistakes here). 2) You need to deploy the files that changed (dll's, aspx, cshtml, etc...). If the class library dll's have not changed you do not need to redeploy them.

Follow the steps above and you should be fine.

It sounds like you're talking about a precompiled .net application. The app is compiled using Aspnet_compiler.exe, and the new DLLs are copied to the host.

The DLLs don't have to be registered, IIS "knows" what to do with a precompiled .net app. It's pretty much just drop-and-go; not unlike copying the .aspx files directly.

You are able to update a subset of the DLLs (e.g., the class library). There are several modes available that allow you to compile all or part of the application.

When you change a DLL, often times you can just drop it right in assuming you aren't referencing by a specific version number. Generally to be on the safe side, I copy the entire website out again when changing DLLs. Its not strictly necessary, but its probably the easiest method if your website isn't too large.

If you're changing a file that is not deployed in its compiled form (.aspx, .aspx.cs, .cs files in the App_Code folder) you can just update that specific file and restart IIS for good measure.

Generally speaking, if a dependent assembly changed you can just deploy the new assembly. However, if ANY of the interfaces to that assembly changed OR there are other corresponding changes to the web application then you'll have to deploy the whole thing.

That said, I've seen shops that require a full recompile, deployment, and testing even if just one line of code inside a dependent assembly changed.

The full deployment part is pretty easy.

1. Right click on the web project and click Publish.
2. Publish either directly to the web server (I don't recommend this) or publish it to a local directory.
3. Make any config changes necessary for the production push.
4. If you publish to a local directory, copy the compiled files to your production server.

Some people say to delete the production files first, then copy. Others say copy to a new directory and repoint IIS to the new directory. You'll have to see what works for you.

Now, one thing web apps give you is config transformations. This means that you can let the compiler make config changes depending on the environment you are publishing to. I highly recommend you research and use these. It makes bad pushes much less likely.