Autofixture: Soporte para CoreCLR

Todavía no, al menos. ¿Qué es DNX?

Jaja ... es el nuevo marco asp.net multiplataforma. https://github.com/aspnet/DNX

el tiempo de ejecución es "dnx451" en lugar de "net451", etc.

¿Qué significa "apoyo para" en este contexto? ¿Está diciendo que es imposible probar ASP.NET 5 desde una biblioteca de prueba con una dependencia de una biblioteca .NET 4?

ASPNET 5 se ejecuta en múltiples plataformas. Solo estamos escribiendo ASPNET 5 en la plataforma dnx en este momento, por lo que es un conjunto diferente de bibliotecas de tiempo de ejecución. Actualmente, nuestro código no está compilado para "net451", por lo que las bibliotecas se dirigen de manera efectiva a plataformas incompatibles.

Mis pruebas funcionan bien con este project.json:

{
"dependencias": {

     "xunit.runner.dnx": "2.1.0-*",
     "xunit":"2.1.0-*",
    "AutoFixture.Xunit2":"3.30-*",
    "NSubstitute": "1.8.0",
    "ManagementWeb": "",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "AutoFixture": "3.30.4-*",
    "AutoFixture.AutoNSubstitute": "3.30.4-*",
    "Microsoft.Azure.Documents.Client": "0.9.2-preview",
    "WindowsAzure.Storage": "4.4.1-*",
    "DeepEqual": "1.1-*"
},
 "frameworks": {
    "dnx451": { }
},
"commands": {
    "test": "xunit.runner.dnx"
}

}

interesante. Tendré que molestar al tipo que está trabajando en esto para ver cuál es la diferencia.
¿Hiciste algo especial para que funcionara?

No, realmente no. IIRC Autofixture siempre funcionó con aspnet 5, pero en el pasado tuve problemas con la extensión xUnit. Ahora que el soporte de xUnit 2 para AF ha desaparecido y DNX y xUnit funcionan bien, simplemente funciona.

Parece que la idea aquí es realmente "soporte para CoreCLR", no DNX. Todo lo que funcione para .NET Framework 4.5 funcionará para 4.5 en DNX. Es probable que CoreCLR requiera algún esfuerzo de soporte, pero no tengo idea de cuánto. La mejor manera de averiguarlo es intentar compilarlo para CoreCLR y ver qué se rompe.

Sí, debería haber sido claro. Me refiero a CoreCLR, no solo a DNX.

Con solo mirar en el repositorio de coreclr , es difícil para mí obtener el estado del proyecto. ¿Está en vista previa? ¿Beta? ¿Publicado?

Sin haberlo probado en absoluto, si CoreCLR se parece a las bibliotecas de clases portátiles en el sentido de que las funciones admitidas son una intersección de las funciones disponibles en varias plataformas, es bastante poco probable que sea posible adaptar AutoFixture para que se ejecute en CoreCLR sin cambios importantes.

Recientemente, @moodmosaic fue tan amable de hacer el análisis para AtomEventStore (un proyecto mucho más pequeño que AutoFixture), y aquí el resultado fue que una versión PCL no era factible .

Sin haber examinado las fuentes de AutoFixture en absoluto, estoy de acuerdo con su evaluación: es probable que se produzcan cambios importantes. #if DNX_* directivas de estilo

CoreCLR está, más o menos, funcionando desde Windows Phone 8.

ASP.NET 5 será RC en noviembre, CoreCLR para Linux y Mac también será RC en noviembre de 2015. Junto con CoreFX. Versión 1.0 para todo lo planeado para el 1T2016.

Me sorprendería enormemente si fuera posible agregar soporte para CoreCLR sin introducir cambios importantes, así que agregué el hito _4.0_ a este problema.

Por curiosidad, ejecuté API Portability Analyzer en el ensamblado Ploeh.AutoFixture y obtuve algunos resultados interesantes:

Espere antes de abrir el Champagne. Ese 3% aproximado de símbolos no admitidos, desafortunadamente, explica algunos bastante fundamentales:

| Tipo de objetivo | Miembro objetivo |
| --- | --- |
| System.Console | M: System.Console.get_Out |
| System.Threading.Thread | M: System.Threading.Thread.get_ManagedThreadId |
| System.Threading.Thread | M: System.Threading.Thread.get_CurrentThread |
| System.Reflection.ICustomAttributeProvider | M: System.Reflection.ICustomAttributeProvider.GetCustomAttributes (System.Type, System.Boolean) |
| System.Net.Mail.MailAddress | M: System.Net.Mail.MailAddress. # Ctor (System.String) |
| System.SerializableAttribute | M: System.SerializableAttribute. # Ctor |
| System.Runtime.Serialization.SerializationInfo | T: System.Runtime.Serialization.SerializationInfo |
| System.Reflection.ParameterInfo | M: System.Reflection.ParameterInfo.IsDefined (System.Type, System.Boolean) |
| System.Type | M: System.Type.get_IsGenericTypeDefinition |
| System.Type | M: System.Type.get_IsEnum |
| System.Type | M: System.Type.get_BaseType |
| System.Type | M: System.Type.get_IsPrimitive |
| System.Type | M: System.Type.get_Assembly |
| System.Type | M: System.Type.get_IsGenericType |
| System.Type | M: System.Type.GetTypeCode (System.Type) |
| System.Type | M: System.Type.get_IsClass |
| System.Type | M: System.Type.get_IsValueType |
| System.Type | M: System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M: System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M: System.Reflection.PropertyInfo.GetSetMethod |
| System.Exception | M: System.Exception. # Ctor (System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M: System.Reflection.MethodBase.GetCurrentMethod |

Sin embargo, existen algunas soluciones:

• Reemplace todas las referencias a las propiedades en System.Type con las correspondientes en System.TypeInfo , disponibles a través del método de extensión GetTypeInfo(Type) .
• Elimine todas las referencias a System.SerializableAttribute .
• Elimine todas las referencias a System.Runtime.Serialization.SerializationInfo (probablemente solo se use en _constructores de excepciones_).
• Elimine todas las referencias a System.Net.Mail.MailAddress .
• Elimine todas las referencias a la propiedad System.Reflection.MemberInfo.ReflectedType y use el objeto reflejado para obtener su tipo.
• Reemplace todas las referencias a la propiedad System.Reflection.PropertyInfo.GetSetMethod con la propiedad System.Reflection.PropertyInfo.SetMethod lugar.

Este es solo un primer paso y las cosas podrían cambiar ya que CoreCLR aún se está desarrollando. Al menos tenemos una idea general de lo que se necesitaría para que AutoFixture sea compatible con él.

Vaya, gracias @ecampidoglio por realizar este análisis: +1:

Algunos de los tipos incompatibles (por ejemplo, MailAddress ) podemos movernos a una biblioteca complementaria que solo funciona en el marco completo. Ya tenía en mente sacar algunas características de la biblioteca _Ploeh.AutoFixture_ para la versión 4 .

La idea de reemplazar PropertyInfo.GetSetMethod con PropertyInfo.SetMethod es buena. AFAICT, solo funcionará en .NET 4.5+, pero está bien, porque la rama _v4_ ya está en .NET 4.5.

No estoy seguro de si la etiqueta "Jump In" es adecuada para este problema. Por lo general, se usa para indicar problemas pequeños, aislados y del tamaño de un bocado que son bastante fáciles y amigables para los nuevos contribuyentes. Parece que este problema requeriría una comprensión bastante buena de una gran parte del código base y su historial.

@chaitanyagurrapu , quizás tengas razón.

La razón por la que agregué la etiqueta _jump in_ fue que considero que este trabajo no está relacionado con los detalles de AutoFixture. Sí: se tendrán que tomar decisiones sobre cómo abordar varias incompatibilidades, pero también hay mucho trabajo simplemente para averiguar cómo funciona toda la infraestructura de código / compilación relacionada con CorCLR, y esa parte no está relacionada en absoluto con AutoFixture.

Por el momento, no tengo estas habilidades, así que me encantaría recibir ayuda con esto. Las decisiones que deben tomarse con respecto a los problemas de compatibilidad las podemos discutir aquí, o en temas específicos de Github.

Empecé a trabajar en esto. Preguntas por venir :)

Me suena bien: +1:

@lbargaoanu Suena bien: +1: Recuerde, si es posible, pequeño .

Me gustaría mover MailAddressGenerator a un proyecto diferente que tenga como objetivo el marco completo en la rama v4, para poder compilar AutoFixture para .NET Core. También podría declarar un tipo de marcador de posición para .NET Core, pero he evitado la compilación condicional hasta ahora. Y siempre habrá cosas compatibles solo en el marco completo.

Está en proceso . Pero mientras tanto ...

Para futura referencia
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

¡Buen post! ¿También cubre las bibliotecas? (Busqué _library_ pero no encontré mucho ...)

:) Eso es todo acerca de las bibliotecas, pero esta publicación y sus enlaces deberían ser suficientes.

Me encantaría ver a AutoFixture trabajando en CoreCLR también, y dispuesto a ayudar donde sea necesario. Mirando los últimos RP de Lucian Bargaoanu (# 511 y # 513), parece que este problema quedó obsoleto en algunas discusiones sin resolver.

Me gustaría empezar a rodar, pero no sé cuál era el plan general para esto y cómo lidiar con algunos de los detalles que bloqueaban las discusiones. Por lo tanto, podría ser útil llegar a algo así, antes de entrar en todos los detalles.

Algunas preguntas que he visto flotando por ahí, o que tengo yo mismo:

• ¿Debería convertirse AutoFixture en PCL o usar algo como proyectos compartidos?
• ¿Qué plataformas son definitivamente necesarias o deseadas a largo plazo? (¿.NET, CoreCLR, UWP?)
• ¿Son las compilaciones condicionales no deseadas para un proyecto como este?

@ploeh Me @lbargaoanu ¿Tiene quizás alguna aportación sobre esto? ¡Gracias!

Veo que me he olvidado de responder a este hilo; por favor acepte mis disculpas: enrojecido:

Cualquier trabajo que podamos hacer para preparar el código base de AutoFixture para .NET Core es bienvenido, siempre y cuando no degrade el código base o introduzca cambios importantes.

Aún es posible realizar cambios importantes, pero tendrían que ir a la rama _v4_.

En cualquier caso, sin embargo, necesitaré una buena justificación para cualquier cambio que parezca injustificado tal como está. Si bien no puedo decir que sigo de cerca la situación de .NET Core, parece que todavía hay muchos problemas y no estoy dispuesto a introducir cambios especulativos mientras el objetivo aún se esté moviendo.

No me sorprendería que la compilación condicional terminara siendo necesaria, y no estoy en contra mientras podamos mantener la cordura. Si aún puedo ejecutar el script de compilación para compilar lo que sea necesario para publicar, probablemente estará bien. Debo admitir, sin embargo, que no tengo mucha experiencia con esto.

Tampoco sé qué plataformas se buscan. Básicamente, si alguien en la comunidad nos envía solicitudes de extracción que parecen fáciles de mantener y que amplían el alcance de AutoFixture, consideraremos aceptarlas.

AFAICT, tendríamos que apuntar a netstandard1.X que es el conjunto de API que se ejecutarían en cualquier plataforma que las implemente (incluida la plataforma cruzada de netcore y el marco de red solo en Windows).

Consulte https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

En general, los números más altos tienen más API, pero menos plataformas compatibles. Probablemente deberíamos comenzar (continuar) esta discusión entendiendo a qué X debemos apuntar en netstandard1.X .

El primer párrafo de ese documento me asusta un poco:

Compartimos los primeros planes para el futuro de la creación de bibliotecas de clases .NET.
- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic también me asusta, pero la

Por ejemplo, si necesitamos API de reflexión para AutoFixture, la lista de objetivos que posiblemente podríamos tener se reduce. Si necesitamos colecciones concurrentes, lo mismo ocurre. Esas plataformas ya existen (net framework full, Windows phone, etc.), así que creo que no es algo que pueda cambiar si discutimos qué API necesitamos.

Podría [re] iniciar la conversación ... (descargo de responsabilidad: todavía estoy aprendiendo estas cosas también)

Empiezo con el más bajo ( netstandard1.0 ) que ya está implementado en la mayor cantidad de plataformas, y busco razones por las que no podemos (o no lo haremos) comprometernos con esa plataforma.

Según tengo entendido, el conjunto de API netstandard1.0 es bastante antiguo y restrictivo. No tiene cosas como:

• System.Linq.Parallel (comienza desde netstandard1.1 )
• System.Console (comienza desde netstandard1.3 )
• System.Collections.Concurrent (comienza desde netstandard1.1 )
• System.ComponentModel.Annotations (comienza desde netstandard1.1 )
• System.Collections.Specialized (comienza desde netstandard1.3 )

Esto me lleva a pensar que no es práctico que AutoFixture apunte a netstandard1.0 .

Me pregunto si esperar al analizador mencionado por @ecampidoglio aquí es una mejor estrategia.

Editar: aquí está el repositorio de herramientas del analizador de portabilidad de la API de .NET y aquí está el sitio web http://dotnetstatus.azurewebsites.net

Perdón por el exceso de comentarios no deseados, lo dejaré ahora :)

Para su información, ejecuté el último analizador de portabilidad en un Ploeh.AutoFixture.dll construido localmente desde v4 4a7d415 y el resumen es:

A continuación, se muestran algunos cambios que recomienda actualmente:

La salida completa está aquí .

@ploeh Muchos componentes ampliamente utilizados de Asp.Net Core requieren como mínimo netstandard1.3 . Ejemplos de esto incluyen EntityFrameworkCore (usa 1.3) y Mvc (usa 1.6).

Si Autofixture usara cualquiera de estos como base, creo que estaría en un buen lugar.

¿Alguna línea de tiempo sobre cuándo podría estar disponible la compatibilidad con .Net Core?

Me las arreglé para hacer una compilación en .NET Core basada en la rama v4. Sin embargo, no intenté construir proyectos de prueba. Consulte esta rama si desea crear un paquete.

FWIW, aquí está la comparación entre AutoFixture / AutoFixture v4 y uhaciogullari / AutoFixture net-core . Se ve bien 👍

Bueno, en realidad no es tan sencillo. La existencia de project.json provoca un error en la creación de proyectos csproj regulares en este momento. Podríamos migrar todos los proyectos al formato project.json, pero no estoy seguro de si es una buena idea para los otros proyectos. No los he revisado en detalle, pero sospecho que son complementos para otros marcos de prueba. No tengo idea si también son compatibles con .NET Core.

Otra cosa es que Microsoft anunció que pronto se alejarán

Hay una forma de compilar sin errores: # 712

De hecho, traté de compilar desde su rama pero no genera un dll. Probablemente le falte alguna configuración, pero crear una carpeta adicional en cada proyecto no me atrajo estéticamente.

¿Hay alguna actualización sobre esto?

Creo que fue prudente esperar hasta que las herramientas principales de .net alcancen el estado de RTM. Las herramientas de csproj actualizadas no se trasladarán a VS2015 y, por lo tanto, solo estarán disponibles en VS2017. Ver https://twitter.com/TheCodeJunkie/status/822048014172880900

https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/

@hoetz todavía puede instalar vs2017 community edition.

¿Hay algún plan para analizar este problema?

Se siente realmente mal escribir pruebas para ensamblajes estándar .NET sin AitoFixture ...

Hola a todos, esto requiere que alguien de la comunidad intervenga y contribuya. Obviamente, es difícil en este momento porque los problemas del modelo de gobierno aún no se han resuelto (n. ° 703). Alguien también necesita intervenir en ese frente.

Estoy jugando con el problema. En este momento me estoy enfocando solo en Src \ AutoFixture.sln.

Mi estrategia es convertir Src \ AutoFixture \ AutoFixture.csproj al nuevo formato de proyecto (VS 2017) para que pueda admitir tanto .NET Framework como .NET Standard.

Ejecuté la prueba de portabilidad de .NET y el mejor objetivo debería ser .NET Standard 1.5 (ver archivo adjunto).

Para empezar, no convertiré los proyectos de prueba, aunque supongo que es posible que deseemos ejecutar la prueba también en el tiempo de ejecución de .NET Core en el futuro.

AutoFixtureNetPortabilityTest.zip

Hola @Kralizek - Solo para su información - Tuve éxito con netstandard1.3 en el n. ° 712

@Kralizek mi error, parece que comencé a planificar para netstandard1.3 pero en realidad terminé con netstandard1.5 👍

Casi llegamos. Todas las pruebas son verdes en .NET Framework. La compilación es toda roja en .NET Standard. :D

Solo me encontré con estas categorías de problemas:

Generador no necesario
Solo un caso, MailAddressGenerator , porque System.Net.Mail.MailAddress no está disponible en .NET Standard. Solución: el archivo completo ha sido "eliminado" por #if NET40 ... #endif

Publicación por entregas
SerializableAttribute, SerializationInfo y StreamingContext no existen en .NET Standard. Además, Exception no tiene el constructor que toma esos dos tipos. Usando la directiva del compilador, eliminé el atributo y ese constructor de todas las excepciones. Especialmente eliminar el atributo no es realmente agradable.

Uso de Reflection para obtener información sobre un tipo
En .NET Standard Type es mucho más pobre. Todo se delega a un objeto TypeInfo que contiene todas las propiedades que se utilizan. El problema es que .NET Framework todavía usa la antigua clase Type.
Solución:
Creé un método de extensión que reenvía el mismo objeto Type public static Type GetTypeInfo(this Type type) => type; e hice que este método de extensión estuviera disponible solo en .NET Framework a través de la directiva del compilador. Este truco resolvió muchas incompatibilidades dejando intactos los archivos. Nota: el método de extensión está marcado como internal .

Uso de Reflection para obtener el ensamblado actual
Ok, este fue difícil porque no conozco perfectamente el diseño del proyecto. Usé ReSharper para verificar rápidamente la jerarquía de clases, pero ustedes deberían verificarlo.
El archivo es TerminatingWithPathSpecimenBuilder y la línea es var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; . Parece que está buscando el ensamblado en el que estamos. Dado que esta clase no tiene herederos, es seguro asumir que typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly devuelve el mismo resultado , pero de nuevo, podría estar equivocado. (Pongo el método de extensión falsa entre paréntesis). Si mi suposición es correcta, sugeriría marcar esta clase como sealed para evitar el riesgo de que se herede y se rompa.

De todos modos, permítanme presentarles el nuevo archivo de proyecto.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;netstandard1.5</TargetFrameworks>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.ComponentModel.DataAnnotations" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.5' ">
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.1.0" />
  </ItemGroup>
</Project>

sí, este es el archivo del proyecto completo .

@Kralizek, ¿has notado que tenemos la intención de apuntar a> = net45 en la rama v4 ?

@adamchester no ... No debería importar mucho, pero cambiaré el marco de destino. ¡Gracias por el aviso! 👍

Por cierto, descubrí que System.Threading.Thread está disponible como paquete .

Desbloqueó un nivel completamente nuevo de errores del compilador ... agradable: P

.NET Standard 2.0 Debería agregar mucha API, ¿tal vez valga la pena esperar?

No, no es. .NET Standard 2.0 vence en el tercer trimestre de 2017. Estamos a un compromiso de admitir .NET Standard 1.5, ¿por qué deberíamos esperar a 2.0? ¿Para generar mensajes de correo en un tiempo de ejecución nunca lo admitirá?

Además, 2.0 será en su mayoría una corrección del marco 4.6 con una gran cantidad de NotSupportedException por todas partes.

@Kralizek Bastante justo. Por supuesto, me encantaría que el autofixter se lanzara más rápido, así que era una pregunta más general.

FWIW, soy el colaborador que agregó el soporte para el generador de direcciones de correo, y aunque, es bueno que haya hecho que AutoFixture tenga soporte para eso, de ninguna manera es un aspecto vital de AutoFixture y vale la pena el esfuerzo de espéralo.

Tener AutoFixture en el estándar .NET más bajo posible debería tener la mayor prioridad, en mi humilde opinión. Continúe con el buen trabajo, y si está buscando ayuda o apoyo para probarlo, definitivamente puedo ayudar.

@Kralizek, las cosas de TypeInfo también están presentes en .NET 4.5, por lo que ayudaría.

Fue mordido por el error "Package AutoFixture 3.50.5 no es compatible con netcoreapp1.1 (.NETCoreApp, Version = v1.1)" hoy al comenzar a agregar pruebas a varios proyectos de .NET Core.

Estoy pidiendo un tipo de respuesta de "estado de autofixture para .net core" que dé una dirección para cuando este paquete nuget extremadamente útil estará disponible para esta plataforma (y .net core 2.0 ya es rtm y pendiente de lanzamiento ..) .

¿Qué lo detiene? (gracias de antemano)

Actualmente estamos trabajando en eso y puedes seguir el progreso en el # 773. Tenga en cuenta que este PR es sobre el proyecto AutoFixture sí. Tenemos otros 9 proyectos más que deberían ser migrados, pero eso debería hacerse solo después de que terminemos de trabajar en este.

La compatibilidad con .NET Core se lanzará como v4, puede encontrar el alcance completo aquí . Esperaría un par de meses antes de que todo esté listo.

Mientras tanto, también estamos trabajando en el feed de Dev NuGet (n. ° 762), por lo que podrá participar en las primeras pruebas de productos 😉

@zvirja gracias por la actualización detallada. Estoy seguro de que también será útil para otros desarrolladores. Estaré encantado de participar en las primeras pruebas de productos.

@zvirja, así que solo para aclarar: el enfoque actual (temporal) para escribir pruebas unitarias en aplicaciones / bibliotecas de .NET Core es usar AutoFixture en, por ejemplo, .NET 4.7 proyectos de prueba y migrar los proyectos de prueba a .NET Core en un momento posterior?

¿Es esta la solución alternativa sugerida por el momento? (Siempre que la aplicación que estoy escribiendo pueda ser completamente .NET Core, en realidad no es un gran problema escribir las pruebas en un entorno .NET 4.7 normal).

@andersborum Nunca pensé en la solución temporal. No estoy seguro de que todas las API que usamos en v3 (paquetes, publicados en NuGet) sean compatibles con .Net Standard 2.0 (para usar una nueva característica de .NET Standard).

Háganos saber si encontró una manera de combinar v3 y .Net Core, para que podamos aconsejarlo a otras personas 😉

Solo para notificar a todos: el soporte de .Net Standard para AutoFixture PR (# 773) se ha fusionado con la rama v4 . Puede consumir el paquete de nuestro feed privado .

Tenga en cuenta que solo se ha migrado la biblioteca AutoFixture. Otras bibliotecas de pegamentos seguirán más adelante.

¿Es posible mover la v4 a nuget.org, incluso la versión alfa? No se pudo encontrar nada comparable a la instalación automática hasta ahora que admita .netstandard.
¿Ya se decidió la fecha de lanzamiento de la v4?

@RomanKernSW No en este momento; aún no hemos migrado ni la mitad de los proyectos (como xUnit, NUnit, NSubstitute support), así que es demasiado pronto. También tenemos un plan para cambiar el espacio de nombres , así que preferiría hacerlo _antes_ de que publiquemos algo, ya que sería una gran ruptura entre lanzamientos. Por otro lado, quiero cambiar el espacio de nombres lo más tarde posible, ya que constantemente fusionamos master con v4 y será un infierno hacerlo después del cambio.

¿Tiene algún problema con el feed privado? Puede agregar el feed a través de NuGet.config si es muy necesario.

hm Tengo que verificar si es posible usar nuget.config para la restauración de nuget (.Net Core 2 - Tarea de vista previa en VSO). En este momento, tenemos un feed privado (VSO) con nuget.org sin ningún archivo nuget.config. Necesito tiempo para probar esto ...

.Net Standard 2.0 tiene un modo de compatibilidad para .Net Framework NuGets.
He escrito pruebas de .Net Core con AutoFixture 3.50.xy sin problemas, así que
lejos.

@roarwrecker ¡ Genial, gracias por compartir! Lo que significa que tenemos un búfer de tiempo más grande hasta que implementemos el soporte oficial para NuGet: wink:

@roarwrecker gracias ... este no era el problema en .netstandard 1.6. Podría instalar el nuget, pero nunca se compila sin error

Hola chicos, no estoy seguro de qué tan avanzado está el trabajo de .NetCore, pero ¿es posible obtener una versión alfa en NuGet?

@selmendorfFrontline Copiando la respuesta desde aquí :

La publicación de la versión preliminar en NuGet es una pregunta un poco dolorosa para mí. Si bien comenzamos a admitir .NET Core para la mayoría de los proyectos , tenemos un plan para cambiar el espacio de nombres predeterminado . Este sería un gran cambio para nuestros clientes y todo el código del cliente dejará de compilarse. Este es el punto en el que aparece la confusión:

• si liberamos alpha con un espacio de nombres existente y cambiamos el espacio de nombres entre alpha y RTM, confundirá a nuestros clientes, ya que ya vieron v4 con el espacio de nombres existente. Quiero que nuestros clientes sientan que la v4 siempre se lanzó con un nuevo espacio de nombres a medida que se cambiaba el modelo de gobierno.
• si liberamos alpha con un espacio de nombres cambiado, no podremos fusionar la rama master con v4 sin más problemas. Actualmente nos comprometemos con ambas ramas, por eso me gustaría aplazar el cambio de espacio de nombres hasta el final. Otro punto es que nuestra documentación no está lista actualmente, por lo que es posible que las personas simplemente no entiendan por qué todas las importaciones de espacios de nombres no son válidas y que simplemente necesitan ejecutar un reemplazo de texto. Eso les dará miedo y la experiencia no será tan fluida como quisiera.

La mejor manera de resolver esta situación sería no liberar alpha y liberar solo el RTM. Lamentablemente, no puedo proporcionarles una ETA precisa, ya que depende de mi capacidad (estoy trabajando en este proyecto en mi tiempo libre) y de la disponibilidad de otros colaboradores (mis RP deben revisarse 😉). En mi cabeza imagino el lanzamiento en uno o dos meses y espero que suceda dentro de este rango. Este proyecto estuvo muerto durante aproximadamente 9 meses debido al cambio del modelo de gobernanza, esa es la razón principal de tal retraso en el soporte.

Mientras tanto, utilice el paquete del feed de vista previa. Puede ajustar su Nuget.config como se mencionó anteriormente, por lo que esto debería ser un problema.

Voy a cerrar este problema después de que el # 857 finalmente se fusione. Nuestra tabla de compatibilidad de .NET final sería la siguiente:

| Producto | .NET Framework | .NET estándar |
| ------------------ | ------------------------ | ------------------------ |
| AutoFixture | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoFixture.xUnit | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| AutoFixture.xUnit2 | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoFixture.NUnit2 | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| AutoFixture.NUnit3 | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoFakeItEasy | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.6 |
| AutoFoq | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| AutoMoq | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoNSubstitute | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoRhinoMock | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| Modismos | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 2.0 |
| Idioms.FsCheck | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| SemanticComparison | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |

Todas las bibliotecas no admitidas excepto Idioms.FsCheck no se pueden actualizar ya que sus dependencias no son compatibles con .Net Standard y es poco probable que lo hagan (la mayoría de ellas están obsoletas). Intenté transferir Idioms.FsCheck para admitir tanto .NET 452 como .NET Standard 2.0 (ya que es técnicamente posible), pero no pude hacerlo funcionar. Parece que F # SDK todavía es bastante difícil y tenemos que esperar nuevos lanzamientos. La compilación y la carga del proyecto simplemente fallan después de definir TargetFrameworks node.

A menos que alguien tenga otra visión, seguiré este plan 😃También siento lo cerca que estamos del lanzamiento y cuánto queda atrás 😊

¡Ve! Ve! Ve!

Intenté transferir Idioms.FsCheck para admitir tanto .NET 452 como .NET Standard 2.0

¿Ha intentado cambiar a una versión más nueva de F # en ese? IIRC, está en F # 3.1 y este podría ser el caso.

Buen trabajo @zvirja. ¿Crees que podemos sacar la v4? Cuanto más nos acercamos, más emocionado me siento :)

Ojalá pudiera ofrecerte una cerveza :)

¿Ha intentado cambiar a una versión más nueva de F # en ese? IIRC, está en F # 3.1 y este podría ser el caso.

@moodmosaic Sí. Si marca FsCheck 2.9.0 , encontrará que depende de FSharp.Core (>= 4.1.17) , por lo tanto, no tuve otra opción 😅 El problema es más bien con SDK. Si empiezo a apuntar a ambos marcos simultáneamente, no puedo cargar la solución en VS
Proyecto:

<PropertyGroup>
  <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>
  .....
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="FsCheck" Version="[0.9.2,3.0.0)" Condition=" '$(TargetFramework)'=='net452' " />
  <PackageReference Include="FSharp.Core" Version="3.1.2" Condition=" '$(TargetFramework)'=='net452' " />

  <PackageReference Include="FsCheck" Version="[2.9.0,3.0.0)" Condition=" '$(TargetFramework)'=='netstandard2.0' " />
  <PackageReference Include="FSharp.Core" Version="4.1.17" Condition=" '$(TargetFramework)'=='netstandard2.0' " />

  <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
</ItemGroup>

Intentando abrir en VS:

Todo está bien con el proyecto: el problema está en algún lugar del SDK de F #. Es por eso que me gustaría posponer el soporte de .NET Core por parte de FsCheck hasta los mejores tiempos.

@Kralizek Por favor, vea la respuesta a algunas respuestas arriba .

Acabo de verificar en VS 2017.4 y aún no puedo apuntar a múltiples marcos para el proyecto F #. Por lo tanto, cerraré este problema por ahora, ya que admitimos .NET Core para todos los demás proyectos.

JFYI: Me libera v4 RC1 a la NuGet, por lo que puede consumir y prueba sin necesidad de jugar con una alimentación personalizado.