sourcelink VS docs

The premise of the tool seems very useful: edit debug symbols and assert messages so that source code can be found by debuggers. But this description does not make it clear how this tool accomplishes the whole task:

> Why not fix the binary coming out of the build cache, so it points to the absolute path of the source files?

What is the absolute path? If you had a virtual file system that allowed you to construct a path to any file at a given commit, this would work great. But who does that other than Google? Or if you agree that every developer will check out the same source code repo at the same path, but the you have to have the right commit checked out.

Ideally you would want your binary to point back to your code repo, like SourceLink does.

https://github.com/dotnet/sourcelink

Reference https://github.com/dotnet/sourcelink/tree/main/src/Microsoft.Build.Tasks.Git

The tooling isn't quite there yet, but between SourceLink and EmbedUntrackedSources, it should be completely reasonable to be able to maintain trust (and eventually, easy, exact reproducibility) for projects that use source generation. Plus, AFAIK, for a package to truly be considered deterministic, all of the sources used for the build either must be tracked by source control, or embedded with the aforementioned flag.

It looks like your NuGet packages is missing symbols (the .pdb files next to .dll files). Symbols let folks map from compiled code back to source code. No symbols make it harder for users to debug your package. I'd recommend using Source Link for your project: https://github.com/dotnet/sourcelink

If you want to enable Source Link for the consumers of your NuGets, make sure you turn on deterministic builds using dotnet build /p:ContinuousIntegrationBuild=true.

MS docs ar now on github. Licence lists "CC-BY-4 and MIT licence found" https://github.com/dotnet/docs/tree/main

Yeah, I saw that devdocs and the like don't include what was previously not cross platform and not popular for linux guys: C#, msbuild.

This ability to nest object/collection initializers is not documented TMK and if you feel it is you could update this nearly 4 year old ticket requesting it be documented: https://github.com/dotnet/docs/issues/12979 .

To be like, really pedantic, C#'s foreach will perform an implicit typecast in some scenarios, which can cause the enumeration to throw an InvalidCastException when it hits an item that can't be cast to the specified type (in this case, ShadowCaster2D).