vstest icon indicating copy to clipboard operation
vstest copied to clipboard

Support test target for desktop msbuild

Open pvlakshm opened this issue 8 years ago • 22 comments
trafficstars

Description

User should be able to run tests specifying the test target with desktop msbuild. For example

> MSBuild testapp.csproj /t:VSTest

This target should first build the app and then run tests for all the outputs (similar to how dotnet test behaves today).

To get this target, user may need to add a package reference to Microsoft.NET.Test.Sdk. This package will include the target and the related task.

Related customer ask: https://github.com/dotnet/sdk/issues/546

pvlakshm avatar Jan 09 '17 12:01 pvlakshm

The testplatform targets and task are part of Microsoft.TestPlatform.Build nuget. They're not in a form that nuget's build extensibility hooks can discover and use them. In the short term, we can refactor this package?

@Faizan2304 @harshjain2 thoughts?

codito avatar Jan 11 '17 03:01 codito

We should not bifurcate the project format between MSBuild and CLI. We had talked about making test a first class SDK in CLI and VS. Once this is done, we can bundle test into the "how do we make SDK's available to MSBuild directly" problem. Until we solve that one, /t:Test will not be able to execute a build since the project under test won't be able to find SDK="Microsoft.NET.Sdk"

TheRealPiotrP avatar Jan 19 '17 08:01 TheRealPiotrP

Until this is done, some projects cannot successfully run tests this way. dotnet test cannot execute a test if the csproj contains targets that use a desktop based Task. There are many existing useful build tasks that can be used to generate a netcoreapp project but they must be run using desktop msbuild.

clairernovotny avatar Jan 20 '17 03:01 clairernovotny

I don't think MSBuild testapp.csproj /t:VSTest should force build on the project. If I wanted to build the project I would have used /t:Build;VSTest.

tmat avatar Feb 14 '17 18:02 tmat

Also I'd consider calling the target Test instead of VSTest, to be consistent with dotnet test.

tmat avatar Feb 14 '17 18:02 tmat

Is there a workaround for this? I have a multi-targeted test library that can only be built with desktop msbuild. I want to run tests!

clairernovotny avatar Mar 08 '17 22:03 clairernovotny

@onovotny Check this one out: https://github.com/dotnet/roslyn-tools/blob/master/src/RepoToolset/Test.props https://github.com/dotnet/roslyn-tools/blob/master/src/RepoToolset/Test.targets

You should be able to use these in your project.

tmat avatar Mar 08 '17 23:03 tmat

(the .props file might not be needed)

tmat avatar Mar 08 '17 23:03 tmat

Thanks, will check it out. Do you use anything for Code Coverage? I was using opencover but that seems broken lately and def doesn't support ppdb's or embedded ppdb's yet.

clairernovotny avatar Mar 08 '17 23:03 clairernovotny

@tmat your targets had something that might actually work for me -- after running the build normally with msbuild /t:build, I tried using dotnet test --no-build. I think that actually worked! The issue is that I'm using GitVersionTask in some of my projects and those tasks don't yet support coreclr. So once it's built, it doesn't matter.

clairernovotny avatar Mar 08 '17 23:03 clairernovotny

Looks similar to issue #1155 I raised. Is there any update when "msbuild /t:VSTest" will be able to test both dncore and regular desktop app ? Thanks!

pchalamet avatar Oct 09 '17 19:10 pchalamet

I have removed the question tag. We will use this item as an input when we take up planning for Q2 of next year.

pvlakshm avatar Nov 30 '17 17:11 pvlakshm

Bump. Using dotnet test --no-build no longer works for certain scenarios. Really need a way to invoke the targets via an MSBuild target.

clairernovotny avatar Mar 28 '18 21:03 clairernovotny

I should add that as-of MSBuild 15.6. we can now have SDK's distributed via NuGet, so it should be a lot easier to support adding this as a test sdk out-of-band for both msbuild and dotnet.

clairernovotny avatar Mar 28 '18 21:03 clairernovotny

Anyone planning to fix this? Building via dotnet msbuild CLI and MSBuild.exe is generally inconsistent.

jnevins-gcm avatar Jun 06 '18 13:06 jnevins-gcm

Bump?

clairernovotny avatar Jun 23 '18 18:06 clairernovotny

@onovotny We haven't decided when to pick this yet. If you would like to contribute, Let me know I'm happy to help you.

smadala avatar Jun 26 '18 08:06 smadala

Has this been picked up yet? Just ran into this today as I was setting up our new build system.

redoz avatar Oct 04 '18 15:10 redoz

is there at least a workaround for this? e.g. can I somehow tell msbuild.exe to import the targets explicitly?

shtratos avatar Jun 21 '23 19:06 shtratos

Y'all should probably close this issue if the future milestone gets removed without a replacement. As much as i'd like to have the feature i'd rather take a set answer on whether its something y'all want to take on.

MeikTranel avatar Sep 05 '23 11:09 MeikTranel

@novacole, this is what you're looking at with https://github.com/dotnet/msbuild/pull/9193, right?

rainersigwald avatar Sep 06 '23 14:09 rainersigwald

@novacole, this is what you're looking at with https://github.com/dotnet/msbuild/pull/9193, right?

Yes, that's correct! @rainersigwald

novacole avatar Sep 11 '23 17:09 novacole