Scripting for .NET Deployment
I am exploring various options for deploying a .NET application package. Deployment is more than just copying files, we need to stop / start services, invoke an EXE file that runs database scripts, initiate multiple installations setup.exe
, etc.
These scripts will be outsourced to third party developers who will apply various application updates to our various client servers.
The two best options look like CS-Script and PowerShell , but I'll let the vote decide.
UPDATE: Based on the answers so far, I feel I should clarify. First, the people applying the updates will be sysadmin types; not end users. So, in this case, a full blown WiX installer , Wise , etc. is probably overkill.
Second, it's safe to assume that .NET 2.0 and even PowerShell (or CS-Script or whatever) will be installed on these machines. We create images so we can specify what will be installed. The problem is that when we resolve the image, outside of the application updates we will write scripts, it will be very difficult to install "new" applications.
source to share
Comparing CS-Script and PowerShell, here are some of the advantages of CS-Script over PowerShell:
- CS-Script is lighter and easier to deploy. http://www.csscript.net/help/Deployment.html says "Distribute the script engine executable (cscs.exe / csws.exe) along with the script itself.
- C # is a widely used language with an easily available debugger. PowerShell is another language to learn.
- C # can be compiled
source to share
It really depends on what you are comfortable with and how the end user will use it. All scripting languages will let you do what you want. You can even use a simple batch script to accomplish this.
If end users will be involved and they don't need to be sysadmins, I would suggest going with the full installer. Thus, they graphically described what was being done. If it's for sysadmins or just for your own use, what scripting language allows you to do this first, even if it's VBS.
source to share
The downside to using PowerShell as the environment for your deployment scripts is that you have to ensure that the target computers have .NET Framework 2.0 and PowerShell. You will need a script to do this and hence you will be back to your original question minus PowerShell.
I like PowerShell as a scripting environment. It's easy to use, flexible and can handle deployment scenarios with ease. Also, since it runs on .NET and you are deploying .NET, there is less overhead for internal people to look at and debug the script.
Personally, I would take a hit to have a bootable script file that provides PowerShell installation and then use PowerShell as the actual deployment script.
source to share
It sounds like you want to create a wrapper package for installing and configuring a number of other things ...
As a former Windows setup developer, I can highly recommend NSIS for an easy-to-create and completely script-driven installation process. There are many plugins available for NSIS that will allow you to start external programs, start and stop services, print command line output, and basically do whatever you can imagine in your scripting language.
Link for NSIS: http://nsis.sourceforge.net/Main_Page
source to share
We have used different approaches. In the end, works well for us:
- Normal executables with good command line handling.
- Scripting libraries (F #, IronPython, CS-Script) for operations.
- msbuild (calling exexcutables, sometimes custom tasks, sometimes scripts)
Speculative: Consider using MS Deploy (on RC1). It does most of what you need to do. I am currently evaluating.
What doesn't work well: A jumble of above + batch files. Over time, everything will move into executables and installation libraries as this is a technology that can handle all tasks and scale. Mandatory UI steps are evil and forced manual installation.
CS-Script and Powershell have disadvantages. CS-Script - awkward assembly reference schemes. Powershell: Few people can look at this. Do a proof of concept in each one before you go with them - maybe you will like them better than me. My experience is easy for them - after the proof of concept, I disabled IronPython.
source to share