ZipArchive is not functioning in Blazor WebAssembly when using System.IO.Compression.ZipArchive and SkiaSharp v3.118.0-preview.1.2 in .NET 9.0.

[pandi123]

Description

We are experiencing an issue with the System.IO.Compression.ZipArchive and SkiaSharp package v3.118.0-preview.1.2 in our Blazor WebAssembly .NET 9.0 project. The problem began after we added the following line in our .csproj file:

This issue does not occur when using the SkiaSharp package v2.88.8 or checking .NET 8.0 working fine. I have attached a sample project and a screenshot of the issue for your reference.

Platform: Blazor wasm
Visual Studio version: 2022
.NET version : .NET9
SkiaSharp version : v3.118.0-preview.1.2

Code

@page "/"
@using System.IO.Compression;
@using System.Xml.Linq;
@inject IJSRuntime JS;


<button @onclick="ZipArchive">Download ZIP</button>


@code {
    public async void ZipArchive()
    {
        using (MemoryStream zipStream = new MemoryStream())
        {
            using (ZipArchive archive = new ZipArchive(zipStream, ZipArchiveMode.Create, true))
            {
                ZipArchiveEntry entry = archive.CreateEntry("Sample.xml");
                using (Stream entryStream = entry.Open())
                {
                    XDocument xmlDocument = new XDocument(
                        new XElement("Root",
                            new XElement("Child", "Content")
                        )
                    );
                    xmlDocument.Save(entryStream);
                }
            }
            zipStream.Position = 0;
            await JS.InvokeVoidAsync("downloadFileFromByteArray", "SampleArchive.zip", zipStream.ToArray());
        }
    }
}

Expected Behavior

The program should run without any exceptions in blazor wasm while using System.IO.Compression.ZipArchive and SkiaSharp package v3.118.0-preview.1.2

Actual Behavior

Aborted(Assertion failed: native function stackRestore called after runtime exit (use NO_EXIT_RUNTIME to keep it alive after main() exits))
The thread '.NET TP Worker' (33996) has exited with code 0 (0x0).
The thread '.NET TP Worker' (42984) has exited with code 0 (0x0).
Uncaught RuntimeError RuntimeError: unreachable
at $__trap (wasm/022f640e.wat:3678318:1)
at ___trap (localhost꞉7023/_framework/dotnet.native.krq9w4nbeb.js:11275:54)
at abort (localhost꞉7023/_framework/dotnet.native.krq9w4nbeb.js:775:5)
at assert (localhost꞉7023/_framework/dotnet.native.krq9w4nbeb.js:468:5)
at (localhost꞉7023/_framework/dotnet.native.krq9w4nbeb.js:808:5)
at (d:\Net9\ZipArchive3.118.0-preview.1.2\ZipArchive3.118.0-preview.1.2\wwwroot_framework\https:\raw.githubusercontent.com\dotnet\runtime\9d5a6a9aa463d6d10b0b0ba6d5982cc82f363dc3\src\mono\browser\runtime\invoke-cs.ts:328:20)
at beginInvokeDotNetFromJS (localhost꞉7023/_framework/blazor.webassembly.js:1:43656)
at invokeDotNetMethodAsync (localhost꞉7023/_framework/blazor.webassembly.js:1:3978)
at invokeMethodAsync (localhost꞉7023/_framework/blazor.webassembly.js:1:5486)
at (localhost꞉7023/_framework/blazor.webassembly.js:1:13036)
at R (localhost꞉7023/_framework/blazor.webassembly.js:1:13214)
at (localhost꞉7023/_framework/blazor.webassembly.js:1:52854)
at invokeWhenHeapUnlocked (localhost꞉7023/_framework/blazor.webassembly.js:1:44875)
at (localhost꞉7023/_framework/blazor.webassembly.js:1:52817)
at R (localhost꞉7023/_framework/blazor.webassembly.js:1:52844)
at I (localhost꞉7023/_framework/blazor.webassembly.js:1:13005)
at dispatchGlobalEventToAllElements (localhost꞉7023/_framework/blazor.webassembly.js:1:15626)
at onGlobalEvent (localhost꞉7023/_framework/blazor.webassembly.js:1:14835)

Version of SkiaSharp

3.118.0-preview.1 (Next Preview)

Last Known Good Version of SkiaSharp

2.88.8 (Previous)

IDE / Editor

Visual Studio (Windows)

Platform / Operating System

Windows

Platform / Operating System Version

Window11

Devices

Visual studio v2022

Issue reproducing sample

ZipArchive3.118.0-preview.1.2.zip

Working sample

ZipArchive 2.88.8.zip

Relevant Screenshots

No response

Relevant Log Output

Code of Conduct

• I agree to follow this project's Code of Conduct

[mattleibow]

This may be fixed with #3064

Can you try the nightly on the preview feed: 3.118.0-nightly.27

https://aka.ms/skiasharp-eap/index.json

Let me know if this fixes it and I will push out the 3.x release.

[dotnet-policy-service]

Hi @pandi123. We have added the status/needs-info label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[mattleibow]

The stable 2.x packages should now have the correct WASM binaries for .NET 9. The new version number to use is 3.1.56.

Note: I probably won't be able to backport the changes to make installing the WebAssembly package automatically include the binaries, so if you still need to use 2.x for some reason, you will need the manual include that you have shown.

With .NET 9, there is a bug in the runtime sou you will also have to temporarily include this workaround in your app csproj:

  <!-- Workaround for https://github.com/dotnet/runtime/issues/109289 -->
  <Target Name="RuntimeIssue109289_Workaround"
          AfterTargets="_BrowserWasmWriteRspForLinking">
    <ItemGroup>
      <_WasmLinkStepArgs Remove="@(_EmccLinkStepArgs)" />
      <_EmccLinkStepArgs Remove="&quot;%(_WasmNativeFileForLinking.Identity)&quot;" />
      <_WasmLinkDependencies Remove="@(_WasmNativeFileForLinking)" />

      <_SkiaSharpToReorder Include="@(_WasmNativeFileForLinking)" Condition="$([System.String]::Copy('%(FullPath)').Contains('libSkiaSharp.a'))" />
      <_WasmNativeFileForLinking Remove="@(_SkiaSharpToReorder)" />
      <_WasmNativeFileForLinking Include="@(_SkiaSharpToReorder)" />

      <_EmccLinkStepArgs Include="&quot;%(_WasmNativeFileForLinking.Identity)&quot;" />
      <_WasmLinkDependencies Include="@(_WasmNativeFileForLinking)" />
      <_WasmLinkStepArgs Include="@(_EmccLinkStepArgs)" />
    </ItemGroup>
  </Target>

I am not sure when the real fix will appear in .NET 9, but this also is going to be difficult to backport. The latest 3.x series will have this fix.

So hopefully, once my PR #3082 is merged then you will not need the manual include of the .a file and the app should run without workarounds. If you install the SkiaSharp.Views.Blazor nightly nuget now, it should work today. The final PR is just moving the fix lower down the dependencies.

I was hoping to make 3.x stable last week, but I was not able to get to it.

[dotnet-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.