Open vincent1405 opened 1 year ago
vincent1405
commented
1 year ago I have just found a workaround: If I remove the --no-build argument, the tests run ie
dotnet testinstead of
dotnet test --no-buildNB: It even works with the --no-restore flag, the error seems to come from the dll being tested directly, without having been built by the test step.
vincent1405
commented
1 year ago Not sure if this issue can be associated with: https://github.com/dotnet/sdk/issues/3684
ericsampson
commented
1 year ago I'm having the exact same issue now, whereas my GitHub Actions workflow used to work just fine.
Any idea what's going on?
fifi98
commented
12 months ago Having the exact same issue. Once I add the --no-build argument it fails with the "The argument ...dll is invalid"
EDIT: found the mistake. are you still getting that error if you do dotnet test --configuration Release --no-build?
abdulwahid211
commented
10 months ago @fifi98 is right, if you do dotnet test --configuration Release --no-build should work because in your build step you are setting the configuration for release dotnet build --configuration Release --no-restore
lucasoares
commented
7 months ago For me the error persists even building with dotnet build --configuration Release --no-restore and testing with dotnet test --configuration Release --no-build and I honestly don't want to remove the --no-build tag since I run different types of tests in different jobs on my CI and I don't want it building the project multiple times.
I'm trying to use ubuntu-latest instead of windows on my CI but this is proving to be very hard.
Edit:
I'm building using a solution filter (that also includes all the tests projects) but I'm running dotnet test in the test project csproj only, not the solution filter itself. Maybe this is related?
Edit2:
I tried to execute tests using the solution filter and added a --filter to filter which tests I want to execute, but the execution time for this is very high. The job that previously was running with 6s for unit tests now is taking 4~5 minutes even with --no-build, probably because it is analyzing all projects and searching for tests that only exists in two other projects (this solution filter have many and many projects).
kikutano
commented
6 months ago I have just found a workaround: If I remove the --no-build argument, the tests run ie
dotnet testinstead of
dotnet test --no-buildNB: It even works with the --no-restore flag, the error seems to come from the dll being tested directly, without having been built by the test step.
This worked for me!
lucasoares
commented
3 months ago I have just found a workaround: If I remove the --no-build argument, the tests run ie
dotnet testinstead of
dotnet test --no-buildNB: It even works with the --no-restore flag, the error seems to come from the dll being tested directly, without having been built by the test step.
This worked for me!
Yes, it works but it is not a viable workaround for 90% of the cases. If you have steps in your CI that first build the project and then runs the test, you will end up building everything twice, wasting resources and time.
baronfel
commented
3 months ago I want to see proof that this ever worked for folks. Setting a configuration of Release impacts the output paths that dotnet build and dotnet test use to locate the DLLs that should be tested. I can think of no actual scenario where doing a build in the Release Configuration and then testing without an explicit Configuration (which defaults to Debug) would work when --no-build is specified. The best way to prove exactly what's happening is with an MSBuild Binlog.
lucasoares
commented
3 months ago I want to see proof that this ever worked for folks. Setting a configuration of
Releaseimpacts the output paths thatdotnet buildanddotnet testuse to locate the DLLs that should be tested. I can think of no actual scenario where doing a build in theReleaseConfiguration and then testing without an explicit Configuration (which defaults toDebug) would work when--no-buildis specified. The best way to prove exactly what's happening is with an MSBuild Binlog.
But what you're describing is not what is hapenning for me.
For me the error persists even building with
dotnet build --configuration Release --no-restoreand testing withdotnet test --configuration Release --no-build
Sadly I can't reproduce it anymore because I don't have access to the project I was testing.
nosalan
commented
1 day ago doing a build in the
ReleaseConfiguration and then testing without an explicit Configuration..
@baronfel But we do specify the explicit configuration for both build and test yet the problem is still there. These are my commands:
dotnet restore
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-build
dotnet test still complains that the dll parameter is invalid.
Plevi1337
commented
16 hours ago I've managed to get it working by specifying both the runtime and the configuration on both the build and test command
RUN dotnet build {TEST PROJ DIRECTOR}/{TEST PROJ CSPROJ} \
--no-restore \
--configuration Debug \
--runtime linux-x64
CMD ["dotnet", "test","--runtime", "linux-x64", "--no-restore", "--no-build", "--logger:trx", "--results-directory", "/testresults", "--collect:\"XPlat Code Coverage\""]
Describe the bug
In my CI workflow on github build.yaml, I use the following steps :
The Test step fails with the following message:
To Reproduce
Please visit https://github.com/vincent1405/test-dotnet-test-in-ci
Exceptions (if any)
No Exception thrown, just an error message:
Further technical details
Result of dotnet --info