James Kovacs' Weblog

A few announcements… First the big one. Many people have been using psake – both the PowerShell 1.0- and 2.0-compatible versions – in production without any significant issues. For that reason, we have released psake v1.00 (compatible with PowerShell 1.0). The only difference between psake v1.00 and psake v0.23 is the version number. My friend, Ayende, has a great example of converting Rhino Mocks build to use psake.

http://psake.googlecode.com/files/psake-v1.00.zip

We have released psake v2.01 (compatible with PowerShell 2.0). (This was formerly called psake v0.24, “Jorge”, and psake-ps2.) A big thanks to Jorge Matos for all his work on psake v2.01.

http://psake.googlecode.com/files/psake-v2.01.zip

A few minor changes… The source code for psake has been moved to GitHub and the SVN repository at Google Code has been retired. We will still be using Google Code for bug tracking, wiki pages, etc. If you want the latest source code, you can always download a zip file for master (aka trunk in SVN terms) – or any tags/branches – from:

http://github.com/JamesKovacs/psake

Note that there is no need to install Git to download the latest package as GitHub will create the appropriate zip file on the fly.

If you have some great idea, you can download the git repo from git://github.com/JamesKovacs/psake.git or http://github.com/JamesKovacs/psake.git. (msysgit is the Git package of choice for Windows. You can download it from http://code.google.com/p/msysgit/.) I would encourage you to read Jeremy Skinner’s excellent guide for contributing to MvcContrib via GitHub. Just mentally replace “MvcContrib” with “psake”, though I’d encourage you to contribute to MvcContrib too.

I would like to offer lots of kudos to my collaborators/conspirators on the project. Jorge Matos has been instrumental in updating/improving psake to use the new PowerShell v2 features. Thanks to Shaun Becker for patches and answering newsgroup questions. And thanks to Eric Hexter for his assistance in moderating the psake-users Google Group. I am heartened and thankful for the willing collaboration on this project and am excited to watch it grow. If you have any questions, please do not hesitate to ask.

Going forward, we are retiring psake v1.00 and focusing on psake v2.00. If there is demand for a PowerShell v1-compatible version of psake, we will create a branch based on the v1.00 tag, but we will mostly be focused on the PowerShell v2-compatible version (aka psake v2.00). So your next question probably is…

What’s New in psake v2.01?

(from Jorge Matos)

The main difference is that psake v2.01 has been re-written as a module that contains advanced functions.  Someone using the module could either run the import-module command with the path to the module file (i.e. import-module .\psake.psm1) or (my preference) you can copy the psake.psm1 into a folder called psake into the “Modules” folder in your profile directory (you may have to create it if it’s not there) or your machine-wide “Modules” directory:

i.e. Profile Directory:

C:\Users\Jorge\Documents\WindowsPowerShell\Modules\psake

i.e. Machine-wide Modules folder:

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\psake

Once the psake folder is created and you’ve copied the psake.psm1 file into it – restart PS and type “import-module psake” – PS will find the module and load it automatically.  What I’ve done is add the “Import-Module psake” to my profile script so that it is loaded everytime I startup PS.

Module Benefits:

1. Build scripts don’t need to know where psake is installed, they just call Invoke-psake and it works.
2. Encapsulation… Global variables are no longer required since they can be private to a module unless explicitly exported (I haven’t gotten around to actually changing the psake code to not use global variables yet).
3. Modules can be unloaded if needed which removes all the code and variables from memory.

Advanced Functions:

The other big difference is that the “Invoke-psake” and “Task” functions have been converted into Advanced Functions which basically means you can take advantage of comment help which means you can type help invoke-psake and you will get back real help with examples.

Minor changes:

1. Coding style is different.
2. Try/Catch is used instead of the “Trap” statement.
3. Got rid of the “exec” function.
4. You can now define “Pre” and “Post” actions for a task.
5. You can define how the task name will be formatted.
6. You can define a “TaskSetup” function that will be executed before every task (took that from NUnit).
7. You can define a “TaskTearDown” function that will be executed after every task (took that from NUnit too).
8. Create a global variable called “psake_buildSucceeded” that will be set to true if the build succeeds – scripts can check this.
9. Also added a “$noexit” switch to Run-Psake so that the function will not use the exit() function so that you can test a build script at the command line without PS closing down (the default behavior when the build fails is to call exit(1) so that the calling code can determine if the build failed or not).
10. The psake-buildTester.ps1 had to be changed slightly in order for it to call the Invoke-psake function.
11. Added more examples in the .\examples folder for POST conditions, PRE and POST Actions, etc.

Happy (build) scripting!

As many of you know, I am an independent consultant and use my own laptop when possible. I’ve got all my tools set up the way I like them and everything else that I need to be productive. Given that I work for multiple clients, I can’t join my laptop to any particular client’s domain. First is the hassle factor, especially when switching between different clients within a week. Each domain join requires a domain admin to authorize the join by typing in his/her credentials when prompted on my laptop. Second I don’t want a client’s Group Policy being applied to my laptop. Third – and more importantly – is the non-disclosure agreements that I sign with clients. If I join my laptop to a domain, the domain admins have full rights to my machine and hence data from other clients. So domain joining just isn’t an option.

In most cases, not being joined to a client’s domain doesn’t make one iota of difference. You need to access a network share or printer, browser to it and you will be prompted for domain credentials. The fact that you’re using different domain credentials to access the resource from those that you logged in with doesn’t matter one bit. If you want to expedite the process and not wait for an authentication time-out, you can utilize NET USE from the command line to tell Windows which credentials you want to use when accessing certain computers. You can even make them persistent or roll the whole thing into a batch script that you can execute whenever at a particular client.

net use \\server /user:domain\username /persistent:yes

Unfortunately this doesn’t work in all cases. One of my longstanding development pet peeves has been certain tools – I’m looking at you SQL Server Management Studio and SQL Query Analyzer – that don’t allow you to specify alternate domain credentials for authentication. For example, SQL Server Management Studio allows you to log into a SQL Server instance using Windows Authentication or SQL Server Authentication. If the SQL instance requires Windows Authentication – the recommended configuration – SQL Server Management Studio uses your logged in credentials. This works well if your computer is part of the domain, but fails horribly if not. It doesn’t let you specify alternate credentials or even prompt you for alternate credentials if the log-in fails.

I’ve tried seemingly everything. NET USE doesn’t help here because NET USE is specifically for network shares.

net use \\sql-server-name /user:domain\username # DOES NOT WORK – Only provides the domain credentials when accessing shares

RUNAS also fails – either the SHIFT right-click variety or command line – as it tries to run the command locally as the domain user, who is unknown by your computer because you’re not part of the domain.

runas /user:domain\username “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”

For years (yes, years) I have resorted to using Remote Desktop to log into a domain computer so that I could run SQL Server Management Studio, used a domain-joined virtual machine, or begged co-workers to run commands for me. Now I feel foolish because I stumbled upon a solution that has been built into Windows for years. It is a simple command line switch for the RUNAS command that I never noticed: /netonly. (Note that the /netonly flag is not accessible via the SHIFT right-click menu, only via the command line.)

runas /netonly /user:domain\username “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”

Success! And SQL Server Management Studio running using /netonly domain credentials. The command is run as my local user, but uses the supplied domain credentials only when accessing the network.

I can access remote SQL Servers using Windows Authentication without problem now! (You’ll have to take my word for it or try it yourself as it would be impolite for me to show screenshots of me accessing a client’s SQL Server.) Hopefully this makes some other consultant’s life a little bit easier.