v2.0 Discussion

Our team is actively working on the development of version 2.0. If you have any suggestions or discussions, please share your idea here. 🙌

I still believe that separating the project into multiple assemblies was a good call to make both for readability and scalability. However, I also realize that releasing multiple packages would not benefit the end user as much as I had hoped, and it might in fact be just cumbersome to deal with.

My suggestion would then be to keep the current project structure, but keeping the old release strategy of a single MiniExcel nuget package, at least until the multi-package idea evolves into a more mature, better defined one.

@izanhzh

@izanhzh would you like to share your opinion?

Releasing multiple NuGet packages is indeed a common practice among many open-source projects. By using Directory.Build.props to centrally manage versions, even if a package hasn't changed any code, it should still be version-bumped when other related packages are updated. Based on this understanding, here's my perspective:

Maintain the multi-assembly structure - Each assembly should be an independent NuGet package
Preserve backward compatibility - Keep one assembly with the same name as the previous version that contains all functionality. This "all-in-one" package would depend on the other split packages, making it easy for users who need complete functionality to simply use this familiarly-named package
Enable selective usage - For users like myself who only need specific features (e.g., Excel without CSV), we can simply reference the dedicated Excel NuGet package

This approach gives users the flexibility to choose between the full-featured package for convenience or individual packages for a lighter footprint, while maintaining the architectural benefits of separation.

graph TD
    MiniExcel --> MiniExcel.OpenXml
    MiniExcel --> MiniExcel.Csv
    MiniExcel.OpenXml --> MiniExcel.Core
    MiniExcel.Csv --> MiniExcel.Core

@izanhzh

@izanhzh All of that makes sense and that's why I suggested the multiple packages strategy in the first place. The reason why I started second guessing myself is that the OpenXml functionality is not separated from the Core functionality, and effectively this is what the dependecies actually look like now:

graph TD
    MiniExcel --> MiniExcel.Core
    MiniExcel --> MiniExcel.Csv
    MiniExcel.Csv --> MiniExcel.Core

I think this still needs some thinking about in terms of how to properly structure everything, For example the Core module could contain all the abstractions other than the inaccessible mapping methods, some of which we could expose to let users create their own additional modules. Point is, I support the multiple packages strategy but I also believe it needs a bit more maturity.

Again, my suggestion is making a single preview package release for now, start receiving some feedback for all the changes we've already made, and then keep working on the separation of the assemblies in a way that makes the multiple packages strategy more worthwhile for the end user.

We'll release new NuGet preview package tomorrow, please feel free to feedback 🐱‍🏍

I'm not very familiar with the process of creating packages but I've read that it can be tricky to create a single package from multiple assemblies, we should make sure there are no problems with that. We should also release a new 1.x version since we've made a couple bugfixes there as well.

I uploaded new NuGet preview package, please feel free to check 🐱‍👓

Looks like it's working well!

@shps951023

@shps951023 I just noticed you removed the net10.0 target framework, did you find issues with it?

@michelebastione

@michelebastione because .net 10 is on-preview version now, did we need .net 10 new functions?

Yes, this was discussed in #825. It's not a big deal though, we're gonna get .NET 10 RC 1 later this month anyways, we can add it back for the next preview version after we merge #850.

@michelebastione

@michelebastione 🙌 got it, I will add it back.

Hi, congratulation on releasing the first preview version on NuGet. I took the liberty to fiddle with it a little. I had hoped that the new async implementation would allow me to parse Excel files in the browser. However, I run into this issue:

Error: System.NotSupportedException: Specified method is not supported.
   at Microsoft.AspNetCore.Components.Forms.BrowserFileStream.Seek(Int64 offset, SeekOrigin origin)
   at MiniExcelLib.Core.Helpers.ThrowHelper.ThrowIfInvalidOpenXml(Stream stream)

Which was generated by simply importing a file in a Blazor WASM app and running

documentStream.QueryAsync<T>(excelType: ExcelType.XLSX);

I am assuming that that MiniExcel does rely on Stream.Seek a lot, but in the offchance it does not, I am hereby expressing my wish for Blazor WASM support in v2.0.

PS. Good to note that the upgrade process to v2.0 was almost seamless, I had to remove a few lines in my wrapper class because the new implementation already returns an IAsyncEnumerable

@RiRiSharp

@RiRiSharp It was a necessity for the input stream to be seekable in previous versions, but that may not be necessary anymore with our new API, at least for queries. I'll look into it.

@RiRiSharp

@RiRiSharp this is a very simple proof of concept that currently works (given the appropriate file in input). Does it satisfy your use case?

@using MiniExcelLib.Core 

@page "/" 


<InputFile OnChange="@FileSelected" />

@foreach (var user in _users)
{
    <div @key="@user" class="my-3">
        <div>Name: @user.Name</div>
        <div>Points: @user.Points</div>
    </div>
}


@code{
    private List<User> _users = []; 

    private async Task FileSelected(InputFileChangeEventArgs e)
    {
        using var ms = new MemoryStream();
        using var fs = e.File.OpenReadStream();

        await fs.CopyToAsync(ms);
        ms.Seek(0, SeekOrigin.Begin);

        var importer = MiniExcel.Importers.GetOpenXmlImporter();
        _users = importer.Query<User>(ms).ToList();
    }


    class User
    {
        public string Name { get; set; }
        public decimal Points { get; set; }
    }
}

@michelebastione

Hey @michelebastione, thanks for your reply! I have tested your code and also found a way to make it work in v1 (listed below). So yes, this works for my use case!
From a tech-loving perspective it's a bit of a pity we loose the full fledged streaming capabilities, so parsing files >1GB in the browser wouldn't work using this approach. But that is not my use case, if I can find the time I might try to find a fix for this then. During testing I also found another small issue, but I will open a seperate issue for that.

private async Task FileSelected(InputFileChangeEventArgs e)
{
    using var ms = new MemoryStream();
    using var fs = e.File.OpenReadStream();

    await fs.CopyToAsync(ms);
    ms.Seek(0, SeekOrigin.Begin);

    var items = ms.Query<T>().ToList();
}

Navigation Menu

Repository navigation

v2.0 Discussion #859

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

v2.0 Discussion #859

Description

Activity

michelebastione commented on Aug 25, 2025

michelebastione commented on Aug 27, 2025

izanhzh commented on Aug 28, 2025

michelebastione commented on Aug 29, 2025

shps951023 commented on Aug 30, 2025

michelebastione commented on Aug 30, 2025

shps951023 commented on Aug 31, 2025

michelebastione commented on Aug 31, 2025

michelebastione commented on Sep 1, 2025

shps951023 commented on Sep 1, 2025

michelebastione commented on Sep 1, 2025

shps951023 commented on Sep 1, 2025

RiRiSharp commented on Sep 4, 2025

michelebastione commented on Sep 4, 2025

michelebastione commented on Sep 5, 2025

RiRiSharp commented on Sep 6, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions