Use .Net Core MSBuild for OS X and Linux Builds

[joperezr]

Use .Net Core MSBuild for OS X and Linux Builds

[mellinoe]

Change this comment, or do we need a condition here?

[joperezr]

We can certainly add a condition, but technically is not required. The reason is that .Net Core MSBuild can only load assemblies living in the same directory as itself, so even though this properties say that the assemblies loaded should come from different folders, it is loading the .Net Core versions that live on the same dir. I'll add the condition either way to make it more clear.

[mellinoe]

I can test this on my machine when the packages have been uploaded to buildtools and the temporary sources are removed, since the CI won't be building any of this.

I'm happy to see this is finally going in, it should hopefully get us much closer to a unified build process for x-plat builds.

[joperezr]

@mellinoe I just pushed a change to my buildtools PR dotnet/buildtools#396 that removes the temporary sources given that I'm done pushing the packages into the buildtools feed now. That means that you should be able to sync to my branch in buildtools and build to produce a buildtools package, and use that to build xplat using the code in this PR.

[joperezr]

cc @weshaggard @naamunds @JohnChen0

[weshaggard]

Is this still necessary with your change to set OsEnviroment to Unix?

[joperezr]

It is not anymore. I think that the ideal solution is not to change OsEnvironment to Unix, but instead handle the cases for OS X as well, but that is not super easy given that we have so many files that special-case Unix. Given that treating OS X as Unix was the way that builds in Mac used to work, I will remove this conditions for now, and log an issue so that we can move to special casing OSX as well.

[mellinoe]

@joperezr I think there may be an issue with the Open signing key. So far most of the projects have built fine, but I'm getting this error from the projects that do use the new key:

CSC : error CS7027: Error signing output with public key from file '/home/eric/projects/corefx/Tools/Open.snk' -- Cannot marshal 'return value': Invalid managed [/home/eric/projects/corefx/src/System.Diagnostics.DiagnosticSource/src/System.Diagnostics.DiagnosticSource.csproj]

Still running the build (haven't gotten to to tests or packaging yet), but everything seems to be running smoothly other than the above.

[joperezr]

@mellinoe yeah I saw that as well, that started happening this morning when I rebased. It seems to be a compiler bug, I'll log the issue and push the workaround

[mellinoe]

Workaround looks fine to me. Like I mentioned, we are doing the same thing with the ECMA key right now.

EDIT: Actually, maybe we should make the workaround the same as the ECMA Key one:

https://github.com/dotnet/corefx/blob/0dd1ab7223dea82f236ec81d42f4ae0227176bf4/dir.props

<!--
      Delay signing with the ECMA key currently doesn't work.
      https://github.com/dotnet/roslyn/issues/2444
    -->
    <UseECMAKey>false</UseECMAKey>

In the project files we just do:

<UseECMAKey Condition="'$(UseECMAKey)' == ''">true</UseECMAKey>

I'm fine either way, but it might be nice to have both of these properties in one place so we can remember to address them both (I'm assuming they're related)

[weshaggard]

I kind of agree with @mellinoe that we should probably just add the explicit set to false in the same place and in the individual projects only set it to true if the property is empty.

[joperezr]

@weshaggard @mellinoe Sounds good, I'll do that.

[weshaggard]

LGTM please make sure to file the various tracking bugs for the comments.

[weshaggard]

@dotnet-bot test Innerloop OSX Release Build and Test

[mellinoe]

LGTM

[ghost]

@ellismg, can we have a similar upgrade in CoreCLR? Currently building CoreCLR on NetBSD is requiring Mono; which unlike FreeBSD is bit more inconvenient -- although we have installed full mono packs on our systems, but this is something we would greatly appreciate and even willing to pull off ourselves (by taking inspirations from @joperezr's work in this PR), if we get a 'go ahead'. =)

[ellismg]

@jasonwilliams200OK We are 99.99% of the way there, and dotnet/coreclr#3214 will remove the last mono dependency.

[ghost]

Thanks @ellismg! Perfect timings I'd say.. 🎯