net4x assets are not built and they are needed by VS code

[nguerrera]

There are net4x-specific assets in the closed build that are not produced in the source build. For standard dotnet usage, these assets are never used, but they are needed if msbuild is running on Mono or .NET Framework and pointed at the targets in the .NET Core SDK folder. VS Code's C# support does builds using Mono this way and things are broken without the net46 assets. VS for Mac has the same requirement. (Edit: So does Visual Studio.)

See dotnet/vscode-csharp#1744

We need to teach source build how to build these assets. In the closed build of dotnet/sdk, the assets are built on Windows and packaged on all platforms.

Major complication: targeting net4x using .NET Core msbuild on non-Windows is not yet officially supported. We can workaround it in various ways, or better yet implement it as a true supported feature, but it will require access to full framework reference assemblies during the build. And that probably means we need to build full framework reference assemblies from source...

Another path forward would be to make all of the task dlls (nuget too, not just dotnet/sdk) target .NETStandard and stop multi-targeting them to net4x and netcoreapp. However, it is currently next to impossible to make .NETStandard msbuild tasks. See dotnet/msbuild#1309 for some of the issues with it.

cc @DustinCampbell @Petermarcu @shawnro @dleeapho @karajas @leecow

[nguerrera]

cc @omajid

[omajid]

See OmniSharp/omnisharp-roslyn#919 for some related discussion.

Edit. Nope, that is a different issue. Thanks for correcting me.

[DustinCampbell]

@omajid: That's only tangentially related. In the case described by that issue, the .NET Core SDK being used was not built from source.

[nguerrera]

Adding @AndyGerlicher re: path forward to .NETStandard-based build tasks.

[jaredpar]

However, it is currently next to impossible to make .NETStandard msbuild tasks. See dotnet/msbuild#1309 for some of the issues with it.

Definitely. When we begin looking into this though we need to consider both the problems with a general task and a tool task. Tool tasks are doubly difficult to make NetStandard when they wrap a managed tool. There is no feasible way to implement ExecuteTool in that setup.

Consider the C# compiler task. How are we to implement ExecuteTool in a portable way? There are at least 3 different activation models we need to consider:

• Desktop: just run csc
• CoreClr: dotnet exec csc
• Mono: mono csc

[weshaggard]

All great points. While I would love to make the tasks build against .NET Standard there will definitely be some challenges.

In addition to this dependency on .NET Framework corefx also has a dependency on the targeting pack in order to generate the compat shims for .NET Core. We could fix that dependency by just generating the list of type-forwards manually and committing them to the repo.

As for building the .NET Framework reference assemblies from source we do have a flavor of that in the standard repo (https://github.com/dotnet/standard/tree/master/platforms/net461). It isn't a complete set but it gives us a model and the possibility to produce the reference assemblies from source.

[DustinCampbell]

It sounds to me like .NET Standard tasks are a bit into the future yet -- at least for tool tasks as Jared mentions. Without some sort of NetStandard Exe (which seems like a good feature to pursue at some point), I can't see how we could make tool tasks work without some sort of nasty shenanigans.

It seems like having net46 assets build from source is something we need.

[weshaggard]

I can't see how we could make tool tasks work without some sort of nasty shenanigans.

That isn't a .NET Standard issue exactly that is more of a hosting issue for the platform you are running on (i.e. .NET Core/mono/etc). We definitely need to figure out a strategy to that problem regardless of whether or not these ToolTasks cross-compile for .NET Framework. In the case of ToolTask I think the only thing we can really do is use the host that msbuild is running on to execute these custom tools.

[DustinCampbell]

Agreed. And if those custom tools were some sort of NetStandard Exe, there would be a much better chance that the current runtime host could run them.

Regardless, being able to build net4x cross platform is a valid scenario that will require build from source for .NET Framework reference assemblies. Going down the road of focusing on MSBuild NetStandard tasks would only solve this particular issue, and not the general customer scenario.

[omajid]

To clarify, this affects everyone using omnisharp-roslyn, not just VSCode. Emacs and Eclipse would be affected too.

Surprisingly, vim which uses omnisharp-server is immune ;)

[DustinCampbell]

I don't believe omnisharp-server supports .NET Core 2.0 though. Does it even support .NET Core at all?