How are production images/tarballs created?

[pauldotknopf]

This project currently only supports Linux ATM, so what about Windows and OSX? You guys must build product-ready images via some other method, yeah?

If so, what is that method? Individual CI for each project (netstandard,coreclr,corefx,core-setup,sdk,websdk,cli,etc) with NuGet outputs for each?

Let's say I want to produce a Linux build using the exact method used for production. Where do I look/begin?

[crummel]

Yes, each individual project has its own build and NuGet feeds are used to move packages between them. Projects generally have this build configuration checked in, either as JSON (e.g. CoreFX) or YAML (e.g. CliCommandLineParser). You can follow along with the steps in the builds but you won't be able to get exactly the same builds due to signing, build numbers, or other variables filled in by the build system. It will also be more difficult to use your bits all the way through the stack instead of pulling official packages from NuGet - that's part of what source-build handles for you.

[pauldotknopf]

I would go through the 10-15 repos and build Yocto recipes for each one, but I fear that once I get it done, it will impossible for me to keep it up to date, especially considering the build.sh in each repo is so different.

I'm just throwing this out there. I'd recommend a Yocto build CI to each of your repos. I'd love to contribute the initial recipe for each project.

I fear that otherwise, we'd never be able to get a working Yocto build/sdk that can be maintained by the community alone.

[dagood]

The 2.1 and 2.2 Microsoft builds have some more going on behind the scenes, too. The "Product Construction" (ProdCon) infrastructure orchestrates all the repos to build all at once and point to each other's outputs. ProdCon actually shares some implementation details with Source-Build, like the format for overriding package versions (Package Version Props). You can see the results of ProdCon builds here in the readmes: https://github.com/dotnet/versions/tree/master/build-info/dotnet/product/cli/release.

I wouldn't consider ProdCon realistic to try to replicate. The biggest reasons IMO are that many machines of various OSes and configurations are required, and build/CI definitions aren't available publicly everywhere.

Source-Build is the way to build all the repos on a single machine. We have a long-standing desire to make Microsoft builds as similar as possible to Source-Build as we can get them--we're pretty far away from that, but hope to improve (especially with the work on vNext).

[pauldotknopf]

Source-Build is the way to build all the repos on a single machine.

Unfortunately, it doesn't handle cross compilation at the moment (#324).

I managed to add some patches to make it work, but it in the v2.1.401 tag of source-build, the core-setup project was referencing different versions of coreclr/corefx that were built locally, causing NuGet packages to be retrieved from some public NuGet feed. I'm not entirely sure/certain that this is happening with any other package as well.

Correct me if I'm wrong, but I think I should not be trying to use this repo ATM to build a cross-build SDK (even with the patches). It seems as if there are many parts still in the air.

[wfurt]

I agree with @dagood . I was facing similar problem with getting FreeBSD build working.
Relations between individual components are complicated and they do change.
I think that would be maintenance nightmare.
I would suggest to create single recipe for runtime. Solving cross-compilation is easier problem IMHO and I can probably help. I did some prototyping on Yocto while back for ARM and x86. (AARM64 TBD)

[pauldotknopf]

The cross-compilation of the coreclr/corefx/core-setup is something that I can easily manage as well. It is the the wrapping sdk/cli/etc repos that becomes problematic.

The only way (IMO) to truly get this working is for Microsoft to take on the burden of adding some recipes into their CLI (one for each of the dotnet/* projects). This could easily testable with a docker image.

My main drive at the moment to get a locally compiled runtime is mainly because of lttng-ust not working (https://github.com/dotnet/core-setup/issues/4484). The issue is fairly difficult to debug as well because I can't get a working SDK inside of the Yocto image :(

[dagood]

Correct me if I'm wrong, but I think I should not be trying to use this repo ATM to build a cross-build SDK (even with the patches). It seems as if there are many parts still in the air.

My view is that it might not be reasonable to use source-build for this, but I also don't really see a better way. I'm not actually sure what the right place is to propose/discuss adding CI for a new platform product-wide. Maybe https://github.com/dotnet/core?

If we can get Yocto working (#655 I think tracks that pretty specifically), then vNext is bringing some improvements that could make Source-Build part of each repo's CI. I suspect Yocto can be part of that testing matrix if we get it working in Source-Build. (This is generally doc'd at dotnet/arcade Maestro.md, where Source-Build is a part of the "product build" mentioned.)

I'm closing this because the original question is answered, and getting Source-Build working with Yocto seems tracked more specifically in #655 and #699. Let me know if you disagree.

[wfurt]

You can try instructions from @pauldotknopf https://github.com/dotnet/core/blob/master/samples/YoctoInstructions.md
It would be interesting to know if we regress and broke something.

I don't know if that would help but you can try:
export DOTNET_CLI_TELEMETRY_OPTOUT=1

I only have Raspbian running on ARM so it is difficult for me to help more unless you can reproduce it in VM under QEMU.

[pauldotknopf]

@wfurt,

Currently, lttng-ust must be completely removed from the image. The coreclr links against it, but it fails nicely if it can't load the event provider dll. With lttng-ust in the image, there is a hang when executing any dotnet command that invokes the clr. See this for more info: https://github.com/dotnet/core-setup/issues/4484

I know this issue is closed, but I want to bring something else up.

I really only need to cross compile core-setup/coreclr/corefx. As far as I know, these are the only projects that contain unmanaged code, the rest is pure IL.

With that said, is there a way to just build the dotnet/cli project with production versions of, say, 2.1.401? If I can get custom nupkg's for corefx/coreclr/core-setup that are production versions, I can override the NuGet feed during the build of dotnet/cli to use my local packages instead of the coreclr/corefx/core-setup from public feeds.

I feel this would be MUCH more manageable.

Thoughts?

[pauldotknopf]

To add to my previous comment, let's assume that I can build a Microsoft.NETCore.App that contains my cross-compiled libs with an exact/released version of, say, 2.1.3.

[wfurt]

You should try the self-contained app as documentation suggests. That would give some clues.

The rest is not that simple even if managed code. That would get you on unsupported path.
What you suggesting is possible but high maintenance cost and high risk.