Initial implementation

[ForestEckhardt]

Resolves #1

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[sophiewigmore]

@ForestEckhardt its been a bit so I forgot some context- could you remind me why it's preferable to check the runtimeconfig.json for existing and for runtime versions during build, rather than using its existence as detection criteria?

[ForestEckhardt]

@sophiewigmore We check it at build because this buildpack will now run after dotnet-publish and we want to pull the version of the framework from the runtimeconfig if at all possible with is generated during publish. Therefore we have to check after the during build.

[sophiewigmore]

Ahhh yes, thank you

[fg-j]

Mostly nitpicks, but a couple of key questions:

1. the name of the buildpack
2. the priority order of version resolution

[fg-j]

should we switch to using checksum + the published SHA512 now that it's possible in jam and packit?

[fg-j]

or do you want to defer that to a subsequent PR?

[ForestEckhardt]

I can take a quick crack at it.

[fg-j]

@ForestEckhardt I just experimented with combining this buildpack with the existing rearchitecture spike, and I'm seeing the running app fail to locate the ASP.NET Core runtime, even though the runtime is present in a layer on the app image. The app fails to start with:

docker run -it --rm --env PORT=8080 test-rearch
Setting ASPNETCORE_URLS=http://0.0.0.0:8080
You must install .NET to run this application.

App: /workspace/source-app
Architecture: x64
App host version: 6.0.9
.NET location: Not found

Learn about runtime installation:
https://aka.ms/dotnet/app-launch-failed

Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=ubuntu.18.04-x64&apphost_version=6.0.9

However, running

DOTNET_ROOT=/layers/paketo-buildpacks_dotnet-core-aspnet-runtime/dotnet-core-aspnet-runtime /workspace/source-app

inside the container makes the app start as expected. I believe this buildpack must set DOTNET_ROOT.

[ForestEckhardt]

@fg-j After our short investigation is appears that the DOTNET_ROOT needs to be set for FDEs I will make a commit shortly.

[sophiewigmore]

@ForestEckhardt @fg-j I'm surprised that DOTNET_ROOT needs to be set if the runtime is already on the PATH. Could you give a bit more context about why that is Forest?

[ForestEckhardt]

@sophiewigmore It have to do with how FDE works. Because we are not invoking the dotnet cli the FDE is like trying to look in a default install location which we have not installed the installation in. Because of that the warning message given tells us we need to specify the DOTNET_ROOT if we are in the non-default location.

However because of our restructure we can get away with using the default directive instead of the override directive which is the preferred option.

[sophiewigmore]

@ForestEckhardt thank you! that makes sense

[sophiewigmore]

@fg-j are you able to re-test with the changes here since you have the re-architecture spike pulled already? Assuming that works now, this PR looks good to me

[fg-j]

I've verified that with the new changes setting DOTNET_ROOT, the buildpack now integrates as expected with the other language family buildpacks. I've built and run source apps, FDDs, FDEs, and self-contained apps successfully.