Urchin is great, but we had to hack it up a bit, so I just bashed out a quick test harness.
I'll look at generalizing our changes (a lot of them are TeamCity-specific) and we can try to reintegrate them into urchin someday
command line help seems to be good. However the parsed option value seems to be incorrect.
This was reported in bug # https://github.com/aspnet/kvm/issues/89
Also find that Kvm-Set-Global-Process-Path is nothing special and it does a subset of what kvm-use does. So removing that and using kvm-use everywhere.
This fix originally started while investigating https://github.com/aspnet/kvm/issues/35. In case of a global install pointing to a .nupkg file, in https://github.com/aspnet/kvm/blob/dev/src/kvm.ps1#L314 we pass in the full path to the nupkg file as a parameter. For example:
while executing command:
kvm install \\projectk-tc\drops\Coherence\dev\Latest\build\KRE-CLR-amd64.1.0.0-rc1-10864.nupkg -g
we pass in \\projectk-tc\drops\Coherence\dev\Latest\build\KRE-CLR-amd64.1.0.0-rc1-10864.nupkg as the parameter value to Kvm-Set-Global-Process-Path. Then the
Then the function computes the name of the KRE incorrectly as `KRE-CLR-x86.\\projectk-tc\drops\Coherence\dev\Latest\build\KRE-CLR-amd64.1.0.0-rc1-10864.nupkg` in line https://github.com/aspnet/kvm/blob/dev/src/kvm.ps1#L490 resulting in a failure as listed in the bug even though kvm install is successful as it cannot find such a KRE\bin folder.
The fix is to pass in the KRE name instead of the full path in case of global installs. And removing Kvm-Set-Global-Process-Path which does exactly the same as kvm-use and performs subset.
anurse
Pranav K
anurse
Praburaj