Building .NET apps from source, including their (build) dependencies.

[tmds]

If you want to add a .NET app into a distro's package repository, you are faced with a daunting task.

Distro repositories require all binaries that are distributed, and needed to built the app, to be built from source.
That means the app needs to be built without using NuGet packages since those have prebuilt binaries.
Instead of using NuGet packages, you needs to build the NuGet packages again from source, so they can be consumed by your build.

To facilitate the maintainer, it would be nice if the tooling could support this use-case.
For example, distros do this by having source packages which include everything needed to build a package from source.

I understand this is not a major use-case for .NET apps, and the effort for this would be high.
I'm creating this issue to raise awareness.

cc @omajid @musuruan @richlander

[omajid]

cc @dotnet/distro-maintainers

[asbjornu]

Just thinking out loud without much preprocessing here: Could NuGet itself be extended to resolve this issue? NuGet already supports symbol packages (which contain at least some form of the source code) – could it perhaps be extended to support source packages as well? That would benefit the entire .NET ecosystem and not just those few of us that maintain distributions of the .NET SDK or runtime.

[richlander]

I like the scenario. I'm not sure how to solve it.

We've had similar discussions, for secure-supply-chain scenarios. We wanted to determine if we could rebuild NuGet packages using sourcelink information (in the PDB). So far, we've concluded that this angle doesn't work.

A much more direct angle would be enabling a first-class transformation from PackageReference to ProjectReference. There is a lot of hand-waving there. To enable that, we'd have to document some standard toolchain requirements that projects would need to conform to. This, too, would probably be based on sourcelink but be much more formal.

@mhutch @tmat

[omajid]

As a concrete example, @hickford is looking to add git-credential-manager to Fedora and is stuck: git-ecosystem/git-credential-manager#816

[omajid]

There's a related issue about documenting our solution (when we have one) at dotnet/docs#17757

[omajid]

I got some community feedback that another set of libraries/applications that might be a good idea to package would be AvaloniaUI and Jellyfin. Jellyfin is even available via rpmfusion (https://pkgs.rpmfusion.org/cgit/free/jellyfin.git/tree), but can't be added to Fedora proper due to the offline build restrictions.

[danzuep]

It seems that currently dotnet cannot be built offline as prep.sh downloads a pre-built CLI from AzureEdge. Does this mean that dotnet isn't really FOSS? See also: #3465 and #2960

[richlander]

My understanding is that prep.sh exist so that you can copy it and then pull those assets to an offline environment and then build offline.

The C# compiler is written in C# so it requires an existing C# compiler to build. This is a common characteristic with compilers. In addition, it isn't possible to build .NET 8 with .NET 6 or 7. We make lots of breaking changes each release that breaks our old build system. A big part of that is that we use new .NET 8 feature in the .NET 8 source code, which prevents the .NET 6 compiler from compiling the code.

That all means you need binaries to build the code. A C++ compiler on its own is not sufficient. The source build scripts provide the MS-built SDK. We know it works and the distros we work with have been OK with that.

It is fully OK if people want to work on an alternate script and process that uses the RHEL, Ubuntu, or other distro build of .NET as part of source-build. Certainly, that will involve pulling packages over the network.

I read the four essential freedoms and the rest of the page you linked to. It isn't clear to me where .NET is violating FOSS in spirit or name.

[tmds]

As @richlander explained, .NET needs some binaries to build.
If you don't have previously built those from source ./prep.sh gets them for you.
The output of a ./build.sh will include these binaries re-built from source.
Successive builds start with binaries that were all built from source.

Does this mean that dotnet isn't really FOSS?

This process enables .NET to meet the requirements distros set for software to be included in distro packages.
These guidelines are written up to provide a user with FOSS software.
This means that what gets distributed through distros can be considered FOSS.

Some parts of .NET are under restrictive licenses and are not FOSS, like the vsdbg debugger component.
There are some projects that try to compensate like https://github.com/Samsung/netcoredbg.
I think lack of these components cause .NET to not be FOSS when looking from the "development platform" perspective.

This specific issue is about enabling/facilitating to build .NET apps using a .NET distro SDK so they meet the (FOSS) requirements to be included in the distro.