Flight of the BryCoBat » Software Engineering

TIL: Calling MSBuild with arguments from PSake

brycobat — Thu, 18 Nov 2010 17:22:20 +0000

If you want to call msbuild with arguments from psake without getting errors like “MSB1008: Only one project can be specified”, you’ll have to do some quoting:

exec {msbuild "/verbosity:quiet" "/p:WarningLevel=4;OutDir=$build\\" "/t:Clean,Build" MySolution.sln }

TIL: Powershell ISE, Text Encoding, and Mercurial.

brycobat — Thu, 18 Nov 2010 17:15:49 +0000

By default, PowerShell ISE uses a 16-bit Unicode text encoding, if you let it create your script. Mercurial, specifically TortoiseHg, says a file is binary if it contains any NUL bytes.

ASCII-compatible text, encoded as UTF-16, or a variant thereof, will contain *plenty* of NUL bytes for Mercurial to find, thus you can’t see diffs for scripts you create with Powershell ISE in your Commit window.

To create UTF-8 versions of your scripts, you can run:

1	gci -recurse -include .ps1,.psm1 \| %{$foo = gc $_; $foo \| out-file -en utf8 $_}

Of course, if you actually *need* UTF-16 characters in your scripts/modules, this would be a Bad Idea.

Other workarounds include using a different text editor to create your script, then edit in Powershell ISE.

Serving Mercurial from Windows, Part 2: Maybe I don’t have to after all…

brycobat — Wed, 09 Jul 2008 16:32:25 +0000

Perhaps this is a bit short-sighted of me, but it looks like we could actually make use of network shares to get to repositories on other machines. A “developers” share is already set up on our machines, and everybody knows how to get to it from project machines. If this is a viable solution, I wouldn’t need anything special to A) serve up a mercurial repo or ten or B) get IT to back it up, since they already take good care of our existing shares. This would totally eliminate the need to install copSSH or LightTPD, or train people on how to use them, or convince IT (both ours and our clients) that “yes, you really do want me to install this extra server.”

I like potential solutions that are actually easier than what we’re doing now.

That leaves the code review cases, where I have a changeset I want someone else to review, but it doesn’t belong in the “central” repo until after it’s passed.

Perhaps if everybody had a share set up as \\MyMachineName\hg that pointed to wherever their local repos were kept, that would simplify finding shares.

Progress! I love it!

Serving Mercurial from Windows, Part 1: Finding LightTPD

brycobat — Wed, 09 Jul 2008 14:39:01 +0000

This may seem simple and/or obvious, but LightTPD for Windows can be had at http://en.wlmp-project.net/.

I’m currently trying just the server package, called “LightTPD for Windows” on the downloads page. They also have a WLMP Webserver Package that has other stuff built in. I don’t think I’ll need MySQL and such, but hey, if I do, it’s out there.

Serving Mercurial from Windows, Part 0

brycobat — Wed, 09 Jul 2008 14:35:10 +0000

Ok, I’ve drunk the distributed source code control kool-aid. I’m convinced. I want it. Unfortunately, for various reasons, if I want to use it at work right now, it has to run on Windows.

That is, I need to be able to *serve* the repositories from Windows. I don’t have the luxury of slapping a Linux box or two in our server room for this purpose (yet), and so I have to be able to do it from Windows.

Mercurial seems to have the best client support on Windows, so that’s the one I’m going to try first. It looks like there’s three ways to serve up a repository:

hg serve

This is only meant for small groups, on controlled networks, and it only handles clone and pull ops. We are a relatively small group, 8-10 people, and the network is controlled. If clone/pull is all most people need to serve up, then this may be the way to go for the 80% case.

hg over SSH

If you have an SSH server, you can do hg over ssh. This means installing Cygwin, which is overkill, I think, or using something like copSSH. I think I’d also have to manually manage users, or get permission from IT to hook in to the domain authentication stuff. That’s theoretically possible, but wouldn’t be easy for them or me.

hg over HTTP using CGI

If you have a web server, you can use that instead. There’s Apache, LightTPD, and IIS. I haven’t seen any success stories for hg on IIS, and I’m not really in this to break new ground if I don’t have to, so that leaves Apache and LightTPD. Of those two, I’m going to try LightTPD first, it’s a smaller install.

Not everybody will need push support, of course. I may be able to get away with only setting this up on a few key machines, and letting everybody else just do hg serve. They would still be able to pull changes from other repositories, and with hg serve we could pull changes from theirs. This would support the KernelPractice style, which is where I’d like to be when this is set up and working.

(edit: removed a trailing sentence fragment, what I get for not proofreading…)

Modifying app.config from nant using

brycobat — Thu, 28 Feb 2008 23:14:35 +0000

If you’re trying to modify app.config files for a .Net app from a nant build script using the task, the namespace you need to use switches part-way through. If you’ve set prefix “x” as “urn:schemas-microsoft-com:asm.v1″ in the namespaces, then a full path for assembly redirection may include the following:

/configuration/runtime/x:assemblyBinding/x:dependentAssembly/…

Note the lack of x’s on configuration and runtime, yet their presence on assemblyBinding (and all child nodes).

I feel both silly and outraged. Silly because I probably should’ve caught this sooner than I did. Outraged because it’s not mentioned anywhere, and the examples given for don’t go deep enough to uncover this particular xml-newbie gotcha.

*sigh*