Source-based apps should have an SDK intelligently installed

[menehune23]

When staging source-based apps that use a non-default version of the SDK, this buildpack should lookup which SDK to install based on the contents of *.csproj, removing the requirement to use a buildpack.yml or global.json to specify the SDK.

We do part of this during finalize, where we parse the runtime version from the project.

We could extract that version-gathering logic into a DRYer location and combine it with the runtime->SDK mapping that we maintain in our manifest to go from *.csproj -> <runtime version> -> <SDK version> and install that.

Here's an example of BRATs using the mapping info to build a go map.

Open questions:

• What about *.fsproj and *.vbproj? It seems our buildpack might already handle this (see here and here) without extra code.

Relates to #446

[macsux]

When staging source-based apps that use a non-default version of the SDK, this buildpack should lookup which SDK to install based on the contents of *.csproj, removing the requirement to use a buildpack.yml or global.json to specify the SDK.

This is not a behavior that I would expect as a .NET developer. .NET defaults to the highest version of SDK installed, and should do the same in the buildpack. As a .NET developer I would expect buildpack to use latest GA version of SDK in buildpack - currently it's 6.x. SDKs are built to be backward compatible as long as necessary target frameworks are installed. For rare scenarios when use of old SDK is required, the user can provide global.json to explicitly fall back to an older SDK (or use preview version if we ever bundle those in buildpack).

[johnnyr0x]

@sophiewigmore @ForestEckhardt - please review and close if applicable.

[ForestEckhardt]

I think that I agree with @macsux assessment of the situation. Also that mapping has been removed.