Dotnet plugin - runtime vs SDK

snapcraft
1

Hello

I feel there’s something off with the way the dotnet plugin is expected to operate.

In the current plugin, the SDK gets pulled so that the app can get built (and ran) when creating the snap, but the SDK is not available on some platforms such as armhf.

A solution for that is to build the app on a platform which does support the SDK, and target linux-arm, zip the binaries and use those, together with another part which includes the runtime.

I don’t mind doing that, but it implies that build.snapcraft.io can’t be used to build an armhf snap from source, which is what all other plugins can do, and is the strength of snaps.

For that, perhaps we can modify the dotnet plugin to indicate to only pull a runtime, and where the binaries are expected to already exist, and additional checks can happen based on that?

Original PR for plugin on Github: https://github.com/snapcore/snapcraft/pull/1574 but it doesn’t discuss this issue.

1 Like
2

If you already have everything built, why not just use the dump plugin for those prebuilts and maybe the correpsonding runtime if it is not part of those prebuilts?

3

Also take into account that plugs and slots for dotnet runtimes are in progress. Where you wouldn’t need to bundle the runtime. We are just waiting for auto downloading of the default slot provider for a smooth experience.

4

That’s exactly what I’m doing right now, and works.

It would indeed be solved if the runtime could be supplied for the users of the snap with a plug, since then there’s a clear distinction between the runtime, and the sdk that builds the app.