How to stop the localized Microsoft.CodeAnalysis.*.resources.dll files from getting published by ASP.NET Core?

Question

When I publish an ASP.NET Core 3.0 project, I get a few localized folders where the 4 assemblies shown are in each of these folders. I am not sure why these folders and files get included. None of my packages reference a CodeAnalysis package.

I added <PreserveCompilationContext>false</PreserveCompilationContext> in the csproj file but it didn't help. Is there a way to exclude them?

Answer 1

You get a lot of language folders containing CodeAnalysis.dll files in your published output if you have a project reference to Microsoft.VisualStudio.Web.CodeGeneration.Design, which is needed for scaffolding controllers. If that is true for your project, change the package reference in your .csproj file to include ExcludeAssets="all"

<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.0.0" ExcludeAssets="All" />

For example, old *.csproj file

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UserSecretsId>aspnet-foo-4E53EF45-B3BE-4943-81BE-2449DC5AA2BC</UserSecretsId>
    <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
  </PropertyGroup>
  
  <ItemGroup>
    <!-- ... -->
    <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design"
                      Version="3.0.0" />
  </ItemGroup>
  
  <ItemGroup>
    <!-- ... -->
  </ItemGroup>
</Project>

New file *.csproj should be

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UserSecretsId>aspnet-foo-4E53EF45-B3BE-4943-81BE-2449DC5AA2BC</UserSecretsId>
    <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
  </PropertyGroup>
  
  <ItemGroup>
    <!-- ... -->
    <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design"
                      Version="3.0.0"
                      ExcludeAssets="All" />
  </ItemGroup>
  
  <ItemGroup>
    <!-- ... -->
  </ItemGroup>
</Project>

Answer 2

Add this:

<SatelliteResourceLanguages>en</SatelliteResourceLanguages>

to the .csproj file:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <SatelliteResourceLanguages>en</SatelliteResourceLanguages>
  </PropertyGroup>

As suggested, you can use none to exclude all of them:

<SatelliteResourceLanguages>none</SatelliteResourceLanguages>

and taking consideration languages do you want like english and spanish:

<SatelliteResourceLanguages>en;es</SatelliteResourceLanguages>

Works with VS2019 and other versions

UPDATE 2021/2022:

Still working with Visual Studio 2022 and .NET 6

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <SatelliteResourceLanguages>en</SatelliteResourceLanguages>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

Answer 3

In my case, the source of these localized folders was from the package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation. It has a dependency on Microsoft.CodeAnalysis.Razor. You can read more about the purpose of the package here: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-3.1

You cannot just exclude an asset when trying to take advantage of the package. My work-around was to conditionally include the package reference whenever the project is in debug mode.

  <ItemGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="3.1.1" />
  </ItemGroup> 

I then used an #if pre-processor directive to conditionally run the code that enables razor runtime compilation.

#if DEBUG
            services.AddRazorPages().AddRazorRuntimeCompilation();
#else
            services.AddRazorPages();
#endif

Please note: You may need to delete your bin folder to see the folders removed after a build. Also, make sure you are building under the correct solution configuration.

I was able to find a Github issue describing this exact scenario, but unfortunately it was never resolved. https://github.com/dotnet/extensions/issues/2247