Partilhar via

Alterações de quebra do MSBuild no .NET Core 2.1 - 3.1

  • Artigo

As seguintes alterações estão documentadas nesta página:

Quebrando a mudança Versão introduzida
As compilações em tempo de design retornam apenas referências de pacotes de nível superior 3.1
Alteração de nome de arquivo de manifesto de recurso 3.0
Ferramentas de projeto agora incluídas no SDK 2.1

.NET Core 3.1

As compilações em tempo de design retornam apenas referências de pacotes de nível superior

A partir do .NET Core SDK 3.1.400, somente referências de pacote de nível superior são retornadas RunResolvePackageDependencies pelo destino.

Versão introduzida

SDK do .NET Core 3.1.400

Alterar a descrição

Em versões anteriores do SDK do .NET Core, o RunResolvePackageDependencies destino criou os seguintes itens do MSBuild que continham informações do arquivo de ativos do NuGet:

  • PackageDefinitions
  • PackageDependencies
  • TargetDefinitions
  • FileDefinitions
  • FileDependencies

Esses dados são usados pelo Visual Studio para preencher o nó Dependências no Gerenciador de Soluções. No entanto, pode ser uma grande quantidade de dados e os dados não são necessários, a menos que o nó Dependências seja expandido.

A partir do SDK do .NET Core versão 3.1.400, a maioria desses itens não é gerada por padrão. Apenas os itens do tipo Package são devolvidos. Se o Visual Studio precisar dos itens para preencher o nó Dependências, ele lê as informações diretamente do arquivo de ativos.

Razão para a alteração

Essa alteração foi introduzida para melhorar o desempenho de carga de solução dentro do Visual Studio. Anteriormente, todas as referências de pacote eram carregadas, o que envolvia o carregamento de muitas referências que a maioria dos usuários nunca visualizaria.

Se você tiver lógica MSBuild que depende desses itens que estão sendo criados, defina a EmitLegacyAssetsFileItems propriedade como true em seu arquivo de projeto. Essa configuração habilita o comportamento anterior onde todos os itens são criados.

Categoria

MSBuild

APIs afetadas

N/A

.NET Core 3.0

Alteração de nome de arquivo de manifesto de recurso

A partir do .NET Core 3.0, no caso padrão, o MSBuild gera um nome de arquivo de manifesto diferente para arquivos de recurso.

Versão introduzida

3.0

Alterar a descrição

Antes do .NET Core 3.0, se nenhum , ou metadados foram especificados para um EmbeddedResource item no arquivo de projeto, o MSBuild gerou um nome de arquivo de manifesto no padrão <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.DependentUpon ManifestResourceNameLogicalName Se RootNamespace não estiver definido no arquivo de projeto, o padrão será o nome do projeto. Por exemplo, o nome de manifesto gerado para um arquivo de recurso chamado Form1.resx no diretório raiz do projeto foi MyProject.Form1.resources.

A partir do .NET Core 3.0, se um arquivo de recurso for colocalizado com um arquivo de origem com o mesmo nome (por exemplo, Form1.resx e Form1.cs), o MSBuild usará informações de tipo do arquivo de origem para gerar o nome do arquivo de manifesto no padrão <Namespace>.<ClassName>.resources. O namespace e o nome da classe são extraídos do primeiro tipo no arquivo de origem colocalizado. Por exemplo, o nome de manifesto gerado para um arquivo de recurso chamado Form1.resx que é colocalizado com um arquivo de origem chamado Form1.cs é MyNamespace.Form1.resources. A principal coisa a observar é que a primeira parte do nome do arquivo é diferente das versões anteriores do .NET Core (MyNamespace em vez de MyProject).

Nota

Se você tiver LogicalName, ManifestResourceName, ou DependentUpon metadados especificados em um EmbeddedResource item no arquivo de projeto, essa alteração não afetará esse arquivo de recurso.

Essa alteração de quebra foi introduzida com a EmbeddedResourceUseDependentUponConvention adição da propriedade aos projetos .NET Core. Por padrão, os arquivos de recursos não são explicitamente listados em um arquivo de projeto .NET Core, portanto, eles não DependentUpon têm metadados para especificar como nomear o arquivo .resources gerado. Quando EmbeddedResourceUseDependentUponConvention é definido como true, que é o padrão, o MSBuild procura um arquivo de origem colocalizado e extrai um namespace e um nome de classe desse arquivo. Se você definir EmbeddedResourceUseDependentUponConvention como false, o MSBuild gerará o nome do manifesto de acordo com o comportamento anterior, que combina RootNamespace e o caminho do arquivo relativo.

Na maioria dos casos, nenhuma ação é necessária por parte do desenvolvedor, e seu aplicativo deve continuar a funcionar. No entanto, se essa alteração quebrar seu aplicativo, você poderá:

  • Altere seu código para esperar o novo nome de manifesto.

  • Desative a nova convenção de nomenclatura definindo EmbeddedResourceUseDependentUponConvention como false no arquivo de projeto.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Categoria

MSBuild

APIs afetadas

N/A

.NET Core 2.1

Ferramentas de projeto agora incluídas no SDK

O SDK do .NET Core 2.1 agora inclui ferramentas comuns da CLI, e você não precisa mais fazer referência a essas ferramentas do projeto.

Alterar a descrição

No .NET Core 2.0, os projetos fazem referência a ferramentas externas do .NET com a configuração do <DotNetCliToolReference> projeto. No .NET Core 2.1, algumas dessas ferramentas estão incluídas no SDK do .NET Core e a configuração não é mais necessária. Se você incluir referências a essas ferramentas em seu projeto, receberá um erro semelhante ao seguinte: A ferramenta 'Microsoft.EntityFrameworkCore.Tools.DotNet' agora está incluída no SDK do .NET Core.

Ferramentas agora incluídas no SDK do .NET Core 2.1:

<Valor DotNetCliToolReference> Ferramenta
Microsoft.DotNet.Watcher.Tools dotnet-watch
Microsoft.Extensions.SecretManager.Tools dotnet-user-secrets
Microsoft.Extensions.Caching.SqlConfig.Tools dotnet-sql-cache
Microsoft.EntityFrameworkCore.Tools.DotNet DOTNET-EF

Versão introduzida

SDK do .NET Core 2.1.300

Remova a <DotNetCliToolReference> configuração do seu projeto.

Categoria

MSBuild

APIs afetadas

N/A