Compiling .net core app with CoreRT / another AOT

Question

I'm building an REST API on ASP.NET CORE 1.0. In production it'd be IMHO very useful NOT to use JIT because the docker containers with the app are scaling up and down, redeploying during CI over and over, so the just-in-time compilation for every deployed container causes terrible lags, LB health-check deaths and other pains.

As I read, the native compilation with dotnet CLI is discontinued. I tried building with CoreRT but without luck (details on demand due to complexity).

Since this question is quite abstract I'm not providing sample codes or detailed info, so for the start there are few questions instead:

1. Is my presumption correct - will ahead-of-time compilation solve the problem with slow first execution of each path -or - isn't there any other solution anyway?
2. If it's true, is currently possible to build "native" app (ubuntu x64 target) from .NET Core?
3. If it's, what's the best practice - how can I do it? Does anyone has experience with that?

(The target platform would be ubuntu-14.04-x64 docker image as well as the compilation platform. For develop purposes would be also nice to compile it on OSX.)

Thank you in advance.

Intermingle

If that's doable at this stage I wonder why Microsoft does not yet announce it. So my understanding is that the time is not right and you should not bother yourself with such a big topic. – Puck

Are you sure? The CoreRT project sounds quite promising [github.com/dotnet/corert/blob/master/Documentation/… – Intermingle

everyone knows it is promising and Microsoft even demoed it last year at Connect. But before it reaches production quality, leave it alone. – Puck

I've posted an answer that I think helps below but... can you share what you startup times look like? You mention health check failures .. what are the kinds of tolerances you need to hit for that? – Aphasic

Answer 1

Having full native ahead of time compilation isn't possible at this time. It's one of the goals of the CoreRT project linked above but isn't in any state I'd call production ready. The demo at Connect last year should be taken with a pretty big grain of salt. For example they still don't have a reflection subsystem. However, we have a couple of solutions that can greatly reduce the amount of code needing to be generated at JIT time. For .NET Core the tooling is called CrossGen and it's pretty baked these days.

While I have your attention I'll also mention that we're working on an evolution of the NGEN/CrossGen format that alleviates a big chunk of the typical pain involved with typical ni files. That goes under then name ReadyToRun

Hope that helps. Let me know if you have other questions.

Disclosure: I work on the .NET Native runtime and compiler team for UWP (a sister project to CoreRT and LLILC etc)

Aphasic

Thanks for your attention, I definitely take look at these. -- Back to question above - the startup times for almost every path is 10-20s. And it's small project yet. – Intermingle

So I tried to use CrossGen. Found it somewhere in tenth folder level of nuget package cache. But now I realize I don't know how to use it since there is almost none documentation for that. When I run it on project it tells me that 'System.Private.CoreLib.dll' is missing. Could you please give me some basic instructions? I can open a new question. – Intermingle

In order to keep from leading you astray, I've contacted the dev folks that own crossgen. Hopefully one of them can get us sorted out. – Aphasic

Answer 2

There is a guide for using CrossGen at https://github.com/dotnet/coreclr/blob/master/Documentation/building/crossgen.md. It's a little out of date - I'll see if I can get it updated sometime. The most important part of using CrossGen is to specify the -Platform_Assemblies_Paths switch on the command line, to tell CrossGen the location of all the dependencies that it needs (e.g., System.Private.CoreLib.dll).

Hope that helps. Please let me know if you run into any further issues.

Griswold