Initial .NET Framework ARM64 support#60735
Conversation
|
Actually hold off on reviewing for now, I think I found a way to have a sane unified build. |
This adds the initial support for Roslyn producing .NET Framework ARM64 binaries. This is necessary because on an ARM64 machine a binary tagged as AnyCPU will actually run under X64 emulation. This meas the Roslyn tools will run out of the box but they do so under emulation which is significantly slower. In order to get the performance expected the binaries need to be targetted to ARM64 so they run natively. The challenge here is there is not concept of multi-targeting between <PlatformTarget> values. In order to support producing both AnyCPU and ARM64 EXEs we are going to make use of shared projects for csc, vbc and VBCSCompiler. The bulk of the code will be in the shared project with the actual project files toggling the PlatformTarget and TargetFramework elements.
|
Okay this change is ready for review now that I've redone the build work. I've separated this out into two commits:
|
|
@RikkiGibson, @dotnet/roslyn-infrastructure PTAL |
| </PropertyGroup> | ||
| <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" | ||
| Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" /> | ||
| <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.Default.props" |
There was a problem hiding this comment.
I didn't understand what these projects are. Where did they come from? Does VS need to be installed in order to build these?
There was a problem hiding this comment.
I don't know what they are either but it's boiler plate in every .shproj hence included here. Perhaps @rainersigwald, or @baronfel know the reason for them existing
There was a problem hiding this comment.
No idea, sorry. My assumption would be that it lights up VS functionality but isn't required at build time.
| <Compile Include="..\CommandLine\BuildProtocol.cs" /> | ||
| <Compile Include="..\CommandLine\ConsoleUtil.cs" /> | ||
| <Compile Include="..\CommandLine\NativeMethods.cs" /> | ||
| <Compile Include="..\CommandLine\CompilerServerLogger.cs" /> |
There was a problem hiding this comment.
I see that those four Compile items are the only things you transferred over from the now removed CommandLine.projitems import.
Did other properties (like Import_RootNamespace) not need to be copied here as well?
| <StartupObject>Microsoft.CodeAnalysis.VisualBasic.CommandLine.Program</StartupObject> | ||
| <ServerGarbageCollection>true</ServerGarbageCollection> | ||
| <GenerateMicrosoftCodeAnalysisCommitHashAttribute>true</GenerateMicrosoftCodeAnalysisCommitHashAttribute> | ||
| <EmbedUntrackedSources>true</EmbedUntrackedSources> |
There was a problem hiding this comment.
It looks like this was not in vbc.csproj previously. Was that a bug you fixed?
There was a problem hiding this comment.
Yes. It's meant that untracked sources, build inputs that aren't in GitHub, weren't being embedded. This would break rebuild verification. A bit niche at the moment but a subtle issue I noticed when doing this work
jcouv
left a comment
There was a problem hiding this comment.
LGTM Thanks (iteration 2). Only minor questions
Co-authored-by: David Barbet <dibarbet@gmail.com>
This adds the initial support for Roslyn producing .NET Framework ARM64
binaries. This is necessary because on an ARM64 machine a binary tagged
as AnyCPU will actually run under X64 emulation. This meas the Roslyn
tools will run out of the box but they do so under emulation which is
significantly slower. In order to get the performance expected the
binaries need to be targetted to ARM64 so they run natively.
There are a few challenges here. The first is that there is not a
concept of multi-targeting between
<PlatformTarget>values. In orderto support producing both AnyCPU and ARM64 EXEs we are going to make
use of shared projects for csc, vbc and VBCSCompiler. The bulk of the
code will be in the shared project with the actual project files toggling
the
PlatformTargetandTargetFrameworkelements.The second challenge is there are no CI machines with .NET Framework
ARM64 installed on them. The only way to run tests is to do so manually
on a machine. There are 3 test failures when I did this but they are
pretty minor issues. Nothing that would block us getting the binaries
out for the rest of the effort to move forward.
The overall effort here and remaining work items are tracked here
#59421