On ppc64le, VMR at 8 Preview 6 doesn't build using itself #3571
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
MichaelSimons
added
area-upstream-fix
|
Able to reproduce on x86 as well with mono |
|
Hi @MichaelSimons it seems this failure happens in or near the The message "Failure has occurred while loading a type." also sounds suspiciously like the above problem. Not sure if this is just a coincidence or if that problem is coming back somehow? |
|
As was said earlier, the issue can be reproduce on x64. With this SDK, the issue can be reproduced by restoring an invalid project file:
Run
@akoeplinger @lambdageek can you help debug this further? |
|
Hi @tmds we've had some more progress in tracking this down. Enabling Mono logging shows the following failure: This is consistent with the error message, as the What is still unclear is why it is looking for the 7.0.0 version here. My understanding is that in source-build, this version string should be overridden to refer to the version built as part of the source-build runtime (i.e. a 8.0.0-preview something version). We are still trying to figure out why there's still a 7.0.0 reference remaining here. |
When I disassemble this dll (from the sdk folder), it looks like a reference assembly ( |
Interesting ... is the corresponding dll from a coreclr build also version 7.0.0 or something else? |
Source-build no longer overrides all version strings starting in 8.0. Repo's now have the ability to control if they want source-build to utilize the latest or if they want a specific version in which a reference assembly is used. See #2482 for more details. I would not expect a behavior difference between the CoreCLR and Mono builds however. |
Huh, I must have missed that. I'm not sure I fully understand how this intended to work with the specific case of the is in fact the assembly from the System.Security.Permissions nuget package for version 7.0.0. However, in an SDK resulting from a source-build / VMR build, that file cannot be from nuget - and in fact it appears to be just a reference assembly. But in my understanding these files under sdk/ are supposed to be suitable for execution, not just reference DLLs. Am I missing something here, or how is this supposed to work?
The one difference is (same as when we saw it with .NET 6) that CoreCLR lazily loads assemblies to resolve types, while Mono is more eager. So it may be that the problem that this assembly cannot be executed simply doesn't show up with CoreCLR as it's never even attempted to be executed ... |
The problem is that the repo/project declaring this dependency is utilizing a ref assembly and it should not be. It will need to declare this dependency in the repo's version.details.xml file and mark it with the source-build element. This will trigger source-build to lift it to latest. Do you know where this dependency comes from? |
System.Security.Permissions.dll is required by Microsoft.Build.dll, which is built as part of the msbuild repo. |
|
The mono sdk has the dll in 3 places: All 3 have the reference assembly instead of the implementation assembly. |
Correction: I was comparing to the Microsoft build which has the implementation assembly. A source-built SDK with CoreCLR also has the reference assembly. As @uweigand mentioned, probably it doesn't effectively try to load the assembly to perform the type check in |
Ah, good point. But as far as I can see, all those dependencies on System.Security.Permissions.dll come from some Microsoft.Build*.dll assembly, either directly or indirectly via System.Configuration.ConfigurationManager. So it's probably still all about the msbuild repo. |
That doesn't surprise me at all. Unfortunately, the SDK contains a fair number of assemblies that don't get loaded. |
|
I have a fix for MSBuild's reference to System.Security.Permissions. It allows the repro described in #3571 (comment) to properly report the syntax error. I'll link the fix to here once I get it out. |
|
There may be a few additional cases to tackle. These are the sdk assemblies that are ref assemblies on source-build and implementation assemblies in the Microsoft build: |
Verified patch on ppc64le VM and found issue is fixed |
|
FYI - #2817 is a related tracking issue that will enhance our infrastructure to detect reference packages being getting bundled in the output. |
) When .NET is source-built with the mono runtime, there can be scenarios where MSBuild is made to attempt to load a reference assembly for System.Security.Permissions. See dotnet/source-build#3571 (comment) for such a scenario. The reason a reference assembly exists in this case is because MSBuild has a reference to the 7.0.0 version of System.Security.Permissions. When building with source-build, it loads that reference from SBRP (which only contains reference assemblies) in order to fulfill compile time references. The problem is that the assembly is also getting included in the output. This should have been detected by poison leak detection but that doesn't yet handle reference assemblies. The solution is to update Version.Details so that the "live" version of System.Security.Permissions, that was previously built with source-build, will flow to the build of the MSBuild repo. Essentially, this causes the SystemSecurityPermissionsVersion property to be overridden with the live version. Fixes dotnet/source-build#3571
…ons for source-build (#9158) When .NET is source-built with the mono runtime, there can be scenarios where MSBuild is made to attempt to load a reference assembly for System.Security.Permissions. See dotnet/source-build#3571 (comment) for such a scenario. The reason a reference assembly exists in this case is because MSBuild has a reference to the 7.0.0 version of System.Security.Permissions. When building with source-build, it loads that reference from SBRP (which only contains reference assemblies) in order to fulfill compile time references. The problem is that the assembly is also getting included in the output. This should have been detected by poison leak detection but that doesn't yet handle reference assemblies. The solution is to update Version.Details so that the "live" version of System.Security.Permissions, that was previously built with source-build, will flow to the build of the MSBuild repo. Essentially, this causes the SystemSecurityPermissionsVersion property to be overridden with the live version. Fixes dotnet/source-build#3571 Original commit: dotnet/msbuild@be26b4c [[ commit created by automation ]]
|
The preview can be built using this patch: dotnet/msbuild#9158. Looking into the other reference assemblies is tracked by #3599. |
…ons for source-build (#9158) When .NET is source-built with the mono runtime, there can be scenarios where MSBuild is made to attempt to load a reference assembly for System.Security.Permissions. See dotnet/source-build#3571 (comment) for such a scenario. The reason a reference assembly exists in this case is because MSBuild has a reference to the 7.0.0 version of System.Security.Permissions. When building with source-build, it loads that reference from SBRP (which only contains reference assemblies) in order to fulfill compile time references. The problem is that the assembly is also getting included in the output. This should have been detected by poison leak detection but that doesn't yet handle reference assemblies. The solution is to update Version.Details so that the "live" version of System.Security.Permissions, that was previously built with source-build, will flow to the build of the MSBuild repo. Essentially, this causes the SystemSecurityPermissionsVersion property to be overridden with the live version. Fixes dotnet/source-build#3571 Original commit: dotnet/msbuild@be26b4c [[ commit created by automation ]]
Describe the Bug
We are trying to confirm that source-build can build using itself.
This works on x64. We can build .NET 8 Preview 6 offline (after using the bits downloaded by prep.sh), then use what we just-built to build .NET 8 Preview 6 itself completely offline.
This doesn't work on ppc64le. We can build .NET 8 Preview 6 using a cross-compiled ppc64le SDK and the bits downloaded by prep.sh. We can do this offline too. But then using that just-built SDK to build .NET 8 Preview 6 again fails on ppc64le. The error happens when building runtime.
Steps to Reproduce
Other Information
The text was updated successfully, but these errors were encountered: