Aspnetcore: Assemblies sendo removidos do Microsoft.AspNetCore.App 3.0

Acho que os pacotes MVC também devem se tornar pacotes NuGet adicionais. O MVC é ótimo, mas ao contrário do ASP.NET Core básico, ele é extremamente opinativo sobre como um aplicativo nós deve ser apresentado, o que realmente não agrada a todos, muito menos se encaixa no paradigma de todas as linguagens .NET. Eu realmente acredito que a estrutura compartilhada do ASP.NET Core merece ser MVC livre ou ter uma segunda versão gratuita MVC dela. O que você acha?

Qual seria o benefício? Como isso tornaria a vida das pessoas que criam aplicativos ASP.NET Core melhor?

Excelente! Eu só preciso do que preciso quando uso o núcleo do asp.net.

@davidfowl

Qual seria o benefício? Como isso tornaria a vida das pessoas que criam aplicativos ASP.NET Core melhor?

Pelas mesmas razões pelas quais você não inclui os pacotes listados no início desta edição. Só acho que é sempre mais fácil adicionar mais pacotes à estrutura que será fornecida com o .NET Core 3.0 do que remover pacotes posteriormente. Por que você não começa a adicionar o menor denominador comum para executar um aplicativo ASP.NET Core básico e, em seguida, oferece o restante como pacotes NuGet. Se isso for um problema para os desenvolvedores, você sempre poderá adicionar mais coisas mais tarde, mas não será mais capaz de remover coisas mais tarde com tanta facilidade.

Porque temos que encontrar um equilíbrio entre ser útil por padrão também.

Ok, bem, acho que o ASP.NET Core vanilla já é útil (e pensei que você também achava, caso contrário, por que você não o tornou útil?), Mas se você já definiu o que deve estar na estrutura e o que não esquece;)

Se você fosse um purista, não teria a maior parte do middleware ou MVC ou SignalR na caixa porque eles não são estritamente necessários. Traçar esta linha entre o que o conjunto padrão de coisas deve ser e não é muito mais um pressentimento e algo confuso (com base na experiência, olhando para outras plataformas do passado e do presente e fazendo uma chamada). A partir do ASP.NET Core 3.0, não temos planos de retirá-los (pelo menos agora).

Sim, eu sei que essa é sempre uma decisão difícil de fazer, mas às vezes não tenho certeza de qual é a justificativa para a tendência (da Microsoft) de inchar as coisas mais do que o necessário. A maneira como você posiciona seus próprios produtos no mercado é como isso será visto. Supõe-se que o ASP.NET Core seja o novo framework web moderno e flexível, mas a maneira como você posiciona tudo é que o ASP.NET Core é inútil, a menos que você force MVC + SignalR + Identity + EF para baixo em todos. Na minha opinião, você já fez a chamada de onde as linhas devem ser desenhadas, é por isso que MVC e SignalR não estão embutidos no ASP.NET Core, mas uma estrutura separada que pode ser adicionada quando desejado, então por que você está borrando essas linhas agora? Parece inconsistente e não consigo pensar em nenhum valor que você obtenha com isso. Em vez de apenas promover o ASP.NET Core + um próspero ecossistema de código aberto, você está promovendo uma experiência web muito restrita. Tudo o que faz é criar frustração com aqueles que querem ser um pouco diferentes e trabalhar mais para você, já que você acaba empurrando para as pessoas coisas que eles podem não querer.

Não é como se as pessoas não usassem MVC se você não o colocasse no framework padrão. Transforme-o em um único pacote NuGet e ninguém reclamará de ter que obter MVC do NuGet. É mais provável que mais pessoas venham perguntar por que você inflou a estrutura padrão com coisas que elas não querem como eu.

Suponho que esta seja uma discussão e ainda algo que vocês devem considerar, então se há uma coisa que eu gostaria que vocês perguntassem é trazer essa questão à sua equipe novamente e ver se vocês estão realmente decididos sobre isso ou se você pode suavizar a minha ideia :)

PS: Não tenho certeza se esse é o caso, mas espero que SignalR seja um pacote NuGet separado também. É como se você incluísse Bootstrap e Angular2 em sua estrutura padrão. Se esses dois produtos fossem desenvolvidos pela Microsoft, você provavelmente o faria, mas não faria sentido e acho que só porque eles são feitos por terceiros, você vê como não faz sentido.

TBH Adoraria ver mais coisas removidas da instalação padrão. Especialmente MVC. Isso é o que torna os Frameworks alternativos no ASP.NET Core ainda mais atraentes. Também me pergunto por que coisas como ContentResult vivem em MVC e não no núcleo. É muito usado em funções do azure e agora sempre tenho que fazer referência às coisas MVC - apenas para ContentResult.

Acho que o ponto é mais que não deveria impactar negativamente você ter o material MVC no SDK ASPNET. A maioria dos desenvolvedores irá usá-lo, portanto, enviá-lo dessa forma é preferível em vez de sobrecarregar a carga de restauração. Se você não quiser, simplesmente não pode usar. A maioria dos pacotes listados acima trazem dependências de terceiros (json), têm algum aspecto pesado (razor) ou são conceitualmente separados do ASPNET e frequentemente referenciados fora do SDK (EFCore).

Por mais que eu concorde com o padrão de mínimos para promover um campo de jogo igual para estruturas OSS, isso tem que ser equilibrado. Nos primeiros dias do core (beta e até 1.0), as coisas eram pacotes em todos os lugares e isso era MUITO mais confuso e a restauração demorava uma eternidade.

@psibernetic mesmo se o material estiver em pacotes separados, o instalador do núcleo .net pode colocar esses pacotes já em caches locais.

@psibernetic Você é a segunda pessoa mencionando que é importante equilibrar, mas o que isso significa? O equilíbrio entre o quê? Não vamos falar de extremos, porque isso obviamente não é bom, vamos falar de propostas realistas aqui. Se MVC for um único pacote NuGet, de que forma isso afeta a usabilidade? Realmente não importa e esse é o meu ponto. Pensar que você vai resolver um extremo implementando o extremo oposto é um pensamento estreito. Existem muitos intermediários. A estrutura não precisa ser inchada e MVC e SignalR também não precisam ser fragmentados em 100 pacotes. Ambos podem ser evitados ao mesmo tempo.

Dê-me um caso do mundo real em que ter MVC como um único pacote NuGet seria confuso, a restauração demoraria uma eternidade ou qualquer um dos outros pontos negativos que você mencionou?

E por falar em tempo de restauração ...

IMHO é mais importante ter contêineres de início rápido ou arquitetura sem servidor (já que é isso que tem um impacto no mundo real nos negócios) do que ter uma construção um pouco mais rápida em uma máquina de desenvolvedor. Sim, o último também é extremamente importante e eu quero que seja extremamente rápido, mas se eu tivesse que classificar a importância, prefiro dar um pequeno golpe na minha máquina de desenvolvimento do que na minha infraestrutura de produção na nuvem. Portanto, manter a área ocupada o menor possível é apenas (se não mais) importante do que reduzir o tempo de restauração.

Qual seria o benefício? Como isso tornaria a vida das pessoas que criam aplicativos ASP.NET Core melhor?

Acho que é um bloatware indesejado para todos os outros usuários que não usam MVC, como o CandyCrush pré-instalado no meu PC com Windows 10. O núcleo Asp.net pregou que estava se tornando menos opinativo com middleware totalmente configurável, conforme necessário, etc. Os modelos dotnet permitem que o MVC seja um pacote incluso padrão sem a necessidade de ser embutido no núcleo?

Existem muitos outros frameworks lá fora, como Nancy, ServiceStack e Giraffe, todos têm seus méritos e não devem ter o inchaço / conflitos com uma instalação forçada de MVC indesejada / desnecessária. Parece inconsistente, dado que autenticação, navalha, EF etc estão todos empacotados, mas MVC, a criança dourada consegue fazer parte do framework principal quando não é o principal?

Se for devido ao MVC ser tão fortemente acoplado ao núcleo que o desacoplamento daria muito trabalho, eu posso conseguir isso, mas com base nisso, geralmente torna a vida de alguns desenvolvedores mais fácil, parece preguiçoso e muito parecido com o antigo asp.net Mentalidade MVC da qual eu esperava que estivéssemos nos afastando.

O .NET Core deveria ser o clone modular enxuto de node.js para .NET, mas não parece que tenha qualquer intenção de replicar as características que fomentam seu ecossistema vibrante e próspero - um núcleo pequeno, flexível e sem opinião com recursos incluídos no núcleo, beneficiando tudo isso, graças a não ser empacotado com nenhum framework web opinativo, está maduro com a experimentação desfrutando de um número saudável de frameworks populares com suas próprias comunidades independentes.

Quer dizer, eu faço a equipe ASP.NET acreditar que está construindo a melhor estrutura possível, mas nem todos concordam com todas as opiniões que estão sendo escolhidas ou com o nível de complexidade necessário para fazer algo. Tudo no .NET Core foi desenvolvido com o benefício de uma visão retrospectiva, sendo muito inspirado por quais abordagens foram vistas se tornarem bem-sucedidas em outras plataformas, ao cozinhar em opiniões sobre quais tecnologias usar, você está matando a próxima inovação vinda de .NET e até quando a próxima coisa ganhar força em outras plataformas, o ASP.NET Core estará em desvantagem para replicar seu sucesso, já que estaremos sempre pagando o "imposto MVC" padrão daqui para frente, onde todos devem usar seu modelo de desenvolvimento para toda a Web Aplicativos ad infinitum.

A leveza do Node também o torna adequado para o desenvolvimento de uma série de outros casos de uso, como Electron, Native Mobile Apps, IOT, scripts de shell, etc., ou seja, nenhum dos quais se beneficia de ter uma estrutura da web agrupada na instalação padrão. Quanto mais inchada a instalação padrão se torna, menos útil ela se torna para uso em outros cenários.

IMO, o padrão deve estar de volta à visão original do .NET Core de ter um núcleo enxuto e modular com o foco em tornar mais fácil adicionar recursos (que todos possam tirar proveito), ou seja, não agrupá-lo por padrão e inchar o padrão instalar.

Obrigado pelo feedback. Deixe-me compartilhar alguns pensamentos.

1. Não estamos aparando montagens porque apenas temos vontade. Cada montagem que removemos é uma alteração significativa e aumenta o custo de atualização de 2.x para 3.0. Estes são os princípios orientadores que usamos para decidir o que entra em Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. As assembleias que estamos propondo remover estão faltando alguns dos critérios para inclusão na estrutura compartilhada. Notavelmente, esses assemblies: (1) têm dependências no código de terceiros que não temos capacidade de serviço (2) os próprios assemblies estão sendo preteridos no 3.0 ou (3) eles implementam protocolos ou mecanismo de autenticação que estão altamente sujeitos a alterações ( por exemplo, o Facebook / Google / Twitter pode decidir amanhã mudar a forma como o auth funciona)

2. Remover MVC de Microsoft.AspNetCore.App não é algo que consideraríamos. Embora reconheçamos que nem todos os usuários fazem referência ao MVC em seus aplicativos, acreditamos que essa seja uma peça central da oferta do ASP.NET Core. Planejamos manter isso em Microsoft.AspNetCore.App.

3. O MVC faz parte do Microsoft.AspNetCore.App desde o 2.1, mas como você verá nos modelos 2.1 "Web vazia" , você não precisa usar o MVC. Sua presença na estrutura compartilhada não o força a usá-lo em seu aplicativo. Você ainda é bem-vindo para usar alternativas, escrever sua própria estrutura de visualização ou usar as APIs aspnetcore mais "brutas" para ler e escrever diretamente solicitações e respostas HTTP.

4. @dustinmoris : Só acho que é sempre mais fácil adicionar mais pacotes à estrutura que será enviada com o .NET Core 3.0 do que remover pacotes posteriormente. Por que você não começa a adicionar o menor denominador comum para executar um aplicativo ASP.NET Core básico e, em seguida, oferece o restante como pacotes NuGet. Se isso for um problema para os desenvolvedores, você sempre poderá adicionar mais coisas mais tarde, mas não será mais capaz de remover coisas mais tarde com tanta facilidade.

   Isso é exatamente o que estamos tentando fazer. É mais fácil adicionar do que remover. Adicionamos muitas coisas no 2.0 e estamos reajustando de volta ao que acreditamos ser um conjunto sustentável de coisas para o caminho previsível à frente. A maioria dos assemblies removidos de Microsoft.AspNetCore.App ainda serão oferecidos como pacotes NuGet. Se descobrirmos posteriormente que 90% de todos os clientes fazem referência ao mesmo pacote, esse é um bom candidato para a estrutura compartilhada. Conforme mencionado no documento de orientação , no entanto, o quanto uma API é usada é uma métrica importante, mas não o único fator que consideramos.

5. "Vanilla" é subjetivo. Para muitos de nossos usuários, MVC e SignalR são "baunilha".

6. Algumas pessoas disseram que o .NET Core deveria ser isso ou aquilo ou alguma outra coisa. As coisas mudam, coletamos feedback do usuário, observamos como o produto é usado e tentamos ajustar os padrões para corresponder ao que achamos que beneficiará o maior número de clientes. Os ajustes propostos nesta edição são um reflexo dos comentários que recebemos sobre o .NET Core 2.x.

Consideração final: esse problema não vai deixar ninguém feliz. Se parece que estamos ignorando seu feedback, peço desculpas. Por favor, reconheça que temos centenas de milhares de clientes, e apenas um pequeno número deles vem ao GitHub para compartilhar feedback. Também coletamos informações de visitas pessoais, ligações, emails, mídia social, solicitações de suporte ao cliente, blogs, telemetria do Visual Studio e muito mais. Tudo isso é parte do que consideramos quando tomamos decisões e o que faz parte da experiência padrão e o que não é.

Se algo não estiver claro sobre nossas motivações ou motivos, por favor me avise e tentarei esclarecer.

Se você tem tanto contato direto com o cliente, quando foi a última vez que perguntou quantos deles estão usando MVC e SignalR? Há métricas reais de uso por trás dessa postura de mantê-los definitivamente em vez de ter cada um em um único pacote NuGet que pode ser facilmente instalado quando necessário?

@dustinmoris incluindo MVC no tempo de execução compartilhado significa que é enviado pré-compilado, este é um benefício que seria perdido, o que aumentaria os tempos de inicialização no mínimo, tornando-o, IMO, uma escolha ruim em seu exemplo de inicialização rápida contêineres docker. Além disso, cada implantação agora precisaria enviar os pacotes junto com o aplicativo, uma vez que não está no tempo de execução, isso aumenta o tamanho do pacote de implantação de cada aplicativo MVC. Finalmente, qualquer pacote dependente de MVC no tempo de execução também deve se tornar um implantável separado, não tenho certeza de quantos, se houver, já que não consigo encontrar a lista completa.

Tudo isso dito, e lembre-se de que eu tenho 0 afiliação com a Microsoft ou equipe aspnet, PODERIA ver um runtime separado enviado que fosse um aspnetcore básico SE a comunidade realmente vocalizasse e provasse que era um desejo importante. A missão é fornecer uma ótima experiência para o maior número possível de aplicativos e desenvolvedores, e o fato, no momento, é uma porcentagem incrivelmente alta daqueles que se beneficiam do MVC no tempo de execução compartilhado. @natemcmaster existe uma maneira preferencial de os indivíduos interessados ​​votarem nisso para o futuro, talvez seja uma questão de GitHub, e essa é uma solução razoável?

@psibernetic, você é bem-vindo para iniciar um novo problema do GitHub para remover MVC da estrutura compartilhada, mas como afirmei acima, remover MVC de Microsoft.AspNetCore.App não é algo que consideraríamos, portanto, é improvável que esse problema ganhe força dentro nosso time.

@Bomret Quase todos os aplicativos de clientes do mundo real que inspecionamos usam MVC de alguma forma. Há muitos benefícios em mantê-lo na estrutura compartilhada, e não vejo motivos claros para removê-lo.

@Natemcmaster : Estou no meu telefone agora, mas obrigado pela explicação e eu só
percebi que se trata do metapacote enquanto eu falava sobre o
estrutura compartilhada.

@natemcmaster Acho que @forki , @dustinmorris , @gerardtoconnor e @mythz declararam motivos muito sólidos pelos quais ainda não ouvi contra-argumentos. Teria sido muito bom ter uma base de tempo de execução / lib da web que os autores do framework pudessem construir em cima, como o nodejs, em vez de empacotar coisas opinativas com ele. Como foi mencionado antes, o node é muito bem-sucedido porque não exige muito, mas fornece boas abstrações sobre as quais você pode construir. O MVC não teria desaparecido, apenas deixaria de funcionar e se tornaria uma escolha a ser feita entre uma variedade de outras bibliotecas e estruturas da web. Ao incluí-lo, você toma uma posição em favor dele. É claro que a maioria dos desenvolvedores apenas o aceita como é enviado com o tempo de execução, em vez de olhar mais além. Na minha opinião honesta, isso soa como política e marketing - sem ofensa.

Chama-se "Microsoft.AspNetCore.App", porque não criar um segundo "Microsoft.AspNetCoreMVC.App"?

De qualquer forma, eu entendo que é muito difícil estabelecer limites, mas acho que o feedback geral aqui é que vocês têm um número crescente de pessoas que gostam do que vocês fizeram com aspnet core, mas que realmente não gostam de coisas como MVC, razor , EF ou signalR.

De fato. Você pode contar com a comunidade vibrante o suficiente para vir com muitas ideias de bibliotecas e frameworks para lidar com api, web, websockets, modelos, acesso a banco de dados e assim por diante. Vocês estariam fornecendo uma opção para aqueles com MVC, Razor, EF etc., mas não apenas a única nem padrão.

@natemcmaster Meu erro, na verdade eu estava falando sobre a estrutura compartilhada nesta edição. Acho que as mesmas razões também se aplicam ao meta pacote, mas para ser honesto, estou menos incomodado com isso, porque já posso fazer referência a pacotes individuais em vez do meta pacote, mas não posso cortar facilmente uma estrutura compartilhada se quiser manter um contêiner o menor possível, então sua sugestão de abrir um novo problema para a estrutura compartilhada faz sentido 👍

@natemcmaster Você poderia confirmar rapidamente se eu entendi as coisas corretamente:

• Haverá uma estrutura ASP.NET Core compartilhada incorporada ao próximo tempo de execução do .NET Core (3.0), o que significa que o ASP.NET Core é enviado como parte da instalação do .NET Core em um ambiente.

• Além disso, há um meta pacote chamado Microsoft.AspNetCore.App e Microsoft.AspNetCore.All que são uma coleção de pacotes NuGet para aplicativos ASP.NET Core

• A estrutura compartilhada do ASP.NET Core <o pacote Microsoft.AspNetCore.App meta que inclui coisas como EF Core?

• Posso construir um aplicativo da web ASP.NET Core sem ter que incluir o pacote Microsoft.AspNetCore.App meta que contém EF Core, SignalR, MVC, etc. se eu só quiser criar uma API extremamente pequena?

• O que quer que vocês estejam fazendo, será possível criar um contêiner Docker com apenas as dependências mínimas para ASP.NET Core para executar uma API minúscula?

Haverá uma estrutura ASP.NET Core compartilhada incorporada ao próximo tempo de execução do .NET Core (3.0), o que significa que o ASP.NET Core é enviado como parte da instalação do .NET Core em um ambiente.

sim

Além disso, há um meta pacote chamado Microsoft.AspNetCore.App e Microsoft.AspNetCore.All, que são uma coleção de pacotes NuGet para aplicativos ASP.NET Core

Não. Há um novo conceito chamado FrameworkReference e Microsoft.AspNetCore.App será um deles. Microsoft.AspNetCore.All não existirá no 3.0.

A estrutura compartilhada do ASP.NET Core <o meta pacote Microsoft.AspNetCore.App que inclui coisas como EF Core?

Não, não inclui EF.

O que quer que vocês estejam fazendo, será possível criar um contêiner Docker com apenas as dependências mínimas para ASP.NET Core para executar uma API minúscula?

Com o corte de montagem e o vinculador, sim, não removendo pacotes porque não haverá nenhum para o ASP.NET Core.

@natemcmaster

Não estamos aparando montagens porque apenas temos vontade. Cada montagem que removemos é uma alteração significativa e aumenta o custo de atualização de 2.x para 3.0.

O lugar certo para fazer qualquer correção seria na janela da versão principal v3, que é efetivamente o único momento em que mudanças como essa podem ocorrer, ou seja, ao mesmo tempo em que outros pacotes são removidos.

Remover MVC de Microsoft.AspNetCore.App não é algo que consideraríamos. Embora reconheçamos, nem todo usuário faz referência a MVC em seu aplicativo.

É chamado de "Microsoft.AspNetCore.App", que logicamente é lido como "referência a este pacote" se você estiver criando um "aplicativo ASP.NET Core".

acreditamos que esta é uma peça central da oferta do ASP.NET Core. Planejamos manter isso em Microsoft.AspNetCore.App.

Isso está se aproximando do cerne da questão, onde parece que os objetivos do ASP.NET Core estão se afastando de promover um ecossistema de estilo node.js aberto e enxuto. É a intenção da equipe que todos confundam os ASP.NET Core Apps como sinônimos de MVC Apps? Alguns dos pontos de venda do ASP.NET Core eram "Pague para jogar" e "camadas" desacopladas, mas isso sugere que um "Aplicativo ASP.NET Core" foi para sempre destinado a = Aplicativo MVC.

Ficaria mais claro para todos os envolvidos se os pacotes fossem mais explícitos onde:

• Microsoft.AspNetCore.App => Base para todos os aplicativos ASP.NET Core
• Microsoft.AspNetCore.Mvc => ASP.NET Core MVC App

Mas se "Microsoft.AspNetCore.App" for intocável, poderíamos pelo menos ter um meta pacote oficial de "linha de base" (ou FrameworkReference) apenas com os recursos do servidor central (ou seja, sem quaisquer libs opinativas), alguma nomenclatura potencial:

• Microsoft.AspNetCore. [Base | Bare | Lite | Básico]

("Core" também seria apropriado, mas já existe um uso exagerado do termo).

Sem um meta pacote / nome oficial, ele não será tão acessível quanto o atualmente recomendado "Microsoft.AspNetCore.App", que é a base recomendada para todos os aplicativos ASP.NET Core.

Restrições geram inovação onde se MVC pudesse apenas rodar no mesmo campo de jogo que todos os outros, talvez todos pudéssemos ter acesso a um recurso que nos permite declarar fácil e explicitamente quais produtos (também conhecido como conjunto de pacotes) os aplicativos precisam, por exemplo, pode parecer algo gostar:

• Microsoft.AspNetCore.Mvc + SignalR + EF

Onde todos podem facilmente declarar e instalar apenas o que precisam e as ferramentas nos bastidores podem combinar os meta pacotes "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" e "Microsoft.AspNetCore.EF". (Ou uma solução superior para cumprir a intenção).

Sua presença na estrutura compartilhada não o força a usá-lo em seu aplicativo.

Parece a justificativa para cada monólito já criado. "Você não precisa usar tudo o que empacotamos, está lá apenas para sua conveniência".

Você ainda pode usar alternativas, escrever sua própria estrutura de visão,

Não é tão acolhedor quanto você pensa, por exemplo, enquanto estávamos desenvolvendo nossa própria alternativa de "estrutura de visualização" para MVC e Razor, encontramos um comportamento mágico no .NET Core em que a construção falhava ao executar o comando padrão para publicar um. Projeto NET Core, ou seja:

 dotnet publish -c Release

Que falharia com:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

Comportamento surpreendente dado que estávamos desenvolvendo uma alternativa ao MVC que explicitamente não fazia referência ao MVC, Razor ou incluía quaisquer páginas .cshtml já que seu objetivo era construir aplicativos sem usá-los.

Depois de vasculhar vários threads do GitHub tentando diferentes soluções alternativas, descobri que outras pessoas estavam tendo o mesmo problema em que a solução acabou optando por sair da compilação do MVC Razor quebrando compilações com:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

O que permitiu a publicação do projeto. Durante o tempo de teste de diferentes switches para consertar a compilação quebrada, também descobrimos que poderíamos reduzir nossa pegada publicada em 150 .dlls em /refs/*.dll desativando os metadados que estavam inchando desnecessariamente nosso aplicativo da Web .NET Core 2.0 ao optando por não receber metadados necessários ao Razor com:

<PreserveCompilationContext>false</PreserveCompilationContext>

Então, basicamente forçado a jogar whack-a-mole para descobrir quais interruptores precisamos para dizer às ferramentas que não estamos usando MVC para evitar que ele interrompa construções de projeto e produza metadados desnecessários que apenas os aplicativos MVC / Razor precisam. Teria sido muito mais preferível começar com um pacote de metadados "base" onde tais problemas não fossem possíveis, pois o conjunto de ferramentas não poderia assumir que todos os aplicativos estavam usando MVC porque os bits MVC não existiriam.

Embora seja fácil dizer que o ASP.NET Core ainda é uma plataforma acolhedora que incentiva a experimentação, a criação e o uso de "estruturas de visão" alternativas, agrupar Web Frameworks preconceituosos como MVC é a coisa mais hostil que poderia ser feita para desencorajar a criação e uso dessas alternativas. Dedicar um momento para dar uma olhada no número de alternativas populares emergentes é uma boa medida para ver o quão convidativa a plataforma é para eles.

Se a intenção é que cada aplicativo ASP.NET Core inclua MVC, então qualquer outra "estrutura de visão" alternativa (incluindo um único .cs arquivo drop-in de métodos ext) parecerá ser mais "pesado "e complicado do que usar o MVC integrado, uma vez que todos eles precisam ser integrados a ele + qualquer outra coisa que a estrutura de exibição precise.

Em resumo, seria preferível se "MVC" fosse opt-in e não incluído no pacote .App , mas se a decisão for irreversível, poderíamos pelo menos ter uma base de meta pacote oficial que não não inclui?

Por favor, reconheça que temos centenas de milhares de clientes, e apenas um pequeno número deles vem ao GitHub para compartilhar feedback.

IMO, a demanda por pacote inicial não inchado está sendo sub-representada, anedota: de todos os modelos de projeto C # /. NET que criamos para VS 2012, VS 2013, VS 2015, VS 2017 e .NET Core, consistentemente o modelo mais popular de longe sempre foi o modelo "Vazio", que também era uma crítica frequente ao ASP.NET clássico de que o modelo vazio padrão do VS.NET não era vazio o suficiente. Foi quando você pôde criar um ASP.NET .NET Framework clássico "vazio" sem MVC, mas agora no framework ASP.NET Core mais novo, mais leve e modular, o MVC vem dentro do pacote inicial mínimo recomendado.

Também coletamos informações de visitas pessoais, ligações, e-mails, mídias sociais, solicitações de suporte ao cliente, blogs

As pessoas não gostam de inchaço, que muitas vezes é equiparado a complexidade irremovível, o que provavelmente está sendo solicitado é tornar os projetos o mais simples possível, que é o que deve ser o foco e pode ser feito sem inchar os projetos padrão.

Na minha experiência, ser explícito é mais simples de raciocinar do que estruturas inchadas com comportamento mágico. Se for explícito, você pode interagir com ele, pesquisar, ler sobre ele, removê-lo, executar o teste sem usá-lo (para ver se é a causa dos problemas) e é visível ao comparar projetos de diferentes configurações. Mas com o comportamento mágico do MVC tooling quebrando builds do meu projeto mvc / razor-less acima, eu não tinha ideia de qual parte do meu projeto o estava acionando, por que está em execução, como desabilitá-lo ou como resolvê-lo. Ainda não tenho certeza de que meus projetos que não usam MVC não estão ficando lentos porque o MVC é empacotado ou que está gerando uma saída subótima porque precisa se acomodar para MVC ou Razor.

Telemetria do Visual Studio e muito mais.

Vai ser difícil comparar a telemetria da popularidade de um metapacote básico que não existe, se tivesse IMO teria popularidade mais do que suficiente para merecer sua inclusão. Anteriormente, "Microsoft.AspNetCore.All" visava a outra extremidade do espectro e incluía o universo, mas não o inverso mais útil de ter uma linha de base mínima útil.

É lógico que se você não está construindo um aplicativo MVC e a opção de escolher uma linha de base sem ele é tão acessível, por que você não escolheria em vez da opção inicial mais inchada contendo MVC?

@Bomret

Teria sido muito bom ter uma base de tempo de execução / lib da web que os autores do framework pudessem construir em cima, como o nodejs, em vez de empacotar coisas opinativas com ele.

Mas é exatamente assim que funciona. Você é livre para compor seu aplicativo da maneira que quiser. Se você não quiser usar MVC, apenas não adicione o middleware. Sim, os modelos são opionados, mas você pode alterar seu aplicativo para fazer o que quiser, usando o que quiser.

Acho que você está interpretando mal a estrutura compartilhada aqui. Você só precisa vê-lo como uma espécie de biblioteca padrão que acompanha o .NET Core. Para fazer uma referência ao Node: Imagine que a versão atual do Express foi empacotada com o Node. Você não _tem_ de usar, mas já está lá quando você quiser.

E quanto ao MVC, acredito que você não esteja exatamente ciente do que o MVC realmente inclui no ASP.NET Core. Se você não quiser usar controladores e visualizações do Razor, tudo bem, mas provavelmente ainda usará muitas funcionalidades MVC em seu aplicativo.

Se você não quiser usar controladores e visualizações do Razor, tudo bem, mas provavelmente ainda usará muitas funcionalidades MVC em seu aplicativo.

Como o quê?

Se você não quiser usar controladores e visualizações do Razor, tudo bem, mas provavelmente ainda usará muitas funcionalidades MVC em seu aplicativo.

Sim, por favor diga, parece um pouco paternalista, a maioria de nós está envolvida em estruturas alternativas construídas no middleware / kestrel central, então temos uma ideia decente do que estamos usando, controladores e visualizações do Razor são um pequeno subconjunto do MVC, nós sabe disso. Os frameworks F #, Giraffe / Saturn & Zebra, têm melhor desempenho do que MVC com melhor roteamento e modelo de processamento simplificado. Na renderização, Zebra x2 mais rápido do que MVC no TechEmpower, é por isso que preferimos mantê-lo fora por padrão. se assembly-trimming / linker é capaz de reduzir a pegada mais tarde, então isso é pelo menos alguma coisa, mas seria ideal se não fosse incluído por padrão para permitir um campo de jogo mais uniforme para outras estruturas, ganhe o máximo de atração para a plataforma principal do asp.net.

@mythz de uma perspectiva organizacional, você está certo, existem algumas divisões lógicas aqui. No entanto, qualquer subdivisão vem com complexidade significativamente adicionada e sobrecarga de engenharia que leva tempo longe de melhorar os recursos do produto. Quando esperamos que uma maioria significativa de clientes aproveite as vantagens dos componentes MVC, não vale a pena dividi-los. As desvantagens para os desenvolvedores que não os usam são insignificantes, alguns MB extras no diretório de instalação e nenhum impacto no tempo de execução, a menos que você os carregue.

Só posso apontar para @mythz para ilustrar o ponto. Quanto mais acopladas as coisas, mais elas se enredam. Quero dizer Wat !? MVC influencia a construção de um aplicativo Asp, mesmo que você não faça referência a ele em nenhum lugar ?!

@cutucar
Como os outros já escreveram: não é. É um pacote de coisas que não tem nada a ver com um tempo de execução básico. Imagine que a estrutura expressa teria sido agrupada com o nó por padrão, você acha que o ecossistema teria se tornado tão vibrante e diverso?

Eu também absolutamente não entendo como remover MVC, SingalR etc. da instalação básica e fornecê-los como um único pacote NuGet, cada um pode ser rotulado como "complexidade adicional". Os desenvolvedores instalam pacotes extras na maioria dos casos. E se fornecê-los como pacotes extras aumentaria o tempo de restauração “significativamente”, eles são muito gordos de qualquer maneira.

@Tratcher

No entanto, qualquer subdivisão

A subdivisão à qual isso se refere é a dissociação do MVC para que os ASP.NET Core Apps possam ter uma linha de base mínima útil sem nenhuma estrutura de desenvolvedor opinativa que prescreva o que eles devem usar para desenvolver ASP.NET Core Apps.

vem com complexidade significativamente adicionada e sobrecarga de engenharia que leva tempo longe de melhorar os recursos do produto.

Para esclarecer como isso se lê: requer muita sobrecarga de engenharia para remover sobrecarga desnecessária de cada aplicativo ASP.NET Core que não usa MVC, porque se MVC tivesse que funcionar como qualquer outra estrutura alternativa, isso aumentaria significativamente a complexidade "para MVC".

Se o MVC requer complexidade significativa para funcionar com as mesmas opções de extensibilidade em que todas as outras estruturas alternativas devem funcionar, isso é indicativo de um problema com o MVC e quaisquer recursos adicionados para fazê-lo funcionar de maneira mais perfeita podem ser adicionados para o benefício de todos. Assim como dissecar um monólito, a complexidade do conjunto de ferramentas e do tempo de execução seria mais enxuta e menos complexa com a complexidade adicionada movida para onde ela pertence no MVC e sua integração / conjunto de ferramentas.

Em vez disso, acabamos com a situação em que o MVC está entrincheirado nas ferramentas padrão, o que pode interromper os projetos de publicação e inchar os resultados dos projetos que não o utilizam. Uma vez que não funciona como todo o resto, não há como dizer que você está usando MVC ou qualquer forma de dizer que você não está usando MVC, sempre é assumido.

Quando esperamos que uma maioria significativa de clientes aproveite os componentes MVC

Bem, isso é esperado, em detrimento de todas as outras alternativas, é o framework prescrito empacotado na instalação mínima recomendada padrão, como a Apple dando a todos uma música do U2 de graça, gostem ou não.

As desvantagens para os desenvolvedores que não os usam são insignificantes

Os desenvolvedores se beneficiariam de um ecossistema mais saudável com mais variedade, opções e inovação?

Os desenvolvedores se beneficiam da confusão adicional e da definição indefinida do que é um "aplicativo ASP.NET Core"? "Costumava ser como node.js para .NET, mas agora é mais uma estrutura opinativa de um único fornecedor, onde essencialmente cada aplicativo começa com um monte de coisas opinativas que prescrevem como você deve construir aplicativos da Web, você pode pensar nisso como cada App sendo pré-instalado com express e suas dependências por padrão - você deve usá-lo "

Os desenvolvedores se beneficiam do invólucro especial do MVC? Ele não é instalado ou atualizado como qualquer outra coisa e depende de ferramentas ocultas e comportamento mágico que você precisa vasculhar para saber que existe e desabilitar. Casos especiais como esse são o que adiciona complexidade acidental, ao raciocinar sobre seu projeto, você deve manter um conjunto diferente de regras de como o MVC funciona versus como todo o resto funciona.

Se fosse explícito, melhoraria a legibilidade e você poderia dizer pela configuração do projeto que é um aplicativo MVC, por exemplo:

• Microsoft.AspNetCore.Mvc

O que sinaliza que é um aplicativo MVC e para instalar todas as dependências e configurar automaticamente todas as ferramentas personalizadas que o MVC precisa - de preferência usando o mesmo modelo extensível aberto ao qual todos os outros têm acesso.

Ao mantê-lo no projeto padrão "Microsoft.AspNetCore.App", você o vincula para sempre a todos os aplicativos ASP.NET Core, tornando-o desvantajoso para qualquer coisa melhor. ASP.NET Web Pages foi outra estrutura de visualização do Razor adicionada ao ASP.NET anos atrás que foi instalada e também teve seu comportamento mágico invasivo ativado por padrão. Ele veio com seu próprio Web Matrix IDE que não tem mais suporte ou está disponível para download, então o que resta é um caso em que a complexidade de uma tecnologia morta está para sempre incorporada no ASP.NET clássico e causa ativamente problemas para outros Web Frameworks ativos amarrando o uso de páginas Razor .cshtml que precisam para sempre carregar a bagagem abaixo para evitar explicitamente que as páginas da Web quebrem suas estruturas de visualização com:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

Para reiterar as solicitações de recursos em ordem de preferência:

1. Altere "Microsoft.AspNetCore.App" para ser a linha de base útil mínima para todos os aplicativos ASP.NET Core (ou seja, sem MVC).
2. Mantenha um meta pacote como "Microsoft.AspNetCore.Base" que todos que não usam MVC possam usar como base mínima útil.

Se nada disso for considerado, podemos pelo menos ter um sinalizador para todo o projeto, como mvc:enabled = false que todas as ferramentas MVC possam verificar para desabilitá-las e impedir sua execução?

@mythz, você está colocando palavras na minha boca. A complexidade adicional não é para MVC, é para construir infraestrutura, empacotamento, instaladores, etc. necessários para criar e enviar mais uma camada de componentes, independentemente do que essa camada consiste.

Se nenhum desses for considerado, podemos pelo menos ter um sinalizador para todo o projeto como mvc: enabled = false que todas as ferramentas MVC poderiam verificar para desabilitá-los e impedi-los de rodar?

Você pode ser mais específico sobre quais recursos de ferramentas gostaria de ver desativados? Isso pode valer a pena um problema separado.

@Tratcher

A complexidade adicional não é para MVC, é para construir infraestrutura, empacotamento, instaladores, etc. necessários para criar e enviar mais uma camada de componentes, independentemente do que essa camada consiste.

ou seja, a complexidade adicional do que seria necessário para fazer o MVC funcionar.

Você pode ser mais específico sobre quais recursos de ferramentas gostaria de ver desativados? Isso pode valer a pena um problema separado.

Os 2 problemas que encontrei foram a necessidade de configurar manualmente /p:MvcRazorCompileOnPublish=false que estava impedindo meu projeto (sem as páginas .cshtml) de publicar. A outra sinalização que deve ser desativada é:

<PreserveCompilationContext>false</PreserveCompilationContext>

Como acontece com a maioria dos comportamentos mágicos, estou assumindo que há mais, mas só descubro sobre eles quando os encontro.

Basicamente, um sinalizador para especificar que o MVC não é usado e para desativar todas as ferramentas ou concessões ativadas por padrão que foram adicionadas por causa do MVC.

@mythz, vá em frente e registre esse problema.

Na verdade, você pode fazer uma estrutura compartilhada semelhante para pilha de serviço se as dlls MVC e SignalR extras forem uma preocupação para seus usuários.

@davidfowl Isso realmente parece muito bom, eu pude ver alguns casos de uso diferentes para frameworks fornecidos pela comunidade. Existe alguma documentação sobre isso?

Como você pode imaginar, não é algo para o qual construiríamos um suporte de primeira classe, pois o número de pessoas que fazem isso é pequeno. Dito isso, você pode observar como construímos o nosso e imitamos esse comportamento.

@davidfowl O pacote básico mínimo seria útil para todos os aplicativos não MVC - por exemplo, muitos outros aplicativos leves e microsserviços vão querer ignorar todos os frameworks e escrever diretamente na própria resposta. IMO, esta opção deve estar disponível na caixa, preferimos não começar de uma base não oficial composta de versões de pacotes sobre as quais não temos controle. Idealmente, tudo seria aditivo do pacote básico, em vez de partir de uma tangente diferente mantida externamente. Mas talvez esta seja uma área onde a comunidade externa pode se reunir para manter um subconjunto "AspNetCore" de base útil para todos os aplicativos e frameworks não MVC.

Dito isso, onde devemos olhar para criar um Framework customizado? Talvez seja tão fácil quanto começar com uma cópia do que foi usado para criar "Microsoft.AspNetCore.App" e remover todas as bibliotecas não essenciais para recuperá-lo a um subconjunto mínimo útil.

@mythz por que você ainda precisa de um framework, você pode apenas usar o servidor Kestrel diretamente. Isso apenas para dizer que talvez a sua versão da luz não seja a ideia de luz ou núcleo de outra pessoa. Atualmente, temos uma opinião e seria incrível se a comunidade pudesse se apresentar aqui e fazer modelos e uma estrutura compartilhada alternativa que fosse suficientemente mínima. Somos OSS, tudo o que é necessário para fazer algo personalizado está lá e somos muito receptivos e teremos prazer em ajudar.

@natemcmaster pode ajudar com detalhes sobre como fazer uma estrutura compartilhada personalizada.

@davidfowl você sugeriu fazer um customizado, eu só estou depois de ser capaz de começar de uma base útil mínima, sem frameworks opinativos. Não queremos fazer referência a vários pacotes individualmente pelo mesmo motivo, a recomendação é que todos os ASP.NET Core Apps façam referência a "Microsoft.AspNetCore.App" - é mais acessível poder fazer referência a um único pacote.

Isso apenas para dizer que talvez a sua versão da luz não seja a ideia de luz ou núcleo de outra pessoa.

Todos parecem ser bastante unânimes aqui que MVC não pertence ao pacote básico. O único outro "produto" que parece estar incluído é o SignalR, que imagino que teria menos uso do que o MVC e menos razão para inclusão. Não estou intimamente familiarizado com o que há em cada pacote, mas todo o resto parece ser genericamente útil e uma parte propícia da "plataforma" ASP.NET Core.

OK, deixe-me lançar uma sugestão para tentar ser construtivo aqui. Não estamos mudando o Microsoft.AspNetCore.App, pensamos que é algo que a maioria dos usuários precisará e usará. Vamos apresentar outra camada que é essa estrutura compartilhada "central" (fizemos algo assim originalmente com https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). Essa é a estrutura compartilhada na qual você basearia essas outras estruturas (como Nancy e ServiceStack).

Ainda enviaremos nossos modelos padrão com Microsoft.AspNetCore.App como agora, mas autores de estruturas como você podem ter outros modelos que usam a estrutura compartilhada de base.

PS: Este tópico não começa remotamente e representa qualquer tipo de maioria de nossos clientes, então eu não tiraria conclusões apenas daqui. Recebemos feedback de muitos lugares e o github tem nossa orientação mais vocal e apaixonada.

Sim, acho que está mais perto de conter muitos dos fundamentos para configurar um aplicativo e colocá-lo em funcionamento. A partir dos dep em Microsoft.AspNetCore.App , também estamos usando:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Então, coisas como HTTP, hospedagem, log e abstrações de configuração (úteis para a maioria dos aplicativos HTTP) também seriam boas para serem incluídas e qualquer outra coisa que alguém considere apropriada. Minha única preferência é não ter MVC / SignalR incluído.

e agora fica interessante. como David já disse: as pessoas têm diferentes
ideias sobre o que significa "núcleo". Do meu ponto de vista, não acho que DependencyInjection
deve estar dentro. / encolher de ombros

Am Do., 8. Nov. 2018 às 08:30 Uhr schrieb Demis Bellot <
notificaçõ[email protected]>:

Sim, acho que está mais perto de conter o essencial para
configurar um aplicativo e colocá-lo em funcionamento. Dos departamentos em
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App também estamos
usando:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Portanto, coisas como abstrações de HTTP, hospedagem, registro e configuração
(útil para a maioria dos aplicativos HTTP) também seria bom ser incluído e qualquer coisa
mais alguém julgar apropriado. Minha única preferência é não ter
MVC / SignalR incluído.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz A maioria deles são incluídos transitivamente.

@forki 😆 Bem-vindo ao nosso mundo.

Não estamos mudando o Microsoft.AspNetCore.App, pensamos que é algo que a maioria dos usuários precisará e usará.

Últimas palavras famosas. Essa é a justificativa de toda decisão errada - "ACHAMOS QUE ELES precisam".

Você sabe oque eu penso? A Microsoft deve começar a tratar sua base de desenvolvedores como engenheiros inteligentes independentes e não como desenvolvedores de ovelhas, e sim, vocês têm muitos desenvolvedores de ovelhas, que irão seguir e usar o que quer que você jogue neles, mas são os outros desenvolvedores mais vocais que farão um vibrante comunidade e construir novas startups na pilha .NET.

Às vezes, é bom ouvir usuários avançados.

Independentemente disso, não vamos alterar o Microsoft.AspNetCore.App. Eu ofereci um compromisso que acho que satisfaz os requisitos aqui.

@forki se você estiver usando aspnet core, você será confrontado com DI de qualquer maneira, melhor fazê-lo incluir métodos de conveniência por padrão (Obter serviço, GetRequiredServicee os gostos estão nesse pacote). E ei, F # não pode nem mesmo criar aqueles por conta própria devido à falta de restrição T:> U https://github.com/fsharp/fslang-suggestions/issues/255 então ¯_ (ツ) _ / ¯

Eu gostaria de ter aquele framework base compartilhado @davidfowl mencionado ... Eu acho que @mythz e @dustinmorris estariam ambos ok com tal abordagem. Isso também é oportuno para Saturno @ Krzysztof-Cieslak

você é confrontado com DI de qualquer maneira

Eu sei e tivemos essa discussão várias vezes. É só que prefiro não
;-) Mas é o que é...

Am Fr., 9. Nov. 2018, 10:57 hat Nino Floris [email protected]
geschrieben:

@forki https://github.com/forki se você estiver usando aspnet core, você
confrontado com DI de qualquer maneira, é melhor fazê-lo incluir métodos de conveniência por
padrão (Get service, GetRequiredService e similares estão naquele
pacote). E ei, F # não pode nem mesmo criar aqueles por conta própria devido à falta
T:> restrição U fsharp / fslang-sugestões # 255
https://github.com/fsharp/fslang-suggestions/issues/255 então ¯_ (ツ) _ / ¯

Eu gostaria de ter esse framework básico compartilhado @davidfowl
https://github.com/davidfowl mencionado ... Eu acho que @mythz
https://github.com/mythz e @dustinmorris
https://github.com/dustinmorris aceitaria essa abordagem.
Isso também é oportuno para Saturno @ Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Atualizou a postagem original para incluir:

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

Eles estão sendo retirados da estrutura compartilhada e serão enviados como pacotes NuGet. Esses assemblies têm uma dependência das APIs IdentityModel que ainda não se enquadram nas diretrizes da estrutura compartilhada. Começamos a trabalhar com a equipe IdentityModel e consideramos colocá-los de volta na estrutura compartilhada no futuro. cref https://github.com/aspnet/AspNetCore/pull/6035

Atualize a postagem original para incluir Microsoft.AspNet.WebApi.Client. Consulte https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

Muitas vezes fico confuso o suficiente, pois é o que eu preciso incluir.

Falando em Visual Studio - Devo abrir o nó Microsoft.AspNetCore.App e fazer uma referência cruzada de tudo lá embaixo com o que posso ter instalado individualmente?

Estou fazendo uma faxina e vejo que tenho esses pacotes. Então, quais são redundantes?

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

Fiquei bastante surpreso ao ver que até as ferramentas SpaServices e EntityFramework estão incluídas atualmente (o que eu não tinha percebido antes - e é ótimo) - mas também tenho algumas referências antigas do 2.2.1 que não podem ajudar em nada.

A questão é - pode algum trabalho de coordenação melhor ser feito com a equipe do Visual Studio para garantir que o IDE seja um pouco mais inteligente para entender esses mega pacotes e me dizer que é seguro remover algo - e então na v3 me dizer que preciso adicioná-lo de volta ;-)

@simeyla obrigado pelo feedback. O que você está dizendo está relacionado ao assunto, mas não é exatamente sobre o que trata este tópico. Ferramentas para otimizar referências de pacote seria um novo recurso do Visual Studio. Esse recurso pode ser geralmente útil, não apenas para este cenário, então eu sugiro enviar este feedback diretamente para o Visual Studio. No VS, use "Ajuda> Enviar feedback ...". Se você compartilhar o link depois de criar a postagem, posso encaminhá-lo internamente para nossas equipes de colegas que trabalham no VS.

No 3.0, eliminaremos o metapacote Microsoft.AspNetCore.App por completo e faremos muitos ajustes nos pacotes que enviamos. Começamos a documentar como atualizar do 2.x para o 3.0 e continuaremos atualizando este documento conforme finalizamos a lista de assemblies enviados no 3.0.

Passando para o marco 'Discussões', porque este item não está rastreando nenhum trabalho, mas vamos atualizá-lo como detalhes da mudança de implementação.

Adicionado Microsoft.Extensions.DependencyModel à lista. Alterado como parte de https://github.com/aspnet/AspNetCore/pull/10271

Pergunta aqui @natemcmaster @DamianEdwards , há menção de que os modelos têm tudo o que é necessário para construir localmente. Com esse pensamento e a remoção das bibliotecas Auth, isso significa que nenhum modelo de autenticação será construído offline no 3.0? Eu entendo que nenhuma biblioteca de autenticação funcionará off-line, mas se eu não tiver um cache nuget, teoricamente poderia ocorrer uma falha de compilação após a atualização de um novo modelo de autenticação se estivesse off-line. Parece uma experiência ruim.

Sim, esse é um dos resultados dessa mudança. A partir da Visualização 6 (em breve), dotnet new mvc , dotnet new razor , dotnet new web e outros não têm nenhum PackageReferences, portanto, não devem ser afetados, mas especificando opções adicionais , como --auth individual pode resultar na presença de um PackageReference que requer o download do pacote.

Estamos fazendo uma troca intencional aqui. Embora os modelos com PackageReference não sejam restaurados offline em uma máquina limpa, também estamos evitando muitos dos problemas que surgem ao tentar fazer um cache NuGet offline pré-preenchido (para iniciantes, verifique https://github.com/dotnet/ dotnet-docker / issues / 237, https://github.com/NuGet/Home/issues/6309 e http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster entendo totalmente e entendi o raciocínio, só precisa ser bem documentado ou haverá uma tonelada de problemas abertos no lançamento 3.0 inicial, onde as pessoas dizem que dotnet new webapp --auth Individual não compila.

Alguém pode me ensinar por que Microsoft.AspNetCore.Authentication.JwtBearer é compilado com uma dependência de .netcoreapp3.0? Não pode estar em .netstandard2.x? Quero usá-lo em uma biblioteca de classe e gosto de manter meus classlibs todos .netstandard

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie Acho que vale a pena mencionar esse problema na documentação do ASP.NET Core 3.0. Conforme mencionado acima, os usuários atualizando para 3.0 precisarão adicionar <PackageReference> para compensar a API que saiu do Microsoft.AspNetCore.App.

@Bomret Quase todos os aplicativos de clientes do mundo real que inspecionamos usam MVC de alguma forma. Há muitos benefícios em mantê-lo na estrutura compartilhada, e não vejo motivos claros para removê-lo.

Certamente não sabemos, e eu conheço algumas pessoas em outras lojas que estão usando o núcleo .net para aplicativos sem servidor, apis da web, etc, onde não temos absolutamente nenhuma necessidade de MVC.

Fechando, já que enviamos o 3.0 hoje.

Precisamos mover esta lista para os documentos

@davidfowl foi adicionado: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-extensions

@pranavkm essa lista é na verdade exatamente o oposto: Coisas que não são mais pacotes, mas provavelmente ainda estão na estrutura compartilhada.

Trata-se de coisas que foram removidas da estrutura compartilhada, mas provavelmente agora estão disponíveis apenas como pacotes.

@scottaddie, esta é a lista que precisaremos consultar no documento de criação da biblioteca ASP.NET Core.

@DamianEdwards this - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-reference-for-removed -conjuntos?

É esse :)

Atrasado para a festa, mas isso não parece estar me ajudando a atingir o objetivo de simplificar o meu desenvolvimento.

a) Parece que agora, se houver uma melhoria em um componente AspNetCore (digamos, SignalR), precisamos esperar que um novo "pacote dotnet" para Microsoft.AspNetCore.App seja lançado para usá-lo, levando com ele tudo mais nesse pacote?
b) Não é mais possível criar classes de utilitário para AspNetCore em bibliotecas de classe netstandard (por exemplo, middleware Auth). Agora, as bibliotecas de classes precisam ser netcoreapp3.0 para armazenar essas coisas. Isso significa dividir nossas bibliotecas de classes de utilitários em implementações netstandard / netcore.
EDITAR: c) Como faço para definir qual versão do pacote estou usando se faço <Project Sdk="Microsoft.NET.Sdk.Web"> ? Obviamente, queremos ter compilações reproduzíveis em diferentes ramos após a atualização do dotnet.

a) Parece que agora, se houver uma melhoria em um componente AspNetCore (digamos, SignalR), precisamos esperar que um novo "pacote dotnet" para Microsoft.AspNetCore.App seja lançado para usá-lo, levando com ele tudo mais nesse pacote?

O SignalR é enviado na mesma programação que o resto do AspNetCore, portanto, não há alteração de programação aqui.

O SignalR é enviado na mesma programação que o resto do AspNetCore, portanto, não há alteração de programação aqui.

Portanto, este é apenas um mau exemplo? O mesmo pode ser dito sobre todos os outros pacotes NuGet que foram removidos?

O SignalR é enviado na mesma programação que o resto do AspNetCore, portanto, não há alteração de programação aqui.

Portanto, este é apenas um mau exemplo? O mesmo pode ser dito sobre todos os outros pacotes NuGet que foram removidos?

Eu penso que sim. Todos os componentes .NET Core e ASP.NET Core usam a mesma programação de envio. Se algo não acontecesse, ele teria que ser enviado em seu próprio pacote.

Eu penso que sim. Todos os componentes .NET Core e ASP.NET Core usam a mesma programação de envio. Se algo não acontecesse, ele teria que ser enviado em seu próprio pacote.

Vou acreditar na sua palavra. Não tenho nenhum contra-exemplo específico. Simplesmente não "parecia" assim ao atualizar os pacotes AspNetCore NuGet no passado.