Replies: 5 comments 7 replies
-
I have scores of my own tools in nuget.org, so this seems like something I should learn. What exactly does "NuGet.org will use deterministic builds metadata for validating packages" mean? My view of nuget.org is a secure file server. When I upload a .nupkg and .snupkg to nuget.org, I've already made sure I did the build in a standardized virtual OS environment, already did my exhaustive tests to know that it works, and checked via a round trip fetch gives the same file. Doesn't nuget.org keep checksums on the files I uploaded, doesn't it disallow for these files to be mutated by someone, and the files in an msbuild or dotnet install are validated with a checksum with those critical tools? Nuget does not have my sources, nor does it know my build env or how I do the build. |
Beta Was this translation helpful? Give feedback.
-
I use nuget to create artifacts when I release since I can't figure it out locally. haha |
Beta Was this translation helpful? Give feedback.
-
The enabling of Deterministic Builds should be quite easy:
The package does not necessarily need to be built in CI, |
Beta Was this translation helpful? Give feedback.
-
Smells like OSGI ;-)
… Le 19 janv. 2022 à 04:21, Gleb Krasilich ***@***.***> a écrit :
I believe .NET SDK does not warn you about some blunders you've described (yet). What .NET SDK deterministic builds does already is the following:
Enables deterministic compilation for Roslyn compiler as described here <https://github.com/dotnet/roslyn/blob/main/docs/compilers/Deterministic%20Inputs.md>.
Embeds compiler flags into assembly metadata. In other words, resulting assembly will contain the full information about how it was built (the full list of parameters passed to Roslyn's csc.exe).
Checks that SourceLink information is well-formed.
The NuGet.org server will be able to read SourceLink information and compiler flags, reproduce builds, and check that published assemblies are byte-wise identical. The verified packages will get some special trusted status on NuGet.org.
So, for now you can think about deterministic builds in .NET SDK not as a tool to help you avoid some blunders while developing locally, but as an attempt to create a subset of trusted verifiable packages in the NuGet ecosystem.
A side note about SourceLink. It also helps consumers to debug library code, since SourceLink adds links to the original source files in debug symbols. Visual Studio (and I believe Rider too) can automatically download source files from repository when stepping into SourceLink-enabled library's code. Here is an article on this feature: https://devblogs.microsoft.com/dotnet/improving-debug-time-productivity-with-source-link/ <https://devblogs.microsoft.com/dotnet/improving-debug-time-productivity-with-source-link/>
—
Reply to this email directly, view it on GitHub <#3498 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZNQJBDXN7YNXW6KRXL4LTUWYU4RANCNFSM5MHF5Z3A>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
Adding to my confusion, I read the information on the C# compiler deterministic builds. https://github.com/dotnet/roslyn/blob/main/docs/compilers/Deterministic%20Inputs.md
But, then I try to verify the claim Even after adding several permuations of the element Sure, I do get an identical .dll if I do a
Is there an example that demonstrates identical dll's built for the same source on two different paths? |
Beta Was this translation helpful? Give feedback.
-
The original discussion: https://groups.google.com/g/antlr-discussion/c/DAuWTC1tmrE/m/atKoQx2bAQAJ
Beta Was this translation helpful? Give feedback.
All reactions