Added capability to use dotnet.exe only without MSBuild.dll

[echalone]

If null or an empty string is provided for msBuildExePath parameter of BuildEnvironment constructor, but a path to dotnet.exe is provided in the dotnetExePath parameter, then this will now work by only calling dotnet.exe without any MSBuild involvement, so this library can then be used with dotnet.exe alone too. We need this functionality now that some of our solutions have been ported to net5/net6 and are built with dotnet.exe and functionalities which are only provided via dotnet.exe.

[daveaglick]

Interesting...at first glance I'm not opposed to this change since it's an opt-in feature by requiring the BuildEnvironment to be created in a certain way, but I'd like to understand the problem it's solving. It's my understanding that MSBuild is shipped with the .NET SDK and is what gets called anyway for dotnet build calls - this just made it explicit so we could specify the exact MSBuild DLL.

I guess what I need help understanding is what this actually changes, functionality-wise. What was the problem you were seeing, what does the executed command-line statement look like with this change, and how does that alternate statement correct the problem?

[echalone]

Yes, sure :)
So the thing is, if you define the MSBuild.dll and use the dotnet.exe that way you seem to not be able to use dotnet.exe only features, like publish. If I try to call the Build method and define parameters like "publish -c release --runtime win-x64 --self-contained false" in the BuildEnvironments it just gets stuck and doesn't return from the Build method. Or if it does build (thanks to other parameters like building only without publish) it has the wrong TargetDir values ("\bin\Release\net5.0-windows" instead of "\bin\Release\net5.0-windows\win-x64").
That all is fixed if one can call dotnet.exe without defining a MSBuild.dll

[daveaglick]

Ah, that makes sense (I think). The dotnet muxer must be using other assemblies to handle commands like publish (or maybe it's still using MSBuild but with lots of extra stuff). In either case - you want to use Buildalyzer to perform full builds that utilize these other commands (I.e. more like a build runner and less an analysis tool). That's not quite my target use case, but this change seems small enough I don't see the harm here. Thanks!

[echalone]

Thank you too :)