CSharpCodeWriter's write string literal can fail with Mono and Roslyn.

[NTaylorMullen]

Original Issue: https://aspnetwebstack.codeplex.com/workitem/1885

We are using razor to generate C# code for web pages, and on some pages there is very much content.

The method that chooses how to write out the text chooses to write out the string using WriteVerbatimStringLiteral only if the length is equal to or less than 1500 characters. The comment says this is because it may be too long to fit in one line, but it does not check the actual length of each line.
What should have ended up as a nicely formatted @"" block across multiple lines got turned into "~80chars" + repeated many many times.

        public override void WriteStringLiteral(string literal)
        {
            if (literal == null)
            {
                throw new ArgumentNullException("literal");
            }

            // From CSharpCodeProvider in CodeDOM
            //  If the string is short, use C style quoting (e.g "\r\n")
            //  Also do it if it is too long to fit in one line
            //  If the string contains '\0', verbatim style won't work.
            if (literal.Length >= 256 && literal.Length <= 1500 && literal.IndexOf('\0') == -1)
            {
                WriteVerbatimStringLiteral(literal);
            }
            else
            {
                WriteCStyleStringLiteral(literal);
            }
        }

This causes a problem when we try to compile the code using Mono.CSharp.Evaluator (see the issue I submitted about the StackOverflowException the generated code causes: https://bugzilla.xamarin.com/show_bug.cgi?id=19332)

Currently I either have to use a modified razor dll which only has the literal.IndexOf('\0') == -1 check, or increase the stack size on the thread that compiles the code and hope the content never reaches the new limit.

Maybe this check could be updated to prefer WriteVerbatimStringLiteral if there are line breaks in the string, but check that none of the lines exceed 1500 characters?

[yishaigalatzer]

Not sure why we break the lines to begin with? These files are not meant to be human readable

[yishaigalatzer]

BTW breaking by linebreaks, might reduce memory because literal strings are going to repeat themselves, and with pre compilation they are going to get interned in one assembly.

[NTaylorMullen]

@yishaigalatzer It was a port from the existing Razor code generation process when we used code DOM. The reason why we did during those days was because CodeDOM did it under the covers (pretty much identical logic). For a specific reason we should consult with @anurse .

[dougbu]

@NTaylorMullen @danroth27 @yishaigalatzer please unconfuse this issue. Should either not be in the Beta milestone or be in the Ready column.

[yishaigalatzer]

Taylor is this a problem for rosyln too? The bug talks about the mono c# compiler

[NTaylorMullen]

@yishaigalatzer Not sure, I'm still surprised that this causes a stack overflow for the evaluator to begin with... We could invest some time to see if this is still an issue and if you feel like its worth it.

As a side note: We do what CodeDOM used to do and they never solved the problem. Most likely the reason: It's a supppper edge case, the string needs to be pretty huge to cause an issue... With Razor I do see how you may be able to generate a very large string unintentionally though.

[Sense545]

The default stack sizes are 256 KB for 32-bit ASP.NET apps and 512 KB for 64-bit ASP.NET apps.
My code example from the xamarin bug report shows that a stack overflow exception will be thrown when appending 1500 x 80 character lines with a stack size of 512 KB.