You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand per #1 comment and a few other historical issues that there isn't a desire to fully support all the CLI tooling (especially the end complexity of dotnet build and dotnet publish). However, behind the scenes dotnet test is likely simple enough to allow to work. I have achieved this in two ways:
conditional logic in each of my .csproj files
experimental minor change in MSBuild.SDK.SystemWeb\sdk.targets on my local machine
Fundamentally the issue is that for reasons you cannot set -p:VSToolsPath=... as part of the dotnet test ... CLI, it gets overridden by something else in the upstream SDKs/tooling.
My current workflow (via workaround (1) above):
MSBuild (full-framework/VS's MSBuild) the SLN
dotnet test $SLN --no-build -p:VSToolsPathOverride=... (other args)
Notably that I am not asking for dotnet test to build the code (though that seems to work? outside my expertise to be sure though), just support/trick it enough that the test projects which reference/depend on the SystemWeb projects can do their things. While this still requires users to go "above and beyond" what is normally expected to run the dotnet test and such CLI tools, for those of us willing to add a few -p override switches/settings this all starts to seem to work just enough.
For reasons of silly corporate oversight/IP ownership, I cannot submit a PR myself on this, merely suggest what one may look like:
PS: would (anonymized) samples of full command lines from build, to test, to (local-folder) publish be something you might want to have/document? We have been using your nuget to great success, figuring out how to mix-match the correct MSBuild-old vs dotnet CLI-new might be quite the challenge to those unfamiliar.
The text was updated successfully, but these errors were encountered:
I understand per #1 comment and a few other historical issues that there isn't a desire to fully support all the CLI tooling (especially the end complexity of
dotnet build
anddotnet publish
). However, behind the scenesdotnet test
is likely simple enough to allow to work. I have achieved this in two ways:MSBuild.SDK.SystemWeb\sdk.targets
on my local machineFundamentally the issue is that for reasons you cannot set
-p:VSToolsPath=...
as part of thedotnet test ...
CLI, it gets overridden by something else in the upstream SDKs/tooling.My current workflow (via workaround (1) above):
dotnet test $SLN --no-build -p:VSToolsPathOverride=... (other args)
Notably that I am not asking for
dotnet test
to build the code (though that seems to work? outside my expertise to be sure though), just support/trick it enough that the test projects which reference/depend on the SystemWeb projects can do their things. While this still requires users to go "above and beyond" what is normally expected to run thedotnet test
and such CLI tools, for those of us willing to add a few-p
override switches/settings this all starts to seem to work just enough.For reasons of silly corporate oversight/IP ownership, I cannot submit a PR myself on this, merely suggest what one may look like:
PS: would (anonymized) samples of full command lines from build, to test, to (local-folder) publish be something you might want to have/document? We have been using your nuget to great success, figuring out how to mix-match the correct MSBuild-old vs dotnet CLI-new might be quite the challenge to those unfamiliar.
The text was updated successfully, but these errors were encountered: