add net48 without system.reflection.metadata

[bruno-garcia]

We had a few customers sharing challenges when building for net48 because of dependencies.

This is an attempt to reduce dependencies when building specifically for newer .NET Framework.

I also believe we should bump the min version to 6.0.0 (as opposed to 5.0.0 which we have now and is deprecated):

https://www.nuget.org/packages/System.Reflection.Metadata/6.0.0#dependencies-body-tab

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- add net48 without system.reflection.metadata ([#3236](https://github.com/getsentry/sentry-dotnet/pull/3236))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against d8eca51

[jamescrosswell]

Is this supposed to be a new target or to replace the net462 target?

[bruno-garcia]

No, we need to keep supporting the older one, but we can at least improve for apps running on the latest version

[jamescrosswell]

I'm not sure I get it. Sentry has a dependency on System.Reflection.Metadata for .NETFramework 4.6.2, .NETStandard 2.0 and .NETStandard 2.1.

Surely one of those is being resolved when compiling for net48. What does having Sentry target net48 specifically do for us?

[bruno-garcia]

I'm not sure I get it. Sentry has a dependency on System.Reflection.Metadata for .NETFramework 4.6.2, .NETStandard 2.0 and .NETStandard 2.1.

Surely one of those is being resolved when compiling for net48. What does having Sentry target net48 specifically do for us?

If using .NET 4.8, it should pick the net462 of our SDK which does have the dependency. BUT this is breaking, because.. .NET Framework and these problems with dependency resolution (is my assumption).

With 2 customers I debugged this with, I suggested they try adding the dependency directly to their app (S.R.M that is) and it resolved the issue. I didn't have access (nor I have a WIndows machine) to debug the issue myself

[jamescrosswell]

If using .NET 4.8, it should pick the net462 of our SDK which does have the dependency. BUT this is breaking, because.. .NET Framework and these problems with dependency resolution (is my assumption).

With 2 customers I debugged this with, I suggested they try adding the dependency directly to their app (S.R.M that is) and it resolved the issue. I didn't have access (nor I have a WIndows machine) to debug the issue myself

OK, with this commit, we're basically dropping the following dependencies for people using .net48 :

<PackageReference Include="System.Reflection.Metadata" Version="5.0.0" />
  </ItemGroup>
<PackageReference Include="System.Runtime.InteropServices.RuntimeInformation" Version="4.3.0" />

Is that because these packages are included as part of .net48 and later? I couldn't find this documented anywhere but maybe I'm just not looking in the right places...

[bitsandfoxes]

I couldn't find this documented anywhere but maybe I'm just not looking in the right places...

I think this is part of the problem. It "should" work. But we don't know. I'd like to hold off on this for now.