Sdk: Framework Dependent Publish doesn't work on 2.1.400

[TatiFKNavarro]

Steps to reproduce

Try to publish web api with dotnet publish -f netcoreapp2.0 -c Release, or within visual studio, with framework dependent selected

Expected behavior

Publish around 30 files

Actual behavior

Publishing over 200 files (self-contained)

Environment data

dotnet --info output:

SDK do .NET Core (refletindo qualquer global.json):
Version: 2.1.400
Commit: 8642e60a0f

Ambiente de tempo de execução:
OS Name: Windows
OS Version: 10.0.17134
OS Platform: Windows
RID: win10-x64
Base Path: C:Program Files\dotnet\sdk\2.1.400\

Host (useful for support):
Version: 2.1.2
Commit: 811c3ce6c0

.NET Core SDKs installed:
2.1.202 [C:Program Files\dotnet\sdk]
2.1.302 [C:Program Files\dotnet\sdk]
2.1.400 [C:Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:

https://aka.ms/dotnet-download

Description

After upgrading to Visual Studio v15.8, which comes with .net core SDK v2.1.4, I've been trying to publish my WebAPI in a Framework Dependent way, but it only generates the Self Contained way, with over 200 files.

[livarcocc]

Can you share your csproj?

[TatiFKNavarro]

```

netcoreapp2.0

```

[livarcocc]

@vijayrkn is this something that you can look at? Is this expected? Maybe because 2.1.400 does not have the store anymore?

[vijayrkn]

@livarcocc - This is happening on dotnet publish -f netcoreapp2.0 -c Release. Shouldn't this publish the non-standalone way by default since there is non RID publish. Why would store have impact in this case?

[livarcocc]

It is publishing non-stand alone still, but it is finding need to publish a lot more assets than before, notably, asp.net assets.

[vijayrkn]

In the actual behavior above, it is mentioned that it is publishing self contained

Actual behavior
Publishing over 200 files (self-contained)

[TatiFKNavarro]

@vijayrkn actually, I'm not sure... I've searched about the cli publishing a high number of files and the results said that perhaps it was publishing in self contained mode. How can I verify? I know that there isn't an exe on the output folder.

[dasMulli]

Quite a few users have been confused over the meaning of "self-contained" meaning "a lot of DLL files" vs "contains runtime" both here on GH and on StackOverflow.
So @TatiTheFreaK does the output contain runtime assets - like clrjit.dll, coreclr.dll - or just a lot of asp.net core related dll files?

[TatiFKNavarro]

@dasMulli the output folder doesn't contain these files you mentioned

[vijayrkn]

@JunTaoLuo - Any changes on the ASP.NET side that could be causing this?

[dasMulli]

Looks like PublishWithAspNetCoreTargetManifest is a no-op in 2.1.400.
I can reproduce this with any asp.net core 2.0 app

publish-2.1.302.binlog.zip
publish-2.1.400.binlog.zip

[livarcocc]

also cc @natemcmaster in case he knows if this is expected. Also, the manifest target above, I believe that's for the store.

[dasMulli]

This may be related to the UseAppHost vs SelfContained property changes.
The 2.0.* M.AspNetCore.All packages have

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest Condition="'$(PublishWithAspNetCoreTargetManifest)'=='' and '$(SelfContained)'=='false' and '$(PublishableProject)'=='true'">true</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>

if I change

'$(SelfContained)'=='false'

to

'$(SelfContained)'!='true'

then 2.1.400 behaves the same as 2.1.302.

[dasMulli]

cc @peterhuene @nguerrera as I believe they were involved with those changes

[JunTaoLuo]

Is the SelfContained property no longer set in 2.1.400? I was under the impression that both it and UseAppHost are set for back-compat purposes, i.e. exactly this scenario. In any case, I don't know how much we will prioritize this issue as 2.0 will soon go out of support on Oct 1, 2018 (https://www.microsoft.com/net/support/policy). We recommend migrating to 2.1 where the publish trimming works a lot differently.

[natemcmaster]

This appears to be a regression in the 2.1.400 SDK. Even though the 2.0 runtime is going out of support, the SDK should still support building older TFMs. We cannot make changes to shipped NuGet packages, so we'll need a fix in Microsoft.NET.Sdk.

@TatiTheFreaK If upgrading to 2.1 is infeasible, try adding this to your .csproj file. In my minimal repro, this appears to workaround the issue.

<PropertyGroup>
  <PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

[dasMulli]

Yeah this is a slight but impactful change in the SDKs behavior / API.
Though the SelfContained property is properly set for back-compat when publishing self-contained (so checks for == 'true' work), it is not explicitly set to false for portable applications, thus failing the == 'false' check.

[TatiFKNavarro]

@natemcmaster I'll try to upgrade to 2.1 later, but adding these lines didn't work here.

Edit: Updating to 2.1 worked

[nguerrera]

So the fixfor compat is to make sure we set it to false and never leave it empty? Seems reasonable.

[nguerrera]

(MSBuild handling of booleans is baffling, btw. Empty string is not coerced to false in such a comparison, but 'no' and 'off' are.)

[dasMulli]

MSBuild handling of booleans is baffling

I wouldn't be surprised if '$(SelfContained)' < 'true' somehow magically worked.

[peterhuene]

@livarcocc servicing consideration for 2.1.4xx? We need to restore setting SelfContained explicitly to false to ensure the websdk doesn't break here.

A much larger issue is ensuring regressions like this do not happen in the future. MSBuild being so, ahem, flexible leads to seemingly innocuous changes causing breaks like this. While I might argue that conditionals like the above should check for != 'true' to support unset also meaning false, this is on me for only going so far as validating the change for the .NET Core SDK (we use the != 'true' comparison extensively).

I will of course add test coverage for this break as part of the fix, but I think we should consider spending some cycles to shore up our test coverage that includes the websdk and combinations of RID/no-RID and 1.x/2.x target frameworks.

[livarcocc]

Yes, let's prepare a PR to fix this and get the ASK mode template filled out.

[dasMulli]

Are there any side effects of .400 (maybe also .401) having this bug?
e.g. if I publish once with .400 tooling to azure, then again with say a fixed .402 version, am I left with old runtime dll files that would theoretically downgrade the version of asp.net core if one updates the .All reference from 2.0.5 to 2.0.8?

[peterhuene]

@TatiTheFreaK another workaround if you don't want to edit your project file is to publish with dotnet publish -f netcoreapp2.0 -c Release --self-contained false. The bug is that SelfContained should be implicitly set to false, but it's actually an empty string with the 2.1.4xx SDK. I have a fix ready that we hope to get into a 2.1.4xx servicing release. Thanks very much for reporting this issue to us!

[vivmishra]

Add a known issue for 2.1.400

[peterhuene]

Unfortunately the fix didn't meet the servicing bar due to there being a reasonable (although, inconvenient) workaround and it only affects 2.0 web projects (2.1 should publish correctly). This will be fully fixed in a 3.0 SDK.