Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Make _TargetFrameworkVersionWithoutV public

See original GitHub issue

Building logic on top of the target framework version is super helpful, but it would be easier if _TargetFrameworkVersionWithoutV was public. current logic only duplicates it. It is super small (.TrimStart('vV')) and should be exposed publicly. Mabe we can find a better name but that’s irrelevant. Having something to compare against is helpful in custom build targets.

Is this reasonable to do?

Issue Analytics

State:
Created 5 years ago
Reactions:1
Comments:9 (9 by maintainers)

Top GitHub Comments

7reactions

rainersigwaldcommented, Oct 24, 2018

We’ve been talking (https://github.com/Microsoft/msbuild/issues/3212#issuecomment-413956874) about introducing a new MSBuild version-comparison function that would ignore leading [vV]. Would that be enough for your needs?

0reactions

dsplaistedcommented, Mar 22, 2021

I’m not sure there’s much value in cleaning up existing code in the .NET SDK. I don’t feel very strongly about it.

The MSBuild target framework parsing functions are in the .NET 5 SDK. They aren’t in the .NET Core 3.1 SDK. You can use the .NET 5 SDK to build projects targeting .NET Core 3.1, and we normally recommend using the latest .NET SDK (though I understand that in Docker it’s not so simple).

Are you getting the MSB4184 error in Visual Studio or in a command-line build? If it’s from the command line, a binlog would help investigate, probably as a separate issue.