I may have to support .NET deployment in the near future. I need to be able to talk with the people who are developing this application and be able to evaluate if they have some sense of best practices for deployment, or if, as I suspect, their processes are kludgy and they are just muddling through.
This is a problem for me because I’m a Java developer and I don’t speak .NET. So I don’t have an understanding of what the best practices should be.
So, to put it into a perspective that I can relate to, I would like to know what is the same and what is different about deploying Java and Java EE web applications vs. deploying .NET applications?
When I deploy fairly basic Java application to the web, I usually have an automated process that gets the code from source control, runs an ANT or Maven script to generate a .war file, drops that file in a webapps directory, and then Tomcat – or some other application server – inflates the .war file and makes it run.
What would the equivalent process be in .NET? What tools are commonly used? What artifact is created that would be similar in purpose to a .war file? What are the bad practices that are common, but should be avoided?
Assemblies in .Net are the highest level “package” it knows about. They are roughly equivalent to .jar files in Java. There are systems on top of assemblies (like Web Deploy packages), but those are used by higher level tools and addons – they are not core concepts of .Net.
Instead of Ant, we have MsBuild.
Visual Studio Solutions are combinations of Visual Studio Projects, and Visual Studio Projects are MsBuild scripts. You can build either of them with Visual Studio, or MsBuild.
Assemblies are compiled for you by the compiler. You use a MsBuild script to specify which files get compiled into the assembly, and to specify which other assemblies get referenced.
.Net assemblies can see assemblies in the GAC (Global Assembly Cache – this is system wide) and assemblies in the same directory. There are no magic library directories that get loaded up like there are from a Java WAR.
On the .Net side, IIS is both the web server and the application server.
It has a thing called application pools which run under a specific user, and load a specific version of the .Net Framework. You can apply these at a “site” level or “application” level.
In IIS, you have “sites” (sometimes just “Default Web Site”), and you create a “virtual directory” under that site. Then you can “mark it as an application”. You bind virtual directories to real file system directories and you can simply drop the files you are deploying into that directory.
See: Understanding Sites, Applications, and Virtual Directories on IIS
There is no deploy directory in IIS like there is Java application servers. You drop your pages and assemblies straight into the directory it is served from.
But there is a directory structure for web sites. Projects you’ve built in Visual Studio are already set up to match that hierarchy, so you can simply grab the whole project folder and throw it in IIS.
If you want to do something a bit more automated, look into Web Deploy.