Building from source uses highly flawed method of detecting versions

Current buildpack tries to parse .csproj file as XML to extract TargetFramework and a few other properties to determine the correct version to introduce. This is a highly flawed way of doing it because .csproj is essentially an MSBuild script. There can be a very large number of ways to set these properties in a way that is non standard for all sorts of legit reasons. The value of <TargetFramework> may actually be a variable that comes from a common import file at parent level. It may be set by Directory.Build.props which is a common way to set it for multiple projects simultaneously as it's automatically imported from a parent folder. It may be absent altogether and declared as signifying that the project can run on multiple runtimes. The only thing that can accurately answer which TargetFramework is actually being used is MSBuild itself.

The simplest way to query MSBuild for this info is to inject a target that echos the property to console and parse it. For example if you append this to the bottom of csproj

  <Target Name="__GetFrameworkVersion">
    <Message Text="TargetFramework is '$(TargetFramework)'" Importance="High" />
  </Target>

one can print out the value of TargetFramework to console by running

> dotnet msbuild /t:__GetFrameworkVersion

Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  TargetFramework is 'net6.0'

Start by locating the buildpack code that parses .csproj files for TargetFramework, then review the MSBuild behavior described in issue #520. Run dotnet msbuild /t:__GetFrameworkVersion against representative projects and verify that the implementation uses MSBuild output instead of XML parsing, including projects using imports or TargetFrameworks.