Closed bbartels closed 2 weeks ago
This shouldn't happen in a clean checkout, and I cannot reproduce it (and neither does CI) so it seems to be something that is specific to your local environment.
Generally you should only get this message if you have modified any of the *Asn.xml files. The intention of the error is to say "You modified the XML, you better check in the C# that it generated, too"
These two files evidently have some purpose as deleting them will regenerate them again.
Well, yes. They are types that are used as part of ASN.1 serialization.
Presumably when you build, the AlgorithmIdentifierAsn.xml.cs
and SubjectPublicKeyInfoAsn.xml.cs
files have changed. If you look at the git differences (git diff
) how did the compiler change those files?
While it is an older fresh pull from github, the HEAD is targeting a commit from today(55d2ada) and I ran git clean -xdf
to clean any build artefacts. The following is the output of git status
& git diff
.
PS D:\dotnet\runtime> git rev-parse HEAD
55d2adab3aa7e3fb764a44bf5661cffd21936596
PS D:\dotnet\runtime> git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: src/libraries/Common/src/System/Security/Cryptography/Asn1/AlgorithmIdentifierAsn.xml.cs
modified: src/libraries/Common/src/System/Security/Cryptography/Asn1/SubjectPublicKeyInfoAsn.xml.cs
no changes added to commit (use "git add" and/or "git commit -a")
PS D:\dotnet\runtime> git diff
warning: in the working copy of 'src/libraries/Common/src/System/Security/Cryptography/Asn1/AlgorithmIdentifierAsn.xml.cs', CRLF will be replaced by LF the next time Git touches it
warning: in the working copy of 'src/libraries/Common/src/System/Security/Cryptography/Asn1/SubjectPublicKeyInfoAsn.xml.cs', CRLF will be replaced by LF the next time Git touches it
I frankly should have checked what exactly the diff
output was. Having ran the build again with: git config --global core.autocrlf false
it built successfully first try🤦 Still not entirely sure why any line endings would have changed though, could a change in .gitattributes
stop something like this from happening?
could a change in .gitattributes stop something like this from happening?
Got it. Yeah our generated code is sensitive to line ending differences, and it sounds like you had git to default to lf
line endings instead of "default" line endings.
I think this scenario should work though. I'll take a look at making changes to the .gitattributes
so that git knows it really no-kidding needs to use CRLF on Windows.
Just curious, if the build generates then why don't they go to temp? Why check them in? Is it due to some circular dependency?
Why check them in?
The original reason was that the XML transformation task was missing in portable MSBuild so you had to do the generation with desktop MSBuild on Windows. Since the files are used on other platforms they had to be checked in. I don’t think this is a blocker anymore.
From https://github.com/dotnet/runtime/issues/45210
One of the things that has been great about the current model is that the source files show up on source.dot.net; that's something I'd like to keep true under any change.
So changing that was not something I had considered without input from @bartonjs. Since the current stance is to check them in, the most sensible thing to do is to ignore the line endings when diffing.
Thanks @vcsjones! It's always a bit difficult coming back to contribute whenever I find time and running into small things like this. So happy to see this resolved going forward :)
It's always a bit difficult coming back to contribute whenever I find time and running into small things like this
Definitely. Papercuts like this add up. Thanks for writing an issue to get it fixed.
Having followed the instructions here, attempting to build the runtime + libraries I ran into the following errors after running
build.cmd clr+libs -rc Release
. Upon a second attempt to compile, the build is successful. These two files evidently have some purpose as deleting them will regenerate them again. What is that purpose of these files, how am I suppose to deal with them? The error makes it sound like I am supposed to "check them in"(to git?). I presume that is not the case.My suggestion would be to:
.gitignore
for these files for them not to pollute the git context or some guidance around how one is suppose to deal with the filesWhen following the instructions