views:

934

answers:

8

I package our server releases into zip files using a batch file (Windows), running the command-line version of WinZip. Previously we did this sort of thing "by hand" but I developed the process of automating it with a batch file.

The batch file has become quite complicated because our product is complicated (i.e., Which sections are we releasing this time? Are we releasing the config files as well?) and I'm starting to run into some frustrating limitations with batch files.

Would PowerShell be a good thing to investigate as an "upgrade" to the batch file? Or is that complete overkill given that most of what it would be doing is firing off DOS commands?

Bonus: can PowerShell consume .NET assemblies? As in, could I start doing the zipping with SharpZip?

+1  A: 

I'm not sure about powershell, but might I recommend using something like IronPython (if you want to have access to the .NET libraries) or plain python? You get a full-blown programming language with very few limitations.

jimka
I share your reservations considering powershell. I played with it. It seems that most of it's power comes from being able to interoperate with .Net API's but it doesn't have many facilities for structuring complex scripts. Python or Ruby dialects are better for that.
Mendelt
Despite my distaste for PS syntax, I eventually abandoned IronPython for Powershell. Unlike python, IronPython does not yet have the "batteries included". Especially with server 2008 R2 and PS 2 - everything MS works with Powershell and smoothly. If your are a mixed shop - there is more of an argument for IronPython or Python. Complex constructs and scripts are not a problem for Powershell.
Precipitous
+10  A: 

If you have a working solution, then you don't need to go to powershell. Having said that, if you plan to make changes or improve the process then I would highly recommend powershell as the way to go. Powershell can access .Net assemblies...mostly. Some assemblies are structured in a way that makes it more difficult than others.

You can check here for some resources if you decide to look at powershell.

EBGreen
I agree. If you're going to enhance the scripts, powershell is a very good way to go.You might also want to know that with the powershell community extensions you get cmdlets that handle outputting to zip files (so you don't need to worry about SharpZip).
Mike Shepard
+2  A: 

The answer is YES - PowerShell can use .NET assemblies. There is a bit of funny business involved in v1 if you need to wire up delegates and v2 makes that much more clean.

Just call LoadFile / LoadAssembly to get the appropriate libraries in memory and away you go

[Reflection.Assembly]::LoadFile('/path/to/sharpzip.dll')
$zip = new-object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.CreateZip('C:\Sample.zip', 'C:\BuildFiles\', 'true', '^au')
# note - I didn't actually test this code 
# I don't have SharpZip downloaded - just read their reference.

Also note that the PowerShell Community Extensions support various compression methods like write-zip.

Goyuix
+1  A: 

Take a look at PowerShell Community Extensions (PSCX), its FREE and it has Zip cmdlets:

Write-Zip

Write-BZip2

Write-GZip

http://www.codeplex.com/PowerShellCX

Shay Levy
+1  A: 

I've tried to replace one of lengthy the batch files I use with power shell. I found it a pain: at least at that time, documentation focused on the funny verbiage and what cool, perly things you can do with it, but lacked in the "getting simple things done" category. I got it working, but the error handling was to shaky - my policy was that"anything funny" should abort the build and print diagnostic messages.

YMMV, try powershell, you might enjoy it. But try it before updating your build batches.

My solution: use a C# console application. I've got serious logging, exception handling, can use my utility functions, and if something doesn't work I have a real debugger. It#s the first solution I like to modify.

peterchen
A: 

On the one hand, if it works, just leave it. But it sounds like this is something you'll be adding to over time, and of course your eventual successor/coworker who needs to edit the batch file will also need to understand it. If you're from a programming background then you may well find the power of Powershell makes your script a lot shorter and easier to read/maintain (for example, even just having full if statements and for/while loops). On the other hand if you're not overly familiar with programming, a lot of people find Powershell a bit daunting at first glance.

Regarding the .NET part, Powershell is built on top of .NET so yes, you can access .NET assemblies (but you should always see if there's a cmdlet available first).

I would recommend a book called "The Powershell Cookbook" by Lee Holmes, published by O'Reilly. It provides "recipes" which you can use for common tasks; this will probably speed up your time to implement the script, and it'll teach you Powershell along the way.

Saqib
A: 

Initially I was really excited about PowerShell. Finally a powerful native shell on Windows. However, I quickly realized that compared to your favorite unix shell PowerShell is just way too verbose. Even doing simple stuff takes way too much typing compared to what you can do with bash and GNU tools for Win32.

I like the idea, that the shell knows about different types, but if I need to do that much additional work, I prefer just getting the necessary data with the various unix stream editors.

Brian Rasmussen
+2  A: 

You should watch this presentation/discussion with Jeffrey Snover, PowerShell creator and architect. If you're not amazed by the technical details (lots of "wow" moments to be had), you'll be amazed by Jeffrey's enthusiasm :). Once you get the basics, it's easy to be very productive with PowerShell.

Bergius