Create a .NET Core build of the LSIF generator

[jasonmalinowski]

The only "interesting" bit here is trying to create the NuGet package. Ideally, I'd just pack this as a dotnet tool, but the dotnet pack support for that simply blocks the ability to create a tool if you are also targeting .NET Framework, since there's no official support there whatsoever. For now I still want to pack a net472 version in case we run into compatibility issues; thus I change the current existing hacks for packing to put each TFM into it's own subfolder, matching the path that dotnet pack would pack a tool in, at least for net60.

Fixes #64510

[NTaylorMullen]

For now I still want to pack a net472 version in case we run into compatibility issues

Love it, ya great point!

[dibarbet]

For now I still want to pack a net472 version in case we run into compatibility issues;

It sounds like we will eventually not need a net472 version. What do we need to do to validate that and just use dotnet pack? Should we track it somewhere?

[jasonmalinowski]

It sounds like we will eventually not need a net472 version. What do we need to do to validate that and just use dotnet pack?

Right now this mostly got some smoke testing on my side, but I'm not sure if there are deeper gotchas. So it's more when we know the LSIF generator doesn't need to work on repositories that might have a bunch of legacy tasks/targets that rely on .NET Framework features. It's possible those might exist for awhile.

I'm going to go ask the dotnet pack owners if they'd up for adding some way to suppress the checks. At that point then there's basically zero extra cost for maintaining both targets.

[NTaylorMullen]

FWIW, we can always revert back to an older version of the package which is net472 enabled (that's how we typically deal with breaks anyways). For instance, if we found the netcore bits were breaking the experience we'd probably just go back to an older lsif generator package to resolve. Meaning, if you wanted we could work with you dropping net472 and testing things out 😄

[NTaylorMullen]

Also, totally have a theory that this might fix: #64491 (I can validate once a package is available)

[jasonmalinowski]

@NTaylorMullen Chatting with msbuild folks, they've confirmed that for now we're going to need both since the net60 version won't be able to build projects that load net472 tasks, which is going to be a lot of them. So I expect it to stay around for quite some time.

[NTaylorMullen]

@NTaylorMullen Chatting with msbuild folks, they've confirmed that for now we're going to need both since the net60 version won't be able to build projects that load net472 tasks, which is going to be a lot of them. So I expect it to stay around for quite some time.

Ah crap I see. Thinking about this from the Code Index side. Is there an easy way to detect .NET Core vs. .NET Framework before calling into the tool? I'm trying to think, how will I know which one to invoke

[jasonmalinowski]

Is there an easy way to detect .NET Core vs. .NET Framework before calling into the tool? I'm trying to think, how will I know which one to invoke

Dunno, let's discuss that in a better forum than this PR (not to be dismissive, but we'll probably need to ask others). The skeptic in me assumes in some cases we'll need an override.