What is "Service Include" in a csproj file for?

Question

In a C# solution, I added a existing project.
After that, Visual Studio has added the following entry in other .csproj files:

<ItemGroup>
    <Service Include="{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}" />
</ItemGroup>

What's this for?
Can I delete it?

Solution 1

I had a similar case, where this was added:

<ItemGroup>
  <Service Include="{82A7F48D-3B50-4B1E-B82E-3ADA8210C358}" />
</ItemGroup>

This inclusion turns out to be generated on purpose by VS2013 if you create an NUnit test project, but forget to tag it as test project, as described in this answer from Microsoft:

This behavior is intentional.

To support third-party test frameworks, like NUnit and XUnit, Visual Studio 2012 loaded Test Explorer on solution open, regardless of whether it contained test projects. This added seconds of delay to startup and solution open scenarios for all users, majority of whom don't use tests.

In Visual Studio 2013, we changed it so that Test Explorer package is loaded only when the solution contains one or more test projects. Test projects are identified in two different ways. Projects created from one of the built-in unit test project templates are identified using project type GUIDs. Other types of projects, such as Class Library project with XUnit or NUnit tests, are identified by Test Explorer during first test discovery and “tagged” with the <Service/> item.

Solution 2

Personally I don't like this service added to my project files and I think having it is more like a workaround rather than a proper solution. So marking your test projects as test projects seems more correct to me and this can be achieved by adding this to the first PropertyGroup:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<TestProjectType>UnitTest</TestProjectType>

{3AC096D0-A1C2-E12C-1390-A8335801FDAB} means Test Project and {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} - C#. For other project type guids go here

Solution 3

The good thing about well-known / constant GUIDs is that they are pretty much unique and therefore very easy to search for in Google. Which I did, and found: this and this, as well as other interesting hits.
It looks like this is actually a known bug in the T4 DSL tool which comes with the SDK. And fortunately it's easy enough to resolve by changing some registry keys.

Comments

[joe]

The solution compiled successfully after deleting it - but is the question is: what happens at runtime? I have to know what it does.

[WynandB]

^ I prefer ProjectTypeGuids too but if you're doing cross-platform development and using MonoDevelop you won't be able to open {3AC096D0-A1C2-E12C-1390-A8335801FDAB} projects: "This project type is not supported by MonoDevelop". Both IDEs seems happy if you simply remove the test project type GUID.

[J Pollack]

I wonder what are other possible types for the <TestProjectType>? Could not find any info about it.

[binki]

And now when I search it I get this SO question ;-).

[Jaanus Varus]

Is it still useful for VS 15.3+?

[Lars Kemmann]

@JaanusVarus Yes, this still occurs in VS 15.4 (I was trying to understand the behavior and that led me here). I'm not sure if the performance decision should be revisited, if that was your question.

[dimaaan]

Still occurs in 15.6

[Adrian]

What do I need to do to mark the project as a test project? I have a project with a class inside that has the [TestFixture] attribute, a reference to NUnit dll, and since I've updated VS2017 to 15.6.2, I'm getting the same problem.

[GalacticCowboy]

@Adrian This is how you mark it as a test project. VS is basically saying, "This looks like it's probably a test project, so I'm going to just go ahead and mark that for you." Or add the project type mentioned in Vladimirs' answer.

[Structed]

With Visual Studio 2017 (Version 15.x), this problem came and went away. See this thread for a history. This thread also mentions this will finally fixed in Visual Studio 15.7

[Stephen Kennedy]

Can confirm fixed in 15.7.

[duncanp]

Just to be clear, that T4 DSL bug was that the service tag B4F97281-0DBD-4835-9ED8-7DFB966E87FF was being added to all projects, even if they didn't use T4. That bug was fixed in Visual Studio 2008. A service tag is still added to projects that do use T4 (although the GUID is different). This is still in the case in VS2017.