¿Para qué sirve "Incluir servicio" en un archivo csproj?


194

En una solución C #, agregué un proyecto existente.
Después de eso, Visual Studio ha agregado la siguiente entrada en otros archivos .csproj:

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

¿Para qué es esto?
¿Puedo borrarlo?


1
La solución se compiló con éxito después de eliminarla, pero la pregunta es: ¿qué sucede en tiempo de ejecución? Tengo que saber lo que hace.
Joe

Respuestas:


260

Tuve un caso similar, donde se agregó esto:

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

VS2013 genera esta inclusión a propósito si crea un proyecto de prueba NUnit, pero se olvida de etiquetarlo como proyecto de prueba, como se describe en esta respuesta de Microsoft:

Este comportamiento es intencional.

Para admitir marcos de prueba de terceros, como NUnit y XUnit, Visual Studio 2012 cargó Test Explorer en la solución abierta, independientemente de si contenía proyectos de prueba. Esto agregó segundos de demora al inicio y los escenarios abiertos de solución para todos los usuarios, la mayoría de los cuales no usan pruebas.

En Visual Studio 2013, lo cambiamos para que el paquete Test Explorer se cargue solo cuando la solución contiene uno o más proyectos de prueba. Los proyectos de prueba se identifican de dos maneras diferentes. Los proyectos creados a partir de una de las plantillas de proyecto de prueba de unidad incorporadas se identifican mediante GUID de tipo de proyecto. Test Explorer identifica otros tipos de proyectos, como el proyecto Biblioteca de clases con pruebas XUnit o NUnit, durante el primer descubrimiento de prueba y se "etiqueta" con el <Service/>elemento.


8
¿Sigue siendo útil para VS 15.3+?
Jaanus Varus

55
@JaanusVarus Sí, esto todavía ocurre en VS 15.4 (estaba tratando de entender el comportamiento y eso me llevó aquí). No estoy seguro de si la decisión de rendimiento debe revisarse, si esa fue su pregunta.
Lars Kemmann

2
Todavía ocurre en 15.6
dimaaan

2
@Adrian Así es como lo marca como un proyecto de prueba. Básicamente, VS dice: "Parece que probablemente sea un proyecto de prueba, así que voy a seguir adelante y marcarlo por ti". O agregue el tipo de proyecto mencionado en la respuesta de Vladimirs.
GalacticCowboy

2
Con Visual Studio 2017 (Versión 15.x), este problema vino y desapareció. Ver este hilo para una historia. Este hilo también menciona que esto finalmente se solucionará en Visual Studio 15.7
Estructurado el

35

Personalmente, no me gusta que este servicio se agregue a mis archivos de proyecto y creo que tenerlo es más una solución alternativa que una solución adecuada. Así que marcar sus proyectos de prueba como proyectos de prueba me parece más correcto y esto se puede lograr agregando esto al primero PropertyGroup:

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

{3AC096D0-A1C2-E12C-1390-A8335801FDAB}significa Proyecto de prueba y {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}- C #. Para otras guías de tipo de proyecto, vaya aquí


11
^ Prefiero ProjectTypeGuidstambién, pero si está haciendo un desarrollo multiplataforma y está utilizando MonoDevelop, no podrá abrir {3AC096D0-A1C2-E12C-1390-A8335801FDAB}proyectos: "Este tipo de proyecto no es compatible con MonoDevelop". Ambos IDEs parecen contentos si simplemente elimina el tipo de proyecto de prueba GUID.
WynandB

3
¿Me pregunto cuáles son otros tipos posibles para <TestProjectType>? No se pudo encontrar ninguna información al respecto.
J Pollack

12

Lo bueno de los GUID conocidos / constantes es que son bastante únicos y, por lo tanto, muy fáciles de buscar en Google. Lo cual hice y encontré: esto y esto , así como otros éxitos interesantes.
Parece que esto es realmente un error conocido en la herramienta DSL T4 que viene con el SDK. Y afortunadamente es bastante fácil de resolver cambiando algunas claves de registro.


8
Y ahora cuando lo busco me sale esta pregunta SO ;-).
binki

Para que quede claro, ese error de T4 DSL fue que la etiqueta de servicio B4F97281-0DBD-4835-9ED8-7DFB966E87FF se agregaba a todos los proyectos, incluso si no usaban T4. Ese error se corrigió en Visual Studio 2008. Todavía se agrega una etiqueta de servicio a los proyectos que usan T4 (aunque el GUID es diferente). Esto sigue siendo así en VS2017.
Duncanp
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.