Mark RichCodeNav.EnvVarDump as private asset

[jasonmalinowski]

Otherwise this package becomes a dependency of all our NuGet packages.

[tmat]

I wonder if the package needs to be excluded in source build...

[BertanAygun]

I wonder if the package needs to be excluded in source build...

The package can be excluded if EnableRichCodeNavigation != true but should be a no-op in that case anyway. It is needed to be part of source build though as the target generates a log file to help with LSIF generation afterwards.

[tmat]

Yes, it's a no-op, but the problem is that source build does not have access to this package at all.

Another thing that we might want to consider is to set EnableRichCodeNavigation = true in one leg of CI build, so that we have some validation done during PR. This would avoid breaking our official build if something went wrong. How much time does it take to run the target?

[BertanAygun]

Another thing that we might want to consider is to set EnableRichCodeNavigation = true in one leg of CI build, so that we have some validation done during PR. This would avoid breaking our official build if something went wrong. How much time does it take to run the target?

This build target is very quick since it only produces an extra file near the output file with some build info (not index itself). There would be another build step (which I was thinking to do in a parallel CI for now to not cause any issues with existing builds) which then runs the actual LSIF tool based on those files.

[tmat]

In that case we should always run the target in CI (when ContinuousIntegrationBuild is true).

[jasonmalinowski]

I wonder if the package needs to be excluded in source build...

I wasn't sure; I saw the other analyzers being excluded. How do I know? (It seems like the source build CI did fail, but because of some TLS handshake issue; I don't think it actually validated the change.)

[tmat]

@BertanAygun BTW, once this is implemented: #41395 you might be able to extract the information you need from DLL+PDB (build drop).

That said, the most efficient approach would be to integrate generation of LSIF data in csc task itself. This is because the compiler already has all symbols loaded and bound during compilation. Perhaps LSIF generation could be an analyzer that outputs data to a file?

[BertanAygun]

@tmat, those are the long term plans I believe. I agree it would make everything a lot easier if we provided a msbuild variable that let the compiler output lsif side by side with the assembly.

Regarding the compiler switches in pdb, would that info also include csproj path, target framework etc? I assume latter can be derived from assembly itself but it would be nice to have that available easier.

[tmat]

Regarding the compiler switches in pdb, would that info also include csproj path, target framework etc? I assume latter can be derived from assembly itself but it would be nice to have that available easier.

No, it wouldn't contain this information since the compiler doesn't have it. It would contain all information necessary to recreate the compilation, assuming that all metadata references are available on a (symbol) server and all sources are available in the source control (or embedded in the PDB).

[tmat]

@tmat, those are the long term plans I believe. I agree it would make everything a lot easier if we provided a msbuild variable that let the compiler output lsif side by side with the assembly.

OK, sounds like a good plan.

[ghost]

Auto-approval