ASP .Net Framework 4.8 webSITE cannot resolve assembly references for projects with dependency on netstandard2.0

[johnazule]

Issue Description

I am slowly losing my mind. I am working on a legacy solution with multiple asp .net framework website projects. I cannot stress this enough, these websites DO NOT contain a project file and instead msbuild generates a metaproj file, which uses the ResolveAssemblyReferences task to copy assembly dlls into the projects bin folder and then it calls asp_compiler.exe to compile the website. Visual Studio uses a different process internally which works with no issues, however directly invoking msbuild on the sln file things get messy. Best as I can tell ResolveAssemblyReferences is not looking inside the Facades folder of the .net framework 4.8 assembly folder, and as of such is unable to locate the netstandard.dll that resides there. I have tried adding NETStandard.Library to the project to no avail (I believe the target file only does anything meaningful if the actual project targets .netstandard instead of having a depency on it), I have tried manually copying the relevant dlls (found in the NETStandard,Library/{version}/build/netstandard2.0/ref ) into the bin folder. No luck. It doesn't seem like there is a way to edit the metaproj file after it has been generated to add the facades folder to the search paths. I am quite lost, any help would be amazing thankyou.

Steps to Reproduce

Create a asp net framework website project. Add a project that denpends on netstandard2.0. Try and build the sln. Verify that the solution cannot find the referenced assembly.

Expected Behavior

For the above to compile and correctly copy the relevant dlls to the bin folder

Actual Behavior

Msbuild fails to resolve references for any project that depends on netstandard2.0, and cannot copy the relevant dlls to the bin folder

Analysis

No response

Versions & Configurations

No response

[johnazule]

Looking into this a bit more, I have found something interesting. _projectTargetFrameworkAsString in ResolveAssemblyReference.cs which is the backing field for TargetFrameworkVersion and is what _projectTargetFramework is derived from does not seem to be set anywhere outside of tests. It is just an empty string. It is also what determines _checkAssemblyVersionAgainstTargetFrameworkVersion in ReferenceTable.cs. Manually hard coding a version 4.8.1 still doesn't resolve my issue as the netstandard.dll isn't copied, but it removes the warning about it not being apart of the target framework @MichalPavlik

Edit: Looking a bit further it seems I am not quite understanding the mechanism that sets task parameters, but when I was debugging this the actual value for _projectTargetFrameworkAsString was still an empty string

Edit 2: I have found we're we are setting it. In SolutionProjectGenerator we don't add a target framework version. I am currently investigating if the behaviour of omitting this matches the docs explaination:

Optional String parameter.

The project target framework version. The default value is empty, which means there's no filtering for the references based on target framework.

[johnazule]

// Set condition for when to check assembly version against the target framework version
_checkAssemblyVersionAgainstTargetFrameworkVersion = unresolveFrameworkAssembliesFromHigherFrameworks || ((_projectTargetFramework ?? ReferenceTable.s_targetFrameworkVersion_40) <= ReferenceTable.s_targetFrameworkVersion_40);

This logic doesn't seem to meld with my understanding of the documented intent. When targetFrameworkVersion is NOT set we currently DO check assemblies against the targetFrameworkVersion. Any clarity would be amazing

[johnazule]

Got a PR up for this, but am unsure if it the right approach