Fix native sourcelink support

[hoyosjs]

microsoft/MSBuildSdks#360 sets DebugType=none in a non-overrideable manner. The problem is
that property gates the sourcelink targets from running. While this is not very clean, the other
alternatives are not all that much better

• Modify sourcelink to allow to generate this always.
• Modify this to run in empty.csproj instead of runtime-prereqs.proj and add a p2p ref. That be invoked separately if any other part of the repo wants native sourcelink.
• Revert to the old NoTargets behavior, but I don't think this is right...

Opening this PR to discuss if there's a better fix and have one that at least solves the issue.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[hoyosjs]

cc @jkotas

[ViktorHofer]

For such cases, the NoTargets SDK has an extra hook point to import logic after the Sdk.targets file comes into play: https://github.com/microsoft/MSBuildSdks/blob/9af7ea2c0d302af50ec2cc2566c7f4e32325ec3f/src/NoTargets/Sdk/Sdk.targets#L87.

You can set a property that points to a targets file that then sets the required properties.

[ViktorHofer]

Did you consider submitting a change to https://github.com/dotnet/sourcelink to allow overriding this setting via a custom property?

[hoyosjs]

dotnet/sourcelink#830

[hoyosjs]

For such cases, the NoTargets SDK has an extra hook point to import logic after the Sdk.targets file comes into play: https://github.com/microsoft/MSBuildSdks/blob/9af7ea2c0d302af50ec2cc2566c7f4e32325ec3f/src/NoTargets/Sdk/Sdk.targets#L87.

You can set a property that points to a targets file that then sets the required properties.

Creating a file for that one property seems like overkill, unless there's a strong preference, I am going to leave as it - It's localized next to the target invocation so it makes discoverability a bit easier IMO.

[ViktorHofer]

Creating a file for that one property seems like overkill, unless there's a strong preference, I am going to leave as it - It's localized next to the target invocation so it makes discoverability a bit easier IMO.

Sure that works as well. Just wanted to let you know that such a hook exists.