Vstest: Test projects end up with this GUID

[davidfowl]

Is there any way to get rid of this GUID? Can it come from somewhere else? The SDK? Maybe? A nuget package? Why does this exist? Who it for? Can it be inferred?

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
  </ItemGroup>

[smadala]

VS generates this automatically, to identify project as test project. More details here.

[davidfowl]

Can we make test projects have their own msbuild sdk to avoid this being added to all test projects?

[codito]

440 is adding a capability for test projects. This guid dependency should go away once VS Test Window starts consuming this.

[davidfowl]

Is that an RTM feature? I'd love to keep the project files as clean as possible...

[codito]

Not planned for RTM currently.

Tagging @sbaid @pvlakshm @srivatsn for bar check.

[codito]

Triage: this will require a fix in test window, we should take this in 15.1.

[davidfowl]

My project file thanks you.

[jnm2]

This kind of noise going back and forth in your source control is a bit irritating, when a bunch of project files suddenly have pending changes and nothing of real consequence happened. I'm really looking forward to getting it out of there.

[NickCraver]

I'm on 15.1 and this is still annoying the crap out of me on every commit trying to sneak its way into my git repo. What's the status of removing this thing?

[JamesNK]

Conscientious csproj citizens don't dirty pristine projects with their grubby GUIDs.

[navin22]

This issue is fixed. Fix will be available in the next VS update.

[PureKrome]

Thank you heaps!

[jnm2]

This issue is fixed. Fix will be available in the next VS update.

Wow so that was quick! Is this the version you're referring to or is it the next one?
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes#a-id1522643004arelease-date-may-10-2017---version-152-2643004

[codito]

This fix should be part of the next 15.3 preview updates.

[sharwell]

@navin22 @codito I just hit this in 3 projects with Visual Studio 2017 version 15.3 Preview 6.

[navin22]

@sharwell Does the project have the "TestContainer" Capability?
<ProjectCapability Include="TestContainer" />

BTW, If the service GUID is already added, the fix made can't remove it. It should be removed manually.

[sharwell]

Does the project have the "TestContainer" Capability?

I'm assuming you are referring to the UnitTestContainer capability.

I'm not sure. It is possible the bug is currently only affecting cases where this capability is not included. However, it would still be the same bug for these cases. If separate test-related handling is desired for projects which do not have this capability, it needs to be relocated to either the solution user options (*.suo) or the project user options (*.csproj.user).

BTW, If the service GUID is already added, the fix made can't remove it. It should be removed manually.

Yes, this is my expectation.

[jnm2]

If separate test-related handling is desired for projects which do not have this capability, it needs to be relocated to either the solution user options (.suo) or the project user options (.csproj.user).

Absolutely.

[jnm2]

Which VS version was this fixed in?

[ATimmeh33]

Started getting this yesterday on the latest version of VS2017 @jnm2 So it might be reintroduced

[smadala]

@jnm2 @ATimmeh33 Fixed in VS 15.3. If you are still facing the issue. Please share repro steps, project and VS version.

[ATimmeh33]

Version 15.4.5 here. The bug started appearing after right clicking in a class and using the "Create Unit Tests", after which 3 different Unit Test's csproj file kept getting automatically changed. I think I fixed it by unchecking Test > Test Settings > Keep Test Execution Engine Running

[jnm2]

I watched VS reinsert the guid into all the test projects in https://github.com/nunit/nunit. I think I was running 15.4.4, actually. I'll try to boil down a repro when I have time.

[ATimmeh33]

Although we also do use nunit, the projects that were affected for me used xunit. So it's probably not nunit related?

[smadala]

@jnm2 @ATimmeh33 Looks like issue appears only when there is no package reference to Microsoft.NET.Test.Sdk >= 15.0.0( i.e, No <ItemGroup><ProjectCapability Include="TestContainer" /></ItemGroup> prop file.). Which is expected as fix is available in Microsoft.NET.Test.Sdk.

Can you try adding below item group to test csproj or add reference to Microsoft.NET.Test.Sdk to get rid of GUID?

<ItemGroup>
<ProjectCapability Include="TestContainer" />
</ItemGroup>

[jnm2]

Sure, though having any csproj element at all is only marginally better than the service guid. Do I understand then that the fix would be for NUnit Framework to ship a .props containing that item?

[smadala]

@jnm2 Yes, Adapter having props solves the issue. See https://github.com/Microsoft/vstest/issues/394#issuecomment-276254646 & https://github.com/Microsoft/vstest/pull/440 for more context.

[jnm2]

@smadala Thanks! I didn't know a decision had yet been made. I'm getting right on it.

[jnm2]

@smadala I have a request. Would you mind pinging @rprouse or me in addition to pinging Brad when such decisions are made? See for example: https://github.com/Microsoft/vstest/pull/440/files#r111365665

That would be super helpful so that we can stay on top of things. That or opening an issue at https://github.com/nunit like your team has done with a couple of other things.

❤️

[jnm2]

@smadala I'm reproing the GUID insertion on VS 15.4.5 but I can't get it to happen with VS 15.5.5.

Does this mean that you see <ProjectCapability Include="TestContainer" /> as a temporary workaround for NUnit and xUnit to employ until the majority of users are on VS 15.5, or is there a reason we should continue shipping this .props indefinitely?

[smadala]

@smadala I have a request. Would you mind pinging @rprouse or me in addition to pinging Brad when such decisions are made? See for example: https://github.com/Microsoft/vstest/pull/440/files#r111365665

/cc @Microsoft/vstest , @pvlakshm

Does this mean that you see as a temporary workaround for NUnit and xUnit to employ until the majority of users are on VS 15.5, or is there a reason we should continue shipping this .props indefinitely?

No, It is not temporary workaround. TestContainer & IsTestProject can be used for other scenarios too see https://github.com/Microsoft/vstest/issues/1129#issuecomment-344762968 . Consider adding IsTestProject to NUnit https://github.com/Microsoft/vstest/pull/440#issuecomment-278226239.

I'm also not able to repro it in VS 15.5, @ManishJayaswal may have idea about it.

[jnm2]

@smadala I see that @bradwilson pushed back on adding it to xUnit: https://github.com/Microsoft/vstest/pull/440#issuecomment-279194436 What conclusion did you come to? It does feel like it isn't NUnit's responsibility to do either IsTestProject or ProjectCapability.

For example, say I'm developing a library of custom constraints for NUnit. Just by referencing the package, my non-test project is now marked as a test project. The only reason we added ProjectCapability is because today the alternative is to leave VS causing problems (from our users' perspectives).

[jnm2]

Another question I still have is, what is it about this GUID that couldn't be redirected into .csproj.user?

[bradwilson]

We did end up doing this:

https://github.com/xunit/xunit/blob/b7c3bedaeecc03f2e578c59f2403a8a5a8e2aa62/src/xunit.core/build/xunit.core.props

<ItemGroup>
  <ProjectCapability Include="TestContainer" />
</ItemGroup>

<PropertyGroup>
  <IsTestProject>true</IsTestProject>
</PropertyGroup>

It's a lame requirement, but nobody sees it and we already had a props file to put it into. Honestly, I so thoroughly hate that GUID that I did for my own sanity. :angry:

[jnm2]

Same but we only added the ProjectCapability so far and aren't motivated to add IsTestProject since the guid is already gone.

Given your good points, my predisposition and the opinion of another NUnit team member, I'm viewing adding any of these as temporary workarounds only. Since VS should be putting the guid into .user or .vs\ and since this causes non-test projects to end up being marked as tests.

[bradwilson]

The GUID has been around since VSTest first shipped; it's just that nobody noticed or cared about this noise when the default .csproj file was 100+ lines long. Now that we have sane & readable .csproj files, people are pushing back against bad decisions like this.

100% agree that this belongs in the .user file.

[PureKrome]

I just updated to VS 15.6.

I just noticed that my .csproj is asking to add this back in.

Is this a regression? Anyone else noticed this?

[jnm2]

@PureKrome VS has never stopped doing that. A workaround is to add this itemgroup or reference a NuGet package which has that (NUnit 3.10 will).

[PureKrome]

Oh dang. i thought it was a fixed thing?

[jnm2]

@PureKrome I did too; see this comment. Instead of fixing it in VS, they preferred to fix it by adding that MSBuild property to the Microsoft.NET.Test.Sdk NuGet package, which you have no reason to be referencing for .NET Framework tests.

[bradwilson]

We (@xunit) also put it into the xunit.core NuGet package so everybody would get it. https://github.com/xunit/xunit/blob/97aca4d37b97952e2c0f693484f25508d8be1eab/src/xunit.core/build/xunit.core.props#L10

[PureKrome]

• Adding in Microsoft.NET.Test.Sdk still added in the GUID. :/
• @bradwilson I'm using xUnit.Core 2.3.1 ... should that have added it? I also uninstalled and reinstalled that package ... GUID still back :(

I must be:

• cursed
• suck at all of this tooling stuff.
• badluck
• all of the above :/

[bradwilson]

Yes, it was in 2.3.1. If the GUID's back, then there's nothing I can do about it, and suggests the bug is still present in Visual Studio.

[singhsarab]

@AbhitejJohn @ManishJayaswal Has something changed around this ?

[ldematte]

Same issue: just updated to 15.6, and this is appearing in all my test .csproj files. Again. :(

[wilhen01]

Just updated to 15.6 and suddenly seeing this in all our NUnit .csproj files. Yuk.

[wilhen01]

@smadala or someone else from MS, can we reopen this issue please?

[jnm2]

To reiterate, in case there's a chance: If the presence of this GUID is somehow useful to VS, would you please redirect it into the .vs cache and keep our projects clean?

[ManishJayaswal]

@singhsarab - I don't think this was ever fixed. I have reopened the issue.
@navin22 - let's chat offline to understand why this was resolved as fixed and if was indeed fixed then what change in 15.6 brought it back.
@KevinH-MS - FYI

However the good news is that we have actually fixed this in 15.7 release - this time for sure, I promise :-)

We wanted to make this change early in a release to understand all the fall outs since apparently code lens test indicators had a dependency on it. 15.7 Preview 1 will release shortly and that would have this change. We will close this issue after someone in the community has verified that 15.7 release does fix this.

[HppZ]

still happen in 15.6.2

[mookid8000]

Seems to be an issue in 15.6.4 too .... good times 😐

[jnm2]

@HppZ @mookid8000 Like the team said right above your comments, you should not expect this to work until 15.7.

Has anyone installed 15.7 yet? I'm going to play with Blazor when I get a chance, so if no one else wants to confirm the GUID fix I'll do it.

[davkean]

This has been fixed in 15.7.