LocalCommandLineTask uses WorkingDirectory instead of ExecutableIsLocatedAt

[miensol]

LocalCommandLineTask used WorkingDirectory to build ProcessStartInfo.FileName to be executed. I believe the ExecutableIsLocatedAt should be used instead.

[ferventcoder]

We'll take a look and let you know. Thanks!

[drusellers]

@miensol can you give me the story behind this change. It would break a lot of existing deployments that already use this behavior and I would like to not just break peoples deployments just because. Totally open to the idea, just want to hear the reasoning. :)

[miensol]

I was automating deployment of some legacy Windows service (not build with Topshelf). CommandLine option with InstallUtil.exe looked like a natural choice for this. InstallUtil.exe is of course located at .net framework installation directory (which is not part of PATH system variable). The install step look like this:

  s.CommandLine("InstallUtil")
    .ExecutableIsLocatedAt(@"c:\Windows\Microsoft.NET\Framework\v4.0.30319\")
    .Args(@"c:\path\to\legacy\service.exe");

The step failed during local deployment because it could not find InstallUtil. Then I looked through LocalCommandLineTask which has this reasonable behavior of deriving ExecutableIsLocatedAt from WorkingDirectory. This works great if the executable is at WorkingDirectory or at one of directories in PATH. However if one specified the executable location explicitly, like I did, it had no effect. What's more, a verify run apparently looks for the .exe in the ExecutableIsLocatedAt giving some false positives. I hope the test that I've written, named badly though, exposes this behavior.

[drusellers]

this has been merged in 8c32217 - i needed to rebase it so it didn't auto close