Build server error about cyclonedx-dotnet

[stevespringett]

0.3.2 published. Will be available shortly.

[Drewster727]

Interestingly, when I login as the build service user on the build server, and run the command directly, it works...

[Drewster727]

Hmm, so I uninstalled 0.3.1 and installed 0.3.2 -- seems to still happen:

I am executing the app via powershell start-process:

It works outside of the build operation.

Any tips?

[stevespringett]

The path issue seems to be expected behavior. Someone at Microsoft must think that information disclosure in error messages is a good thing.

Regarding execution. I only have the ability to execute from command line. I don't have access to a Windows machine so cannot powershell. It appears to be caught on line 177 which is:

Console.SetCursorPosition(Console.CursorLeft, Console.CursorTop - 1);

Perhaps powershell is doing something weird with the console. Don't know.

[Drewster727]

I also just tried loading cyclonedx-dotnet into the local working directory:

@stevespringett note that I can run this via powershell on a windows machine outside of the build operation without problems. (same script I'm running in the build)

[Drewster727]

@stevespringett https://stackoverflow.com/a/18366631
You may just have to try/catch the cursor manipulation for now... :(

I think it has to do with TFS build operation redirecting output.

Update: confimed my suspicion... when I force redirecting standard output, it blows up on my dev box:
Start-Process -NoNewWindow -Wait -RedirectStandardOutput $true -FilePath "dotnet-cyclonedx.exe" -ArgumentList $bomArgs

[Drewster727]

OK, another update... I got around the problem by totally silencing any output from the tool:
Start-Process -WindowStyle Hidden -Wait -FilePath "dotnet-cyclonedx.exe" -ArgumentList $bomArgs | Out-Null

[stevespringett]

Thanks for the stackoverflow link. I removed the setting of cursor. There were two occurrances of this in the code which have since been removed. I pushed 0.3.3 to NuGet and it should be available shortly.

If you could test this and verify that it works without the workaround, that would be great.

Thanks for your patience and help in getting the dotnet plugin to where it needs to be.

[Drewster727]

@stevespringett confirmed! 0.3.3 resolved the issue. Thank you!