Aspnetcore: Discussão: ASP.NET Core 3.0 só será executado no .NET Core

Criado em 29 out. 2018  ·  213Comentários  ·  Fonte: dotnet/aspnetcore

Este é um item de discussão para https://github.com/aspnet/Announcements/issues/324.

Comentários muito úteis

"Matando .NET Framework", episódio 2: mesma história, mesmos personagens : rofl:

Infelizmente, isso apenas destaca uma coisa: você falhou completamente em fazer do .NET Standard o carro-chefe do ecossistema .NET . Não se move tão rápido quanto deveria e nada mais é do que um mínimo denominador comum que é sempre atualizado no último momento, quando todas as plataformas incluem (ou estão prestes a incluir) as novas APIs.

Talvez seja só eu, mas nunca entendi por que não foi tão rápido quanto netcoreapp (que é o primeiro a obter as novas APIs, por definição).

Você é autor de um pacote NuGet e deseja que eles usem as coisas mais recentes? Almeje a versão netstandard recente: claro, inicialmente, apenas aplicativos baseados em netcoreapp serão capazes de usá-los, mas eventualmente outras plataformas - como Xamarin, Mono ou .NET Framework - irão alcançá-los e as pessoas poderão usar seus pacotes sem exigir que você altere nada. É assim que as coisas deveriam funcionar.

Claro, pode demorar um pouco para as plataformas não .NET Core como o .NET Framework se atualizarem, pois os lançamentos são mais raros e a barra de estabilidade muito mais alta, mas mesmo que leve 6, 12 ou mesmo 18 meses, eu não Acho que é um problema, porque é isso que as pessoas querem ao usar o .NET Framework: uma estrutura estável, não um alvo que se move rapidamente.

IMHO, seria uma abordagem muito melhor fazer com que o ASP.NET Core 3.0 visasse um novo netstandard TFM expondo todas as APIs do .NET Core de que você precisa. Quando tiver certeza de que as novas APIs são estáveis ​​o suficiente, faça o backport delas para o .NET Framework para que sejam compatíveis com o padrão mais recente.

Tenho certeza de que as pessoas prefeririam ter que esperar alguns meses antes de poder mover seu aplicativo .NET Framework para a versão mais recente do ASP.NET Core em vez de serem bloqueados para sempre em uma versão antiga com um suporte super curto de 3 anos.

Faça o que você prometeu: torne o .NET Framework uma estrutura estável que evolui mais lentamente, em vez de um beco sem saída para aqueles que confiaram em você ao migrar para o ASP.NET Core.

Todos 213 comentários

Acho que agora faz muito sentido no quadro geral. Tanto o .NET Core quanto o ASP.NET Core já existem há tanto tempo que as pessoas já tiveram ou ainda têm a chance de mudar para ele, sem causar grandes problemas (em comparação com quando o suporte foi interrompido pela primeira vez no passado com 2.0) .

No entanto, estou triste com as implicações para certos componentes do ASP.NET Core que podem existir atualmente como dependências separadas. Porque isso provavelmente significará que os componentes individuais deixarão de oferecer suporte ao padrão de rede, exigindo netcoreapp3.0; e especialmente com o # 3756, esses componentes seriam inutilizáveis ​​fora de um contexto ASP.NET Core.

Por exemplo, projetos como RazorLight serão então efetivamente forçados a abandonar o .NET Framework e, mais importante, o suporte ao .NET Standard em geral.

Isso deixará muitas pessoas que venderam a mudança para o novo modelo de programação ASP.NET Core em suas organizações para permanecerem em uma plataforma com suporte e ativamente desenvolvida no frio em uma plataforma sem suporte em menos de 3 anos (. NET Core 2.1 LTS).

Não tenho certeza de quais análises você usou para justificar esta mudança, mas para a execução de aplicativos ServiceStack ASP.NET Core no .NET Framework , estamos vendo que o modelo web-corefx mais popular para a execução de projetos ASP.NET Core no O .NET Framework tem mais de 1/3 (33,8%) de compartilhamento do que o mesmo modelo da web vazio que é nosso modelo de projeto mais popular para execução no .NET Core.

IMO 3 anos não é tempo suficiente para abandonar Clientes que começaram ou mudaram para o novo modelo de programação ASP.NET (para escapar da plataforma ASP.NET Framework estagnada) apenas para descobrir agora que a plataforma que eles venderam para a organização para a qual mudar foi abandonada.

Por alguma razão, existem clientes que não podem migrar para o .NET Core por dependerem apenas de dependências do .NET Framework. Se a MS não quiser manter o suporte para .NET Framework no ASP.NET Core 3.0 no futuro IMO, você deve estender o suporte para ASP.NET Core 2.1 no .NET Framework por um período estendido, como 7 anos. As migrações de sistemas de produção existentes podem levar anos, desde o início do .NET Core, está claro que o ASP.NET Framework foi deixado para estagnar com a posição oficial de que o ASP.NET Core é o futuro modelo de programação para .NET, agora os mesmos clientes serão logo começarão a descobrir que o novo modelo de programação para o qual eles mudaram / estão mudando não será mais compatível em alguns anos. A melhor maneira de acomodar esses clientes .NET existentes é oferecer suporte ao .NET 2.1 por um período LTS adicional, pelo menos para patches de segurança (de preferência, para resolver bugs também).

"Matando .NET Framework", episódio 2: mesma história, mesmos personagens : rofl:

Infelizmente, isso apenas destaca uma coisa: você falhou completamente em fazer do .NET Standard o carro-chefe do ecossistema .NET . Não se move tão rápido quanto deveria e nada mais é do que um mínimo denominador comum que é sempre atualizado no último momento, quando todas as plataformas incluem (ou estão prestes a incluir) as novas APIs.

Talvez seja só eu, mas nunca entendi por que não foi tão rápido quanto netcoreapp (que é o primeiro a obter as novas APIs, por definição).

Você é autor de um pacote NuGet e deseja que eles usem as coisas mais recentes? Almeje a versão netstandard recente: claro, inicialmente, apenas aplicativos baseados em netcoreapp serão capazes de usá-los, mas eventualmente outras plataformas - como Xamarin, Mono ou .NET Framework - irão alcançá-los e as pessoas poderão usar seus pacotes sem exigir que você altere nada. É assim que as coisas deveriam funcionar.

Claro, pode demorar um pouco para as plataformas não .NET Core como o .NET Framework se atualizarem, pois os lançamentos são mais raros e a barra de estabilidade muito mais alta, mas mesmo que leve 6, 12 ou mesmo 18 meses, eu não Acho que é um problema, porque é isso que as pessoas querem ao usar o .NET Framework: uma estrutura estável, não um alvo que se move rapidamente.

IMHO, seria uma abordagem muito melhor fazer com que o ASP.NET Core 3.0 visasse um novo netstandard TFM expondo todas as APIs do .NET Core de que você precisa. Quando tiver certeza de que as novas APIs são estáveis ​​o suficiente, faça o backport delas para o .NET Framework para que sejam compatíveis com o padrão mais recente.

Tenho certeza de que as pessoas prefeririam ter que esperar alguns meses antes de poder mover seu aplicativo .NET Framework para a versão mais recente do ASP.NET Core em vez de serem bloqueados para sempre em uma versão antiga com um suporte super curto de 3 anos.

Faça o que você prometeu: torne o .NET Framework uma estrutura estável que evolui mais lentamente, em vez de um beco sem saída para aqueles que confiaram em você ao migrar para o ASP.NET Core.

Eu não gosto disso No início do .net core, a Microsoft não escolheu mono ou .net framework como uma plataforma cruzada e você disse que há vários .net runtime lá, então você projeta o .netstandard , agora ainda há muitos pacotes nuget que não suportam o núcleo .net (razão média). Muitos desenvolvedores deixarão para trás o antigo modelo de programação principal do asp.net se o núcleo do asp.net for executado apenas no núcleo .net. então .net standard existirá apenas no nome (pelo menos para o núcleo do asp.net, as pessoas começam a construir pacotes netcoreapp apenas).
Talvez um dia, o núcleo .net possa substituir a estrutura .net na janela, mas e quanto a mono e outras plataformas dependem de mono (xamarin, unit3d).
e outra razão porque prefiro o framework .net é que o framework .net core share é realmente enorme, quão grande é a sua pasta C:/program file/dotnet se você atualizar seu aplicativo do .net core 2.0 para o .net core 2.1 mais recente? Há um arquivo GBs na minha pasta, e ele aumenta quando atualizo o tempo de execução do núcleo .net. mas o framework .net irá apenas substituir a versão antiga.

Faça o que você prometeu: torne o .NET Framework uma estrutura estável que evolui mais lentamente, em vez de um beco sem saída para aqueles que confiaram em você ao migrar para o ASP.NET Core.

FWIW esta seria a estratégia ideal, minha sugestão de estender o LTS é a barra mínima para dar mais tempo aos clientes existentes que foram comercializados agressivamente para migrar para ASP.NET Core que agora foram abandonados em uma plataforma futura sem suporte com isso anúncio.

O padrão .net é uma piada? Espero que a equipe mono bifurque repos aspnetcore e renomeie para aspnetmono, caso contrário, posso deixar a pilha .net.😔

Acho que isso significa que, no meu trabalho, nunca usaremos o ASP.NET Core. Nós ficaremos no ASP.NET para sempre, não importa em portar um aplicativo para o Core, porque agora isso envolveria ainda mais mudanças.

Claro, se seu objetivo é não sofrer alterações, você pode continuar fazendo a mesma coisa para sempre. Onde eu trabalho, começamos a usar o ASP.NET Core alguns anos atrás, inicialmente rodando no .NET Framework. Com o tempo, conforme a plataforma .NET Core amadurecia e ganhava recursos, mudamos nossos projetos para o netcoreapp. Um ou dois projetos mais antigos ainda estão usando ASP.NET, e não temos planos de reescrevê-los - é um código funcional. Mas, para as novidades, estamos ansiosos por recursos como o Span.

A mudança pode ser adiada, mas não é algo que você pode ou deve evitar para sempre - a tecnologia _é_ mudança e o trabalho do desenvolvedor sempre exigirá aprender coisas novas. Se você estiver usando ASP.NET Core no .NET Framework hoje, é improvável que demore três anos de trabalho para movê-lo para o .NET Core.

Venha para o .NET Core, a água está quente ...

Por alguma razão, existem clientes que não podem migrar para o .NET Core porque dependem apenas de dependências do .NET Framework ...

Mais seriamente, você pode usar as bibliotecas .NET 4.x no .NET Core 2.0 desde .NET Standard 2.0 ; embora haja a possibilidade de eles usarem alguns recursos que o .NET Core não possui; embora exista o Pacote de Compatibilidade do interoperabilidade COM e outros modelos de aplicativos como WinForms e WPF etc.

Quaisquer bloqueadores que impeçam um aplicativo ASP.NET Core de mover para o .NET Core do .NET Framework provavelmente devem ser criados em dotnet / corefx .

Para Xamarin; Posso estar errado, mas presumo que seja improvável que você o use para executar um servidor da web no iOS ou Android.

Para aplicativos cliente Mono, o servidor da web pode ficar sem processo e ser executado no .NET Core enquanto a IU é executada no Mono. O Kestrel nunca foi capaz de rodar em uma plataforma Big Endian que corta algumas das outras plataformas do Mono, embora os sabores BSD sejam atualmente uma lacuna do .NET Core.

Pela unidade; os jogos fazem todo tipo de coisa estranha, então talvez esse seja um cenário não coberto; se o jogo estava usando o servidor web no cliente; em vez de em um servidor ou fora do proc; quando o .NET Core pode executar essa parte.

Fora do modelo de aplicativo ASP.NET Core; por exemplo, para bibliotecas .NET Standard é mais importante, pois o ASP.NET Core tem todos os tipos de recursos úteis, sendo o Razor um exemplo particular.

Nem todas as bibliotecas estão mudando apenas para .NET Core (por exemplo, Microsoft.Extensions.* permanecem como .NET Standard) e provavelmente seria útil fornecer cenários específicos que seriam afetados como @daveaglick fez em https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416 para que possam ser levados em consideração; sobre quais bibliotecas e / ou recursos específicos podem ser mantidos disponíveis no .NET Standard, ao invés de apenas um nebuloso "tudo".

O ASP.NET Core está gerando muitas mudanças e novas apis no .NET Core e eu posso entender o desejo de usar esses recursos (já que esse era um de seus casos de uso); caso contrário, é um pouco autodestrutivo.

Por outro lado, seria bom se eles também estivessem em uma versão do .NET Standard, para que outros tempos de execução pudessem oferecer suporte ao ASP.NET Core 3.0 quando eles começassem a implementá-lo. Realisticamente, isso não seria tão cedo (já que o .NET Standard 2.1 ainda não foi finalizado e precisaria ser uma versão além disso).

Talvez o modelo de aplicativo ASP.NET Core retorne ao .NET Standard posteriormente, quando as coisas melhorarem? Embora possa estar sempre indo rápido demais para o processo do .NET Standard, conforme funciona atualmente?

@gulbanana e se o seu núcleo do asp.net no .net framework usando com? ou há um pacote nuget que suporta apenas a estrutura .net?

Acredito que nunca foi uma questão de se a mudança deveria ser feita ou não, mas apenas quando.
Da última vez que isso causou uma ~ discussão ~ tempestade, o ecossistema não estava pronto para permitir a portabilidade de aplicativos existentes.
Agora existem os pacotes de compatibilidade do Windows e WinForms e WPF estão chegando ao .NET Core.

Acho que os pacotes 2.1 disponíveis para o .NET Framework fornecem um bom caminho de migração: migre para o 2.1 no netfx e depois para o .NET Core.

Isso é semelhante a AngularJS vs Angular: migre o código existente para componentes (hard) no último 1. * e, em seguida, vá para a versão Angular mais recente. É muito difícil, mas factível.

Com novos recursos interessantes sendo adicionados ao CoreCLR e mono (por exemplo , métodos de interface padrão ou apenas Span rápidos) que nunca chegaria ao .NET Framework, parece razoável deixar o .NET Framework para trás em algum ponto.
Isso não significa necessariamente "não oferecer suporte" ao .NET Framework, mas apenas deixá-lo como está.

Ainda existem alguns sites por aí que usam ASP clássico (não ASP.NET, mas o material realmente antigo). Ele ainda funciona e vem no Windows, você simplesmente não criaria novos aplicativos com ele.
Eu acredito que em menos de 10 anos, esta pode ser a situação com o .NET Framework.

Eu concordo com o suporte estendido solicitado para 2.1, mas gostaria que a equipe monitorasse os downloads de pacotes 2.1 para tomar uma decisão em 2-3 anos se precisariam de suporte (= corrigir problemas de segurança importantes) por um tempo um pouco mais.

@ John0King COM terá suporte no .NET Core 3.0.

Além disso: temos aplicativos legados que usam coisas como .NET Remoting.
Mas esses já são legados.

O mundo basicamente roda em código legado e continuará a fazê-lo. É uma decisão de negócios de portar ou não algo para uma coisa "com suporte" ou mesmo "nova", mas até então, como @dylanbeattie coloca:

img_6086 3

Sim, vale a pena mencionar que se algo é “suportado” não é tão relevante - aplicativos antigos não precisam realmente ser portados para uma nova estrutura só porque está disponível. Os servidores da Web são um caso um tanto especial devido às ameaças à segurança. Um longo período de suporte a patch de segurança para o LTS ajudaria as pessoas.

@gulbanana É apenas adicionar uma barra mais alta para portar aplicativos de System.Web para ASP.NET Core, já que você precisa alterar a estrutura da web, a estrutura de aplicativo subjacente e, em seguida, atualizar ou trocar quaisquer dependências incompatíveis (que podem envolver a compra de novos licenças).

Se você fizesse uma análise de custo / benefício, não tenho certeza se seria benéfico para o ASP.NET Core.

Isso é especialmente aplicável quando você desenvolve software com base em projeto e, claro, cada projeto tem orçamento apertado o suficiente, então, embora a manutenção regular seja possível, é difícil justificar a troca de todo o framework sem um benefício tangível aparente .

Se você fizesse uma análise de custo / benefício, não tenho certeza se seria benéfico para o ASP.NET Core.

Então .. bem .. deixar isso? Se você não precisa migrar para o ASP.NET Core, não faça isso.
Não estou tentando soar sarcástico nem nada, mas se não houver necessidade de manter um aplicativo com as "últimas novidades", não faça o port. O benefício é que o .NET Framework / ASP.NET classic ainda tem suporte e seu aplicativo será executado como está.

A portabilidade é freqüentemente desnecessária, eu concordo - ASP.NET para ASP.NET Core é uma grande mudança, e parte dessa mudança é que o Core se move mais rapidamente (3.0 terá alterações de quebra de api também, assim como 2.0). Esta questão de discussão é sobre a mudança de netfx para corefx, e para a maioria dos aplicativos ASP.NET Core que não é

Isso parece remover o ponto intermediário "ASP.NET Core no .NET Framework" que tornaria as migrações muito mais graduais e fáceis. Depois disso, migrando uma ASP.NET MVC / WebAPI / etc. a aplicação ao ASP.NET Core será uma mudança muito grande, mudando a estrutura da web e os tempos de execução subjacentes de uma só vez.

Para aplicativos de grandes empresas, espero que isso seja muito doloroso. Minha equipe está observando isso de perto há um ou dois anos, mas:

  • EntityFrameworkCore não faz tudo o que exigimos, e somente agora, com o .NET Core 3.0, o próprio EntityFramework está chegando ao .NET Core. Quanto disso e em quais plataformas ele será executado, não acredito que tenha sido comunicado claramente, e provavelmente terei de realmente testar uma versão de visualização para ver.

  • A história do OData parece ainda estar no ar em termos de aplicativos em grande escala. Há uma quantidade _substancial_ de (re) trabalho necessário para mover de OData 3 / System.Data.Services para OData 4 / WebAPI e assim por diante. Isso é algo que não é resolvido há vários anos e, honestamente, não tenho certeza se algum dia será.

Além disso, agora teríamos que cortar todas as outras tecnologias sem suporte (AppDomains, Remoting, etc.) _primeiro_, em vez de poder fazer esse trabalho em paralelo ou em um estágio posterior.

Além disso, agora teríamos que eliminar todas as outras tecnologias sem suporte (AppDomains, Remoting, etc.) primeiro, em vez de poder fazer esse trabalho em paralelo ou em um estágio posterior.

Por que você não pode migrar para o 2.1 primeiro?

@davidfowl Provavelmente poderíamos usar isso como um intermediário, a menos que encontremos algum novo recurso em 3.0 / 3.1 / etc. que precisamos para migrar. Eu não fiz uma análise completa ainda, nós fomos bloqueados principalmente no EF e OData até agora.

Novo recurso do ASP.NET Core 2.1 que é necessário para migrar? Eu quis dizer ASP.NET Core 2.1 no .NET Framework.

Quando esse problema surgiu há alguns anos, lembro-me de reclamar que era muito difícil transferir tudo. Aqui está uma citação de um antigo comentário do github que fiz naquela época:

imagine aplicativos da web que usam Active Directory ou automação Office COM, ou que fazem miniaturas usando alguma biblioteca baseada em System.Drawing ou compartilham código com um aplicativo WPF

O legal é que, a partir do .NET Core 3.0, todos esses cenários são suportados. Muito trabalho foi feito para tornar isso mais fácil.

@davidfowl também eu.

Hipoteticamente, pode haver algum recurso que estamos usando na ASP.NET/MVC/WebAPI que não foi implementado no 2.1, mas chega em uma versão posterior. Nesse caso, 2.1 não seria um trampolim viável.

Eu teria que fazer uma análise mais completa, para ver se há realmente algo crítico de que precisamos que não esteja no 2.1.

@PinpointTownes

Infelizmente, isso apenas destaca uma coisa: você falhou completamente em fazer do .NET Standard o carro-chefe do ecossistema .NET . Não se move tão rápido quanto deveria e nada mais é do que um mínimo denominador comum que é sempre atualizado no último momento, quando todas as plataformas incluem (ou estão prestes a incluir) as novas APIs.

Você não está errado, mas de certa forma ignora os objetivos do .NET Standard. O objetivo do padrão nunca foi conduzir a inovação, mas conduzir a convergência. Se você abordar desse ângulo, é por design uma coisa que tem que ficar para trás, porque temos que pensar sobre quais conceitos podem ser universais ou mesmo deveriam ser universais. Se você está curioso para saber como é isso, eu o convido a dar uma olhada nos mais de 35 PRs que mesclei nas últimas três semanas após a revisão de todos os proprietários de implementação .NET.

Vemos o .NET Core como a plataforma de ponta onde a inovação acontece. Construímos vários recursos que nos permitem lidar com a rotatividade e os riscos que vêm com isso, muito melhor do que o .NET Framework tinha. No entanto, nem todos os recursos importantes para o ecossistema .NET fazem parte da experiência do .NET Core. Por exemplo, a compilação antecipada é muito mais proeminente no Xamarin e no Unity. E quando pegamos os recursos do .NET Core e os adicionamos ao padrão, precisamos considerar seus ambientes de tempo de execução, sistemas operacionais e restrições de hardware.

Talvez seja só eu, mas nunca entendi por que não foi tão rápido quanto netcoreapp (que é o primeiro a obter as novas APIs, por definição).

A realidade é que "mover rapidamente e quebrar as coisas" não é algo que todo o nosso público aprecie. Já é ruim o suficiente se tivermos que remover APIs nas versões principais do .NET Core, mas é virtualmente impossível de fazer com o .NET Standard. Portanto, temos que nos mover um pouco mais devagar e incluir apenas conceitos que acreditamos serem maduros o suficiente para serem adicionados.

Faça o que você prometeu: torne o .NET Framework uma estrutura estável que evolui mais lentamente, em vez de um beco sem saída para aqueles que confiaram em você ao migrar para o ASP.NET Core.

Isso ainda pressupõe que o .NET Framework eventualmente obterá todos os recursos que o .NET Core possui, mas com um atraso. Aprendemos que isso simplesmente não é realista. Podemos decidir não inovar drasticamente no .NET Core ou aceitar a realidade da engenharia de que uma boa parte dos novos recursos nunca retornará ao .NET Framework. Acreditamos que atendemos melhor aos nossos clientes para preservar a proposta de valor central do .NET Framework (uma plataforma de desenvolvimento rica e madura), ao mesmo tempo permitindo que os clientes explorem novos recursos no .NET Core. No futuro, espero que estejamos mais dispostos a inovar em áreas que requerem mudanças de tempo de execução, biblioteca e linguagem, como fizemos para Span<T> . Embora essas coisas sejam caras, elas também nos permitem mudar a maneira como as pessoas podem escrever códigos. Um bom exemplo disso são as implementações padrão de interfaces, a capacidade de criar código genérico envolvendo aritmética, ser capaz de usar intrínsecos de hardware etc. E esses recursos são provavelmente exatamente do tipo que não faremos backport para .NET Framework devido ao risco .

Acho que faz todo o sentido que nossa pilha da web seja capaz de explorar esses recursos; e a única maneira de fazer isso é remover a limitação do ASP.NET Core para executar no .NET Framework também. Lembre-se de que o motivo original pelo qual fizemos o ASP.NET Core rodar no .NET Framework foi porque o .NET Core simplesmente não tinha APIs suficientes. No .NET Core 3.0, teremos mais de 120k das APIs existentes . Isso é mais da metade de todo o .NET Framework e ainda inclui WinForms e WPF. Sim, ainda há um grande número de APIs ausentes, mas fizemos grandes incursões na longa cauda. Embora nunca tenhamos uma paridade de 100%, espero que possamos fechar essa lacuna ainda mais no futuro, com base nos dados dos clientes.

@ yaakov-h Eu ficaria surpreso se fosse esse o caso. Quando você fizer a análise, me avise.

Você não está errado, mas de certa forma ignora os objetivos do .NET Standard. O objetivo do padrão nunca foi conduzir a inovação, mas conduzir a convergência.

E você está indo exatamente na direção oposta: abandonando o .NET Standard para o ASP.NET Core porque ele não se move rápido o suficiente, forçando os pacotes NuGet direcionados ao ASP.NET Core a abandoná-lo também. Não me faça pensar que é convergência, não sou tão ignorante : rofl:

Se você abordar desse ângulo, é por design uma coisa que tem que ficar para trás, porque temos que pensar sobre quais conceitos podem ser universais ou mesmo deveriam ser universais.

É uma escolha, não um problema técnico: nada impede que você determine se uma determinada API deve ser incluída em uma nova versão do .NET Standard ao revisá-la para inclusão no corefx / coreclr.

Se você está curioso para saber como é isso, eu o convido a dar uma olhada nos mais de 35 PRs que mesclei nas últimas três semanas após a revisão de todos os proprietários de implementação .NET.

Não estou dizendo que é uma tarefa fácil e isso prova meu ponto: você está esperando demais para criar novas versões de netstandard e, nas raras vezes que você faz isso, é um processo doloroso porque vem com toneladas de novas APIs ao mesmo tempo.

A realidade é que "mover rapidamente e quebrar as coisas" não é algo que todo o nosso público aprecie.

No entanto, é exatamente assim que funciona cada iteração do ASP.NET Core: ela vem com mudanças significativas (às vezes massivas) que tornam os pacotes escritos para uma versão incompatível com as próximas. Ainda assim, você não nos dá muitas opções: atualizar ou permanecer nas versões legadas para sempre, com uma política de suporte que não tem nada a ver com o que tínhamos (não é apenas ASP.NET/.NET, o ciclo de vida do Windows também é muito mais curto atualmente).

No futuro, espero que estejamos mais dispostos a inovar em áreas que exigem mudanças de tempo de execução, biblioteca e linguagem, como fizemos para Span. Embora essas coisas sejam caras, elas também nos permitem mudar a maneira como as pessoas podem escrever códigos. Um bom exemplo disso são as implementações padrão de interfaces, a capacidade de criar código genérico envolvendo aritmética, ser capaz de usar intrínsecos de hardware etc. E esses recursos são provavelmente exatamente do tipo que não faremos backport para .NET Framework devido ao risco .

O que o impede de introduzir uma nova versão lado a lado do .NET Framework (digamos, .NET Framework 5) que inclui essas alterações "arriscadas"? Novamente, não é um problema técnico.

Alguma chance de promover Microsoft.AspNetCore.Razor.Language e Microsoft.AspNetCore.Razor fora de aspnet ou mantê-lo na onda netstandard ? Mesmo que o razor seja apenas para html, existem várias bibliotecas que o usam para modelos de e-mail e seria ótimo se pudéssemos continuar usando-o como está.

Essa mudança mostra a falta de suporte para netstandard no roteiro do .NET, ao contrário do que foi dito antes. Se uma das principais novas bibliotecas abandona o netstandard, não é um bom presságio para sua adoção.

Esta é uma mudança que agora os desenvolvedores .NET devem antecipar para todas as outras novas bibliotecas desenvolvidas pela Microsoft em aberto? A comunidade pode obter uma declaração mais oficial sobre o futuro do netstandard e sua adoção?

@terrajobst Eu entendo totalmente o que você disse sobre não adicionar a .netstandard aquelas APIs que não parecem estar prontas para abranger todas as plataformas (e provavelmente nunca estarão). No entanto, isso não impediu que você (MS) introduzisse o netstandard2.0 quando, por exemplo, o UWP não estava pronto para suportá-lo. Pelo que entendi, foi necessário um esforço notável para adicionar esse suporte algum tempo depois, mas você conseguiu. Isso era de alguma forma uma história diferente?

E você está indo exatamente na direção oposta: abandonando o .NET Standard para o ASP.NET Core porque ele não se move rápido o suficiente.

ASP.NET Core só faz sentido no .NET Framework e .NET Core, mas o .NET Standard precisa ser implementado por todos. Simplesmente não faz sentido, por exemplo, fazer o Xamarin / Unity fornecer APIs que são predominantemente usadas por uma pilha da web de servidor.

É uma escolha, não um problema técnico: nada impede que você determine se uma determinada API deve ser incluída em uma nova versão do .NET Standard ao revisá-la para inclusão no corefx / coreclr.

Isso é o que fizemos nos dias do .NET Core v1. Separamos o padrão do .NET Core com v2. Então, sim, é uma escolha, mas não foi arbitrária. O objetivo era ser capaz de se mover mais rápido com o .NET Core. Simplesmente leva mais tempo para considerar como os recursos funcionam no contexto de N outros tempos de execução do que um único.

é um processo doloroso porque vem com toneladas de novas APIs ao mesmo tempo.

Não, é um processo doloroso porque você tem que revisar o design com vários implementadores e vários tempos de execução diferentes. No entanto, fazer isso após o fato, agregado e empacotado é muito mais barato do que ter que coordenar isso à medida que avançamos. O repo CoreFx é um repo de alto volume. É muito mais fácil para o Xamarin e o Unity revisar os recursos agrupados do que beber da mangueira de incêndio e se inscrever em todas as discussões de API no CoreFx.

No entanto, é exatamente assim que funciona cada iteração do ASP.NET Core: ela vem com mudanças significativas (às vezes massivas) que tornam os pacotes escritos para uma versão incompatível com as próximas.

E porque você não gosta disso, quer impor isso a todos, tornando o .NET Standard compatível com o .NET Core? Desculpe, mas este argumento não faz sentido para mim.

O que o impede de introduzir uma nova versão lado a lado do .NET Framework (digamos, .NET Framework 5) que inclui essas alterações "arriscadas"? Novamente, não é um problema técnico.

O que te faz pensar que não é um problema técnico? Enviar versões lado a lado do .NET Framework não é uma solução viável. Em primeiro lugar, é bastante caro devido ao fato de ser um componente do sistema operacional e, portanto, precisa de manutenção. Você não tem ideia de quão complexa é nossa estratégia de ramificação / manutenção / patch para .NET Framework 3.5 e 4.x. Adicionar um terceiro é quase impraticável. Em segundo lugar, apenas fazer isso também traz riscos, pois precisamos fazer alterações na ativação para selecionar o tempo de execução correto para coisas como componentes gerenciados ativados por COM. E isso levanta a questão de saber se também suportamos in-proc lado a lado e com quantas combinações. Não é uma tarefa simples e também não está isenta de riscos.

Não me faça pensar que é convergência

@PinpointTownes É convergência ... no .NET Core 😉

Simplesmente não faz sentido, por exemplo, fazer o Xamarin / Unity fornecer APIs que são predominantemente usadas por uma pilha da web de servidor.

Existem pessoas que gostariam de usar o ASP.NET Core não apenas no .NET Core, mas também no UWP, então por que não também no Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

Há uma diferença entre algo que não faz sentido - para você - e algo que você não deseja apoiar.

O repo CoreFx é um repo de alto volume. É muito mais fácil para o Xamarin e o Unity revisar os recursos agrupados do que beber da mangueira de incêndio e se inscrever em todas as discussões de API no CoreFx.

Eu sugeri uma abordagem tão extrema? Tenho certeza de que você pode encontrar um compromisso, como discutir novas APIs padrão logo (ou seja, algumas semanas) depois de serem introduzidas no .NET Core, depois que a poeira baixar um pouco.

E porque você não gosta disso, quer impor isso a todos, tornando o .NET Standard compatível com o .NET Core? Desculpe, mas este argumento não faz sentido para mim.

Você presume que eu não gosto disso, mas está errado: eu gosto de coisas que se movem rapidamente - mesmo que, como mantenedor de 60 pacotes NuGet, seja às vezes muito doloroso. O que não gosto é de obrigar todos a andarem na mesma velocidade, abandonando o pessoal no meio da estrada porque não conseguem acompanhar.

Não tenho certeza de como fazer com que o .NET Standard se mova tão rápido quanto o .NET Core pode ser visto como um castigo: nada o força a focar no netstandard TFM mais recente. Você só fará isso se precisar do conjunto de API mais recente. Se você não precisar dele, escolha uma versão mais antiga para que seus pacotes possam ser usados ​​por um conjunto mais amplo de plataformas.

Da perspectiva do desenvolvedor médio, é uma vitória total: você pode escrever pacotes usando as APIs mais recentes e brilhantes que podem ser usadas pelo mais novo runtime do .NET Core. Quando as outras plataformas alcançam, seus pacotes podem ser usados ​​lá também: você não precisa ir com pacotes de múltiplos alvos ou republicar.

Em primeiro lugar, é bastante caro devido ao fato de ser um componente do sistema operacional e, portanto, precisa de manutenção. Você não tem ideia de quão complexa é nossa estratégia de ramificação / manutenção / patch para .NET Framework 3.5 e 4.x. Adicionar um terceiro é quase impraticável.

Posso certamente imaginar que não é ideal para você, assim como remover o suporte do .NET Framework para ASP.NET Core 3.0 não será ideal para pessoas que não podem migrar para o .NET Core. Mas estou totalmente errado pensando que você - a Microsoft - tem muito mais recursos para lidar com isso do que uma empresa média para migrar para o .NET Core? (Eu nem estou falando sobre dependências externas que você não possui e controla).

Em segundo lugar, apenas fazer isso também traz riscos, pois precisamos fazer alterações na ativação para selecionar o tempo de execução correto para coisas como componentes gerenciados ativados por COM. E isso levanta a questão de saber se também suportamos in-proc lado a lado e com quantas combinações. Não é uma tarefa simples e também não está isenta de riscos.

Claro, não é fácil. E é arriscado. Mas é isso que as versões principais indicam: há o risco de as coisas quebrarem. Agora, entre ser forçado a permanecer para sempre no ASP.NET Core 2.2 e correr o risco de migrar para o .NET Framework 5 para usar o ASP.NET Core 3.0, o que você acha que as pessoas escolheriam?

Mas estou totalmente errado pensando que você - a Microsoft - tem muito mais recursos para lidar com isso do que uma empresa média para migrar para o .NET Core?

Na minha experiência, as pessoas superestimam consistentemente quantos recursos temos e quanto trabalho os recursos temos de fazer para sustentar apenas o status quo.

Mas neste caso não é nem uma questão de recursos. Poderíamos ter apenas o código-fonte aberto do .NET Framework e todos os PRs iriam diretamente para o .NET Framework. Tem a ver com a complexidade da máquina e os riscos de compatibilidade. É uma estrutura centralizada e até mesmo releases lado a lado compartilham um conjunto comum de recursos, como ativação. Já foi provado que estamos errados uma e outra vez que podemos simplesmente designar pessoas inteligentes para que tudo saia corretamente.

Agora, entre ser forçado a permanecer para sempre no ASP.NET Core 2.2 e correr o risco de migrar para o .NET Framework 5 para usar o ASP.NET Core 3.0, o que você acha que as pessoas escolheriam?

Em minha opinião, é muito mais prático ampliar o limite de APIs com suporte no .NET Core para possibilitar que mais pessoas migrem sem problemas para o .NET Core do que tentar portar recursos do .NET Core para o .NET Framework. Tudo o que podemos fazer é causar tristeza. Lembre-se de que as versões lado a lado vêm com outros desafios, como fazer com que a TI permita que você instale, encadear em instaladores ou esperar que seu hoster forneça as máquinas, etc.

Isso se aplica a todas as partes do ASP.NET Core ou algumas partes úteis e geralmente reutilizáveis ​​(como Microsoft.AspNetCore.Http.Extensions ) permanecerão no .NET Standard?

@andriysavin

@terrajobst Eu entendo totalmente o que você disse sobre não adicionar a .netstandard aquelas APIs que não parecem estar prontas para abranger todas as plataformas (e provavelmente nunca estarão). No entanto, isso não impediu que você (MS) introduzisse o netstandard2.0 quando, por exemplo, o UWP não estava pronto para suportá-lo. Pelo que entendi, foi necessário um esforço notável para adicionar esse suporte algum tempo depois, mas você conseguiu. Isso era de alguma forma uma história diferente?

Sim. .NET Standard 2.0 tinha zero APIs novas. Ele foi definido como a interseção do .NET Framework e do Xamarin. Qualquer que seja o delta, simplesmente precisamos dele para obter uma barra de compatibilidade razoável com o código existente. O único trabalho foi em UWP e .NET Core. E essas bases de código foram originalmente projetadas para ser uma reinicialização moderna do .NET, que aprendemos a ser inviável. Como as APIs / tecnologias a serem adicionadas eram amplamente maduras e suportadas em ambientes restritos (Xamarin iOS), a complexidade era baixa - apenas uma tonelada de trabalho de portabilidade.

Mas agora estamos falando sobre adicionar novos recursos e conceitos e isso é uma besta diferente para dirigir.

Na minha experiência, as pessoas superestimam consistentemente quantos recursos temos e quanto trabalho os recursos temos de fazer para sustentar apenas o status quo.

Na minha experiência, os Microsofties superestimam consistentemente quantos recursos temos e quanto trabalho temos que fazer para apoiar apenas o status quo. Seu argumento realmente funciona nas duas direções: sweat_smile:

Em minha opinião, é muito mais prático ampliar o limite de APIs com suporte no .NET Core para possibilitar que mais pessoas migrem sem problemas para o .NET Core do que tentar portar recursos do .NET Core para o .NET Framework.

Vamos ser claros: eu sou totalmente a favor , mas não vai funcionar até que o .NET Core atualize e implemente a maioria / todos os recursos que o .NET Framework tinha. Até que isso aconteça, você ainda verá pessoas sendo bloqueadas por um recurso ausente ou uma API ausente. Há tantas coisas faltando que não é razoável pensar que os grandes aplicativos monolíticos de legado serão capazes de migrar para o .NET Core sem encontrar problemas.

Eu definitivamente entendo suas preocupações. Mas, no final das contas, o que torna sua vida mais fácil tem uma chance de tornar a nossa mais dolorosa: não oferecer suporte ao .NET Framework será um PITA para nós.

Eu definitivamente entendo suas preocupações. Mas, no final das contas, o que torna sua vida mais fácil tem uma chance de tornar a nossa mais dolorosa: não oferecer suporte ao .NET Framework será um PITA para nós.

Essa parte eu entendo. Mas a alternativa não seria mais recursos no .NET Framework, mas simplesmente um ASP.NET Core menos poderoso.

Tentamos coevoluir o .NET Framework e o .NET Core nos últimos anos. Não é como se estivéssemos tentando evitar o trabalho. Eu pessoalmente passei um zilhão de horas conversando com nossos engenheiros de runtime tentando consertar, por exemplo, o pesadelo de redirecionamento de ligação. Ou o suporte ao .NET Standard 2.0 quebrado em 4.6.1. Nós tentamos. Não é uma questão de força de vontade, é uma questão de praticidade.

não vai funcionar até que o .NET Core se atualize e implemente a maioria / todos os recursos que o .NET Framework tinha

Na minha experiência, a disponibilidade de algumas APIs não é nem tão relevante. O que importa muito em ambientes corporativos é a complexidade de suporte e implantação. E “com suporte, enviado e atualizado automaticamente com o sistema operacional” é muito mais atraente do que o suporte de 3 anos que recebemos dos lançamentos LTS do .NET Core e a implementação minuciosa que ainda envolve. E sejamos honestos: ainda não há uma ferramenta estável para .NET Core e ASP.NET Core. Posso dizer com segurança que ainda será o status quo em um ano. Tivemos mudanças a cada lançamento e quem sabe se a nova referência do framework com 3.0 será a solução certa. Portanto, esse é definitivamente um grande ponto de dor ao lidar com empresas onde você não pode simplesmente atualizar as coisas ou fazer da maneira que deveria ser; geralmente, eles querem que seja feito da maneira que têm feito nos últimos 5 anos ou mais. Eles são estragados pela estrutura e qualquer coisa que não seja tão confortável para eles é quase um empecilho.

Mas a alternativa não seria mais recursos no .NET Framework, mas simplesmente um ASP.NET Core menos poderoso.

Isso é basicamente o que sugeri no ano passado: pacotes ASP.NET Core que ainda funcionam no .NET Framework (por exemplo, direcionando netstandard20 e netcoreapp30 ), mas oferecem um conjunto de recursos mais limitado, com muito menos desempenho interessante. Às vezes, o que as pessoas querem são coisas que funcionem. Não as novas coisas brilhantes. Não o material super rápido.

Tentamos coevoluir o .NET Framework e o .NET Core nos últimos anos. Não é como se estivéssemos tentando evitar o trabalho. Eu pessoalmente passei um zilhão de horas conversando com nossos engenheiros de runtime tentando consertar, por exemplo, o pesadelo de redirecionamento de ligação. Ou o suporte ao .NET Standard 2.0 quebrado em 4.6.1. Nós tentamos. Não é uma questão de força de vontade, é uma questão de praticidade.

Obviamente, não concordamos em tudo, mas nem é preciso dizer que estou muito impressionado com o que vocês fizeram (sim, mesmo que coisas como o soluço HttpClient tenham sido bastante dolorosos de lidar).

Eu realmente sinto muito ser aquele cara: sweat_smile:

Até agora, no front do ASP.NET Core, vi o Razor surgir como algo concreto que as pessoas gostariam de disponibilizar fora do ASP.NET Core em geral. Acho que isso é razoável e devemos identificar mais áreas como essa (será uma discussão mais útil). ASP.NET Core 2.1 e 2.2 ainda darão suporte ao .NET Framework, mas não acho que seja razoável oferecer suporte ao .NET Framework para sempre.

@terrajobst

Um bom exemplo disso são as implementações padrão de interfaces, ... E esses recursos são provavelmente exatamente do tipo que não faremos backport para o .NET Framework devido ao risco.

E com essa declaração morreu DIM. Todo o seu ponto é a evolução do legado. Se não se aplica ao legado, e nem mesmo se aplica a bibliotecas que tentam unir o legado ao novo, então não ajuda ninguém.

Até agora, no front do ASP.NET Core, vi o Razor surgir como algo concreto que as pessoas gostariam de disponibilizar fora do ASP.NET Core em geral.

Você pode adicionar o pacote Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection e as dependências subjacentes à lista.

Isso é basicamente o que sugeri no ano passado: pacotes ASP.NET Core que ainda funcionam no .NET Framework (por exemplo, direcionando netstandard20 e netcoreapp30 ), mas oferecem um conjunto de recursos mais limitado, com muito menos desempenho interessante. Às vezes, o que as pessoas querem são coisas que funcionem. Não as novas coisas brilhantes. Não o material super rápido.

Também discutimos isso. O desafio é que não podemos encapsular isso inteiramente, pois algumas das APIs e recursos da plataforma subjacente terão que vazar para a API pública. Isso significa que as bibliotecas que se integram ao middle-ware do ASP.NET Core também precisam fornecer várias implementações. Mas pior, pode não ser possível sem criar um cisma, já que o tipo de troca pública pode ser apenas central, o que criaria duas versões do ASP.NET Core que não são mais compatíveis.

@HaloFour

E com essa declaração morreu DIM. Todo o ponto de evolução do legado. Se não se aplica ao legado, e nem mesmo se aplica a bibliotecas que tentam unir o legado ao novo, então não ajuda ninguém.

Acho que você está misturando código legado com instalações existentes . Mesmo se tivéssemos que portar o DIM para o .NET Framework, você ainda teria que atualizar para uma versão mais recente para usar o recurso. Embora seja provavelmente um recurso exclusivo do .NET Core, ele ainda nos permite desenvolver o .NET Core enquanto ainda podemos consumir o código que foi compilado no .NET Framework.

@terrajobst: Você sempre menciona o Unity. Eles têm sua própria implementação CLR? Tive a impressão de que estão usando Mono.

O Unity tem várias implementações .NET, incluindo sua própria versão AOT não mono, IL2CPP. Sua biblioteca de classes e APIs com suporte também diferem do Mono padrão.

@terrajobst

Acho que você está misturando código legado com instalações existentes.

Não há muita diferença quando se trata de aplicativos "legados" que ainda estão sendo mantidos e desenvolvidos ativamente. Há uma grande diferença entre atualizar a estrutura e ter que migrar para o .NET Core.

Embora seja provavelmente um recurso exclusivo do .NET Core, ele ainda nos permite desenvolver o .NET Core enquanto ainda podemos consumir o código que foi compilado no .NET Framework.

Para quê? Nenhuma dessas APIs "evoluídas" no .NET Core jamais será aplicável ao .NET Standard. E nenhum escritor de biblioteca vai mexer nisso, já que vai criar divergências incompatíveis em suas próprias APIs.

Eu concordo com @HaloFour. As únicas pessoas que poderão fazer uso do DIM são os autores de bibliotecas voltados apenas para .NET Core ... então, basicamente, corefx e aspnetcore. Não consigo imaginar que mais alguém chegasse perto disso.

As únicas pessoas que poderão fazer uso do DIM são os autores de bibliotecas voltados apenas para .NET Core ... então, basicamente, corefx e aspnetcore.

Bem, outra forma de expressar seria que a única plataforma onde você não pode usá-lo será o .NET Framework, enquanto você pode no .NET Core, Xamarin, Mono e Unity.

Não consigo imaginar que mais alguém chegasse perto disso.

Imagino que recursos como esse terão um padrão de adoção de tacos de hóquei nas bibliotecas, o que faz sentido. No final, os autores da biblioteca sempre considerarão o alcance versus o conjunto de recursos. Para aplicativos é mais fácil decidir, porque você conhece (e geralmente controla) seu ambiente de destino.

@ yaakov-h

Isso se aplica a todas as partes do ASP.NET Core ...

A lista provisória do que está acontecendo com qual pacote está aqui: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Achei que as implementações de interface padrão seriam um recurso de linguagem do C #. Dizendo que o .NET Framework não o suportará, você está praticamente dizendo que o .Net Framework ficará para sempre preso na versão C # 7.3 ou, no máximo, na próxima. Essa divergência não é algo que alguém gostaria que acontecesse no ecossistema.

Executamos algumas cargas de trabalho do .NET Core, mas também executamos projetos que são .NET FX de vários anos.

Atualizar para o .NET Core (mesmo no .NET Framework para começar) com segurança é uma tarefa muito grande.

Há algum plano para a Microsoft lançar algumas ferramentas para ajudar a "atualizar" projetos de pelo menos ASP.NET no .NET FX para ASP.NET Core para .NET FX?

Existem artigos do MSDN sobre a criação de novos projetos VS e importação de visualizações e rejigging de projetos, mas há tanto material legado (Global asax, roteamento, ....) que gostaria que houvesse um local central que documentasse a maneira antiga x nova de ajudar portando tudo.

O que o impede de introduzir uma nova versão lado a lado do .NET Framework (digamos, .NET Framework 5) que inclui essas alterações "arriscadas"?

Nesse ponto, há alguma vantagem em não ser .NET Core 3.0? Já está lado a lado e tem as mudanças "arriscadas". O próximo conjunto de recursos do .NET Core precisaria de um .NET Framework 6 etc.?

Com o apis já no .NET Core 2.0 e o novo conjunto de recursos chegando ao .NET Core 3.0, o .NET Core não cumpre o ".NET Framework 5" com o Framework 4.x sendo a versão LTS extremamente longa?

Em um palpite; neste ponto, seria um desafio de engenharia menor cobrir quaisquer lacunas identificadas específicas que o .NET Core 3.0 tem do .NET Framework 4.x em vez de alterar o .NET Framework para se comportar como .NET Core.

Sugestão prática: Existe alguma chance do ASP.NET Core 2.2 se tornar LTS com uma duração de suporte _estendida_ acima dos 3 anos comuns?

Tenho certeza de que isso satisfaria aqueles que precisam seguir a estrutura completa por enquanto, ao mesmo tempo que lhes daria (1) tempo suficiente para realmente migrar para o .NET Core e (2) motivação suficiente para migrar de ASP.NET MVC para ASP .NET Core (quando eles não podem mover para .NET Core _ainda_).

Eu ainda não acho que isso esteja claro, o ASP.NET Core no .NET Framework segue o .NET Core 2.1 LTS ou segue o ciclo de suporte do .NET Framework v4.6.1 + (ou seja, desde que está sendo executado no .NET FX) onde é suportado em um futuro previsível?

@mythz ASP.NET Core é coberto pelo ciclo de vida de suporte do

Acho que a melhor jogada aqui seria manter o padrão .net atualizado para pelo menos 3.0, 4.0 e 5.0 e realmente comunicar que em algum ponto a estrutura .net será completamente migrada para o núcleo .net.
tudo o mais está meio cozido.

Vocês já têm clientes pagando pelo suporte LTS hoje? (Apenas uma pergunta de investigação). Quanto tempo é tempo suficiente?

@terrajobst Parece que o verdadeiro problema é que o netstandard é monolítico. Parece que não precisamos de um padrão de rede, mas sim de conjuntos de API com versão. Esses também serão o TFM, por exemplo, base2.0 + span seriam dois conjuntos de API.

Você poderia então desenvolver o padrão com base em conjuntos de API e possivelmente implementar apenas alguns conjuntos de API na estrutura completa. (Isso também tornaria mais fácil para outras plataformas implementar o netstandard, uma vez que alguns conjuntos de APIs podem ser deixados de fora).

Com os conjuntos de API em vigor, uma compilação separada do ASP.NET Core seria criada para os destinos com menos suporte, como a estrutura completa.

@Sebazzz é um assunto extremamente estranho. Não podemos atrapalhar este tópico com tentativas de redesenhar o padrão de rede? Você pode registrar um problema no dotnet / standard para isso, mas vou dizer que essa ideia já foi proposta e derrubada.

@davidfowl Não acho isso "estranho" ou "descarrilado" de forma alguma. Parece exatamente o que precisamos, embora um pouco menos refinado do que a forma como ele propôs. Se o problema com tudo isso é que acabaríamos tendo que calçar todas essas coisas de servidor web em implementações como Xamarin e Unity que não se importam com servidores web, então a IMO criando um grupo separado de APIs ".NET Web Server Standard" seria a solução ideal.

@Sebazzz @masonwheeler

@terrajobst Parece que o verdadeiro problema é que o netstandard é monolítico. Parece que não precisamos de um padrão de rede, mas sim de conjuntos de API com versão. Esses também serão o TFM, por exemplo, base2.0 + span seriam dois conjuntos de API.

Tentamos isso em vários sabores (perfis, PCLs, contratos avulsos e conjuntos de contratos com versão que se tornaram .NET Standard 1.x). É muito difícil usar ferramentas e entender as regras de compatibilidade ao longo do tempo (quando as versões das plataformas e os conjuntos de APIs evoluem). O .NET Standard como é hoje é o mais próximo que já estivemos de um modelo viável. Embora não seja perfeito, é pelo menos algo que posso explicar em minutos e não deixar a cabeça das pessoas explodir.

Estou feliz em discutir o .NET Standard com mais detalhes, mas concordo com @davidfowl que ele não pertence aqui. Se desejar, registre um problema em https://github.com/dotnet/standard.

Editar Eu marquei nossos comentários do .NET Standard como fora do tópico.

@ Shayan-To

@terrajobst Achei que as implementações de interface padrão seriam um recurso de linguagem do C #. Dizendo que o .NET Framework não o suportará, você está praticamente dizendo que o .Net Framework ficará para sempre preso na versão C # 7.3 ou, no máximo, na próxima. Essa divergência não é algo que alguém gostaria que acontecesse no ecossistema.

É um recurso que requer alterações de idioma, bem como alterações de tempo de execução. É semelhante aos genéricos, pois muda as regras do sistema de tipos. De modo geral, o C # não sabe para qual framework você está compilando (ele apenas passa um conjunto de assemblies de referência que descrevem as APIs que o framework oferece). Qualquer recurso C # que não requeira alterações de API (por exemplo, o operador de coalescência nula ?. ou _ para expressões de descarte) será suportado. Nisso é idêntico a como o compilador sempre funcionou quando você usou o compilador e a versão de linguagem mais recentes e direcionou uma versão mais antiga do .NET Framework que não possui as APIs correspondentes. Por exemplo, async / await não funcionará se você tiver como objetivo o .NET Framework 3.5 ou 4.0 - você precisa estar no 4.5 ou superior para usar Task .

Cara, eu sinto por vocês .. Mudar para o .net core é, imo, a coisa certa a fazer a longo prazo e eu prefiro o maior ritmo de inovação que isso vai proporcionar.

No entanto, as pessoas _ ficarão_ chateadas com isso. Uma parte considerável disso é a comunicação. Quando o 2.1 LTS de 3 anos foi anunciado, as pessoas no fullfx esperavam poder mudar para o 3.0 e ainda executar o fullfx, eles venderam o asp.net core para seus empregadores e clientes colocando sua própria reputação em risco, e agora eles vão sentir como se o tapete tivesse sido puxado para baixo deles. O que eles venderam como uma solução de longo prazo, o futuro do asp.net, agora está (perceptivamente) limitado a 3 anos de suporte

Não importa que seja mais fácil migrar agora, trocar de plataforma sempre será um risco, e isso será um risco e esforço de desenvolvimento que essas pessoas não esperavam, planejaram ou orçaram.

A maioria dos desenvolvedores _quer_ mudar para .net core 3, mas além de potencialmente ter dependências que eles não podem mudar (ou envolver uma mudança de risco), eles agora têm que lançar uma migração _novamente_ e prometer que _ desta vez_ será um investimento de longo prazo. . pode ser uma venda difícil, mas eles se sentirão compelidos a fazê-lo por causa do ciclo de suporte de 3 anos.

Novamente, eu quero descartar fullfx, mas eu realmente acho que você deveria considerar estender o LTS para a última versão que o suporta por uma quantidade considerável. Comunicando também muito claramente, como em blogs, conferências / sessões e assim por diante, quais partes ainda serão o padrão da rede e como as pessoas ainda no 2.1 / framework completo ainda podem aproveitá-las.

Caso contrário, você corre o grande risco de a narrativa se tornar "A Microsoft está deixando seus desenvolvedores dedicados para trás mais uma vez". Não estou dizendo que é justo , apenas tentando avisá-lo sobre o que pode acontecer.

O que é um tempo razoável para o LTS?

6 anos talvez? Mas acho que as mensagens vão desempenhar um papel importante na recepção. No final, algumas pessoas ficarão chateadas, não importa o quê: /

@davidfowl @ aL3891

Para referência, Java LTS "Premier Support" é de 5 anos com "Extended Support" (pago) de mais três anos. Java 11, que é uma versão LTS lançada no mês passado, terá suporte até setembro de 2023 e setembro de 2026, respectivamente

Estamos investigando uma oferta de LTS de "suporte estendido" e forneceremos mais detalhes quando os tivermos. Isso potencialmente ofereceria aos clientes que precisam de um ASP.NET Core com suporte no .NET Framework versão (2.1.x) uma opção mais longa do que o período de suporte LTS atual.

Também para sua informação, conversei um pouco sobre os anúncios de hoje no ASP.NET Community Standup: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Padrão .net alvo, por favor. O núcleo do asp.net pode ter como alvo .netstandard2.1 ou 3.0 e deixar mono e .netframework catchup mais tarde, mas se o núcleo do asp.net tiver como destino netcoreapp , então qualquer biblioteca tentará acessar um tipo dessas bibliotecas aspnetcore deve ser uma biblioteca .netcoreapp .

e o núcleo .net sempre será lançado mais rápido do que .net framework e mono ,
mono e .netframework eventualmente consumirão .netcoreapp assemblies se a microsoft start direcionar mais frameworks / bibliotecas para netcoreapp (isso causará mais biblioteca no destino nuget .netcoreapp também).

se assim for, o .netstandard se tornará .netcoreapp 😂

@ John0King dê exemplos de tipos de que você precisa fora do ASP.NET Core.

  1. Razor como @poke mencionado
  2. Interfaces / atributos do filtro MVC (eu tenho uma biblioteca de classes auxiliares que contém alguns ActionFilters e TagHelpers e um método estático / de extensão comum para string, int, long ect. Eu uso PrivateAssert="All" para fazer referência a pacotes MVC, então quando eu uso isso biblioteca em algum outro lugar, esse projeto não precisa fazer referência a assemblies MVC, acho que tenho que separar a biblioteca em duas, uma é .netstandard e outra .netcoreapp )

outra pergunta é: será um problema para que tipo de biblioteca de classes devo criar? ( .netstandard vs .netcoreapp ). Hoje é muito simples no asp.net core 2.1. escolha .netstandard para biblioteca de classes, escolha .netcoreapp ou net461 para projeto da web.

mono e .netframework eventualmente consumirão assemblies .netcoreapp se a microsoft start direcionar mais frameworks / bibliotecas para netcoreapp (isso também causará mais biblioteca no destino nuget .netcoreapp)

Isso acontecerá se as pessoas não tentarem mais separar o que deve vir para uma biblioteca .netstandard e o que deve vir para a biblioteca .netcoreapp

Interfaces / atributos do filtro MVC (eu tenho uma biblioteca de classes auxiliares que contém alguns ActionFilters e TagHelpers e um método estático / de extensão comum para string, int, long ect. Eu uso PrivateAssert = "All" para fazer referência a pacotes MVC, então quando eu uso esta biblioteca em algum outro lugar, esse projeto não precisa fazer referência a assemblies MVC, acho que tenho que separar a biblioteca em dois, um é .netstandard e outro .netcoreapp)

Você pode elaborar? Isso não faz sentido. MVC é uma estrutura ASP.NET Core e não pode ser usado de forma independente.

@davidfowl esta biblioteca é uma biblioteca de classes auxiliares, posso usar esses filtros quando trabalho em um projeto MVC principal asp.net e só uso seus métodos de extensão em um aplicativo de console.

@davidfowl esta biblioteca é uma biblioteca de classes auxiliares, posso usar esses filtros quando trabalho em um projeto MVC principal asp.net e só uso seus métodos de extensão em um aplicativo de console.

Eu ainda não entendo. Você está falando sobre uma biblioteca que tem coisas MVC e outras coisas aleatórias?

Infelizmente, esse tipo de coisa é comum em software corporativo - 'bibliotecas auxiliares' que têm, como, os utilitários da empresa para MVC + os utilitários da empresa para WPF + os utilitários da empresa para telerik ...
Fazia mais sentido quando '.NET' era uma plataforma unificada única.

@davidfowl yes. Existem algumas classes / métodos na biblioteca auxiliar que você pode usar em qualquer lugar. e quando você fizer referência a essa biblioteca em um projeto mvc, poderá usar sua classe / método relacionado ao mvc.

Bem, isso só força suas bibliotecas a serem melhor dispostas em camadas 😉

Infelizmente, isso significa que qualquer pessoa que ainda faça implantações locais não pode oferecer suporte a seu software por mais de 3 anos. Assim que você lançar um aplicativo voltado para .netcore 3.0, por exemplo, seus clientes terão 3 anos e serão forçados a atualizar. Algumas indústrias vão ficar bem, outras certamente não.

Esse é o maior problema com isso, e eu imagino que faz do .net core um não-válido para muitas pessoas. Na verdade, concordo que, no final, essa é a direção certa a seguir, mas tenho certeza de que isso impedirá que muitos lugares acessem o núcleo .net.

Realmente gostaria de uma resposta da equipe .net sobre isso.

O fato é que o ASP.NET Core é uma estrutura da web. Em que setor é seguro manter um site por> três anos totalmente sem modificações? Se não forem vulnerabilidades de segurança, serão os navegadores substituindo aquilo em que você confiava, ou o TLS 1.4, ou usuários exigindo que o site funcione em seu novo watchlet.

Durante esse período de tempo, você deve ser capaz de fugir com apenas pequenos ajustes e atualizações menor dependência, mas o planejamento para não atualizar um aplicativo web em tudo durante anos a fio é imprudente.

Acho que isso seria mais palatável para a comunidade se você apenas aumentasse o período de LTS do ASP.NET Core 2.1 para 5-7 anos.

Em nossa experiência, o desenvolvimento corporativo corporativo avança a um ritmo glacial em comparação com o desenvolvimento da Web "moderno", e ainda assim eles querem ter certeza de que não estão fazendo novos investimentos em plataformas significativamente mais antigas. Esses aplicativos geralmente levam mais de um ano para até mesmo _inicializar_, quanto mais para fazer uma grande atualização de quebra em 3 anos. Esses aplicativos da Web corporativos (geralmente voltados apenas para uso interno) geralmente têm suporte de 7 a 10 anos, embora eu ache que não é razoável que o LTS para ASP.NET Core 2.1 seja de 10 anos. 5 anos parece uma solução melhor do que 3, com 7 anos sendo uma figura que certamente deixaria quase todos confortáveis.

E isso só é necessário porque o ASP.NET Core 3.0 requer uma grande alteração importante para remover o suporte do .NET Framework. Versões futuras do LTS não devem obedecer a esse padrão, assumindo que as mudanças significativas não sejam tão grandes.

Não tenho certeza de como fazer com que o .NET Standard se mova tão rápido quanto o .NET Core pode ser visto como um castigo: nada o força a focar no netstandard TFM mais recente. Você só fará isso se precisar do conjunto de API mais recente. Se você não precisar dele, escolha uma versão mais antiga para que seus pacotes possam ser usados ​​por um conjunto mais amplo de plataformas.

E se a plataforma nunca alcançar? Então, você terá uma biblioteca que visa netstandard2.3 que precisa do recurso A, que está disponível apenas no .NET Core e Xamarin, mas impossível para o .NET Framework.

Então netstandard2.4 é lançado, tendo alguns novos Apis e algumas dessas APIs são possíveis de portar para o .NET Framework. E agora?

Como você direciona uma biblioteca que precisa de um recurso de netstandad2.4 que é executado no .NET Framework, mas netstandard2.4 não pode direcionar o .NET Framework, porque não pode implementar netstandard2.2 .

Então você teria que cruzar a compilação para três plataformas:
netstandard2.2 para as plataformas antigas e net4x para o padrão líquido apenas para suportar o recurso que foi adicionado em netstandad2.4 e que net4x can also implement but not support because of APIs that went into netstandard2.3`.

Como isso tornaria mais fácil para os autores de pacotes escrever e enviar seus pacotes nugget?

A coisa toda só pode funcionar quando o menor denominador comum que todas as plataformas vão suportar fluir para o padrão líquido. A menos que você deseje que ainda mais APIs gerem PlatformNotSupported exceções, caso contrário, isso levará à fragmentação dentro do padrão da rede.

Posso certamente imaginar que não é ideal para você, assim como remover o suporte do .NET Framework para ASP.NET Core 3.0 não será ideal para pessoas que não podem migrar para o .NET Core. Mas estou totalmente errado pensando que você - a Microsoft - tem muito mais recursos para lidar com isso do que uma empresa média para migrar para o .NET Core? (Eu nem estou falando sobre dependências externas que você não possui e controla).

Qual é o problema real aqui? Pessoas que não podem mover de ASP.NET Legacy para ASP.NET Core não serão capazes de mover, quer o ASP.NET Core seja ou não direcionado ao .NET Framework. O motivo mais provável para eles não poderem ou não serão bibliotecas específicas de System.Web , que não funcionarão nem no ASP.NET Core no .NET Framework. As pessoas que têm seus aplicativos agora, obviamente, já têm o conjunto de trabalho.

E as pessoas que já estão no ASP.NET Core 2.1 no .NET Framework, se está funcionando, por que querer mudar? Obviamente, tudo o que é necessário já está lá e tudo o mais que vem recentemente para o ASP.NET Core 3.0 é bom ter.

Quanto aos outros:
Existem muitas maneiras de migrar um aplicativo para .NET Core, ou seja, separar partes de aplicativos monolíticos antigos e reimplementá-los como microsserviços, de modo que você também reduz o risco e o espalha ao longo do tempo

E se a plataforma nunca alcançar? Em seguida, você terá uma biblioteca que visa netstandard2.3 que precisa do recurso A que está disponível apenas no .NET Core e Xamarin, mas impossível para o .NET Framework.

Se uma API não pode ser implementada pela maioria das plataformas que oferecem suporte ao .NET Standard, então há grandes chances de que ela não faça parte do padrão, não? (na prática, é muito provável que seja o contrário, já que as plataformas nas quais o Xamarin é executado são geralmente muito mais restritas). Eu esperaria que esse tipo de problema fosse detectado ao revisar a API para inclusão no .NET Standard, mas posso estar errado.

E as pessoas que já estão no ASP.NET Core 2.1 no .NET Framework, se está funcionando, por que querer mudar?

  • Apoio, suporte? (um suporte de 3 anos é incrivelmente curto)
  • Uma correção de bug presente apenas no 3.0? (As versões LTS só recebem correções para bugs e vulnerabilidades críticas)
  • Você precisa fazer referência a uma biblioteca compatível apenas com a versão mais recente do ASP.NET Core?

Existem muitas maneiras de migrar um aplicativo para .NET Core, ou seja, separar partes de aplicativos monolíticos antigos e reimplementá-los como microsserviços, de modo que você também reduz o risco e o espalha ao longo do tempo

Sim, claro, em teoria essa é a maneira ideal de lidar com isso. Mas:

  • Alguns aplicativos dependem de bibliotecas externas sobre as quais você não tem controle. Se a biblioteca não funcionar no .NET Core e o fornecedor não quiser (ou não puder) portá-la, você está sem sorte.
  • A migração para o .NET Core pode ser cara e demorada. Se até mesmo as melhores equipes da Microsoft estão lutando com isso, você realmente acha que será tão fácil para qualquer equipe média? Teremos que esperar pelo 3.0 para ver o Entity Framework 6 ser finalmente compatível com o .NET Standard.

Não interprete mal o que estou dizendo: Eu sou totalmente a favor do .NET Core para novos aplicativos. Mas o fato de o ASP.NET Core ser compatível com o .NET Framework ajudou muitas empresas a migrar para o ASP.NET Core por um custo razoável. Estou convencido de que nunca teria sido tão popular sem esse caminho de migração "não muito difícil".

Microsoft, seria pedir demais para estender o suporte 2.1? 2021 não é o tempo suficiente para nós e não temos recursos / tempo suficientes para fazer essa conversão. Talvez até 2022, pelo menos? Um ano a mais nos daria realmente a chance de fazer as mudanças, ainda que dolorosas.

Lembre-se de que muitos de nossos fornecedores terceirizados ainda precisam migrar suas bibliotecas para compatibilidade com .Net Core, que é o maior motivo do nosso desligamento.

Embora eu considere a extensão do LTS conforme necessário, o ciclo de suporte IMO do ASP.NET Core no .NET FX para o .NET FX também deve ser levado em consideração. Para começar, é confuso ter diferentes partes do .NET Framework em diferentes ciclos de suporte, onde juntá-lo faria mais sentido. Em segundo lugar, o código para 2.1 já está escrito, lançado e depende dele, portanto, vai levar muito menos recursos para dar suporte ao 2.1 do que desenvolvê-lo ativamente em tangente com o .NET Core 3.0. Se a mesma equipe estiver mantendo ambos, eu também presumiria que o código-base ativo do ASP.NET Core modular, recente e mais familiar, será mais fácil de suportar do que o código-base ASP.NET clássico completamente diferente.

Quando a MS anunciou o EOL do Silverlight 5 em 2012, eles ainda oferecem suporte até outubro de 2021 (apesar de ter sido descartado no Chrome em 2015 e no Firefox em 2017). Isso é para tecnologia que foi abandonada completamente, o que não é o caso aqui, basicamente a mesma base de código, modelo de programação e equipe de desenvolvimento ativa ainda estão trabalhando nisso, apenas executando software existente no .NET Framework que está sendo abandonado.

Antes deste anúncio, havia mensagens fortes que a MS nunca abandonava o .NET Framework de que era ótimo para cargas de trabalho somente do Windows (em contraste com .NET Core para plataformas cruzadas / cargas de trabalho de alto desempenho) e que o ASP.NET Core era o futuro modelo de programação que ofereceria suporte ao .NET Framework e ao .NET Core no futuro, com o .NET Standard como a solução para o desenvolvimento de bibliotecas voltadas para várias plataformas.

Agora está claro que o .NET Core é o futuro para todos os novos projetos, mas trata-se de como tratar os investimentos existentes e os clientes existentes que tomaram decisões com base nesta orientação até agora. Como as equipes .NET Dev existentes progridem quando precisam dar suporte a sistemas existentes, elas serão forçadas a permanecer no ASP.NET clássico (onde suas habilidades / conhecimentos existentes estão sendo desatualizados a cada dia) enquanto mudam de contexto para desenvolver novos aplicativos no .NET Core.

Se eu fosse forçado a manter sistemas no .NET Framework, preferiria muito mais desenvolvê-lo no novo modelo de programação ASP.NET com acesso a uma base de conhecimento / ecossistema ativo e, então, ser forçado a voltar a usar o antigo ASP.NET indefinidamente, mas isso não será possível, a menos que o ASP.NET Core no FX tenha o mesmo nível de suporte que WebForms.

A MS também tem a oportunidade de posicionar o ASP.NET Core no FX como um ambiente de desenvolvimento "estável" (ou seja, fixado no ASP.NET Core 2.1). Não tem sido fácil ser um desenvolvedor .NET nos últimos anos, desde que o .NET Core começou. Efetivamente, tivemos que abandonar todos os nossos esforços para tentar portar para o .NET Core <1.x, já que era difícil acompanhar o fluxo constante de mudanças significativas. Somente até o .NET Core 2.x é que fomos capazes para apoiá-lo e migrar os aplicativos existentes. Por outro lado, os desenvolvedores ASP.NET Framework existentes viram sua plataforma escolhida estagnada e, em seguida, substituída pelo novo modelo de programação ASP.NET Core e, por extensão, erodindo suas habilidades / conhecimentos existentes. Encerrar o suporte para ASP.NET Core em FX elimina uma estratégia popular de migração em estágios para .NET Core, onde eles correm o risco (sem um fallback de contingência) em uma plataforma abandonada, a menos que sejam capazes de atualizar todo o seu sistema para .NET Core (um risco que pode evitar que as tentativas de migração sejam consideradas), também elimina a oportunidade de participar do futuro modelo de desenvolvimento ASP.NET Core se eles não puderem migrar seus sistemas existentes nos quais trabalham diariamente, o que só será possível se tiver o mesmo suporte que WebForms - que espero que ainda esteja em consideração.

Ninguém mencionou: em nosso aplicativo principal asp.net, precisamos hospedar os serviços WCF e este é o único ponto problemático para migrar do framework .net. Não vejo nenhuma notícia sobre o suporte wcf do lado do servidor em .net core 3, infelizmente.

@DamianEdwards @davidfowl @natemcmaster Estamos no mesmo barco. Minha empresa tem uma série de produtos que rodam em ASP.Net Core em .Net Full framework, e damos suporte a eles por muito mais tempo do que 3 anos, devido à lentidão com que as indústrias que vendemos se movem. Estender o LTS para .net core 2.2 não teria sentido em nossa situação, porque teríamos que portar nossos aplicativos principais ASP.net de volta para ASP.Net. Certamente isso é derrotar o ponto pessoal! Você sugeriria apenas aplicativos de suporte por períodos mais curtos de tempo? Infelizmente, isso também é algo sobre o qual não temos controle. Os setores em que trabalhamos podem levar um ano apenas para lançar nosso novo software.

Infelizmente, isso significa que qualquer pessoa que ainda faça implantações locais não pode oferecer suporte a seu software por mais de 3 anos. Assim que você lançar um aplicativo voltado para .netcore 3.0, por exemplo, seus clientes terão 3 anos e serão forçados a atualizar. Algumas indústrias vão ficar bem, outras certamente não.

Esse é o maior problema com isso, e eu imagino que faz do .net core um não-válido para muitas pessoas. Na verdade, concordo que, no final, essa é a direção certa a seguir, mas tenho certeza de que isso impedirá que muitos lugares acessem o núcleo .net.

Realmente gostaria de uma resposta da equipe .net sobre isso.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Bem, isso só força suas bibliotecas a serem melhor dispostas em camadas 😉

Este argumento não está funcionando na direção oposta?

O que não consigo entender é o que realmente impede você de criar uma arquitetura de camadas adequada do ASP.NET Core?
Portanto, sim, alguns recursos de tempo de execução não estão disponíveis no .Net Framework, como Span<T> , mas isso não significa que não estejam disponíveis. Está disponível , mas não tem tanto desempenho quanto no núcleo .Net. Podemos lidar com isso.

Algumas implementações de baixo nível podem ser implementadas em variações para o núcleo .net especificamente e para o padrão .net. E duvido que haja muito espaço para isso, já que as APIs geralmente estão disponíveis como pacotes NuGet.
Muitos autores de bibliotecas suportam implementações diferentes para plataformas diferentes, isso é o que sempre foi.

Você poderia explicar o que exatamente o impede de suportar .Net Framework / .Net Standard. Alguns exemplos simples que não podem ser abstraídos de forma a ter implementações específicas da plataforma?

impede que você suporte .Net Framework / .Net Standard. Alguns exemplos simples que não podem ser abstraídos de forma a ter implementações específicas da plataforma?

No topo da minha cabeça, itens que exigem tempo de execução ou mudanças de estrutura

  • Ponteiros internos do GC; portanto, criando um Span seguro de um ref apenas sem um objeto: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
  • Utf8String s
  • Implementações de interface padrão
  • Itens de trabalho personalizados do Threadpool
  • Sobrecargas de span em tipos básicos: Stream, Sockets, TextReader / TextWriter, WebSockets
  • Sobrecargas IAsyncDisposable em tipos de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
  • IAsyncEnumeratorsobrecargas em tipos de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Itens de bônus

  • Intrínseco de hardware (x86, x64, ARM)
  • Análise de escape (novas alocações para empilhar)
  • Versões de tempo de execução lado a lado
  • Corrigindo redirecionamentos de vinculação e controle de versão

Não entendo por que não podemos simplesmente ter uma versão netstandard que não suporta mais netframework. Assim como o Windows Phone não tem suporte de padrão de rede além de 1,2. Por que não podemos mover o padrão para frente e permitir que implementações como netcore, mono, xamarin, etc combinem eventualmente ou nunca. Em seguida, cabe ao fabricante da biblioteca decidir qual versão do padrão de rede deseja implementar para maximizar a cobertura.

Esta mudança faz com que o xamarin e o mono não possam mais usar o aspnetcore. Faz com que as bibliotecas sejam forçadas a visar tanto o netcore quanto o netstandard ou, pior ainda, abandonar o netstandard todos juntos e visar apenas o netcore.

Isso acabará por levar à morte do padrão de rede.

impede que você suporte .Net Framework / .Net Standard. Alguns exemplos simples que não podem ser abstraídos de forma a ter implementações específicas da plataforma?

No topo da minha cabeça, itens que exigem tempo de execução ou mudanças de estrutura

  • Ponteiros internos do GC; portanto, criando um Span seguro de um ref apenas sem um objeto: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
  • Utf8String s
  • Implementações de interface padrão
  • Itens de trabalho personalizados do Threadpool
  • Sobrecargas de span em tipos básicos: Stream, Sockets, TextReader / TextWriter, WebSockets
  • Sobrecargas IAsyncDisposable em tipos de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
  • IAsyncEnumerator sobrecarrega em tipos de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Itens de bônus

  • Intrínseco de hardware (x86, x64, ARM)
  • Análise de escape (novas alocações para empilhar)
  • Versões de tempo de execução lado a lado
  • Corrigindo redirecionamentos de vinculação e controle de versão

Os itens dessa primeira lista parecem coisas que seriam candidatos a mudanças no padrão da rede?

A maioria deles não parece impossível de ser trazida para outros tempos de execução, mas parece que ninguém quer revisar o CLR para uma nova versão para trazer Implementações de Interface Padrão para .NET Framework.

Ao mesmo tempo, a Microsoft não parece querer avançar com uma versão do .NET Standard que é para sempre incompatível com o .NET Framework. Caso contrário, isso não seria realmente um problema - basta avançar com netstandard30 ou netstandard40 e descartar o suporte do Framework; e fazer com que o .NET Core tenha como alvo um desses padrões mais recentes.

Eu sinto que este tópico etc. é o resultado da Microsoft se encurralando.

Ao mesmo tempo, a Microsoft não parece querer avançar com uma versão do .NET Standard que é para sempre incompatível com o .NET Framework.

Este falso; .NET Standard 2.1 está sendo finalizado e tem 3104 novas apis sobre .NET Standard 2.0, incluindo Span sobrecargas em tipos de estrutura base; o que pode torná-lo incompatível com o .NET Framework.

O .NET Standard ainda está avançando.

Caso contrário, isso não seria realmente um problema - basta avançar com netstandard30 ou netstandard40 e descartar o suporte do Framework; e fazer com que o .NET Core tenha como alvo um desses padrões mais recentes.

O problema é tornar cada tempo de execução, não apenas o Framework, incompatível com um dos padrões mais recentes; e então incompatível com todos os padrões depois disso. O que entra no .NET Standard precisa ser acordado pelos vários tempos de execução como coisas que podem ser implementadas.

Os vários GCs do Mono e do Unity oferecerão suporte a ponteiros internos em breve? Se não adicioná-los ao .NET Standard, eles serão bloqueados desse .NET Standard em qualquer .NET Standard futuro, até que seus GCs sejam alterados para lidar com eles. Contudo; é melhor adicionar apis que eles possam implementar agora e salvar aqueles que não podem para um padrão futuro.

As apis que estão sendo adicionadas ao Core são as apis certas para serem corrigidas permanentemente para sempre e forçar cada tempo de execução; que quer ser compatível com o próximo padrão, implementar?

Algumas das APIs do Core 2.1 mudaram entre a visualização 1 e a visualização 2 (devido ao feedback de uso); então é difícil até mesmo saber quais são as ápis que são novas no Core X até que ele seja lançado, em que ponto é gravado na pedra. Em seguida, quais deles são o conjunto correto para adicionar ao padrão para todos os tempos de execução para implementar (ou ser deixado para trás).

A abordagem do .NET Standard ainda é mais agressiva do que os padrões do navegador, quando 2 navegadores devem implementar o recurso antes que um padrão seja aceito.

Seria bom se um novo .NET Standard pudesse ser lançado ao mesmo tempo que o .NET Core e todos os tempos de execução pudessem implementá-lo instantaneamente e o ASP.NET Core pudesse usar todas as novas apis via .NET Standard; mas embora seja bom como um ideal, também não é prático. Existem até mesmo algumas apis aprovadas que não foram implementadas no .NET Core

A questão básica é se o ASP.NET Core pode usar as apis que foram solicitadas por ele e ser fornecido na versão do .NET Core que o acompanha (visto que são fornecidos simultaneamente); ou ele pode usar apenas as apis fornecidas na versão anterior do .NET Core - que, portanto, têm uma chance de estar na versão .NET Standard para esse .NET Core? (Como parece que as versões do .NET Standard ficarão na versão apis 1 em relação ao .NET Core atualmente; usando o tamanho de amostra de 1)

Se o ASP.NET Core pode usar as apis; então, as apis obtêm testes de uso e avaliam se são boas apis; se não forem, então melhores apis podem ser propostas. Se o ASP.NET Core não pode usá-los, então se eles são bons apis ainda é bastante desconhecido quando se tornam candidatos ao .NET Standard.

ninguém quer revisar o CLR para uma nova versão para trazer Implementações de Interface Padrão para .NET Framework.

O .NET Core, ao suportar cargas de trabalho tradicionais do .NET Framework (incluindo WinForms e WPF), é essencialmente a revisão do CLR; mas feito de uma maneira mais sustentável e preparada para o futuro?

Este falso; .NET Standard 2.1 está sendo finalizado e tem 3104 novas apis sobre .NET Standard 2.0, incluindo sobrecargas de Span em tipos de framework base; o que pode torná-lo incompatível com o .NET Framework.

Incluindo .NET Framework 4.8 e .NET Framework 4.9?

Sempre existe a possibilidade de que futuras atualizações do Framework obtenham essas novas APIs. No momento, parece que o .NET Framework nunca terá DIM, portanto, qualquer interface com um método DIM poderia _nunca_ ser portada para o .NET Framework.

O .NET Core, ao suportar cargas de trabalho tradicionais do .NET Framework (incluindo WinForms e WPF), é essencialmente a revisão do CLR; mas feito de uma maneira mais sustentável e preparada para o futuro?

E não à prova de versões anteriores. Por mais que a Microsoft tenha mostrado coisas como o Paint.Net em execução no .NET Core, não consigo executar meus projetos existentes do lado do servidor no .NET Core, nem a maioria das pessoas.

Seria bom se um novo .NET Standard pudesse ser lançado ao mesmo tempo que o .NET Core e todos os tempos de execução pudessem implementá-lo instantaneamente e o ASP.NET Core pudesse usar todas as novas apis via .NET Standard; mas embora seja bom como um ideal, também não é prático.

Isso também pode não ser prático, mas acho que as pessoas no geral ficariam um pouco mais felizes se pudesse haver duas versões do ASP.NET Core:

  • Uma versão veloz de última geração que está ligada ao .NET _Core_ e pode usar qualquer nova API que desejar.
  • Uma versão LTS mais lenta que está vinculada ao .NET _Standard_ e é executada em mais lugares; que eventualmente alcança as compilações mais antigas, mas sempre fica para trás.

Ao vinculá-lo ao .NET Core, você está forçando uma compensação com a qual nem todos estão satisfeitos. Eu entendo o raciocínio por trás da abordagem tem que se mover rapidamente, mas também há uma preocupação legítima com o ecossistema .NET em geral.

  • Uma versão veloz de última geração que está ligada ao .NET Core e pode usar qualquer nova API que desejar.
  • Uma versão LTS mais lenta que está vinculada ao .NET Standard e é executada em mais lugares; que eventualmente alcança as compilações mais antigas, mas sempre fica para trás.

Portanto, se o ASP.NET Core 3.0 saiu apenas como .NET Core 3.0; mas em uma data posterior, quando era um .NET Standard que tinha apis; foram lançados pacotes para ASP.NET Core 3.x que também eram .NET Standard (mesmo que o ASP.NET Core tivesse mudado para 4.0); isso atenderia aos seus requisitos?

@ yaakov-h

Uma versão LTS mais lenta que está vinculada ao .NET Standard e é executada em mais lugares; que eventualmente alcança as compilações mais antigas, mas sempre fica para trás.

O que isto significa? Você sempre pode usar o ASP.NET Core 2.1 com o suporte estendido que @DamianEdwards mencionou. Meu palpite é que mesmo que esse apoio fosse de 10 anos, não iria satisfazer as reclamações das pessoas. O instinto me diz que, enquanto houver novos recursos sendo desenvolvidos, as pessoas vão querer ter acesso a eles (mesmo os que estão atualmente no trem lento), mas talvez eu esteja lendo muito sobre essas respostas ...

Você sempre pode usar o ASP.NET Core 2.1 com o suporte estendido que

Não divida a comunidade, por favor !!
(com base na votação) Você espera que 1/3 do desenvolvedor permaneça no asp.net core 2.1? ou espera 2/3 desenvolvedores que criam pacotes nuget que precisam manter 2 versões de suas bibliotecas?

@benaadams

Portanto, se o ASP.NET Core 3.0 saiu apenas como .NET Core 3.0; mas em uma data posterior, quando era um .NET Standard que tinha apis; foram lançados pacotes para ASP.NET Core 3.x que também eram .NET Standard (mesmo que o ASP.NET Core tivesse mudado para 4.0); isso atenderia aos seus requisitos?

Precisamente.

@davidfowl

Você sempre pode usar o ASP.NET Core 2.1 com o suporte estendido que @DamianEdwards mencionou. Meu palpite é que mesmo que esse apoio fosse de 10 anos, não iria satisfazer as reclamações das pessoas.

Parece haver mensagens conflitantes aqui:

  1. É bom ficar no 2.1, a versão LTS mais antiga
  2. O ASP.NET Core está se movendo tão rápido que nem podemos esperar um ciclo de lançamento entre o .NET Core e o .NET Standard subsequente.

Acho que (2) está causando muita confusão e medo de ser deixado para trás.

@ John0King

(com base na votação) Você espera que 1/3 do desenvolvedor permaneça no asp.net core 2.1? ou espera 2/3 desenvolvedores que criam pacotes nuget que precisam manter 2 versões de suas bibliotecas?

Espero que os autores da biblioteca decidam qual é a versão mínima do ASP.NET Core que eles querem oferecer e visem isso. É o que eles já estão fazendo hoje. Algumas bibliotecas oferecem suporte a ASP.NET Core 1.xe 2.x, algumas apenas oferecem suporte a 2.x. Isso não é diferente.

@ yaakov-h

Não entendo muito bem quais são as mensagens conflitantes. O 2.1 atual é LTS e roda em .NET Core e .NET Framework e tem suporte por 3 anos. Esta não é uma mensagem nova, é a mesma que recebemos desde o início.

O ASP.NET Core está se movendo tão rápido que nem podemos esperar um ciclo de lançamento entre o .NET Core e o .NET Standard subsequente.

Isso é especulação com base nos comentários feitos aqui. Oficialmente, estamos vinculados ao ciclo de entrega do .NET Core e adicionamos e consumimos novas APIs a cada lançamento. O ASP.NET Core em execução no .NET Framework nunca foi feito para ser uma coisa permanente (é até mesmo chamado de ASP.NET Core), sempre foi concebido como um degrau. Nós apenas tivemos que adicionar o suficiente das APIs principais de volta para que os clientes pudessem escrever razoavelmente aplicativos totalmente funcionais.

Alguma resposta da equipe do ms?

Infelizmente, isso significa que qualquer pessoa que ainda faça implantações locais não pode oferecer suporte a seu software por mais de 3 anos. Assim que você lançar um aplicativo voltado para .netcore 3.0, por exemplo, seus clientes terão 3 anos e serão forçados a atualizar. Algumas indústrias vão ficar bem, outras certamente não.

Esse é o maior problema com isso, e eu imagino que faz do .net core um não-válido para muitas pessoas. Na verdade, concordo que, no final, essa é a direção certa a seguir, mas tenho certeza de que isso impedirá que muitos lugares acessem o núcleo .net.

Realmente gostaria de uma resposta da equipe .net sobre isso.

Infelizmente, isso significa que qualquer pessoa que ainda faça implantações no local não pode oferecer suporte a seu software por mais de 3 anos

isso é apenas besteira, você pode simplesmente fazer um upgrade. o único momento em que não funciona é dentro de um ambiente embarcado, mas o software embarcado tem muito mais problemas do que uma janela de suporte de 3 anos.

@schmitch Não tenho certeza do que você quer dizer? Obviamente, você pode apenas atualizar, mas para alguns setores, atualizar para uma nova versão do software torna-se um projeto enorme que pode levar anos, dependendo dos ciclos de lançamento e do quão tecnicamente progressivo (ou não) esses setores são.

@davidfowl

Meu palpite é que mesmo que esse apoio fosse de 10 anos, não iria satisfazer as reclamações das pessoas.

Não tenho certeza de como você esperava que as pessoas fizessem isso, todos os efeitos dessa decisão se deparam com a plataforma para a qual foram vendidos para mudar não apenas não tem um futuro, mas seus investimentos existentes construídos no modelo de programação mais recente estão caminhando para funcionar uma plataforma sem suporte (a partir deste anúncio) em menos de 3 anos. Outros que pensaram em uma migração cuidadosa em estágios para o .NET Core via migração para o .NET Framework primeiro agora enfrentam o risco de que não haverá contingência para o fallback - é executado em um novo runtime do .NET Core ou falha.

Uma plataforma de desenvolvedor não deve ser o objetivo em si, pois há um valor exponencialmente maior sendo criado na plataforma do que o valor da própria plataforma. Movimentos cegos como esse fazem parecer que a eficiência máxima dos recursos para aumentar a velocidade da plataforma é mais importante do que os investimentos do ecossistema que está sendo criado nela. A tinta nos bits do .NET Core 2.1 ainda nem secou, ​​mas os sistemas existentes (no FX) já estão sendo tratados como um passivo (com o objetivo de fornecer suporte mínimo) em vez do ativo e valor que agregam ao ecossistema.

Como foi mencionado, os sistemas corporativos podem se mover em um ritmo glacial, muitas vezes equilibrando simultaneamente equipes de desenvolvedores, oferecendo melhorias contínuas que muitos funcionários e clientes precisam usar para obter ROI constante deles. Muitas migrações precisam acontecer "em vôo" com planejamento cuidadoso e testes rigorosos que podem levar anos - tempo que eles prefeririam usar para criar valor do que lutar para sair da plataforma que está tendo o suporte puxado por eles. Grandes sistemas brownfield não são commodities como iPhones que podem ser facilmente descartados e atualizados continuamente a cada poucos anos. Os sistemas mais antigos e mais longos estão em desenvolvimento, mais valor investido nele e mais difícil será migrar dele, o que se torna especialmente difícil de absorver, pois não há valor criado nas migrações, ela requer recursos, absorve o custo de oportunidade, aumenta o risco e o melhor que podem esperar é uma migração perfeita com seus sistemas existentes funcionando exatamente da mesma forma que antes.

Qualquer que seja a data de expiração atribuída ao suporte FX, haverá sistemas existentes em execução que atingiram obstáculos ou seriam impossíveis de migrar para fora dele. O que se torna a orientação então?

ASP.NET Core 2.1 já está desenvolvido, o esforço para ter ASP.NET Core rodando em FX / .NET Core é um custo irrecuperável já investido. Portanto, a decisão deve ser enquadrada como uma questão de recursos de MS para manter uma plataforma já desenvolvida (após LTS) vs quantidade cumulativa de custo, má vontade e inércia gerados por abandonar uma plataforma popular.

Não tenho certeza se entendi o que está sendo pedido então. O ciclo de vida do LTS não mudou desde o lançamento do 2.1. Se você escreveu um aplicativo na versão LTS, seja .NET Core ou .NET Framework, levaria 3 anos até que você fosse “sem suporte”. Eu não entendo muito bem como o tapete está sendo puxado debaixo de você em termos de suporte, isso não mudou. Você precisaria atualizar para obter quaisquer atualizações de plataforma.

Agora eu entendo que 2.1 sendo a última versão LTS com suporte no .NET Framework significa que não há lugar para atualizar, mas é aí que entra o suporte LTS estendido. Se o aplicativo nunca pode

Não tenho certeza se entendi o que está sendo pedido então.

Este segmento está solicitando vários níveis de compromissos da MS, desde: continuar desenvolvendo em conjunto com o .NET Core, desenvolvê-lo em um "trem lento", não abandonar o ASP.NET Core 2.1 e manter o mesmo nível de suporte que WebForms, estender LTS . Minha preferência seria não abandoná-lo como uma opção de hospedagem para ASP.NET Core (edit: obv qualquer coisa acima que seria mais preferível), o que não impediria o .NET Core apenas v3 +, embora forneça muitos utilitários para o .NET existente Investimentos em câmbio.

Agora eu entendo que 2.1 sendo a última versão LTS com suporte no .NET Framework significa que não há lugar para atualizar

O que significa que se tornou uma plataforma sem suporte, qualquer pessoa nela tem que tratá-la como lava e lutar para sair dela antes que alcance seu fim EOL sem suporte.

  • Qualquer um que pensou em usá-lo como uma plataforma de teste para migrar para o .NET Core se tornou uma opção menos viável, pois enfrentam o risco de ficarem presos em uma plataforma sem suporte se a migração demorar mais do que o esperado ou se encontrarem obstáculos se alguma das dependências eles confiam não podem ser executados no .NET Core.
  • Qualquer pessoa forçada a usar os servidores .NET Framework da infraestrutura gerenciada existente em sua empresa não pode participar do uso do novo modelo e ecossistema de desenvolvimento e precisa ver seus conhecimentos / habilidades em ASP.NET clássicos existentes se tornarem menos valiosos a cada dia.
  • As equipes não podem migrar seus sistemas existentes necessários do .NET Framework e exigirão a mudança de contexto para novos projetos ASP.NET Core no .NET Core.
  • Nenhuma organização quer ser forçada a uma migração não planejada porque a orientação que confiaram para basear suas decisões de orçamento, planejamento e investimento mudou.

Novamente, não é um problema para projetos greenfield, para pessoas que podem ou planejam migrar para o .NET Core de qualquer maneira ou para qualquer um que não precisa manter sistemas legados, mas tem impacto no ecossistema .NET FX existente e ASP.NET Core ficou mais pobre por não ser mais capaz de considerar a utilização da opção popular de hospedagem no .NET FX.

Em um mundo perfeito, todos estariam no .NET Core, mas existe uma quantidade considerável de investimento em .NET FX que está sendo desvalorizada com essa decisão.

Se o aplicativo nunca puder ser movido para o .NET Core mesmo após esses 6 anos porque APIs estão faltando,

Há muitas pessoas que não podem ou não querem mudar para o .NET Core, elas querem que ele compartilhe o mesmo nível de suporte do ASP.NET clássico (que a mensagem atual sugere que seja indefinidamente).

APIs ausentes não é o único motivo que impede a migração, por exemplo, eles podem estar contando com uma dependência onde a equipe de desenvolvimento a criou não existe mais, é um componente crítico que não pode ser alterado, não pode ser refatorado com segurança (por exemplo, sem testes), é compartilhado com outros sistemas somente .NET FX, é mantido por outro departamento que não tem orçamento, capacidade de alterá-lo ou devido a fatores externos como a infraestrutura gerenciada de suas empresas só suporta a execução em servidores .NET Framework.

Obrigado por eliminar o .NET Standard com este tipo de decisões.

Até agora, temos ignorado o .NET Core porque existem muitos Assemblies de terceiros que ainda não têm como alvo o Core.

Muitos dos fornecedores que estão dispostos a oferecer suporte ao Core, o fazem de maneira parcial, por exemplo, ODP.NET gerenciado sem as APIs nativas que estão disponíveis apenas no .NET Framework.

Então você chega com esse tipo de decisão.

Não, não adotaremos o .NET Core mais rápido só porque dá muito trabalho para a Microsoft oferecer suporte ao .NET Framework e não é capaz de entregar o .NET Standard que vocês criaram para começar.

@davidfowl , posso dar a você 2 exemplos do que torna difícil migrar para .NET Core - WCF (muitos aplicativos corporativos existentes o usam, acredito que outros já levantaram esse problema) e a falta de biblioteca Adomd em .NET Core / NET Padrão (para comunicação com SSAS, também usado em aplicativos corporativos, rastreado no SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Alguns outros (winforms) devem ser corrigidos com o pacote de compatibilidade .net core 3 (yay!) - temos que esperar e ver como ele realmente funciona.

@mythz

Este segmento está solicitando vários níveis de compromissos da MS, desde: continuar desenvolvendo em conjunto com o .NET Core, desenvolvê-lo em um "trem lento", não abandonar o ASP.NET Core 2.1 e manter o mesmo nível de suporte que WebForms, estender LTS . Minha preferência seria não abandoná-lo como uma opção de hospedagem para ASP.NET Core, que não prejudicaria o .NET Core apenas v3 +, embora forneça muitos utilitários para investimentos existentes em .NET FX.

Bem, no momento, estamos explorando a extensão do suporte LTS, mas não estamos considerando o suporte .NET Framework de primeira classe para ASP.NET Core para sempre (que é o que você está pedindo). Esta versão do ASP.NET Core, que você procura para o mesmo nível de suporte que WebForms, só obteria correções de segurança e de confiabilidade. Posso garantir que, à medida que os recursos aparecem nas versões mais recentes do ASP.NET Core, o nível de satisfação daqueles que usam o ASP.NET Core 2.1 diminuirá (pelo menos, é o que meu instinto me diz), pois essas alterações ainda estarão fora de alcance.

APIs ausentes não é o único motivo que impede a migração, por exemplo, eles podem estar contando com uma dependência onde a equipe de desenvolvimento a criou não existe mais, é um componente crítico que não pode ser alterado, não pode ser refatorado com segurança (por exemplo, sem testes), é compartilhado com outros sistemas somente .NET FX, é mantido por outro departamento que não tem orçamento, capacidade de alterá-lo ou devido a fatores externos como a infraestrutura gerenciada de suas empresas só suporta a execução em servidores .NET Framework.

Isso é muito comum (mesmo dentro da Microsoft) e é por isso que adicionamos a capacidade de fazer referência a dlls do .NET Framework no .NET Core 2.0, porque a maioria dos assemblies são compatíveis, mesmo que não tenham sido compilados para o .NET Core. Agora, há algumas coisas que nunca funcionarão (como AppDomains ...), mas espero que à medida que adicionarmos mais superfície de API, o conjunto de bibliotecas que não funcionam apenas encolherá para um número insignificante.

@pjmlp

Não vejo como isso mata o .NET Standard. O .NET Standard é muito maior do que o ASP.NET Core. Trata-se de criar bibliotecas compartilhadas reutilizáveis ​​(como Microsoft.Extensions *) que funcionam em qualquer plataforma .NET de suporte.

Até agora, temos ignorado o .NET Core porque existem muitos Assemblies de terceiros que ainda não têm como alvo o Core.

Quais? Há suporte para aqueles que estão a caminho ou esses assemblies nunca oferecerão suporte para .NET Core?

Muitos dos fornecedores que estão dispostos a oferecer suporte ao Core, o fazem de maneira parcial, por exemplo, ODP.NET gerenciado sem as APIs nativas que estão disponíveis apenas no .NET Framework.

Eu concordo com isso e tenho visto toneladas de versões deficientes de bibliotecas no .NET Core (mesmo com algumas bibliotecas que a Microsoft fornece), mas eu diria que a maré está mudando isso. Alguns dos motivos para isso foram o conjunto inicial ausente de APIs que existia no .NET Core 1.0. Com 2.0 e 2.1, vimos um grande conjunto de bibliotecas migrar mais facilmente para o núcleo / padrão sem muita perda de funcionalidade.

@voltcode Obrigado pelo feedback concreto! Esperamos que alguns desses tipos de problemas de compatibilidade desapareçam ou sejam mínimos ao longo do período de tempo em que oferecemos suporte a projetos .NET Core hoje (cerca de 3 anos).

@davidfowl

....

Até agora, temos ignorado o .NET Core porque existem muitos Assemblies de terceiros que ainda não têm como alvo o Core.

Quais? Há suporte para aqueles que estão a caminho ou esses assemblies nunca oferecerão suporte para .NET Core?

Em nosso caso, o ODP.NET é o mais óbvio, já que a Oracle não está portando 100% dos recursos do driver para o Core.

Muitos dos fornecedores que estão dispostos a oferecer suporte ao Core, o fazem de maneira parcial, por exemplo, ODP.NET gerenciado sem as APIs nativas que estão disponíveis apenas no .NET Framework.

Eu concordo com isso e tenho visto toneladas de versões deficientes de bibliotecas no .NET Core (mesmo com algumas bibliotecas que a Microsoft fornece), mas eu diria que a maré está mudando isso. Alguns dos motivos para isso foram o conjunto inicial ausente de APIs que existia no .NET Core 1.0. Com 2.0 e 2.1, vimos um grande conjunto de bibliotecas migrar mais facilmente para o núcleo / padrão sem muita perda de funcionalidade.

Não é assim que muitos de nossos clientes veem.

Apenas para você ter uma ideia de como esse tipo de decisão afeta o futuro do .NET, em um projeto recente o cliente pagou o esforço de desenvolvimento para mover um aplicativo do .NET Framework para Java para implantação do UNIX, pois ele não estava disposto a aposte no .NET Core e na implementação deficiente do ODP.NET, enquanto o driver JDBC oferece paridade de recursos 1: 1 com o driver ODP.NET do .NET Framework.

Outros podem escolher outras pilhas alternativas também.

Existem inúmeras dependências que não podem e não podem ser transferidas para um aplicativo corporativo comum.

Este problema apareceu no topo da HN. Vocês (@MSFT) podem querer verificar lá também. Apenas 1 hora e já mais de 50 comentários.

@davidfowl

Não vejo como isso mata o .NET Standard. O .NET Standard é muito maior do que o ASP.NET Core. Trata-se de criar bibliotecas compartilhadas reutilizáveis ​​(como Microsoft.Extensions *) que funcionam em qualquer plataforma .NET de suporte.

Eu não entendo o que ASP.NET Core é se não uma biblioteca compartilhada reutilizável? Se a tendência para as bibliotecas serem modernas e rápidas é abandonar o suporte ao .NET Standard, então é uma mensagem complicada. O Newtonsoft.Json deve mudar para o .NET Core 3 apenas, se puder ser executado muito mais rápido? Deve Autofac?

Eu entendo as razões por trás disso, mas não tenho certeza se os argumentos e a avaliação mudaram muito desde a última vez que isso apareceu! Acho que vamos esperar e ver ...

Vou apresentar meu caso de uso e dar uma perspectiva de como as coisas estão em nossa loja agora, no que se refere a:

AspNetCore tem sido incrível para nossa pilha em termos de auto-hospedagem (http.sys) de uma API da web e conteúdo estático da web em torno de vários serviços. Viemos de Nancy, o que era sólido, mas também tinha muitas falhas de nossa perspectiva, então mudamos para AspNetCore há cerca de um ano. Hoje, estamos executando cada uma de nossas bases de código no 2.x. Em muitos casos, não haveria problema em mudar para um destino .NET Core puro. Mas, também existem muitos serviços que construímos para alavancar AspNetCore que também dependem de coisas como System.DirectoryServices e System.Drawing . Da perspectiva desses serviços, mudaríamos a tecnologia de hospedagem na web antes de sair do .Net Framework. Infelizmente, devido às complexidades de gerenciar 2 tecnologias de hospedagem na web diferentes simultaneamente e ao tamanho de nossa equipe, provavelmente também tiraríamos o AspNetCore do restante de nossos serviços em favor de algo mais compatível em ambos os alvos.

Resumindo - essa decisão nos forçará completamente a sair da AspNetCore em algum momento no futuro (provavelmente quando o LTS expirar para 2.x), pelo que não sei agora. Se for o caso, provavelmente iremos escrever nossa própria solução interna para substituir o AspNetCore, já que nossos casos de uso em termos de número real de recursos do AspNetCore sendo usados ​​são bastante restritos (sendo assim, os recursos que _do_ alavancamos fornecem um enorme valor agregado para nós hoje).

Outros podem escolher outras pilhas alternativas também.

Isso é justo, mas as pilhas alternativas têm a mesma política de suporte. Java mudou para um modelo LTS semelhante (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Existem inúmeras dependências que não podem e não podem ser transferidas para um aplicativo corporativo comum.

@bencyoung

É uma estrutura, não uma biblioteca. É composto de um grande conjunto de bibliotecas que são enviadas juntas.

Eu não entendo o que ASP.NET Core é se não uma biblioteca compartilhada reutilizável? Se a tendência para as bibliotecas serem modernas e rápidas é abandonar o suporte ao .NET Standard, então é uma mensagem complicada. O Newtonsoft.Json deve mudar para o .NET Core 3 apenas, se puder ser executado muito mais rápido? Deve Autofac?

Não vejo como é complicado. Tenho 97% de certeza de que essas bibliotecas não removerão estruturas porque seus clientes reclamariam. A barreira é extremamente alta para a remoção de frameworks e é o mesmo motivo pelo qual mantivemos Microsoft.Extensions. * No .NET Standard 2.0. Concordo que seria confuso se movêssemos tudo para lá, mas não é isso que está acontecendo aqui.

De certa forma, isso é apenas formalizar o que a realidade já é no .NET Core. Nós fornecemos ASP.NET Core com .NET Core. No .NET Core, o ASP.NET Core é uma estrutura compartilhada, não é apenas um conjunto de pacotes. Esses pacotes nunca são enviados separadamente do produto geral, então os benefícios de fazer referência a esses pacotes individuais são pequenos (a lista de pacotes também é pequena).

@robkeimig

Mas, também existem muitos serviços que construímos para alavancar AspNetCore que também dependem de coisas como System.DirectoryServices e System.Drawing

Eles existem no pacote compacto do Windows no .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Resumindo - essa decisão nos forçará completamente a sair da AspNetCore em algum momento no futuro (provavelmente quando o LTS expirar para 2.x), pelo que não sei agora. Se for o caso, provavelmente iremos escrever nossa própria solução interna para substituir o AspNetCore, já que nossos casos de uso em termos de número real de recursos do AspNetCore sendo usados ​​são bastante limitados (dito isto, os recursos que alavancamos fornecem um enorme valor agregado para nós hoje).

Isso também aconteceria se o suporte fosse estendido?

Além disso, agora teríamos que eliminar todas as outras tecnologias sem suporte (AppDomains, Remoting, etc.) primeiro, em vez de poder fazer esse trabalho em paralelo ou em um estágio posterior.

Por que você não pode migrar para o 2.1 primeiro?

A maior razão pela qual eu hesitaria é que o limite de suporte de 3 anos significa que você não pode ficar com eles. É um ponto de partida para a migração de curto prazo, não um ponto onde você pode ter uma plataforma estável de longo prazo. O que significa que você tem que assumir toda a dor de migrar para a frente de uma só vez, porque você não pode arriscar ir até a metade, pausando a migração para construir uma série de novos recursos de alta prioridade e, em seguida, tentar terminar a migração apenas para encontrar um bloqueio rígido e tem que fazer backport de todos os seus novos recursos para a base de código antiga.

A maior razão pela qual eu hesitaria é que o limite de suporte de 3 anos significa que você não pode ficar com eles.

Claro, é por isso que oferecemos suporte estendido como @DamianEdwards mencionado.

Só para mostrar quanta consequência essa decisão cria - e o Blazor? Ele deixará de ser baseado no padrão da rede? Devemos esperar isso também? Blazor está sendo anunciado como a próxima grande novidade. O que mais de github.com/aspnet que atualmente depende do netstandard irá descartá-lo e passar para o núcleo da rede no próximo lançamento principal? Quais são os planos para outras coisas, no controle MSFT, mas fora do repositório aspnet que compartilhará o destino do aspnetcore?

@davidfowl

Outros podem escolher outras pilhas alternativas também.

Isso é justo, mas as pilhas alternativas têm a mesma política de suporte. Java mudou para um modelo LTS semelhante (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

O pequeno detalhe que você está esquecendo é que Java, e outras pilhas, ainda são compatíveis entre as versões, ao contrário do .NET Framework e do .NET Core, sem a necessidade de um padrão que é apenas parcialmente implementado nas implementações de tempo de execução.

Pelo que vale a pena, estou trabalhando atualmente na implantação do primeiro aplicativo principal ASP.Net da minha empresa. Temos um investimento realmente pesado no .NET Framework, portanto, usar ASP.Net Core no .NET Framework em vez do .NET Core era a abordagem óbvia.

Agora estou me perguntando se estou preparando-nos para muita dor mais tarde.

Existem muitas questões interligadas aqui. Você diz que o núcleo ASP.Net nunca foi feito para rodar apenas no .NET Framework. As mensagens da Microsoft sobre o ASP.Net Core no passado não deixaram isso muito claro.

Da mesma forma, muitos desenvolvedores .NET estão acostumados com a ideia de que o .NET Framework é a implementação principal e que geralmente os outros são subconjuntos, exceto, é claro, para APIs específicas do ambiente. Isso mudou com o .NET Core, mas muitas pessoas geralmente tinham a impressão de que o .NET Framework "completo" acabaria dando suporte a tudo que quase o .NET Core faz (exceto para as ferramentas e compatibilidade entre plataformas, obviamente), mas apenas em uma escala de tempo mais lenta, esperando que as torções sejam resolvidas antes de incluí-las.

Recentemente, tem havido muitas sugestões de que alguns recursos realmente significativos podem nunca chegar ao .NET Framework. (por exemplo, que os riscos de compatibilidade do Spantipo considerado muito grave para ser implementado no .NET Framework 4.8 sugere que eles podem nunca ser implementados, já que por que esses riscos seriam menores no 4.9 ?. Preocupações semelhantes aparentemente envolvem os Métodos de Interface Padrão.) Essa é uma grande mudança de paradigma com a qual muitos desenvolvedores não ficarão satisfeitos!

As mensagens neste mesmo tópico sugerem que a Microsoft está começando a considerar o .NET Framework como um recurso legado, algo que receberá cada vez menos atenção de desenvolvimento com o tempo, até que realmente obtenha apenas correções de segurança.

A Microsoft historicamente tem sido péssima em ser clara sobre o que está desenvolvendo ativamente, o que está basicamente mantendo apenas com novos recursos esporádicos e o que planeja realmente fornecer apenas correções de segurança e estabilidade. Parece-me muito que o .NET Framework não está apenas na segunda categoria agora, mas está realmente perto de estar na terceira categoria.

Isso é realmente irritante. O .NET Core tem alguns problemas que o tornam menos do que ideal para alguns aplicativos corporativos. Claro, usá-lo em aplicativos que têm desenvolvimento contínuo contínuo pode ser bom. Mas, como exemplo, a maioria das empresas também possui alguns aplicativos que são implantados e são tocados apenas uma vez a cada poucos anos. Isso funciona mal com o .NET Core. Aqui, as empresas precisam lutar com ciclos de suporte curtos para a maioria das versões. E não havendo no Windows, nenhum mecanismo existe atualmente para instalar automaticamente os novos lançamentos de patch para obter as atualizações de segurança, etc.

Assim, as empresas que estão iniciando novos projetos ficam sem saber o que fazer. Quanto mais amigável para empresas, o .NET Framework está exibindo sinais claros de se tornar obsoleto e, portanto, algo melhor evitado para novos desenvolvimentos. Por outro lado, o .NET Core existe, mas é substancialmente menos amigável para empresas.

Então, isso basicamente se tornou um discurso retórico, mas espero que ilustre melhor as preocupações que muitos desenvolvedores estão tendo.

@davidfowl

Mas, também existem muitos serviços que construímos para alavancar AspNetCore que também dependem de coisas como System.DirectoryServices e System.Drawing

Eles existem no pacote compacto do Windows no .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Eu não sabia que o pacote de compatibilidade era compatível com esse caso de uso. Idealmente, gostaríamos de mover tudo para o .NET Core, e essa parece ser uma resposta muito boa (que podemos ter esquecido inicialmente). Não temos planos de mover a hospedagem de nossos serviços para Linux / OSX, então essas peças poderiam se encaixar perfeitamente para nós.

Isso também aconteceria se o suporte fosse estendido?

Em termos de suporte - sinto que o LTS de 2.x até 2021 é razoável, considerando todas as outras restrições que estão envolvidas com algo de tão longo alcance.

Com base no que estou entendendo agora, provavelmente nos sentiríamos confortáveis ​​em atualizar para AspNetCore 3.x assim que tivermos a chance de revisar e converter projetos .NET Framework em projetos .NET Core (com uso de pacote de compatibilidade conforme necessário).

Obrigado por seu acompanhamento.

Escrevi em .NET (principalmente C #) por 15 anos em projetos de alta pressão. Eu desperdicei tantos anos e dinheiro dos clientes perdendo tempo usando uma estrutura excessivamente projetada. Adorei o conceito de .NET Core. Para mim, foi a velocidade de escrever projetos NodeJS, mas no incrível ecossistema .NET (incluindo toda a gordura). Infelizmente, ele falhou nessa promessa, ainda é (mesmo com este novo anúncio) muito complicado para usar. Nos últimos 3 anos venho construindo em NodeJS, desculpe pessoal, não se compara. Torne-o mais simples e fácil de usar e você atrairá novamente a ampla comunidade de desenvolvedores.

Para projetos com dependências binárias compiladas do .NET Framework (material do fornecedor sem código-fonte) que podem ser executados em aplicativos ASP.NET Core 2.1 direcionados ao .NET Framework implantado no Windows, a adição do Pacote de Compatibilidade do Windows ao projeto os manterá funcionando Core 3.0 se as dependências rígidas fazem referência aos tipos fornecidos pelo pacote?

Existe um enorme ecossistema de bibliotecas comerciais extremamente maduras que, infelizmente, dependem do System.Drawing, GDI e às vezes do Registry (!). Se eles só funcionarem agora com o 2.1 e forem suportados por apenas três anos, esse é um problema que pode impedir a adoção do Core em algumas empresas.

O .NET Core está fazendo um círculo completo para chegar ao ponto de partida.

Eu sugeriria outra abordagem: permitir que o .NET Framework incorpore os recursos úteis do .NET Core e, em seguida, elimine o .NET Core como um branch experimental sem saída. Parando assim a segmentação e economizando a tecnologia para maior benefício dos clientes. Uma abordagem um tanto controversa, mas muito mais sã em relação ao produto.

@davidfowl

O ASP.NET Core em execução no .NET Framework nunca foi feito para ser uma coisa permanente, sempre foi concebido como um trampolim

Isso simplesmente não é verdade. A mensagem no ASP.NET Core sempre foi de que há suporte no .NET Core e no .NET Framework. Mesmo os primeiros anúncios do .NET Core mencionam ambas as plataformas para ASP.NET Core (na época, ASP.NET 5).

A imagem muito conhecida que mostra o .NET Standard também tem ASP.NET Core abrangendo o Core e a estrutura completa. E a documentação oficial ainda diz: “Não há planos para remover o suporte para direcionar o .NET Framework no ASP.NET Core.”

Então, sim, é óbvio que essa decisão mudou agora , mas dizer que sempre foi assim é apenas uma mentira ou uma péssima comunicação feita pela Microsoft ao longo dos anos .

é até chamado ASP.NET Core

Oh vamos lá. Depois de todo esse tempo, pessoas como eu tiveram que lutar contra outras pessoas para separar .NET Core e ASP.NET Core porque eles não são a mesma coisa, não use o nome semelhante para sua vantagem aqui. Isso não é justo. A mudança de nome para “Core” certamente não era para vinculá-lo explicitamente ao .NET Core. Além disso, o EF Core também tem um “Core”, mas continuará a funcionar no padrão da rede, então esse argumento não funciona.

é aí que entra o suporte LTS estendido. Se o aplicativo nunca pode ser movido para o .NET Core, mesmo após esses 6 anos [...]

De onde veio isso agora? Da última vez, a mensagem ainda era “estamos investigando uma oferta de LTS de 'suporte estendido'” . Isso é real agora e temos 6 anos?

@pjmlp

O pequeno detalhe que você está esquecendo é que Java, e outras pilhas, ainda são compatíveis entre as versões, ao contrário do .NET Framework e do .NET Core, sem a necessidade de um padrão que é apenas parcialmente implementado nas implementações de tempo de execução.

Ponto justo, mas não entendo o que isso tem a ver com um suporte melhor. Foi feita a alegação de que mudar para Java seria melhor por causa de bibliotecas menos deficientes (o que é um problema pontual) e suporte corporativo (ciclo de suporte mais longo).

@KevinCathcart

As mensagens neste mesmo tópico sugerem que a Microsoft está começando a considerar o .NET Framework como um recurso legado, algo que receberá cada vez menos atenção de desenvolvimento com o tempo, até que realmente obtenha apenas correções de segurança.

A Microsoft historicamente tem sido péssima em ser clara sobre o que está desenvolvendo ativamente, o que está basicamente mantendo apenas com novos recursos esporádicos e o que planeja realmente fornecer apenas correções de segurança e estabilidade. Parece-me muito que o .NET Framework não está apenas na segunda categoria agora, mas está realmente perto de estar na terceira categoria.

Consulte https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Para projetos com dependências binárias compiladas do .NET Framework (material do fornecedor sem código-fonte) que podem ser executados em aplicativos ASP.NET Core 2.1 direcionados ao .NET Framework implantado no Windows, a adição do Pacote de Compatibilidade do Windows ao projeto os manterá funcionando Core 3.0 se as dependências rígidas fazem referência aos tipos fornecidos pelo pacote?

Sim, é compatível com o binário.

Existe um enorme ecossistema de bibliotecas comerciais extremamente maduras que, infelizmente, dependem do System.Drawing, GDI e às vezes do Registry (!). Se estes funcionarem apenas agora com 2.1 e forem suportados apenas por três anos, este é um problema que pode impedir a adoção do Core em algumas empresas

Como já mencionei várias vezes neste tópico. Adicionamos a capacidade de fazer referência direta às dependências compiladas no .NET Framework em projetos do .NET Core.

@poke Você está certo sobre a mensagem, não ficou nada claro, erro meu.

De onde veio isso agora? Da última vez, a mensagem ainda era “estamos investigando uma oferta de LTS de 'suporte estendido'”. Isso é real agora e temos 6 anos?

Eu inventei 6, não sei como o suporte será estendido quando o oferecermos.

O .NET Core sempre substituirá o .NET Framework (originalmente seria o .NET Framework 5), mas a reescrita foi tão ambiciosa que agora é usada para oferecer suporte a aplicativos de desktop.

Uau, sempre há muitos comentários hilários aqui. Parece que há muita fúria nerd mal colocada, intercalada com pessoas que não leram o artigo.

modo de espera

@edandersen , você executou o ApiPort nessas dlls externas? Ele mostrará se eles usam APIs que não estão disponíveis no .NET Core. Se ele usa apenas APIs disponíveis, então não deve ser um problema, caso contrário, saber quais APIs estão faltando ajuda na discussão e priorização de recursos.
O pacote de compatibilidade do Windows já fornece funcionalidade para system.drawing e o registro. Você já tentou executar essas coisas no .NET Core? System.Drawing funciona até em * nix usando libgdiplus do mono. Isso nos permite usar ClosedXML em sistemas não Windows para trabalhar com arquivos Excel.

A maior dependência do .NET Framework para aplicativos "recentes" em nossa empresa é a funcionalidade WCF.
As bibliotecas de cliente do .NET Core WCF estão melhorando. Não verifiquei o status atual de como eles funcionam com alguns serviços que consumimos, mas, no passado, não podíamos falar com alguns serviços. Mas a funcionalidade ausente já estava em sua lista de problemas. Serviços simples funcionam bem por outro lado!
Por outro lado, não há um substituto "imediato" para a hospedagem de serviços SOAP no .NET Core. Isso bloquearia a migração de alguns aplicativos para o .NET Core (mas, como mencionado - não é necessário).
Para um aplicativo ASP.NET Core recente, criamos um aplicativo Web proxy ASP.NET adicional que apenas hospeda um serviço WCF e, em seguida, encaminha para o aplicativo ASP.NET Core via HTTP / JSON. Não é muito bonito e adiciona complexidade de implantação, mas permite alguns pontos de integração.

Não estou dizendo que realmente quero o recurso de hospedagem WCF no .NET Core, visto que tenho dores de cabeça ao configurá-lo. Algumas opções para hospedar serviços SOAP e gerar WSDL seriam legais. Já vi algumas bibliotecas OSS tentando fazer isso. Talvez isso seja o suficiente.

@ davidfowl

Ponto justo, mas não entendo o que isso tem a ver com um suporte melhor. Foi feita a alegação de que mudar para Java seria melhor por causa de bibliotecas menos deficientes (o que é um problema pontual) e suporte corporativo (ciclo de suporte mais longo).

O ponto é que, embora as versões Java LTS também tenham três anos, a compatibilidade entre todas as principais implementações é ouro, que é algo que vocês estão dispostos a jogar fora da janela aqui.

Todos esses erros do .NET Framework, .NET Core, Xamarin, .NET Standard estão começando a parecer os bons velhos tempos do WinDev vs DevTools, apenas dentro das equipes .NET para uma mudança.

Então, naturalmente, os clientes estão dispostos a mudar para plataformas que não parecem com equipes internas lutando por recursos de roadmap.

Essas decisões não inspiram confiança.

Isso realmente parece um erro da parte da equipe .NET, especialmente no contexto do clima atual!

Para aqueles que mencionam Java, você realmente olhou o que está acontecendo lá recentemente? Entre seu processo absolutamente insano contra o Google por usá-lo no Android e suas últimas travessuras de licenciamento, o comportamento da Oracle parece consistentemente ser o de uma empresa que quer matar um produto indesejado, ao invés de uma que quer que ele prospere!

Este é o momento perfeito para a Microsoft capitalizar isso com marketing poderoso, sugerindo que eles estão fazendo exatamente o oposto, e que o .NET é o lugar certo para opções de desenvolvimento saudáveis, estáveis ​​e seguras. Em vez disso, obtemos ... isso. : desapontado:

@masonwheeler

Nós que trabalhamos em ambos os ambientes realmente apreciamos o trabalho da Oracle
tem feito com o Java.

São aqueles que raramente usam Java em produção, desprezam Oracle, que obtêm
perdidos em argumentos de ódio contra eles.

No que diz respeito ao Android, apóio totalmente a ação, já que o Google
conseguiu bifurcar a plataforma Java, obtendo sucesso onde a Microsoft falhou
com J ++. Ainda estamos ansiosos para o dia em que qualquer JAR aleatório no Maven Central funcionará no Android.

Quanto ao .NET, estou começando a ficar farto das reinicializações contínuas de
como devemos direcionar as plataformas da Microsoft.

Todo o WinRT, UAP, UWP, .NET Native removendo F #, XNA, Core 1.0 foi deixado
muitas uvas verdes e esta decisão recente não torna as coisas melhores
No geral.

.NET é minha plataforma favorita, então não a estrague ainda mais.

@mythz

Agora eu entendo que 2.1 sendo a última versão LTS com suporte no .NET Framework significa que não há lugar para atualizar

O que significa que se tornou uma plataforma sem suporte, qualquer pessoa nela tem que tratá-la como lava e lutar para sair dela antes que alcance seu fim EOL sem suporte.

Esse é um dos pontos que realmente não entendo em toda a discussão. O que você realmente obtém do suporte LTS além das correções de segurança (que poderiam ser cobertas com o suporte LTS estendido)?

No suporte LTS mainstream, existem apenas duas coisas a esperar:

  • Correções de segurança
  • Correções de bugs críticos

A maioria dos primeiros (correções de segurança) será corrigida por meio do Windows Update (desde que você tenha como alvo o .NET Framework). Portanto, apenas as correções de bugs críticos e de segurança restantes são aquelas no próprio ASP.NET Core.

Digamos que você já saiba que o suporte termina em 2018, eu não esperaria que alguém iniciasse novos projetos em 2020, então é (imho) improvável que você encontre um bug crítico após 2021 (ou 2026 ou por quanto tempo o suporte estendido é necessário ser estar).

Isso apenas deixa os bugs de segurança abertos, o que é razoável cobrir com LTS.

Em respostas anteriores, eu vi a menção de TLS 1.4 etc., eles não seriam cobertos em um LTS de qualquer maneira, pois é um novo recurso de qualquer maneira, que é o mesmo para Java (Java 6 apenas tendo suporte para TLS 1.0 - TLS 1.1 se você contar com atualizações não públicas disponíveis apenas para assinantes de suporte estendido da Oracle).

  • Qualquer um que pensou em usá-lo como uma plataforma de teste para migrar para o .NET Core se tornou uma opção menos viável, pois enfrentam o risco de ficarem presos em uma plataforma sem suporte se a migração demorar mais do que o esperado ou se encontrarem obstáculos se alguma das dependências eles confiam não podem ser executados no .NET Core.
    Mas quais APIs estão faltando e que agora você pode usar com o ASP.NET Core no .NET Framework, mas não no ASP.NET Core nos pacotes de compatibilidade do .NET Framework +?

Acho que esse é o ponto mais crítico aqui, para identificar esses e enviar as APIs ausentes com pacotes de compatibilidade futuros ou adicioná-los ao .NET Core, tornando possível fazer referência às bibliotecas do .NET Framework mesmo quando direcionado ao .NET Core.

Desde o .NET Core, você pode fazer referência (e usar) qualquer biblioteca .NET Framework em um projeto .NET Core , desde que use apenas APIs disponíveis no .NET Standard ou .NET Core .

Isso não exige que o autor da biblioteca atualize suas bibliotecas para ter como alvo netstandard / netcoreapp.

Talvez ajudasse se a Microsoft estendesse a página da web / biblioteca do NuGet por um recurso / link ao lado de cada pacote nuget em nuget.org que mostra um relatório se esta biblioteca usa APIs incompatíveis não disponíveis em versões específicas do .NET Core.

Por exemplo

'Company.Example.MyLib` seria mostrado

  • .NET Core 2.1: suporte parcial (relatório detalhado) - onde o relatório detalhado mostraria Apis que funcionam e quais não
  • .NET Core 3.0 :; totalmente suportado

Isso deve ser possível executando o .NET Portability Analyzer? Um bônus seria, se ele adicionar uma lista de APIs públicas que são seguras para chamar (analisando o Código IL e ver quais outras APIs estão chamando para ter certeza de que são seguras ou não)?

Isso pelo menos tornaria mais fácil para os desenvolvedores determinar se uma biblioteca específica de que eles precisam para seu projeto pode ser executada no .NET Core ou não, mesmo que não a chame explicitamente?

No momento, é meio chato descobrir se as APIs são suportadas ou não, você precisa da biblioteca, execute o analisador localmente nela. Muitos desenvolvedores podem não saber que podem usar algumas das bibliotecas que não oferecem suporte oficial ao netstandard.

@davidfowl @terrajobst Seria uma adição viável ao NuGet? Para tornar a descoberta de bibliotecas .NET Framework compatíveis com -NET Core mais fácil e rápida?

  • Qualquer pessoa forçada a usar os servidores .NET Framework da infraestrutura gerenciada existente em sua empresa não pode participar do uso do novo modelo e ecossistema de desenvolvimento e precisa ver seus conhecimentos / habilidades em ASP.NET clássicos existentes se tornarem menos valiosos a cada dia.

Isso dificilmente é um argumento a favor ou contra o suporte do .NET Framework ou não. Pessoas que estão presas a dependências legadas e não podem migrar para o .NET Core (com pacote de compatibilidade ou com bibliotecas .NET Framework) não conseguirão fazer nada depois disso. Como isso mudaria alguma coisa?

Ainda assim, partes dos aplicativos monolíticos podem ser divididas e mover gradualmente partes do aplicativo legado para um novo, mas isso é uma história diferente.

  • Nenhuma organização quer ser forçada a uma migração não planejada porque a orientação que confiaram para basear suas decisões de orçamento, planejamento e investimento mudou.

Se os benefícios superam os investimentos, por que não? ou seja, se houver recursos exclusivos que proporcionam um grande valor em troca ou um grande aumento de desempenho.

Se não, continue com o sistema antigo. O desenvolvimento de software foi assim desde sempre. Ainda existem empresas executando softwares desenvolvidos na Fortune e Cobol.

Há muitas pessoas que não podem ou não querem mudar para o .NET Core, elas querem que ele compartilhe o mesmo nível de suporte do ASP.NET clássico (que a mensagem atual sugere que seja indefinidamente).

APIs ausentes não é o único motivo que impede a migração, por exemplo, eles podem estar contando com uma dependência onde a equipe de desenvolvimento a criou não existe mais, é um componente crítico que não pode ser alterado, não pode ser refatorado com segurança (por exemplo, sem testes), é compartilhado com outros sistemas somente .NET FX, é mantido por outro departamento que não tem orçamento, capacidade de alterá-lo ou devido a fatores externos como a infraestrutura gerenciada de suas empresas só suporta a execução em servidores .NET Framework.

Sim, mas quais dependências? Exemplos concretos seriam necessários para identificar quais APIs essas dependências externas estão usando. Essa API pode ser adicionada ao .NET Core 3.0 ou a uma versão futura do .NET Core.

Isso possibilita o uso dessa biblioteca .NET Framework em projetos .NET Core. O único problema é quando as bibliotecas do .NET Framework usam APIs que não estão disponíveis no .NET Standard ou .NET Core. Mas para consertar esse feedback é necessário identificar as bibliotecas.

@pjmlp

@davidfowl

Outros podem escolher outras pilhas alternativas também.

Isso é justo, mas as pilhas alternativas têm a mesma política de suporte. Java mudou para um modelo LTS semelhante (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

O pequeno detalhe que você está esquecendo é que Java, e outras pilhas, ainda são compatíveis entre as versões, ao contrário do .NET Framework e do .NET Core, sem a necessidade de um padrão que é apenas parcialmente implementado nas implementações de tempo de execução.

Isso não é exatamente verdade para as edições Java posteriores. Java 9 adicionou a primeira etapa para modularizar o tempo de execução, o que É uma mudança significativa . Na Versão 9, isso foi desabilitado por padrão, mas em versões futuras, o sinalizador será habilitado por padrão (ou não será capaz de desligá-lo) e isso cria mudanças significativas nos aplicativos legados.

Por exemplo, as muitas bibliotecas que usam APIs internas por meio de alguma mágica de reflexão podem e irão romper com essa mudança. E muitas dessas bibliotecas, como no mundo .NET, não são mais mantidas, então atualizações não são esperadas.

@ TsengSR

Apesar das mudanças significativas introduzidas no Java 9, 100% de todos os frameworks Java relevantes funcionam em Java 9, 10 e 11, o que definitivamente não é o caso em .NET Framework, UWP e Core.

Imagine que até mesmo existam dois frameworks GUI multiplataforma oficiais, enquanto ainda não temos um roadmap oficial para o Core!

@pjmlp

@ TsengSR

Apesar das mudanças significativas introduzidas no Java 9, 100% de todos os frameworks Java relevantes funcionam em Java 9, 10 e 11, o que definitivamente não é o caso em .NET Framework, UWP e Core.

Imagine que até mesmo existam dois frameworks GUI multiplataforma oficiais, enquanto ainda não temos um roadmap oficial para o Core!

Desculpe, isso é completamente sem sentido.

Os módulos internos do Java 9, que evitam refletir nesses módulos, a menos que --add-opens seja chamado (e iirc sempre deveria ser uma solução temporária para que as pessoas continuassem a executar seus aplicativos legados e removessem algumas versões depois).

Caso você tenha perdido o drama e a merda quando o Java 9 estava para ser lançado, esta foi a resposta a ele:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Para ajudar todo o ecossistema a migrar para a plataforma modular Java em um
ritmo mais relaxado, proponho permitir o acesso reflexivo ilegal
do código no caminho da classe por padrão no JDK 9, e para proibi-lo nouma futura versão.

Além disso, o JAX-WS obsoleto do Java EE 9 foi descontinuado e deve ser removido no Java EE 11. Isso poderia ser visto como equivalente ao WCF. Qualquer uso aplicável não pode ser transferido para uma versão mais recente nem sem substituí-lo por outra coisa, que é um processo de migração. Nem mais nem menos diferente do que migrar do ASP.NET Core no .NET Framework para o ASP.NET Core no .NET Core (ou do ASP.NET para o ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Maior integridade da plataforma - antes do Java 9, era possível usar muitas classes na plataforma que não deviam ser usadas pelas classes de um aplicativo. Com forte encapsulamento, essas APIs internas são realmente encapsuladas e ocultas dos aplicativos que usam a plataforma. Isso pode tornar problemática a migração do código legado para o Java 9 modularizado se seu código depender de APIs internas.

Qualquer aplicativo que usava essas APIs internas (incluindo todas no namespace sun.* que algumas das bibliotecas antigas usavam - ou costumavam usar quando o Java 9 estava para ser lançado) ou usa uma biblioteca de terceiros que depende nestas APIs ou em outra biblioteca podem estar sujeitas a esta alteração significativa. O problema é que, como no .NET Framework e no .NET Core, você não vê apenas na biblioteca quais APIs são chamadas ou não.

@TsengSR

Os módulos internos do Java 9, que evitam refletir nesses módulos, a menos que --add-opens seja chamado (e iirc sempre foi considerado uma solução temporária para que as pessoas possam continuar a executar seus aplicativos legados e remover algumas versões depois).

Ou você pode usar o modo classpath e pular a bagunça que é os módulos. Esse modo permanecerá por um futuro próximo. E se você entrar em módulos, você pode declarar explicitamente as dependências nos pacotes de outros módulos.

Além disso, o JAX-WS obsoleto do Java EE 9 foi descontinuado e deve ser removido no Java EE 11. Isso poderia ser visto como equivalente ao WCF.

Todo o J2EE foi descontinuado e removido no Java 11, que já foi lançado. Mas J2EE apenas define as interfaces, não a implementação. Para continuar usando J2EE, o que eu faço, você só precisa alternar as dependências. Todas as implementações foram separadas de qualquer maneira e funcionam bem no Java 11.

Qualquer aplicativo que usava essas APIs internas (incluindo all in sun. * Namespace que algumas das bibliotecas antigas usavam - ou costumavam usar quando o Java 9 estava para ser lançado) ou usa uma biblioteca de terceiros que depende dessas APIs ou outra biblioteca pode estar sujeita a essa alteração significativa.

Que sempre foi o caso. Eles eram APIs não documentados. Ninguém deveria estar usando-os e eles poderiam ter sido alterados ou removidos a qualquer momento. Muitas das APIs internas comumente (ab) usadas foram deixadas para não quebrar os programas existentes, para que possam migrar para as APIs apropriadas no futuro.

Algumas APIs foram descontinuadas, mas estamos falando de APIs específicas e não de todo o ecossistema JRE ou Java. O trabalho necessário para passar dessas APIs para APIs mais recentes, oficiais e documentadas é geralmente mínimo.

E o Java sempre esteve mais disposto a quebrar a compatibilidade com versões anteriores do que o .NET. Por exemplo, em Java agora é ilegal declarar um tipo denominado var porque está reservado para inferência local. Em Java, é ilegal nomear uma variável _ porque ela está reservada para uso como descarte / curinga. C # tomou a decisão exatamente oposta em ambos os casos, em nome da preservação da compatibilidade com versões anteriores.

Não me entenda mal, Java é sua própria bagunça. Entre os módulos, o suporte para Java 8 está chegando ao fim e a Oracle ficando gananciosa com o licenciamento JRE, há uma grande oportunidade para a Microsoft converter pessoas. Mas isso é muito improvável de acontecer se a Microsoft for lançar mensagens contraditórias sobre o suporte futuro e a evolução de suas plataformas.

@TsengSR

Esse é um dos pontos que realmente não entendo em toda a discussão. O que você realmente obtém do suporte LTS além das correções de segurança (que poderiam ser cobertas com o suporte LTS estendido)?

Há um relógio tiquetaqueando naquele LTS que vai terminar sem nenhum lugar para atualizar, o que é o ponto-chave sendo ignorado quando o Java LTS está sendo usado em comparação. Com Java e .NET Framework, você sempre teve um alto grau de confiança de que poderia atualizar os sistemas existentes com o mínimo de esforço, dado seu forte foco na compatibilidade com versões anteriores. Como não há mais um caminho de atualização, os sistemas existentes são forçados a migrar para um novo tempo de execução ou continuar a funcionar em uma plataforma sem suporte. Por vários motivos, haverá sistemas em que será inviável migrar para o .NET Core, deixando seu futuro (com esta decisão) para manter a execução de suas funções críticas de negócios em uma plataforma sem suporte.

Não tenho certeza de qual seria a metáfora mais próxima dessa decisão na terra do Java, talvez forçando os sistemas existentes a migrar para rodar no GraalVM, muitas coisas funcionarão, algumas não, quanto maior o sistema, menos confiança em ser capaz de prever compatibilidade / problemas até que uma migração seja tentada fisicamente.

Concordo que muito foi feito para possibilitar as migrações para o .NET Core, mas ainda haverá uma série de fatores externos (incluindo fora do controle do MS) que impedirão as migrações e essa decisão só servirá migrações menos prováveis ​​como antes deste anúncio ASP.Core / FX era um caminho de migração popular, mas não será mais prudente recomendar uma estratégia de migração geral para incluir a migração para uma plataforma futura sem suporte, o que evitará muitas migrações de ocorrer, resultando em mais sistemas / desenvolvedores existentes sendo deixados no ASP.NET clássico estagnado.

A maioria dos primeiros (correções de segurança) será corrigida por meio do Windows Update (desde que você tenha como alvo o .NET Framework). Portanto, apenas as correções de bugs críticos e de segurança restantes são aquelas no próprio ASP.NET Core.

As organizações não querem basear sua empresa em uma plataforma parcialmente suportada na esperança de que quaisquer bugs ou problemas de segurança futuros aconteçam apenas nas bibliotecas que foram reservadas para suporte. Seria um longo caminho se o ASP.Core / FX fosse coberto pelo mesmo nível de suporte que o resto do .NET Framework, onde quaisquer vulnerabilidades de segurança futuras serão resolvidas.

Atualmente, apenas a MS será capaz de corrigir e lançar pacotes ASP.Core NuGet atualizados, com a árvore de interconexão de dependências sendo OSS não vai ajudar muito aqui, a menos que 2.1 PR's que eles recebem (pós LTS) sejam revisados, aceitos e liberado.

No final, depois que todos os detalhes foram discutidos, a questão final que ainda importa é:

Podemos continuar executando nossos sistemas existentes em ASP.Core / FX?

Tecnicamente, será possível, mas sem garantias de que futuros bugs críticos / vulnerabilidades de segurança serão resolvidos, a recomendação se tornou NÃO, deixando o ecossistema externo afetado absorvendo a dor dessa decisão.

Se o ASP.NET Core for apenas .NET Core, como devemos nos sentir em relação a toda essa coisa do .NET Standard?

Se a própria Microsoft não está apostando nisso por motivos (sem dúvida válidos), por que deveríamos?

Haverá bibliotecas exclusivas do .NET Core de primeira classe e de ponta e bibliotecas do .NET Standard mais “simples” e menos avançadas?

Isso parece matar a necessidade de melhorar qualquer plataforma não .NET Core.

Espero que alguém possa me mostrar que estou errado e aliviar minhas preocupações.

Oi,
Eu vejo o valor em seguir em frente e adoro isso, mas vejo três questões principais sobre esta decisão:
1) O netstandard será um cidadão de segunda classe se ninguém dentro da microsoft construir algo difícil com ele, se vocês não fizerem dogfood, como podem pedir a outro desenvolvedor para fazer isso? Hoje os autores de bibliotecas têm que trabalhar muito, o suporte não vai melhorar se o ppl interno não usar o padrão.
2) há valor em executar o núcleo do aspnet em outros tempos de execução.
3) há valor em software rodando em tempos de execução antigos (com dependência que nunca será tocada) que não deve ser descartado levianamente.

Depois, há a comunicação: acho que todos adorariam um runtime .net que funcione em qualquer lugar, mas isso é uma utopia para o futuro previsível e o netstandard foi criado como substituto. Do meu ponto de vista, todo projeto que não vise o netstandard, mas uma plataforma, é um passo que não vai na direção dessa visão.
É claro que o framework .net está em modo de manutenção, .netcore tomará seu lugar (deixando algum cadáver para trás) e mono irá rodar nos dispositivos, aot story e CoreRT não procuram avançar.

Com o netcore 3.0 você faz duas coisas ao mesmo tempo: suportar cargas de trabalho de desktop e "dizer ao ppl para saltar imediatamente para se manter relevante". Eu acho que isso vai exigir um salto de fé dos desenvolvedores e é muito otimista porque todos sabem que muitos projetos não serão migrados devido a algumas dependências ausentes, que provavelmente serão adicionadas em versões 3.1 / 3.2 futuras em 1-2 anos ( muito perto dos 3 anos LTS de 2.1). Enquanto isso, os desenvolvedores que desejam ser relevantes são bloqueados para usar os 3,0 bits por causa de dependências sobre as quais não têm controle.

Será possível adiar esta decisão após o ppl ter testado e ver as reais implicações?
É possível ter o núcleo aspnet compilado para netstandard e netcoreapp como você está prescrevendo os autores da biblioteca para fazer? É normal ter um desempenho degradado em execução no framework .net 😄

Roslyn agora é executado em .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

Isso certamente conta como algo difícil!

@davidfowl

Eu acredito que isso vai começar a limitar severamente as opções para o desenvolvimento futuro de sistemas .Net Framework que não podem migrar por vários motivos, já que a comunidade está mudando os esforços para ASP.Net Core.

Por exemplo, o Identity Server já mudou para ASP.Net Core e o post recente sobre o futuro do SignalR afirmou, sem surpresa, que o ASP.Net Core SignalR será o foco futuro do esforço de desenvolvimento, com ASP.Net SignalR em modo de manutenção - o que no momento declarado, ele suportará .Net Framework e .Net Core e espero que essa seja uma tendência que continuaremos a ver.

Eu sei que o suporte LTS para ASP.NET Core já foi definido em 3 anos, mas para implantação no local, um ciclo de vida mais longo é necessário, pois temos que fornecer suporte ao longo dessas linhas (4 anos) para nossos clientes.
Durante esse período, precisamos ser capazes de lançar patches que incluam correções de segurança sem grandes alterações no aplicativo. Isso é para manter em linha com os processos de controle de alterações de nossos clientes que exigiriam testes extensivos de aceitação do usuário por eles para alterações mais importantes e para que não tenhamos que fazer grandes alterações, como a migração para uma versão mais recente em lançamentos que estão em modo de manutenção .

Existe alguma chance de a política de LTS mudar? algo como a estratégia do Ubuntu de um lançamento LTS a cada 2 anos com 5 anos de suporte - embora eu solicite 6 para permitir que o lançamento atual tenha mais de 3 anos de suporte enquanto o trabalho de migração para a nova versão é realizado.

Eu entendo que o suporte estendido foi mencionado, mas presumo que isso seja algo que cada um de nossos clientes teria que comprar, o que eu não acredito que seria palatável se sua instalação inicial (após desenvolvimento, processo de vendas, UAT etc.) na melhor das hipóteses foi 2 anos de suporte.

Além disso, estou curioso para saber como tratar a biblioteca .net padrão em tempos.
O slogan de .netstandard é "Uma biblioteca para governar todos eles".
Antes disso, parece que significa tudo.
Depois disso, parece que significa um pouco.

Só para mostrar quanta consequência essa decisão cria - e o Blazor? Ele deixará de ser baseado no padrão da rede? Devemos esperar isso também?

Alguém pode esclarecer isso?

Então, a recomendação para bibliotecas como Newtonsoft.Json (que podem se beneficiar do alto desempenho) é mudar para o .NET Core em vez do .NET Standard? Não estou vendo muita diferença entre esse tipo de biblioteca e o ASP.NET Core. Incorporamos serviços REST em aplicativos maiores - alguns dos quais podem ser facilmente movidos para o .NET Core e outros não.

No meu entendimento, a recomendação para bibliotecas é direcionar tanto o .NET Core 3 quanto o .NET Standard 2.x se você quiser obter as vantagens das novas APIs, mas não quiser perder públicos.

No meu entendimento, a recomendação para bibliotecas é direcionar tanto o .NET Core 3 quanto o .NET Standard 2.x se você quiser obter as vantagens das novas APIs, mas não quiser perder públicos.

Achei que a estrada à frente fosse normal em todos os lugares e, atualmente, estamos apenas em uma transição. Mas com um movimento como este, outros irão (ou precisarão) seguir e estamos de volta ao multi-targeting.

.NET Framework e .NET Core preenchem a mesma função, então eu acredito que é bastante esperado que o ASP.NET Core não seja executado no .NET Framework algum dia, seja agora ou mais tarde.

No entanto, vejo um grande problema em não executar em .NET Standard X . Para ser honesto, não preciso do núcleo do asp.net para rodar no xamarin ou no Unity, mas é bom poder dizer que sim - é apenas mais um conjunto de bibliotecas que roda na plataforma .NET. Com a interrupção, estamos obtendo uma integração mais estreita entre o .NET Core e o ASP.NET Core e, infelizmente, com o .NET Core 4.5, estamos condenando Microsoft.AspNetCore e @davidfowl a partir do DNX 2.0.

Por outro lado, o .NET Standard definitivamente não é um lugar para experimentar e é difícil fazer as coisas corretamente, então podemos chegar a um acordo? Seria viável ter o ASP.NET Core atual voltado apenas para .NET Core, mas versões LTS voltadas para .NET Standard? Se uma API não encontrar seu caminho para o .NET Standard, realmente vale a pena usá-la?


Também poderíamos ver isso da maneira que você provavelmente pretende:

  • .NET Core é para console / web / desktop de terceiros (padrão + API específica da web)
  • O Unity é para jogos (padrão + API específica do jogo)
  • Xamarin é para dispositivos / desktop (padrão + dispositivo / desktop específico api)

Mas quem impulsiona o .NET Standard? Como você disse antes, os recursos são limitados, portanto, sem uma necessidade real de empurrar as coisas (o que, em minha proposta, cairia na equipe principal do .net core / asp.net pela necessidade de alterações para liberar o LTS). NET Standard ficará rapidamente obsoleto.

Para quem não está prestando atenção, parece que o .NET Standard 2.1 acabou de abandonar o suporte ao .NET Framework.

Considerando que muitas das adições de API no .NET Standard 2.1 exigem alterações no tempo de execução para serem significativas, o .NET Framework 4.8 permanecerá no .NET Standard 2.0 em vez de implementar o .NET Standard 2.1. O .NET Core 3.0, bem como as próximas versões do Xamarin, Mono e Unity, serão atualizadas para implementar o .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Por mais que me dói ver o .Net Framework sendo editado pelo Silverlight, o que importa para mim em relação ao ASP.NET Core é que ele deve ter como alvo o .NET Standard .

Como aquele que é provavelmente um dos maiores aplicativos de referência no ecossistema Core / Standard, acredito que o ASP.NET Core tem a responsabilidade de ser um campeão do .Net Standard e de todas as coisas boas que ele representa.

Acredito que seja razoável para o ASP.NET Core solicitar alterações no padrão que são implementadas no .NET Core.

Da mesma forma que o Span etc _está_ disponível no .Net Framework através de um pacote nuget, acredito que seja razoável que se o ASP.NET Core precisa / deseja depender de algo que ainda não está no .Net Standard, essa dependência deve ser incluída em através de um pacote nuget.

Finalmente, espero (contra todas as evidências em contrário), que haverá um .Net Framework 5.0 que terá como alvo o .Net Standard 3.0+ e será uma instalação lado a lado com o 4.x.

Finalmente, espero (contra todas as evidências em contrário), que haverá um .Net Framework 5.0 que terá como alvo o .Net Standard 3.0+ e será uma instalação lado a lado com o 4.x.

Sim, exatamente. Isso é o que venho dizendo há anos: a arquitetura CLR 2.0 nos serviu bem por muito tempo, mas está começando a ficar difícil, e é hora de uma atualização fundamental do mesmo tipo que os Genéricos. Pode ser um tanto doloroso fazer as mudanças necessárias, mas são necessárias; a atualização com funcionalidades novas e mais poderosas é necessária da mesma forma que os genéricos eram necessários, e adiá-la só piorará a dor, e não a diminuirá, quando finalmente acontecer.

Isso é exatamente o que o .NET Core é, e esse thread é a dor temporária que está ocorrendo.

@terrajobst disse que não vai acontecer: veja o tópico: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
Sim, exceto duas coisas.

  1. Core não é uma atualização do Framework; é um conceito paralelo. Há tantas coisas realmente fundamentais que ele não pode fazer, muitas das quais, como AppDomains, nos disseram que provavelmente nunca acontecerão. Pelo amor de Deus, ainda não temos um Reflection.Emit ! Considerando o quão comum isso é em compiladores e ferramentas de geração de código, você pensaria que teria sido literalmente uma das primeiras prioridades, mas aqui estamos nós 4 anos depois e não funciona! Isso torna muito difícil levar a sério a noção de "Core como uma substituição / atualização do .Net Framework".
  2. O Core não está atualizando radicalmente o tempo de execução, estilo CLR 2.0. Em "Quais propostas de idioma se beneficiariam das mudanças de CLR?" temos uma grande lista da comunidade de recursos ausentes que as pessoas consideram importantes, que o CLR não pode suportar, (ou pelo menos não pode suportar sem enormes e feios kludges para contornar as limitações do CLR), geralmente por causa dos recursos ausentes no sistema de tipo. Quantas das propostas nesse tópico estão sendo levadas a sério pela equipe principal? E quantos dos demais foram dispensados ​​porque as pessoas que executam o projeto não querem ter que atualizar o tempo de execução? Estamos recebendo DIMs e ... mais alguma coisa? Nada mesmo?

Portanto, não, o .NET Core não é um .NET Framework atualizado que faz as atualizações CLR tão necessárias, porque não é um .NET Framework atualizado e a equipe do projeto está fazendo todo o possível para evitar a atualização do CLR sempre que possível. É literalmente o oposto disso.

Pelo amor de Deus, ainda não temos um Reflexo funcionando. Emita! Considerando o quão comum isso é em compiladores e ferramentas de geração de código, você pensaria que teria sido literalmente uma das primeiras prioridades, mas aqui estamos nós 4 anos depois e não funciona! Isso torna muito difícil levar a sério a noção de "Core como uma substituição / atualização do .Net Framework".

Seria ótimo entender o que não funciona. ASP.NET Core e EF usam a emissão de reflexão em alguns lugares, então não estou ciente das grandes lacunas. Você pode elaborar aqui?

Está lá desde pelo menos 2.0 .. iirc até 1.0 tinha DefineDynamicAssembly, embora talvez não todo o pacote de coisas emit.

Também acho difícil levar a sério a ideia de que eles estão evitando atualizar o CLR. Você já viu o grande volume de trabalho sendo feito? https://github.com/dotnet/coreclr/commits/master
Existem recursos de linguagem programados para C # 8 que só funcionarão no .NET Core devido às alterações de CLR também. Muitas dessas objeções parecem apenas ser informações antigas (o que é justo, uma vez que os planos da Microsoft mudaram rapidamente às vezes ...)

@davidfowl

Seria ótimo entender o que não funciona. ASP.NET Core e EF usam a emissão de reflexão em alguns lugares, então não estou ciente das grandes lacunas. Você pode elaborar aqui?

Admito que já se passaram alguns meses desde que verifiquei, então isso pode ter mudado recentemente, mas, pelo que sei, é possível criar uma nova montagem na memória, mas não salvá-la em disco por causa de razões misteriosas envolvendo a geração de Arquivos PDB, o que torna o Core inútil para os mantenedores do compilador como eu.

Isso foi corrigido? Ficaria muito feliz em saber que tem ...

@gulbanna

Também acho difícil levar a sério a ideia de que eles estão evitando atualizar o CLR

O que eu disse é que eles estão evitando atualizar radicalmente o CLR da mesma forma que a atualização 2.0 (genéricos).

Especificamente, eles parecem estar evitando ativamente quaisquer mudanças que adicionariam novos tipos fundamentais de tipos ao sistema de tipos (formas, metaclasses, DUs, etc.) ou novas instruções IL ao conjunto de instruções.

@masonwheeler

É certo que já se passaram alguns meses desde que verifiquei, então isso pode ter mudado recentemente, mas pelo que eu sei, é possível criar uma nova montagem na memória, mas não salvá-la em disco

Olhando para https://github.com/dotnet/corefx/issues/4491 (onde você comentou no passado), acho que a situação ainda é a mesma. Embora eu ache que perder um recurso específico (mesmo que seja importante) é bem diferente de "ainda não temos um Reflection.Emit ".

o que torna o Core inútil para os mantenedores do compilador como eu

Como Reflection.Emit é útil para um escritor de compilador? Achei que estava limitado à produção de assemblies para a estrutura atual, então não poderia ser usado para criar, por exemplo, assemblies .Net Standard, o que eu acho que seria uma limitação significativa para qualquer compilador.

O que eu disse é que eles estão evitando atualizar radicalmente o CLR da mesma forma que a atualização 2.0 (genéricos).

Acho que houve alguma inércia para não mudar o CLR, embora também haja algumas boas razões para isso, especialmente se você considerar que tais mudanças são mais úteis e menos dolorosas quando uma plataforma é jovem.

Acho que DIM é um sinal de que isso pode estar mudando, mas ainda não esperaria novas instruções IL, quando os intrínsecos JIT podem funcionar tão bem, ou novos tipos de tipos quando podem ser razoavelmente codificados no sistema de tipos existente.

@svick

Embora eu ache que perder um recurso específico (mesmo que seja importante) é bem diferente de "ainda não temos um Reflection.Emit funcionando".

Se você tivesse um editor de texto que permitisse digitar arquivos de texto, mas não os salvasse, não diria que não funciona?

Como Reflection.Emit é útil para um escritor de compilador?

Funcionou muito bem até agora. E, pelo que estou ciente, é o único back-end de compilador disponível que permite gerar novos assemblies e salvá-los ou gerar novos assemblies na memória e executá-los.

ainda não esperaria novas instruções IL, quando os intrínsecos JIT podem funcionar tão bem

Claro, mas e os casos em que não o farão?

ou novos tipos de tipos quando eles podem ser razoavelmente codificados no sistema de tipos existente.

Você viu a proposta para implementar Shapes dentro do sistema de tipos existente? Não há nada de razoável nisso; é uma confusão grande e feia do começo ao fim. (Nada contra as pessoas que criaram isso; meio que tem que ser, dadas as limitações com as quais está trabalhando.) E boa sorte na implementação de metaclasses sem suporte de nível CLR!

Precisamos de um CLR atualizado para desenvolver recursos de nível superior de qualquer maneira eficiente, e ninguém está realmente trabalhando para fazer isso no Core.

Alguém da equipe .net pode esclarecer quais são suas recomendações para implantações no local? É apenas "usar asp.net regular"? Estou falando especificamente dos comentários de @ Edward84

Isso afeta as bibliotecas de suporte Microsoft.Extensions.* ? Especificamente Microsoft.Extensions.Logging e Microsoft.Extensions.Configuration .

Temos uma grande base de código que compartilha uma API central comum. Alguns são WinForms, alguns são ASP.NET clássicos, alguns WCF etc. E os aplicativos mais novos são .NET Core (não atualmente, mas eventualmente quando portamos nossas bibliotecas principais para o padrão .NET)

Optamos por basear nosso registro principal e API de configuração nas abstrações das bibliotecas mencionadas acima.

Portanto, estou me perguntando se eles são seguros para uso em uma API .NET Standard referenciada por .NET Core e .NET Framework (4.7.2+) ou se eles também podem começar a usar somente recursos do .NET Core?

@mvestergaard Conforme mencionado no próprio anúncio :

Os pacotes

E no comentário de @benaadams neste tópico :

Nem todas as bibliotecas estão mudando apenas para .NET Core (por exemplo, Microsoft.Extensions.* permanecem como .NET Standard)

@mvestergaard como já mencionado, estamos analisando nossa política de LTS para determinar se coisas como suporte estendido, períodos mais longos, um período de "modo de manutenção", etc. são úteis e como seriam. Também estamos trabalhando para ver se podemos tornar o tempo de novos trens LTS mais previsível (um modelo que vemos e realmente admiramos de outras pilhas que têm um modelo LTS).

O maior problema que tenho com isso é não poder usar os pacotes maduros que só podem ser usados ​​ao direcionar o .NET Framework ou aqueles que simplesmente não estavam disponíveis fora do .NET Framework, como aqueles que precisavam do System.Drawing e GDI +.

Parece que o último cenário terá suporte no .NET Core 3.0, no entanto, AFAICT, ainda perderemos o uso das bibliotecas estáveis ​​e maduras que só podem ser usadas no .NET Framework.

Um exemplo disso é o Entity Framework . Teremos que mudar para o imaturo EF Core, que parece estar muito longe de lidar com todos os cenários complexos que o EF completo poderia e que recorre à avaliação do cliente na memória pelas costas para esconder o problema que causa desempenho problemas .

Um exemplo disso é o Entity Framework. Teremos que mudar para o EF Core imaturo, que parece estar muito longe de lidar com todos os cenários complexos que o EF completo poderia ...

EF6 terá suporte no .NET Core 3.0 conforme explicado por @DamianEdwards nesta semana ASP.NET Community Standup - 6 de novembro de 2018 - Recursos do ASP.NET Core 3.0 em 19:06

@benaadams, isso é uma ótima notícia! muito obscuro para um negócio tão grande! :) bom trabalho em encontrar isso. Encontrei outra menção disso aqui .

@SaebAmini : Você pode usar o System. Baseando-se no .NET Core. Consulte System.Drawing.Common e Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

E antes que o CoreCompat.System.Drawing existisse, como uma porta do System.Drawing do Mono.

Existe algum recurso que está faltando para o seu caso de uso ao executar no .NET Core?

@TsengSR meu cenário específico que nos fez almejar o .NET Framework foi:

  1. A necessidade de usar o pacote Microsoft Solver Foundation, disponível apenas no .NET Framework.
  2. Um pacote de geração de imagem de código de barras que usou System.Drawing.
  3. A necessidade de usar EF6.

Isso foi há cerca de um ano.

@SaebAmini : Como foi mencionado anteriormente, o suporte EF6 vem no .NET Core 3.0, System.Drawing já está lá (e antes disso o pacote CoreCompat existia e pode ter funcionado no seu caso) e para o Microsoft Solver Foundation Package, depois executando o Portability API Analyzer:

Veja como usar o Portability Analyzer

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (baixe e abra o HTML, não encontrei outro lugar para colocá-lo).

Ele mostra 97,93% de compatibilidade com .NET Core 2.0 + Platform Extensions (que foi lançado há cerca de um ano) e lista APIs incompatíveis, que estão principalmente relacionadas a System.Web que foi descontinuado e System.ServiceModel / System.Data.Linq .

Bem, eu não usei este pacote antes, e não tenho certeza por que um solucionador precisaria acessar System.Web e HttpContext ou System.ServiceModel , mas se você não não precisa de nenhuma dessas (e você sabe que seu caso de uso não está chamando isso de APIs), as chances são muito altas de que você possa usá-lo nas extensões de plataforma .NET Core 2.0 / 2.1 + ou no .NET Core 3.0, mesmo se não visar especificamente o moniker de destino netstandard ou netcoreapp20 .

Então, tecnicamente, as chances eram boas de que você pudesse ter migrado seu aplicativo para extensões de plataforma .NET Core 2.0 + há um ano, se o EF Core 2.0 pudesse cobrir as necessidades de seus aplicativos (é claro que isso requer algum trabalho de migração e atualizações para funcionar com EF Core 2.0).

Sim, é um pouco mais trabalhoso analisar as bibliotecas em questão ou o recurso para o framework de substituição (EF6 -> EF Core 2.0 / 2.1), mas está longe de ser impossível. Não acho que as pessoas possam ou devam esperar portar todo o seu código 1: 1 para o ASP.NET Core sem fazer nenhuma alteração (fora do próprio ASP.NET Core).

Só queria que fosse mais óbvio ter a compatibilidade da API exibida, como com um "emblema" (compatível com .NET Core 3.0) e / ou um relatório detalhado de compatibilidade da API em algum lugar na página do nuget para torná-lo mais óbvio do que ter que baixar o pacote e, em seguida, execute-o no analisador de pacotes.

Acho que este anúncio teria sido melhor recebido se enfatizasse o quanto o .NET Core se tornou mais compatível. Existem dois fatores que permitem mover o ASP.NET Core para fora do .NET Framework:
1) Reduzindo a necessidade do .NET Framework, disponibilizando dependências legadas e melhorando a interoperabilidade e assim por diante
2) Aumentando os benefícios, recursos e desempenho do .NET Core e redução da carga de manutenção

O Fator 2 surge na mente das pessoas que realmente precisam construir o ASP.NET! No entanto, há poucas vantagens do ponto de vista do usuário. As pessoas têm algo que funciona e sua maior prioridade é que continue funcionando. A boa notícia é que, na maioria dos casos, sim.

Eu concordo com @gulbanana. O .NET Core agora é muito mais compatível com o .NET Framework. Na verdade, consegui lançar aplicativos .NET Framework bem grandes simplesmente renomeando .exe para .dll e adicionando alguns .DLLs ausentes ao caminho de investigação.

O progresso nas ferramentas de linha de comando dotnet é impressionante. Especialmente a adição de ferramentas globais do .NET Core. Eles tornam o desenvolvimento uma brisa.

A compilação AOT com crossgen é ótima. Posso continuar por muito tempo.

tl / dr .NET Core é realmente impressionante hoje em dia.

O que está faltando:

  • A estratégia atual de comunicação com o cliente está faltando. Os clientes ficam muito desapontados quando ouvem que sua plataforma .NET favorita está sendo fragmentada pela Microsoft. Você deve ser mais claro aqui. Por exemplo, seria uma abordagem muito melhor anunciar diretamente para as pessoas a implementação única, altamente compatível, rápida e preparada para o futuro. Como o .NET Core, o futuro do .NET, que vai resolver a maioria dos seus problemas, produtividade, criatividade, novos nichos de mercado abertos etc.
  • Ainda mais estratégias de compatibilidade fora da caixa
  • Interface gráfica do usuário. Quero dizer, as ferramentas de linha de comando dotnet são ótimas, mas atualmente temos que usar editores de texto e console adicionais para trabalhar em quase todos os projetos no formato .NET SDK. A interface do usuário do Visual Studio é insuficiente nesse sentido. Isso coloca grandes barreiras para muitas pessoas que têm o hábito de apenas apontar e clicar. Isso também deve ser melhorado
  • Suporte LTS

@TsengSR Obrigado por sua resposta detalhada, grande informação! na época, usar o pacote de código de barras não funcionava, pois o projeto simplesmente não compilava reclamando de alvos diferentes. Talvez eu devesse tentar outra vez. (a menos que você queira recompilar nós mesmos e meio que herdá-lo)

Não estou preocupado com o esforço, se isso for razoável. Minha principal preocupação era ser deixado de lado, sem nenhuma opção com EF sendo o principal bloqueador e isso aparentemente não vai acontecer. É ótimo ver que foi bem pensado. Embora eu concorde com @gulbanana que estes podem ser melhor divulgados.

Existem muitas questões confundidas aqui. Meus 2 centavos pessoais são que deixar o .NET Framework para trás não é grande coisa. O que é preocupante, entretanto, é a total falta de qualquer suporte aparente para esforços de padronização (.NET Standard). Claro, você provavelmente não deseja executar o ASP.NET Core, digamos Unity hoje, mas não é sobre hoje. É cerca de um ou dois anos depois, quando outro runtime .NET poderia surgir, eu gostaria de poder dizer "Sim, assim que o SuperNetRuntime suportar .NET Standard 2.2, poderemos executar ASP.NET Core 3 nele" ...

Há alguma chance de pelo menos "reunir" todas as alterações necessárias no .NET Core 3 para ASP.NET Core 3 e encaminhá-las ao grupo de trabalho do .NET Standard como sugestões?

Olá, os pacotes publicados para .NetStandard 2.0 ou .NetCore 2.0 continuarão a funcionar com .NetCore 3.0. Por exemplo: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Se houver compatibilidade com versões anteriores, então mudar para .NetCore 3.0 é adequado, mas se não houver suporte para versões mais antigas, então é realmente inútil, a menos que todo o jogo seja atualizado.

.NetFramework tem um histórico de compatibilidade, mesmo que você possa usar .NetFramework 2.0 nas versões mais recentes, então algo precisa ser mantido para .NetCore também pelo menos 2.0 a 3.0 etc.

obrigado

Olá, os pacotes publicados para .NetStandard 2.0 ou .NetCore 2.0 continuarão a funcionar com .NetCore 3.0. Por exemplo: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Sim, o .NET Core 3.0 mantém compatibilidade com versões anteriores, portanto, pode usar as bibliotecas .NetStandard 1.0 -> .NetStandard 2.1 e .NetCore 1.0 -> .NetCore 2.2

@benaadams então isso é bom. Além disso, .net framework dll funcionará se eles não usarem nenhuma API ausente?

obrigado

Além disso, .net framework dll funcionará se eles não usarem nenhuma API ausente?

Sim, embora seja mais seguro usar uma biblioteca .NET Standard, pois você sabe que funcionará no .NET Core (e no Mono, Xamarin, Unity, UWP)

Além disso, o uso do Pacote de Compatibilidade do

Oi pessoal,
Para dar aos clientes uma etapa razoável em seu caminho para a migração de aplicativos para ASP.NET Core no .NET Core, vamos estender o suporte e a manutenção do ASP.NET Core 2.1.x no .NET Framework para corresponder ao suporte atual política para outras estruturas ASP.NET baseadas em pacote , por exemplo, MVC 5.x, Web API 2.x, SignalR 2.x. Isso significa que os pacotes relacionados ao ASP.NET Core 2.1.x (lista detalhada final a ser definida) terão suporte indefinidamente, além do período LTS de 3 anos para o treinamento do .NET Core 2.1 em geral.

Ótima notícia. Obrigado por ouvir seus clientes.

Vai levar muito tempo para transportar nosso antigo aplicativo MVC, já que estamos no MVC desde CTP3 e temos quase todos os pontos de extensão usados. Isso cobre nossas preocupações.

@DamianEdwards Essa é uma ótima notícia! Apenas me perguntando, isso foi corrigido para 2.1.x ou será atualizado para 2.2.x se isso acabar se tornando uma versão LTS? Houve muito esforço para chegar ao 2.2 e ele ainda nem foi lançado. E uma vez que continua com compatibilidade com o padrão da rede e funciona bem no framework completo, seria um desperdício ignorar isso completamente para o suporte estendido.

@poke, embora eu entenda sua preocupação, temos que traçar um

@DamianEdwards Sim, eu entendo, obrigado pela sua resposta. Eu estava perguntando porque o último comentário sobre isso foi que ainda não foi decidido , então eu só queria saber se esse suporte estendido seria levado adiante se o 2.2 se tornasse LTS.

E eu acho que é importante destacar isso para que as pessoas não atualizem seus aplicativos de framework para 2.2 se tiverem que contar com este suporte estendido. Caso contrário, eles terão que fazer o downgrade novamente.

Os novos recursos não vêm para o LTS, pois são sobre estabilidade.

Isso realmente não corresponde às decisões anteriores do LTS.

@cutucar

Isso realmente não corresponde às decisões anteriores do LTS.

Isso me confundiu. De que maneira? Você está se referindo ao fato de que 1.1 foi adicionado ao trem 1.x LTS? Nesse caso, foi uma anomalia do nosso primeiro trem de lançamento que não se repetirá. Seguindo em frente, nossa intenção é ficar mais consistente com quais versões se tornam LTS vs. Atual (ou seja, onde obtenho estabilidade vs. recursos).

@DamianEdwards Eu estava me referindo principalmente ao fato de que cada lançamento até agora foi um grande lançamento de recurso, e cada decisão LTS foi geralmente feita em retrospecto (pelo menos publicamente).

@poke OK. Bem, até agora tivemos 4 lançamentos (1.0, 1.1, 2.0, 2.1) com o quinto chegando em breve (2.2). Destes, apenas 1.0 e 2.0 foram inicialmente planejados para serem LTS, mas devido a uma série de fatores (principalmente relacionados a nós sermos realmente novos em fazer engenharia desta forma 😉) acabamos com 1.0, 1.1 e 2.1 sendo os trens LTS. 2.0 e 2.2 são (foram, serão) versões atuais. Nesse estágio, o 3.0 quase certamente também será o atual (fazendo com que o 2.2 entre no período de "carência" atual de 3 meses) antes que o 3.1 se torne o trem LTS 3.x. Nossa esperança é que, depois disso, o padrão e a cadência sejam mais consistentes (adoraríamos isso), mas até agora nossa bola de cristal falhou.

@DamianEdwards Obrigado pelos insights! 😄 (A propósito, eu não estava tentando discutir sobre isso, estava apenas curioso;))

Um problema maior para nós são as novas APIs REST hospedadas em processo por aplicativos legados que provavelmente não sairão do .NET Framework tão cedo. Pelo menos sabemos que não devemos progredir além do .NET Standard 2 com suporte a bibliotecas e ASP.NET Core 2.1 agora! É bom que o período LTS seja estendido

Olá a todos, uma pergunta rápida: e aqueles de nós que consomem pacotes nativos na forma de C ++ / CLI? Isso terá suporte no .Net Core em breve ou ficaremos órfãos, a menos que façamos um retrabalho massivo para usar P / Invoke?

@lokitoth - essa seria uma boa pergunta para o pessoal https://github.com/dotnet/core porque é mais geral do que apenas ASP.NET Core.

@lokitoth sim, isso terá suporte, consulte https://github.com/dotnet/coreclr/issues/18013

oO Como eu perdi isso?

Ok, então não tenho problemas com isso.

@ danroth27 Você poderia nos contar o impacto desse problema para o Client-Side-Blazor?

@Slkebe Não espero nenhum impacto. Os aplicativos Blazor do lado do cliente são independentes de qualquer tempo de execução ou plataforma que você decida executar no servidor.

@ danroth27 No meu entendimento, o Blazor do lado do cliente pode ser executado em mono porque os pacotes Microsoft.AspNetCore.* dependentes têm
Estou esquecendo de algo? Blazor precisa manter a meta de Microsoft.AspNetCore.* 2.1.X?

@Slkebe As bibliotecas Blazor do lado do cliente dependem apenas de componentes que continuarão a ter como alvo o .NET Standard (como Microsoft.Extensions. * E amigos). As partes do lado do servidor do Blazor que dependem do ASP.NET Core serão direcionadas ao .NET Core conforme descrito neste problema.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Qual é a decisão agora? Alvo no .net padrão 2.1?

@ John0King Não há uma nova decisão.

Isso são bananas! BANANAS

eu simpatizo com seu ponto de vista.

Peço desculpas se isso já foi mencionado, mas e os casos de uso em que desejo apenas usar Kestrel + algum middleware como parte de um aplicativo não ASP.NET? Terei que extrair toda a árvore 3.0 (o que não é ideal, pois meu caso de uso envolve a definição de um SDK customizado para consumidores) ou esse caso de uso não é compatível com o 3.x?

Atualmente estou desenvolvendo um aplicativo ASP.NET Core rodando no .NET Framework, por causa das bibliotecas incluídas. Estou usando o ASP.NET Core por causa de seus recursos de multi-autenticação. Estou me sentindo enganado e totalmente bloqueado.

Estou usando o ASP.NET Core por causa de seus recursos de multi-autenticação.

@FlorianGrimm O que especificamente? Microsoft.Owin forneceu funcionalidade de autenticação semelhante para ASP.NET 4.

É um aplicativo híbrido com um código-fonte (.exe) rodando no local e no azure, atualmente usando windows auth, aad, basic auth e anonymous.

@FlorianGrimm Quais dependências da biblioteca o impedem de usar o .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom e Microsoft.SharePointOnline.CSOM.

Espero que a equipe do SharePoint termine
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
e encontro outras opções além do ilspy.

De qualquer forma, eu gosto do ASP.NET Core e espero que os outros Microsoft Teams forneçam mais assemblies do .NET Core.

Nós fechamos periodicamente os problemas de 'discussão' que não foram atualizados por um longo período de tempo.

Pedimos desculpas se isso causar algum inconveniente. Pedimos que, se você ainda estiver encontrando um problema, registre um novo problema com informações atualizadas e nós investigaremos.

Esta página foi útil?
0 / 5 - 0 avaliações