Launching .Net 7 binaries seems is broken

snapcraft
1

Hi guys.

I’m stuck with being not able to launch .Net 7 binaries in snap and think that they are most probably broken.

I’ll tried lots of possible combinations and none of them are working. So I’ll briefly describe them here. Hope over time everything will work.

1. Building with dotnet-sdk and bundling with dotnet-runtime as staging is not possible (breaks compilation). Ppl have to bundle with snap entire SDK.

    build-packages:
      - dotnet-sdk-7.0
    stage-packages:
      - dotnet-runtime-7.0

Results in impossibility to build project. That’s why I have to include entire dotnet-sdk for users to be able to launch it which is not great.

This is my workaround so far

    build-packages:
      - dotnet-sdk-7.0
    stage-packages:
      - dotnet-sdk-7.0 #used instead of dotnet-runtime-7.0 because snapcraft fails to build.

As an idea for improvement I hope in the future it will be possible for dotnet to have runtime snap which will reduce snap size from 320MB to something more smaller.

2. dotnet-sdk-70 snap is useless.

If to have configuration like this

    build-snap:
      - dotnet-sdk-70

it will be not possible to build. Probably it should be excluded from snapcraft.io store to avoid confusion for usage. SDK snap in store that is not invokable for build of snap distracts attention to it and people have to spend time on it before realizing that it won’t work.

3. Snap for .Net Runtime is useless

If to have configuration like this

    stage-snap:
      - dotnet-runtime-70

and next command variations:

apps:
  app:
     command: app.dll # error: dotnet runtime is not installed
     command: dotnet app.dll # error: dotnet is not found.
     command: dotnet ./app.dll # error: dotnet is not found.
     command: /snap/dotnet-runtime-70/current/dotnet ./app.dll # error: current is not resolved, but inside file system it exists.
     command: dotnet-runtime-70.dotnet ./app.dll # snaps have aliases but still they are not supported inside snap

will not work.

Since I wasted lots of time on this, I really don’t understand the reason of having dotnet-runtime-70 in a store since consumer of this snap - other snap can request it to be in a system, but not being able to use it. It distracts atttention from other variants. And people have to spend time on it before moving to next variants.

4. Commands do not support spaces

apps:
  app:
    command: usr/bin/dotnet ./app.dll
    plugs:
      - desktop

parts:
  app:
    plugin: dotnet
    dotnet-build-configuration: Release
    source: ./sources
    build-packages:
      - dotnet-sdk-7.0
    stage-packages:
      - dotnet-sdk-7.0 #used instead of dotnet-runtime-7.0 because snapcraft fails to build.

Bundles successfully. But after installation during execution command

usr/bin/dotnet ./app.dll

is converted to

dotnet-./app.dll

Folders are missing, spaces are trimmed. Command fails to execute.

So basically i haven’t found proper way to launch .Net app in snaps.

2

I finally managed to make executable runnable.

That’s the solution.

base: core22

confinement: classic
compression: lzo

apps:
  ui:
    command: bin/app
    plugs:
      - desktop

parts:
  app:
    plugin: dotnet
    dotnet-build-configuration: Release
    source: ./sources
    build-packages:
      - dotnet-sdk-7.0
    override-build: |     
      dotnet publish /p:Version=$SNAPCRAFT_PROJECT_VERSION /p:AssemblyVersion=$SNAPCRAFT_PROJECT_VERSION -r linux-x64 -c Release --self-contained true -o $SNAPCRAFT_PART_INSTALL/bin/
      chmod 0755 $SNAPCRAFT_PART_INSTALL/bin/app

lint:
  ignore:
    - classic 
    - library

As a result you can run app via snap:name.ui .

Basically,

  1. dotnet plugin should build project with –self-contained true . Otherwise it will be impossible to launch executable.
  2. dotnet plugin should find executables and make them executables from csproj files which is easy. When those 2 steps will happen in future there will be no more need to override build.
  3. dotnet plugin should have documentation with hello world UI and console program, from which apps should be able to start with published on github, so i can download it as archive and use it, i.e. boilerplate.

This itself would save 2 days of work.

1 Like
3

I already shared this information with you in another discussion, but for other readers:

We have a tutorial that shows step-by-step how to package a .NET demo application.
(Note: In the tutorial we also build the application self-contained.)

Thanks that you documented all your different approaches! We are aware of the bad UX when trying to package .NET applications with snapcraft (especially with the dotnet plugin) and we are working on improving it.

2 Likes