System.IO.IOException: Stream was too long error on .NET Core 2.0 application

[LarinLive]

In .NET Core 2 console application (ConsoleApp1.zip) writing a large Excel file stops with the following error:
System.IO.IOException: Stream was too long.
at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.Compression.WrappedStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.Xml.XmlUtf8RawTextWriter.FlushBuffer()
at System.Xml.XmlUtf8RawTextWriter.WriteAttributeTextBlock(Char* pSrc, Char* pSrcEnd)
at System.Xml.XmlUtf8RawTextWriter.WriteString(String text)
at System.Xml.XmlWellFormedWriter.WriteString(String text)
at DocumentFormat.OpenXml.OpenXmlElement.WriteAttributesTo(XmlWriter xmlWriter)
at DocumentFormat.OpenXml.OpenXmlElement.WriteTo(XmlWriter xmlWriter)
at DocumentFormat.OpenXml.OpenXmlPartWriter.WriteElement(OpenXmlElement elementObject)
at ConsoleApp1.Program.WriteRandomValuesSAX(String fileName, String sheetName) in C:\Users\anton\Documents\Visual Studio 2017\Projects\ConsoleApplication2\ConsoleApp1\Program.cs:line 80
at ConsoleApp1.Program.Main(String[] args) in C:\Users\anton\Documents\Visual Studio 2017\Projects\ConsoleApplication2\ConsoleApp1\Program.cs:line 105

The application workset grew up to 4 GiB. But there is a x64 application, so the process memory is not limited by 4 GiB.

Meanwhile in .NET FW4.7 the same application (ConsoleApp2.zip) works perfectly with 10 MB workset size.

[twsouthwick]

There appears to be a memory leak here in the .NET Standard version of the library.

[twsouthwick]

I was able to repro this issue outside of the DocumentFormat.OpenXML SDK using just the BCL. I've logged an issue at dotnet/corefx to see what the issue is.

[tarunchopra]

Thanks @twsouthwick; appreciate your help.

[github-actions]

Stale issue message

[BNarayanSharma]

Is there any update on when it will be fixed? Due to this issue, my .NET Core Migration for a few projects has been on hold for the last two years.

I need to generate a large excel file, and it throws the exception "Stream was too long"

I have tried with .NET Core 7.0 as well and still failing. I do not understand why it has been marked as fixed.
If I run with .NET Framework 4.x.x it works perfectly fine but always fails with .NET Core 3.1, .NET 5, .NET 6 & .NET 7

[martinokello]

I am still finding the problem with .net core 3.1. I am afraid I am using a memory stream which I write to and add it to an attachment. As an attachment is reading from stream, the best bet is using a memory stream, and I can't dispose enclosing it with using statement, as I am assuming that the attachment will need to use it even though it goes out of my scope.

This is a terribly confusing thing as I don't want to write the file to disk then open a filestream and attach it to the Attachments collection. I think there is something annoying with this implementation. I am not comfortable with this.

/////////////////////////////////////////////////Code that attaches memory Stream to Attachements collection///////////////////////
var memoryStream = new MemoryStream();
ReadFileAttachment(attachment, memoryStream);
memoryStream.Seek(0, SeekOrigin.Begin);
var attached = new Attachment(memoryStream, attachment.FileName);
mailMessage.Attachments.Add(attached);

//////////////////////////////////////// ReadFileAttachment(attachment, memoryStream) method///////////////////////////////////

    private MemoryStream ReadFileAttachment(IFormFile attacment, MemoryStream memoryStream)
    {
        var bytes = new byte[4096];
        var bytesRead = 0;
        while ((bytesRead = attacment.OpenReadStream().Read(bytes, 0, bytes.Length)) > 0)
        {
            memoryStream.Write(bytes, 0, bytesRead);
            memoryStream.Flush();
        }
        return memoryStream;
    }

//////////////////////////////////////////////This clearly leaves the memory Stream controlled by the Attachment Collection//////////// So vital you don't dispose it with the using statement when you create the memory stream.

[martinokello]

This to me is obviously wrong, as it gives me nightmares, not disposing the memory stream. How else should one do it without saving the file to disk, but in memory manipulation. Beats me.

[martinokello]

And I get an error message: Stream was too long when sending the email.

[jspinella]

I am still finding the problem with .net core 3.1. I am afraid I am using a memory stream which I write to and add it to an attachment. As an attachment is reading from stream, the best bet is using a memory stream, and I can't dispose enclosing it with using statement, as I am assuming that the attachment will need to use it even though it goes out of my scope.

This seems to be an issue with .NET 6 as well. Not sure about .NET 7.

[BogdanGrytsko]

Any updates on the issue? Getting it also, .NET 6

[twsouthwick]

This is something that needs to go into .NET itself - I've tried multiple ways to shim it at our layer and have not been able to get around it. Please add comments to dotnet/runtime#1544 to get visibility there.

[LarinLive]

I've checked this bug on .NET 7. Unfortunately, the problem hasn't been fixed yet.

[udlose]

Is there any update on this bug?

[mikeebowen]

Is there any update on this bug?

Unfortunately, there's no fix in the dotnet runtime yet.

[udlose]

This is kinda important to get this fixed and it needs to be driven by the fix in the .NET Runtime.

EVERYONE, please make sure to vote for this item and make some noise on that issue so we can get it moving along with some sense of urgency for the runtime team. It's disappointing that something so egregious has lingered without a resolution for so many years...

Please add comments to dotnet/runtime#1544 to get visibility there.