Excel.Demo.zip (2.4 MB)
使用Aspose创建workbook对象时，发现主动调用Dispose代码无法释放内存，通过dotMemory分析，发现创建了很多Unmanaged Memroy，如pic1.png；
demo代码已上传，请确认是否是BUG，如果是请修复，如果需要我们做什么额外处理，请告知。
pic1.png (29.0 KB)
用dotMemory跟踪demo代码的内存，发现几乎都是Unmanaged Memroy，如pic2.png；
pic2.png (26.2 KB)
– 追加描述–
我在wb.Dispose()这行代码后主动增加GC.Collect()，发现内存也无变化。
在系统运行过程中，发现内存久居不下，dotMemory分析发现，有很多Unmanaged Memroy，哪怕系统代码中主动调用GC.Collect()，内存也没有下降，导致一旦多读几次Excel（生成workbook对象）后，内存就会变高，这个问题比较严重，请帮忙排查。
我认为这不是 API 的问题，而是由于以下代码行所致：
Console.ReadLine();
当您从 steam 中阅读工作簿时，上面的行将导致该过程继续进行。 请删除此行，您会发现非托管内存问题不会发生。 此外，这一行与 Aspose.Cells.Workbook 对象模型无关。
供您参考，Aspose.Cells for .NET 不一定需要释放进程的资源，因为该组件已经经过优化，可以自动执行此操作。 Aspose.Cells 是在托管 C# 中创建的，我们不使用任何非托管代码。 当对象（例如Workbook或其他相关元素）在进程中不再有用时，GC将收集并释放对象占用的内存。 作为一个纯 .NET 组件，Aspose.Cells for .NET 依赖 .NET 垃圾收集器 (GC) 为不同进程分配和释放内存，尽管您也可以尝试使用 GC.Collect() 或尝试使用 Workbook。 在某些情况下，Dispose() 并相应地将 Workbook 设置为 null。 此外，如果您正在使用Stream对象，当不再使用该对象时，您可以关闭它以手动释放该对象的资源。
Aspose.Cells 通常是纯 .NET 组件，依赖垃圾收集器（GC）来释放内存。 当您将对象设置为 null/nothing、调用 Dispose 或使用 GC.Collect() 时，GC 不会释放内存。 它只在它认为合适的时候释放内存，有时，内存回收不仅由GC处理，还由内部进程处理。