Need to rationalize MSBuildForwardingApp in AOT scenarios

[JeremyKuhne]

In MSBuildForwardingApp.ConcatTelemetryLogger

                Type loggerType = typeof(MSBuildLogger);
                Type forwardingLoggerType = typeof(MSBuildForwardingLogger);

#pragma warning disable IL3000 // Avoid accessing Assembly file path when publishing as a single file
                msbuildArgs.OtherMSBuildArgs.Add($"-distributedlogger:{loggerType.FullName},{loggerType.GetTypeInfo().Assembly.Location}*{forwardingLoggerType.FullName},{forwardingLoggerType.GetTypeInfo().Assembly.Location}");
#pragma warning restore IL3000

In AOT scenarios we'll need to have some code that sits in a dll for code that we'll run out of the AOT process.

I have not looked at all into how the logging works in this particular case. There may be additional work around telemetry logging to handle remoting build logging for telemetry.

cc: @MiYanni @baronfel

[baronfel]

In an AOT world we'll be passing command lines to an MSBuild Server binary, so we just need to be able to construct that command line correctly inside the AOT bubble. The question of where the non-AOT MSBuild ILogger implementation we use should live is kinda separate from this (though it impacts the specifics of how we would construct the path to that dll).

What really interesting to me about this is how this would work in a world where the CLI was both AOT and a separate component from the rest of the SDK installation. In that scenario we'd have two major pathways I could see:

• the logger dll lives in the SDL bubble still
• the logger dll ships with the AOT CLI, perhaps as an embedded resource or bundled file or something

I'm more interested in the second one, as it means that build telemetry could evolve indepndently of the SDK versioning cycle.