.NET 5.0 apps do not build

[sophiewigmore]

What version of Cloud Foundry and CF CLI are you using?

cf version 6.49.0+d0dfa93bb.2020-01-07

What version of the buildpack you are using?

v2.3.34

If you were attempting to accomplish a task, what was it you were attempting to do?

Tried to cf push a .NET Core 5.0 app (I ran dotnet new webapp -o web using the .NET Core 5.0 CLI) and then ran cf push web -b dotnet_core-buildpack. I also tried using an out of the box react app (dotnet new react), and a console app (dotnet new console), and

Is your dotnet app unpublished, platform-dependant, or self-contained?

Unpublished.

What did you expect to happen?

The app would build and push to CF successfully, as it does for .NET Core 3.1 apps.

What was the actual behavior?

> cf push web-app-5 -b dotnet_core_buildpack
...
 -----> Dotnet-Core Buildpack version 1.2.3
   -----> Supplying Dotnet Core
   -----> Installing libunwind 1.5
          Copy [/tmp/buildpacks/cf3ef9c71172107e31df73e46237f7af/dependencies/66a4a9541b55947fd8e80a98630
01705/libunwind_1.5_linux_noarch_cflinuxfs3_6a1dd8f2.tgz]
          using the default SDK
   -----> Installing dotnet-sdk 3.1.412
          Copy [/tmp/buildpacks/cf3ef9c71172107e31df73e46237f7af/dependencies/55df474f5c151e0458bcf4ddaa61ce0a/dotnet-sdk_3.1.412_linux_x64_any-stack_7575f962.tar.xz]
   -----> Installing dotnet-runtime 3.1.18
          Copy [/tmp/buildpacks/cf3ef9c71172107e31df73e46237f7af/dependencies/092d92cdb37093a19ef4218d5fa8c313/dotnet-runtime_3.1.18_linux_x64_any-stack_fb39d01d.tar.xz]
   -----> Finalizing Dotnet Core
   -----> Installing dotnet-runtime 5.0.9
          Copy [/tmp/buildpacks/cf3ef9c71172107e31df73e46237f7af/dependencies/1ec0fa7ed11eb1843386a0e2f96992e2/dotnet-runtime_5.0.9_linux_x64_any-stack_b605c2f7.tar.xz]
   -----> Publish dotnet

          Welcome to .NET Core 3.1!
          ---------------------
          SDK Version: 3.1.412

         /tmp/contents430627291/deps/0/dotnet-sdk/sdk/3.1.412/Microsoft.Common.CurrentVersion.targets(1177,5): error MSB3971: The reference assemblies for ".NETFramework,Version=v5.0" were not found. You might be using an older .NET SDK to target .NET 5.0 or higher. Update Visual Studio and/or your .NET SDK. [/tmp/app/web.csproj]
          **ERROR** Unable to run dotnet publish: exit status 1
   Failed to compile droplet: Failed to run finalize script: exit status 12
   Exit status 223
Error staging application: App staging failed in the buildpack compile phase
FAILED

It appears that the buildpack is incorrectly installing dotnet-sdk 3.1.412 and dotnet-runtime 3.1.18 during the Supply phase, but then corrects itself and installs dotnet-runtime 5.0.9 during Finalize. The dotnet-sdk version is never fixed, which causes it to fail.

It looks like when .NET Core version 5.0 was added to the buildpack, changes were made to finalize, but nowehere else.

I would expect the implementation of this issue is two-fold:

1. Fix the buildpack code to build .NET Core 5.0 apps
2. Add integration test fixtures to ensure we are testing around this case.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/179702635

The labels on this github issue will be updated when the story is started.

[sophiewigmore]

this issue blocks #455

[menehune23]

Investigated this pretty thoroughly, and by following the docs to specify a SDK version via buildpack.yml, the app builds just fine.

For example:

dotnet-core:
  sdk: 5.0

Using something like the above, it behaves as if it were 5.0.x. Other values like 5.x or even x.x also work to float the SDK as desired.

This route seems to be expected when wanting an SDK version different from the default (3.1). There are more sophisticated routes we could consider that could improve the UX -- like:

• using the csproj file to grab the runtime version, then do a reverse-lookup for which SDK to install. This is what the dotnet-sdk CNB does, but it requires some way to maintain a reverse lookup, as the CNB does. If we want this, it would make sense to file a feature request.

• or (less sophisticated) perhaps having a discussion on whether the default SDK should remain 3.1

For this story, however, it comes down to using buildpack.yml, which is covered by our tests, so I don't think there's much else to do here outside of the options above.

As far as what finalize is doing, it is installing the runtime (not the SDK) for use when running the app. In a source-based app, it makes sense to do what it's doing and parse the csproj to decide which runtime to install. It does so happen that supply also installs a runtime (which is derived from the SDK tarball and is required when publishing the app), but that runtime may or may not be the exact version that finalize installs for launch purposes. If they're different, you end up with both installed alongside each other, which doesn't seem to be a problem.

cc: @shanks3012

[menehune23]

Also note that the docs are currently off slightly, as they specify an order of precedence for the SDK version:

1. buildpack.yml
2. global.json
3. fsproj

Options 1 and 2 will work, but the behavior of falling back to an fsproj file is not currently in the buildpack. However, before that logic was removed, it was still very basic: it only used the presence of this file and used a hard-coded SDK value (1.1.x) if fsproj was present, and it did not even parse the fsproj to extract any version info, nor did it look for a csproj.

[menehune23]

UPDATE:

• using the csproj file to grab the runtime version, then do a reverse-lookup for which SDK to install. This is what the dotnet-sdk CNB does, but it requires some way to maintain a reverse lookup, as the CNB does. If we want this, it would make sense to file a feature request.

Actually, I noticed from the previously-mentioned diff that we do maintain the necessary reverse-lookup. I'll dig further to see if we still use it in our code -- and if not, I'll try to see why/when that changed...

[menehune23]

OK, captured the better UX in #460. I'm going to close out this issue as there is a sensible way to get .NET 5 source-based apps to stage (i.e. add buildpack.yml)

Note, I also tried pushing published .NET 5 apps and they work with no problems (i.e. staged successfully, can interact with pushed app in web browser):

• Framework-dependent deployment (via dotnet publish -c Release --self-contained false): I noticed it still downloads the old SDK (3.1) during supply, which is expected since there is no buildpack.yml or global.json, but downloads the proper runtime during finalize (5.0). The runtime is the important part, as SDK isn't needed for pre-published apps.

• Self-contained app (via dotnet publish -c Release -r linux-x64 --self-contained true): Downloads default SDK and runtime (3.1) during supply, but similarly are not needed since it's self contained.