Deploying ASP.net Applications and Constant Rebuilding

Question

I don't know very much about proper project deployment besides copy my entire project to the live server, folder by folder, file by file.

I have found that the application does run exactly as expected on the live server as in local machine development.

However, I also found that I have to rebuild the project locally, then upload the new project library to the live server when I do any of the following, or else, I get an error.

1. Add or edit any .aspx.cs file.
2. Add or edit any .cs file in /App_Code, /App_Start, /Controllers, Global.asax.cs, any *.cs anywhere.
3. Add or update (into the live server's /bin) any .dll that my app depends on.

I remember never having to do this back in ASP.net 4.0 and earlier. I simply uploaded new and updated .cs and .dll files, loaded the page, wait for it to recompile automatically, and I'm good to go.

Maybe there's a new setting, either in web.config or IIS that must be turned on or off that I don't know. Maybe it's a new .net feature that discourages anybody in the team to just change things without telling everybody else?

I personally don't mind rebuilding as long as we do it periodically, but not as often as every single time we change one line of code.

So, is it possible to just upload new/updated .dlls and .cs files without rebuilding the entire application from VS?

Answer 1

While this isn't a direct answer to the question you're asking, I hope it'll solve your problem better than the way you were trying to...

You wrote...

I don't know very much about proper project deployment besides copy my entire project to the live server, folder by folder, file by file.

... so, sounds like this is the perfect opportunity to learn! Once you get build/deployment automation, your life will become all kinds of easier -- it's almost like getting glasses and learning "hey, the whole world isn't blurry!"

So, is it possible to just upload new/updated .dlls and .cs files without rebuilding the entire application from VS?

Once you have deployment automation, this concern becomes moot.

My experience is of course with BuildMaster (as I work for Inedo), but I can say it's a great way to get started, since you don't need to learn scripts or anything like that -- there's a good wealth of help and tutorials, and you can probably get everything working to production in a couple hours.