-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building libs.tests fails in XmlSerializer.Generator.Tests #39227
Comments
Tagging subscribers to this area: @safern, @ViktorHofer |
cc: @ViktorHofer @ericstj -- maybe a fallout from: 8790ade What is weird is that CI is not failing and CI is doing |
Odd. I'd expect serializable types to come from here Line 18 in 8892364
One thing that comes to mind would be that this could happen if you were messing with TargetArchitecture. For instance if you set it to arm64 and built the project (meant to skip) then set it to something else like amd64. It's possible compiler wouldn't rebuild due to incremental, but would try to run the generator. |
Frankly think we shouldn't be conditioning the test this way as it could cause these incremental build issues since the project doesn't represent these as configurations. Instead we should have the condition as attribute on the test. |
Agreed with using runtime detection over compile time exclusion. Probably via an XUnitExtensions attribute? cc @safern |
@safern so far I've seen it in my ARM64 surface, but if I see it in my x64 PC I'll let you know. |
Then I think that confirms @ericstj statement. |
@safern @ericstj I built my x64 PC and I also saw the failure there:
This is the command I used: |
I looked at Carlos's machine. The assembly had the types present. The problem is that the tool was running on an old shared framework.
Ultimately the bug here is that this tool is doing runtime-reflection on build assets:
This is an age-old problem where a build tool conflates build-framework with target-framework. Instead of doing runtime-reflection, this tool should be changed to read metadata. That should be much easier now with MetadataLoadContext. I suspect that's the root cause of #1390. The reason this regressed was because we stopped using the test-framework to execute the tool. The reason it's only happening for Carlos is the set of things I called out above. Perhaps a workaround would be to change Line 8 in 69b0d16
"rollForward": "LatestMajor" |
I have a clean enlistment synced to the latest runtime commit in master.
I ran
.\build.cmd clr+libs -rc release
without problem.When I build
.\build.cmd libs.tests -rc release
, I get this error:Let me know if you need more info.
The text was updated successfully, but these errors were encountered: