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

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?

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](

[To see links please register here]

) 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.

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][1]


[1]:

[To see links please register here]

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][1] and [this][2], 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.



[1]:

[To see links please register here]

[2]:

[To see links please register here]