Autofixture: Suporte para CoreCLR

Ainda não, pelo menos. O que é DNX?

Haha .. é a nova estrutura do asp.net de plataforma cruzada. https://github.com/aspnet/DNX

o tempo de execução é "dnx451" em vez de "net451", etc.

O que "suporte para" significa neste contexto? Você está dizendo que é impossível testar o ASP.NET 5 a partir de uma biblioteca de teste com dependência de uma biblioteca .NET 4?

ASPNET 5 é executado em várias plataformas. No momento, estamos escrevendo ASPNET 5 na plataforma dnx, portanto, é um conjunto diferente de bibliotecas de tempo de execução. Nosso código atualmente não é compilado para "net451", portanto, as bibliotecas estão efetivamente visando plataformas incompatíveis

Meus testes funcionam perfeitamente com este project.json:

{
"dependências": {

     "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"
}

}

interessante. Vou ter que incomodar o cara que está trabalhando nisso para ver qual é a diferença.
Você fez algo especial para que funcionasse?

Não, realmente não. O IIRC Autofixture sempre funcionou com aspnet 5, mas no passado tive problemas com a extensão xUnit. Agora que o suporte xUnit 2 para AF foi lançado e DNX e xUnit funcionam bem juntos, ele simplesmente funciona.

Parece que a ideia aqui é realmente "suporte para CoreCLR", não DNX. Tudo o que funciona para o .NET Framework 4.5 funcionará para 4.5 no DNX. O CoreCLR provavelmente exigirá algum esforço de suporte, mas não tenho ideia de quanto. A melhor maneira de descobrir é tentar construí-lo para CoreCLR e ver o que funciona.

Sim, eu deveria ter sido claro. Eu quis dizer CoreCLR, não apenas DNX.

Apenas olhando o repositório coreclr , é difícil para mim obter o status do projeto. Está em visualização? Beta? Liberado?

Sem ter tentado, se o CoreCLR for algo como as Bibliotecas de Classes Portáteis no sentido de que os recursos suportados são uma interseção dos recursos disponíveis em várias plataformas, é muito improvável que seja possível fazer o retrofit do AutoFixture para rodar no CoreCLR sem interromper as alterações.

Recentemente, @moodmosaic foi muito gentil em fazer a análise para AtomEventStore (um projeto muito menor que o AutoFixture), e aqui o resultado foi que uma versão PCL era inviável .

Sem ter olhado para as fontes do AutoFixture, concordo com sua avaliação: mudanças significativas são prováveis. #if DNX_* diretivas de estilo

CoreCLR está, mais ou menos, funcionando desde o Windows Phone 8.

ASP.NET 5 será RC em novembro, CoreCLR para Linux e Mac também será RC em novembro de 2015. Junto com CoreFX. Release 1.0 para tudo planejado para o 1T2016.

Eu me surpreenderia tremendamente se fosse possível adicionar suporte para CoreCLR sem introduzir alterações importantes, então adicionei o marco _4.0_ a este problema.

Por curiosidade, executei o API Portability Analyzer no assembly Ploeh.AutoFixture e obtive alguns resultados interessantes:

Espere antes de abrir o Champagne. Esses cerca de 3% dos símbolos não suportados, infelizmente, são responsáveis ​​por alguns bastante fundamentais:

| Tipo de alvo | Membro alvo |
| --- | --- |
| 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 |

No entanto, existem algumas soluções:

• Substitua todas as referências às propriedades em System.Type pelas correspondentes em System.TypeInfo , disponíveis através do método de extensão GetTypeInfo(Type) .
• Remova todas as referências a System.SerializableAttribute .
• Remova todas as referências a System.Runtime.Serialization.SerializationInfo (provavelmente usado apenas em _construtores de exceção_).
• Remova todas as referências a System.Net.Mail.MailAddress .
• Remova todas as referências à propriedade System.Reflection.MemberInfo.ReflectedType e use o objeto refletido para obter um controle de seu tipo.
• Substitua todas as referências à propriedade System.Reflection.PropertyInfo.GetSetMethod propriedade System.Reflection.PropertyInfo.SetMethod .

Este é apenas um primeiro passo e as coisas podem mudar, pois o CoreCLR ainda está sendo desenvolvido. Pelo menos nós temos uma idéia geral do que seria necessário para tornar o AutoFixture compatível com ele.

Uau, obrigado, @ecampidoglio , por realizar esta análise: +1:

Alguns dos tipos incompatíveis (por exemplo, MailAddress ), podemos mover para uma biblioteca complementar que funciona apenas no framework completo. Eu já tinha em mente retirar alguns recursos da biblioteca _Ploeh.AutoFixture_ para a versão 4 .

A ideia de substituir PropertyInfo.GetSetMethod por PropertyInfo.SetMethod é boa. AFAICT, só funcionará no .NET 4.5+, mas tudo bem, porque o branch _v4_ já está no .NET 4.5.

Não tenho certeza se o rótulo "Jump In" é apropriado para esse problema. Normalmente, é usado para indicar problemas pequenos, isolados e do tamanho de uma mordida que são bastante fáceis e amigáveis ​​para novos contribuidores. Parece que esse problema exigiria um bom entendimento de grande parte da base do código e de seu histórico.

@chaitanyagurrapu , talvez você esteja certo.

A razão pela qual adicionei o rótulo _jump in_ foi que considero esse trabalho um tanto não relacionado aos detalhes da AutoFixtura. Sim: as decisões terão que ser feitas sobre como lidar com várias incompatibilidades, mas também há muito trabalho simplesmente descobrir como toda a infraestrutura de código / compilação funciona relacionada ao CorCLR, e essa parte não está completamente relacionada ao AutoFixture.

No momento, não tenho essas habilidades, então adoraria receber ajuda com isso. As decisões que precisam ser feitas em relação aos problemas de compatibilidade, podemos discutir aqui ou em questões específicas do Github.

Comecei a trabalhar nisso. Perguntas para vir :)

Parece-me bem: +1:

@lbargaoanu Parece bom: +1: Lembre-se, se possível, mantenha-o pequeno .

Eu gostaria de mover MailAddressGenerator para um projeto diferente que visa a estrutura completa no branch v4, para que eu possa construir AutoFixture para .NET Core. Eu também poderia declarar um tipo de espaço reservado para .NET Core, mas evitei a compilação condicional até agora. E sempre haverá coisas com suporte apenas na estrutura completa.

Está em andamento . Mas enquanto isso ...

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

Bela postagem! Também cobre bibliotecas? (Eu procurei por _library_ mas não encontrei muito ...)

:) É tudo sobre bibliotecas, mas este post e seus links devem ser suficientes.

Eu adoraria ver o AutoFixture funcionando no CoreCLR, também, e disposto a ajudar quando necessário. Olhando os últimos PRs de Lucian Bargaoanu (# 511 e # 513), parece que este problema ficou obsoleto em algumas discussões não resolvidas.

Eu gostaria de fazer a bola rolar, mas não sei qual era o plano geral para isso e como lidar com alguns dos detalhes que estavam bloqueando as discussões. Portanto, pode ser útil chegar a algo assim, antes de entrar em todos os detalhes.

Algumas perguntas que tenho visto flutuando ou que eu mesmo tenho:

• deve o AutoFixture ser convertido em um PCL ou usar algo como projetos compartilhados?
• quais plataformas são definitivamente necessárias ou desejadas a longo prazo? (.NET, CoreCLR, UWP?)
• são compilações condicionais indesejadas para um projeto como este?

@ploeh Posso @lbargaoanu Você tem alguma contribuição sobre isso? Obrigado!

Vejo que esqueci de responder a este tópico; por favor aceite minhas desculpas: liberado:

Qualquer trabalho que possamos fazer para preparar a base de código do AutoFixture para .NET Core é bem-vinda, contanto que não degrade a base de código ou introduza alterações importantes.

Ainda é possível interromper as alterações, mas elas precisam ir para o branch _v4_.

Em qualquer caso, porém, precisarei de uma boa justificativa para qualquer mudança que pareça injustificada como é. Embora eu não possa dizer que estou acompanhando a situação do .NET Core de perto, parece que ainda há muitas dificuldades e não estou interessado em introduzir mudanças especulativas, contanto que o destino ainda esteja se movendo.

Eu não ficaria surpreso se a compilação condicional acabasse sendo necessária, e não sou contra, desde que possamos mantê-la sã. Se eu ainda puder executar o script de construção para construir o que precisa ser publicado, provavelmente não haverá problema. Devo admitir, porém, que não tenho muita experiência com isso.

Também não sei quais plataformas são desejadas. Essencialmente, se alguém na comunidade nos enviar solicitações de pull que pareçam sustentáveis ​​e que estendam o alcance do AutoFixture, consideraremos aceitá-las.

AFAICT, precisaríamos direcionar netstandard1.X que é o conjunto de APIs que seriam executados em qualquer plataforma que os implementasse (incluindo plataforma cruzada netcore e estrutura de rede no Windows apenas).

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

Em geral, os números mais altos têm mais APIs, mas menos plataformas com suporte. Provavelmente deveríamos começar (continuar) esta discussão entendendo qual X devemos visar em netstandard1.X .

O primeiro parágrafo desse documento me assusta um pouco:

Estamos compartilhando planos iniciais para o futuro da construção de bibliotecas de classe .NET.
- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic também me assusta, mas o fato é que o conceito geral de escolher quais APIs teríamos como alvo seria essencialmente necessário de qualquer maneira. netstandard apenas fornece a eles um nome bem conhecido e subconjuntos acordados e uma maneira mais fácil de descrevê-los. Isso presumindo que queríamos ser portáteis em primeiro lugar.

Por exemplo, se precisarmos de APIs de reflexão para AutoFixture, a lista de alvos que possivelmente poderíamos ter é reduzida. Se precisarmos de coleções simultâneas, o mesmo é verdade. Essas plataformas já existem (net framework full, Windows phone, etc), então acho que não é algo que pode mudar se discutirmos quais APIs precisamos.

Posso [re] iniciar a conversa ... (isenção de responsabilidade: ainda estou aprendendo essas coisas também)

Eu começo com o mais baixo ( netstandard1.0 ) que já está implementado no maior número de plataformas, e procuro as razões pelas quais não podemos (ou não vamos) nos comprometer com essa plataforma.

De acordo com meu entendimento, o netstandard1.0 conjunto de APIs é muito antigo e restritivo. Não tem coisas como:

• System.Linq.Parallel (começa em netstandard1.1 )
• System.Console (começa em netstandard1.3 )
• System.Collections.Concurrent (começa em netstandard1.1 )
• System.ComponentModel.Annotations (começa em netstandard1.1 )
• System.Collections.Specialized (começa em netstandard1.3 )

Isso me leva a pensar que não é prático para a AutoFixtura segmentar netstandard1.0 .

Eu me pergunto se esperar pelo analisador mencionado por @ecampidoglio aqui é uma estratégia melhor.

Editar: aqui está o repositório de ferramentas do analisador de http://dotnetstatus.azurewebsites.net

Desculpe pelo excesso de spam de comentários, vou parar agora :)

Para sua informação, executei o analisador de portabilidade mais recente em um Ploeh.AutoFixture.dll criado localmente a partir da v4 4a7d415 e o resumo é:

Aqui estão algumas alterações que ele recomenda atualmente:

A produção completa está aqui .

@ploeh Muitos componentes amplamente utilizados do Asp.Net Core exigem no mínimo netstandard1.3 . Exemplos disso incluem EntityFrameworkCore (usa 1.3) e Mvc (usa 1.6).

Se o Autofixture usasse qualquer um desses como base, acho que estaria em um bom lugar.

Algum cronograma sobre quando o suporte .Net Core pode estar disponível?

Consegui fazer um build no .NET Core baseado no branch v4. Porém, não tentei construir projetos de teste. Verifique este branch se você deseja criar um pacote.

FWIW, aqui está a comparação entre AutoFixture / AutoFixture v4 e uhaciogullari / AutoFixture net-core . Parece bom 👍

Bem, não é tão simples assim. A existência de project.json causa um erro na construção de projetos csproj regulares agora. Poderíamos migrar todos os projetos para o formato project.json, mas não tenho certeza se é uma boa ideia para os outros projetos. Não os verifiquei em detalhes, mas suspeito que sejam plug-ins para alguns outros frameworks de teste. Não tenho ideia se eles oferecem suporte ao .NET Core também.

Outra coisa é que a Microsoft anunciou que sairá do project.json em breve e voltará para o csproj. Eles prometem uma migração fácil, mas você quer gastar seu tempo para usar esse formato temporário? Está tudo nas tuas mãos. Eu poderia enviar um pacote do meu branch atual, mas a v4 parece um trabalho em andamento.

Existe uma maneira de construir sem erros: # 712

Na verdade, tentei construir a partir do seu branch, mas não gera uma dll. Provavelmente está faltando alguma configuração, mas criar uma pasta extra em cada projeto não me agradou esteticamente.

Existe alguma atualização sobre isso?

Acho que foi prudente esperar até que o conjunto de ferramentas principal .net alcance o status RTM. O conjunto de ferramentas csproj atualizado não será portado para o VS2015 e, portanto, só estará disponível no VS2017. Consulte https://twitter.com/TheCodeJunkie/status/822048014172880900

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

@hoetz você ainda pode instalar a edição da comunidade vs2017.

Existe algum plano para olhar para este problema?

É muito ruim escrever testes para assemblies padrão .NET sem AitoFixture ...

Olá a todos, isso requer alguém da comunidade para intervir e contribuir. Obviamente, é difícil agora porque os problemas do modelo de governança ainda não foram resolvidos (# 703). Alguém também precisa intervir nessa frente.

Estou brincando com o problema. No momento, estou me concentrando apenas em Src \ AutoFixture.sln.

Minha estratégia é converter Src \ AutoFixture \ AutoFixture.csproj para o novo formato de projeto (VS 2017) para que ele possa oferecer suporte a .NET Framework e .NET Standard.

Eu executei o Teste de Portabilidade .NET e o melhor alvo deve ser .NET Standard 1.5 (veja o arquivo em anexo).

Para começar, não vou converter os projetos de teste, embora presuma que possamos querer executar o teste também no tempo de execução do .NET Core no futuro.

AutoFixtureNetPortabilityTest.zip

Ei, @Kralizek - Apenas para sua informação - Tive sucesso com netstandard1.3 em # 712

@Kralizek meu erro, parece que comecei a planejar netstandard1.3 mas na verdade acabei com netstandard1.5 👍

Quase lá. Os testes são todos verdes no .NET Framework. A compilação é toda vermelha no .NET Standard. : D

Encontrei apenas estas categorias de problemas:

Gerador não necessário
Apenas um caso, MailAddressGenerator , porque System.Net.Mail.MailAddress não está disponível no .NET Standard. Solução: todo o arquivo foi "removido" por #if NET40 ... #endif

Serialização
SerializableAttribute, SerializationInfo e StreamingContext não existem no .NET Standard. Além disso, Exception não tem o construtor que aceita esses dois tipos. Usando a diretiva do compilador, removi o atributo e aquele construtor de todas as exceções. Principalmente remover o atributo não é muito bonito.

Uso de reflexão para obter informações sobre um tipo
No .NET Standard, Type é muito mais pobre. Tudo é delegado a um objeto TypeInfo que contém todas as propriedades usadas. O problema é que o .NET Framework ainda usa a antiga classe Type.
Solução:
Eu criei um método de extensão que encaminha o mesmo objeto Type public static Type GetTypeInfo(this Type type) => type; e disponibilizei esse método de extensão apenas no .NET Framework por meio da diretiva do compilador. Este truque resolveu muitas incompatibilidades, deixando os arquivos intactos. Nota: o método de extensão está marcado como internal .

Uso de reflexão para obter a montagem atual
Ok, esse foi difícil porque não conheço perfeitamente o layout do projeto. Usei o ReSharper para verificar rapidamente a hierarquia de classes, mas vocês deveriam verificar novamente.
O arquivo é TerminatingWithPathSpecimenBuilder e a linha é var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; . Parece que você está procurando o assembly em que estamos. Como essa classe não tem herdeiros, é seguro assumir que typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly retorna o mesmo resultado , mas, novamente, posso estar errado. (Coloquei o método de extensão falso entre colchetes). Se minha suposição estiver correta, sugiro marcar esta classe como sealed para evitar o risco de ser herdada e quebrá-la.

De qualquer forma, deixe-me apresentar o novo arquivo do projeto.

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

sim, este é todo o arquivo do projeto.

@Kralizek , você notou que pretendemos segmentar> = net45 no ramo v4 ?

@adamchester não ... Não deve importar tanto, mas vou mudar a estrutura de destino. Obrigado pelo aviso! 👍

A propósito, descobri que System.Threading.Thread está disponível como um pacote .

Ele desbloqueou um novo nível de erros do compilador ... bom: P

.NET Standard 2.0 deve adicionar muito api de volta, talvez valha a pena esperar?

Não, não é. O .NET Standard 2.0 deve ser lançado no terceiro trimestre de 2017. Estamos a um compromisso de oferecer suporte ao .NET Standard 1.5, por que devemos esperar pelo 2.0? Para gerar mensagens de email em um tempo de execução nunca vai suportá-lo?

Além disso, 2.0 vai ser principalmente um shim do framework 4.6 com um monte de NotSupportedException sendo jogado ao redor.

@Kralizek Bastante justo. Eu, claro, adoraria o autofixter lançado mais rápido, então era uma questão mais geral.

FWIW, eu sou o contribuidor que adicionou o suporte para o gerador de endereço de e-mail e, embora seja bom que tenha feito o AutoFixture para ter suporte para isso fora da caixa, não é de forma alguma um aspecto vital do AutoFixture e vale o esforço para espere por isso.

Ter o AutoFixture no padrão .NET mais baixo possível deve ter a maior prioridade, IMHO. Continue com o bom trabalho e, se estiver procurando ajuda ou suporte para testá-lo, posso ajudar.

@Kralizek, o material TypeInfo também está presente no .NET 4.5, então ajudaria.

Foi mordido pelo erro "Package AutoFixture 3.50.5 não é compatível com netcoreapp1.1 (.NETCoreApp, Version = v1.1)" hoje ao começar a adicionar testes a vários projetos .NET Core.

Estou pedindo um tipo de resposta "estado de autofixtura para .net core" que dê uma direção de quando este pacote nuget extremamente útil estará disponível para esta plataforma (e .net core 2.0 já é rtm e está com lançamento pendente ..) .

O que está impedindo isso? (desde já, obrigado)

No momento, estamos trabalhando nisso e você pode acompanhar o progresso em # 773. Observe, este PR é sobre o próprio projeto AutoFixture . Temos mais 9 outros projetos que devem ser migrados, mas isso deve ser feito somente depois que terminarmos o trabalho neste.

O suporte do .NET Core será lançado como v4, você pode encontrar todo o escopo aqui . Eu esperaria alguns meses antes que tudo estivesse pronto.

Enquanto isso, também estamos trabalhando no feed Dev NuGet (# 762), então você poderá participar dos primeiros testes de produto 😉

@zvirja, obrigado pela atualização detalhada. Tenho certeza de que será útil para outros desenvolvedores também. Eu ficaria feliz em participar dos primeiros testes do produto.

@zvirja então, apenas para esclarecer - a abordagem atual (temporária) para escrever testes de unidade em aplicativos / bibliotecas .NET Core é usar AutoFixture em, por exemplo, .NET 4.7 projetos de teste e migrar o (s) projeto (s) de teste para o .NET Core posteriormente?

Esta é a solução alternativa sugerida por enquanto? (contanto que o aplicativo que estou escrevendo tenha permissão para ser totalmente .NET Core, na verdade não é um grande problema escrever os testes em um ambiente .NET 4.7 normal).

@andersborum Nunca pensei sobre a solução temporária. Não tenho certeza se todas as APIs que usamos na v3 (pacotes, publicados no NuGet) são compatíveis com .Net Standard 2.0 (para usar um novo recurso do .NET Standard).

Deixe-nos saber se você encontrou uma maneira de combinar v3 e .Net Core, para que possamos aconselhar outras pessoas 😉

Apenas para notificar a todos - o suporte .Net Standard para AutoFixture PR (# 773) foi incorporado ao branch v4 . Você pode consumir o pacote de nosso feed privado .

Observe, apenas a biblioteca AutoFixture foi migrada. Outras bibliotecas de cola seguirão posteriormente.

É possível mover a v4 para o nuget.org, mesmo a versão alfa? Não foi possível encontrar nada comparável ao autofixture até agora que suporte .netstandard.
A data de lançamento da v4 já está decidida?

@RomanKernSW Não neste momento - ainda não migramos nem a metade dos projetos (como suporte para xUnit, NUnit, NSubstitute), então é muito cedo. Também temos um plano para mudar o namespace , então eu prefiro fazer isso _antes_ de lançarmos algo publicamente, pois isso seria uma grande pausa entre os lançamentos. Por outro lado, quero mudar o namespace o mais tarde possível, já que constantemente mesclamos master em v4 e será um inferno fazer isso após a mudança.

Você tem problemas com o feed privado? Você pode adicionar o feed por meio de NuGet.config se for extremamente necessário.

hm Eu tenho que verificar se é possível usar o nuget.config para restauração do nuget (.Net Core 2 - tarefa de visualização em VSO). No momento, temos um Feed privado (VSO) com nuget.org sem nenhum arquivo nuget.config. Precisa de tempo para testar isso ...

.Net Standard 2.0 tem um modo de compatibilidade para .Net Framework NuGets.
Eu escrevi testes .Net Core com AutoFixture 3.50.x e sem problemas então
distante.

@roarwrecker Incrível, obrigado por compartilhar! O que significa que temos um buffer de tempo maior até lançarmos o suporte oficial ao NuGet: wink:

@roarwrecker thanks ... este não era o problema no .netstandard 1.6. Eu poderia instalar o nuget, mas nunca compilar sem erros

Ei pessoal, não tenho certeza de quão longe está o trabalho .NetCore, mas é possível obter uma versão alfa no NuGet?

@selmendorfFrontline Copiando a resposta daqui :

Publicar a versão de pré-lançamento no NuGet é uma pergunta um tanto dolorosa para mim. Embora tenhamos começado a oferecer suporte ao .NET Core para a maioria dos projetos , temos um plano para alterar o namespace padrão . Esta seria uma grande mudança significativa para nossos clientes e todo o código do cliente parará de compilar. Este é o ponto em que a confusão aparece:

• se liberarmos alpha com o namespace existente e alterarmos o namespace entre alpha e RTM, isso irá confundir nossos clientes, pois eles já viram a v4 com o namespace existente. Quero que nossos clientes sintam que a v4 sempre foi lançada com um novo namespace conforme o modelo de governança era alterado.
• se liberarmos alpha com o namespace alterado, não poderemos mais mesclar master com v4 branch sem problemas. Atualmente nos comprometemos com as duas ramificações, é por isso que gostaria de adiar a alteração do namespace para o fim. Outro ponto é que nossa documentação não está pronta no momento, então as pessoas podem simplesmente não entender por que todas as importações de namespace são inválidas e que elas precisam simplesmente executar uma substituição de texto. Isso os tornará assustadores e a experiência não será tão tranquila quanto eu desejo.

A melhor maneira de resolver essa situação seria não liberar alpha e liberar apenas o RTM. Infelizmente, não posso fornecer um ETA preciso, pois depende da minha capacidade (estou trabalhando neste projeto no meu tempo livre) e da disponibilidade de outros contribuidores (meus PRs devem ser revisados ​​😉). Na minha cabeça, imagino o lançamento em um ou dois meses e espero que aconteça dentro desse intervalo. Este projeto ficou inativo por cerca de 9 meses devido à mudança no modelo de governança - esse é o principal motivo do atraso no suporte.

Por favor, use o pacote do feed de visualização enquanto isso. Você pode ajustar seu Nuget.config conforme mencionado acima, então isso deve ser um problema.

Vou encerrar este problema depois que o # 857 for finalmente mesclado. Nossa tabela final de compatibilidade com .NET seria a seguinte:

| Produto | .NET Framework | .NET Standard |
| ------------------ | ------------------------ | ------------------------ |
| 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: |
| Idioms | : 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 as bibliotecas não suportadas, exceto Idioms.FsCheck não podem ser atualizadas porque suas dependências não suportam .Net Standard e é improvável que o façam (a maioria delas estão obsoletas). Tentei portar Idioms.FsCheck para suportar .NET 452 e .NET Standard 2.0 (visto que é tecnicamente possível), mas não consegui fazer funcionar. Parece que o F # SDK ainda é muito difícil e precisamos esperar por novos lançamentos. A compilação e o carregamento do projeto simplesmente falham depois que eu defino TargetFrameworks node.

A menos que alguém tenha outra visão, vou seguir este plano 😃 Também sinto o quão perto estamos do lançamento e o quanto está para trás 😊

Vai! Vai! Vai!

Tentei transferir Idioms.FsCheck para oferecer suporte a .NET 452 e .NET Standard 2.0

Você já tentou mudar para uma versão mais recente do F # nesse? IIRC, está no F # 3.1 e pode ser o caso.

Ótimo trabalho @zvirja. Você acha que podemos lançar a v4? Quanto mais perto chegamos, mais animado eu fico :)

Eu gostaria de poder te oferecer uma cerveja :)

Você já tentou mudar para uma versão mais recente do F # nesse? IIRC, está no F # 3.1 e pode ser o caso.

@moodmosaic Yep. Se você verificar o FsCheck 2.9.0 , descobrirá que ele depende de FSharp.Core (>= 4.1.17) , portanto, não tive outra escolha 😅 O problema é com o SDK. Se eu começar a direcionar os dois frameworks simultaneamente, não consigo carregar a solução no VS
Projeto:

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

Tentando abrir no VS:

Está tudo bem com o projeto - o problema está em algum lugar no F # SDK. É por isso que eu gostaria de adiar o suporte do .NET Core pelo FsCheck para tempos melhores.

@Kralizek Por favor, veja a resposta algumas respostas acima .

Acabei de verificar no VS 2017.4 e ainda não posso direcionar vários frameworks para o projeto F #. Portanto, estou encerrando este problema por enquanto, pois oferecemos suporte ao .NET Core para todos os outros projetos.

JFYI: Eu lancei a v4 rc1 para o NuGet, para que você possa consumir e testar sem precisar brincar com um feed personalizado.