Build-time code generation for .NET Core #3424
Conversation
|
Ok, I've implemented a workaround for the MSBuild bug: now it should happily build in VS / cmdline without trouble. |
Directory.Build.props
Outdated
| @@ -43,6 +44,9 @@ | |||
| <PropertyGroup> | |||
| <!-- System packages --> | |||
| <SystemRuntimeVersion>4.3.0</SystemRuntimeVersion> | |||
|
|
|||
| <MicrosoftBuildVersion>15.3.409</MicrosoftBuildVersion> | |||
There was a problem hiding this comment.
nit: It should go to Microsoft* section in props, alphabetical order ;-) Just to make if easier to locate these.
| @@ -0,0 +1,65 @@ | |||
| using System; | |||
There was a problem hiding this comment.
nit: Filename should be GetDotNetHost.cs
| @@ -23,17 +23,17 @@ | |||
| </ItemGroup> | |||
|
|
|||
| <ItemGroup> | |||
| <None Include="CreateOrleansTables_MySQL.sql"> | |||
| <None Include="CreateOrleansTables_MySql.sql"> | |||
There was a problem hiding this comment.
I believe it fails on non-Windows builds otherwise.
There was a problem hiding this comment.
Makes sense, but then we should correct the casing of the files itself, not pascal casing SQL in the csproj IMHO.
There was a problem hiding this comment.
Yes, because the casing here is incorrect.
| @@ -0,0 +1,3 @@ | |||
| <Project> | |||
There was a problem hiding this comment.
Microsoft.Orleans.CodeGenerator.Build.targets should be a better naming here, since we're removing the duplicate "Orleans" from everywhere, project names, package names, assembly names, etc.
There was a problem hiding this comment.
The name aligns to the NuGet package name
There was a problem hiding this comment.
But not by our new standards, right?
There was a problem hiding this comment.
if the package name changes, we can change this. Otherwise it won't be automatically added to the project when it's installed.
There was a problem hiding this comment.
Unless we modify the name when we pack it, like:
<PackagePath>build\$(PackageId).targets</PackagePath>. I'm not sure that's better, though - it might be confusing.
|
Pushed a bunch of commits to address feedback. The solution also is sort-of buildable on nix now, but that is a non-goal of this PR. To make it make it build cleanly on nix, we would need to remove the Windows-only projects (Service Fabric, etc) from the sln and switch |
This reverts commit 26e0a1e.
Note: this does not yet support building Orleans.sln on Linux or other platforms but it does allow building projects which use Orleans on Linux.
The build fails the first time (and subsequently succeeds) when building in VS. We can fix that by setting Project Dependencies in VS so that
Orleansrelies onClientGenerator.Bootstrap, but that breaks cmdline builds. It's a known issue: dotnet/msbuild#2274Removed
BootstrapCodegen.projbecause it doesn't play nicely with nuget / msbuild. Instead, I added 3*.Bootstrapprojects under a folder calledBootstrapBuild. Each one corresponds to a project insrcand they link their cs files from there. I added those projects toOrleans.slnso that msbuild correctly restores dependencies and initializes its internal structures.The linked sources in those projects are hidden using properties on the
<Compile>csproj item. The<Link>metadata is used to hide the directory structure. This is just to reduce visual clutter in VS: only the Dependencies node is visible in the image below.To make builds work on on .NET Core in the absence of AppDomains, we spawn a new process for code generation. Therefore we need a way to find the correct
dotnetexecutable. This is done using an MSBuild task calledGetDotNetHost.Hopefully we can eliminate bootstrapping in the near future :)