asp.net core 2.0 publish generating lots off DLL

This is caused by a bug introduced in .NET Core SDK version 2.1.400. See Framework Dependent Publish doesn't work on 2.1.400 #9852

There is a workaround - publish via the command line and pass the arg --self-contained false.

Example:

dotnet publish -f netcoreapp2.0 -c Release --self-contained false


On Visual Studio 15.8.2 I too had this problem. Unfortunately I could not simply upgrade the application because we have runtime version restrictions on the internally managed deployed servers. So even though I can build on the latest SDK version (2.1.401), where the application is deployed has an older SDK version (2.1.100).

The SDK and Runtime version correlations for .NET Core 2.0 can be found here.

My problem manifested thusly: The Build and Rebuild succeeded, but the Publish failed with the error message Error NETSDK1068: The framework-dependent application host requires a target framework of at least 'netcoreapp2.1'. I learned from here that the default is to use the latest installed version.

Starting with .NET Core 2.0, the following rules apply when determining which version of the SDK to use:

  • If no global.json file is found or global.json doesn't specify an SDK version, the latest installed SDK version is used. Latest SDK version can be either release or pre-release - the highest version number wins. (emphasis added)

In this same article, I learned to make use of the global.json file to address this error. I used git-bash and cd'd to the local working directory for the web application I was trying to publish. The corresponding csproj file should be in this directory. From here I ran the following:

dotnet new globaljson --sdk-version 2.1.100

Now I can use the following publish configure settings: - Configuration: Release - Target Framework: netcoreapp2.0 - Deployment Mode: Framework-Dependent - Target Runtime: Portable


I'm pretty sure that you just select publish mode for a self-contained deployment so the majority of files is just libs required for running isolated runtime. To get back to a few files again just move forward with Framework-dependent deployments (described the same doc)