[roadmap] Long term build changes

[Mpdreamz]

While this PR: #2711 moves us over to the new new csproj file and makes the dotnet cli the only compile toolchain it does so very pragmatically leaving some outstanding polishing to do.

For full reference before that PR we did a dual build using classic msbuild/xbuild project files and only our netstandardX TFM's were produced by project.json based dotnet CLI builds. FAR from ideal but the only way that gave us confidence the netX TFM's were being build in a reproducable way since the dotnet tooling has been super volatile. Remember our first incarnation of this dual build appeared 2+ years ago written against DNX so that decision to separate the two paid off for us.

That said #2711 offers many improvements but is in itself no panacea:

• Reintroduce Paket, currently blocked by paket isnt aware of current target framework fsprojects/Paket#2233. Other than than that the integration works beautifully now its all msbuild. e.g editors will restore using paket seamlessly.
• Use dotnet pack. As of right now there are a couple of outstanding issues (like this one dotnet pack - version suffix missing from ProjectReference NuGet/Home#4337) which have me a bit weiry of attempting to move over right now. So we now still pack like we always did using nuget.exe and seperate nuspec files. See more issues to track here
• dotnet cli tooling can not build netX TFM's on non windows systems. For that reason we have a DotNetCoreOnly msbuild property and a special Elasticsearch.DotNetCoreOnly.sln so that folks on non windows systems can still develop the client. The issue to track here is: Build for desktop framework on non-windows platforms dotnet/sdk#335
• Only produce netstandard1.1 (possibly separate netstandard1.3) builds of the clients. Still need to investigate how e.g VS2015 behaves here with the version of nuget it ships when targeting net45 and up.
• Move our tooling over to netcoreapp1.1. This is currently blocked by some of our dependencies not being .NET Core ready. Either we need to help them move over (like we have with others) or find alternatives. That's why for now the code generation tooling is excluded from Elasticsearch.DotNetCoreOnly.sln.
• dotnet test can not run netcoreappX because it injects a Main() of its own. Our test project is a runnable because its multi purpose (tests/benchmarks/profiling/litterate documentation). The XUnit team is working on dotnet xunit and all sorts of wonderful stuff that is sadly not ready so we self-host a runner for the time being. This works great but lacks integration with for instance XML result outputs or TeamCity/Appveyor loggers.
• we switched to embedded portabe sourcelinked PDB's. This might prevent folks on ASP.NET < 4.6.3 to get line numbers in stacktraces as mentioned here: https://github.com/dotnet/core/blob/master/Documentation/diagnostics/portable_pdb.md. I think setting us up for the future is the right trade off though.
• F# fsproj files are not supported in latest greatest VS2017 👎
• Travis still requires MONO because the way we invoke FAKE and nuget pack.

This is a tracking issue, please add to it as we roll with the punches after merging #2711 in and create separate issues/pr's for items on this list when we actually get around to tackling them.

[Mpdreamz]

Moved to dotnet xunit here: #2722

[niemyjski]

We had a second signed package that just had a glob pointing to the unsigned source files, if you have this scenario the package creation won't respect the folder structure when packaging source files. This is a big problem. The good news is the .net team's recommend just signing all of your packages and not having duplicates so this shouldn't be an issue but something to keep an eye out for.

[niemyjski]

There is a work around for the tfms on non windows as long as your package supports multiple tfms, and one of those is xplat you can use msbuild conditionals to limit what gets built. Obviously this breaks down pretty quick if your project file only supports net45...

Also, have you considered using SourceLink and not even doing pdbs/symbols? It's what we have started to do for our foundatio packages.

[ErikSchierboom]

@Mpdreamz As a heads-up, fsprojects/Paket#2233 is now closed (fixed in Paket 5).

[Mpdreamz]

Appreciate the ping @ErikSchierboom! Did spot the NDC announcement on Twitter and got a local branch going to jump to both paket and fake 5.x. Fake has some differences in how it delegates executing processes and their *out messages, also both fake 4 and 5 started misbehaving on my windows insiders build because it changes the CMD codepage which means on second invocation I get no console output from any .net application anymore. Anyhow my road to getting everything going involves to many yaks to shave for the moment :) Need a full day to revisit this ticket.

Lastly: Arnhem represent! 👋 🙂

[Mpdreamz]

Closing this as its outdated.