You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS: Debian 11 running on i.MX8 (aarch64 processor)
.NET version: net8.0
Docker version: latest
Microsoft SEAL version: 4.1.1
Issue Description
I am encountering a FileNotFoundException when attempting to run a dockerized .NET application that utilizes the Microsoft SEAL library. This issue is occurring specifically on an i.MX8 device running Debian 11, and I'm constrained to this OS for various reasons.
The exact error message is as follows:
** Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'SEALNet, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. **
This error is thrown immediately when attempting to run the application with Dockerfile, the csproj file has the correct Microsoft.Reasearch.SEALNet package. It works for dockerized application in an ubuntu22.04 machine, not for imx8 debian11 dockerized application.
Reproduction Steps
Dockerize the .NET application with Microsoft SEAL as a dependency.
Deploy and run the Docker container on Debian 11 (i.MX8).
Observe the FileNotFoundException upon executing dotnet publish -c Debug -o out.
Dockerfile :
# Use the official .NET 8.0 SDK image as the build environment
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
# Install necessary dependencies for Rust
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
ca-certificates \
wget \
software-properties-common \
apt-transport-https \
build-essential \
curl \
pkg-config \
libssl-dev \
cmake \
g++ \
net-tools \
# Clean up
&& rm -rf /var/lib/apt/lists/*
# Copy the .NET installation script and execute it
WORKDIR /scripts
COPY scripts/dotnet/install-dotnet.sh .
RUN chmod +x ./install-dotnet.sh \
&& ./install-dotnet.sh \
&& rm ./install-dotnet.sh
ENV PATH="/root/.nvm/versions/node/v16.20.2/bin:/root/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/root/.dotnet"
# Set the working directory and copy the application source code
WORKDIR /fhe_demo
COPY . .
# Restore .NET dependencies and publish the application
WORKDIR /fhe_demo
RUN dotnet restore
RUN dotnet publish -c Debug -o out
# Switch to the runtime image
FROM mcr.microsoft.com/dotnet/aspnet:8.0
# Set the working directory
WORKDIR /fhe_demo
# Copy the published output from the build image
COPY --from=build /fhe_demo/out .
# Expose the port on which the application will communicate
EXPOSE 10003
# Define the entry point to run the application
ENTRYPOINT ["dotnet", "PruebaFhe.dll"]
Any insights or suggestions on how to resolve this would be greatly appreciated.
The text was updated successfully, but these errors were encountered:
I know this is a late answer, but I stumbled upon the same issue on my Apple Silicon Macs and any ARM-based Docker images, it seems like the issue is present on ARM instruction set systems. So maybe this answer can help someone who is running into the same issue.
One solution for Apple Silicon is to run the app dockerised with an amd64 build, thanks to the x86/ARM translation layer macOS provides (i.e the mcr.microsoft.com/dotnet/aspnet:8.0-bookworm-slim-amd64 image). This does have a pretty substantial performance impact but it does work.
If that is not an option (i.e. on the i.MX8 processor mentioned here?) I managed to get it working locally by following the building SEAL instructions in the README.md and making some minor adjustments.
First you need to make sure to build the SEAL_C wrapper library for C# by running the following commands:
Now that the build folder contains the shared library and the C# .csproj files we have to edit some of the .csproj and .nuspec files to target ARM systems instead of x86 ones and update the targeted .NET framework for good measure:
Next you can run the Building .NET Components instructions as usual:
dotnet build build/dotnet/src --configuration Release && \
dotnet test build/dotnet/tests;
Make sure that everything runs and no FileNotFoundException occurs.
Now the built SEALNet.dll is ready to be used in your project, sadly I haven't found a way to get dotnet pack working so I can simply dotnet add package SEALNet the resulting .nupkg file yet. So the current workaround I use is to take inspiration from the example project and simply add the following to my projects .csproj file:
<TargetName="PostBuild"AfterTargets="PostBuildEvent">
<Copy
SourceFiles="<Path to SEAL>/SEAL/build/lib/<Matching lib file>"
DestinationFolder="$(TargetDir)"
/>
</Target>
This did the trick for me, I haven't tested this on Linux but it does work on Apple Silicon running macOS. I know it is a bit hacky but I don't have the C# and Nuget expertise to make SEAL build and package for ARM systems as well as x86 ones. But I hope this can provide some guidance to people running into the same issue to devise a better way to fix this issue.
Environment
Issue Description
I am encountering a
FileNotFoundException
when attempting to run a dockerized .NET application that utilizes the Microsoft SEAL library. This issue is occurring specifically on an i.MX8 device running Debian 11, and I'm constrained to this OS for various reasons.The exact error message is as follows:
** Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'SEALNet, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. **
This error is thrown immediately when attempting to run the application with Dockerfile, the csproj file has the correct Microsoft.Reasearch.SEALNet package. It works for dockerized application in an ubuntu22.04 machine, not for imx8 debian11 dockerized application.
Reproduction Steps
FileNotFoundException
upon executingdotnet publish -c Debug -o out
.Dockerfile :
Any insights or suggestions on how to resolve this would be greatly appreciated.
The text was updated successfully, but these errors were encountered: