Error CS8103 Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals.

[vsfeedback]

I receive this error on my datasets since I've installed the latest VS2017. I have big tables, and think the MSDataSetGenerator generates code different, so now the compiler can't handle the big generated strings anymore?

There is not much information about the error message BC37255.

Can you help?

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/192728/bc37255-combined-length-of-user-strings-used-by-th.html
VSTS ticketId: 561492
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

[jaredpar]

Can you provide a bit more information here? There are limits on how big strings and XML literals can be in an application. But it's hard to see from the issue why this is happening here and what can be done to alleviate it.

[gr8tushar]

Hi,
I am also facing the same issue. It was absolutely working fine in 2015. But in VS 2017, it is giving the above mentioned error.
We have about 6 projects in a solutions. One Web App and others as class libraries. Each project has a constant file. That file would have 100s and 1000s of static strings - be it queries, constants, cache keys, session keys, messages, etc.

The problem started appearing from Web project. As we added more files to it, this error poped up.

Do let me know in case you need more info on the same.

[sol-lee]

Hi @jaredpar
We encountered the same issue here:
13>CSC : error CS8103: Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals.

After upgrade to ".NET Core 2.1 SDK" (netcoreapp2.1), by default RazorCompileOnBuild is set to true and it builds and compiles Razor Pages and Razor views automatically. Then we saw the CS8103 error.
If we set RazorCompileOnBuild to false and keep .cshtml compiled at runtime, it's fine so far.

Any ideas/ suggestions to workaround the issue? Thanks.

[rynowak]

hi @soiwill - sorry you're encountering this problem. We've implemented features inside the Razor compiler to avoid this problem in the past, and it looks like either this is a new case, or we broke something in the 2.1 SDK.

Could I ask you to report this over at https://github.com/aspnet/AspNetCore/issues so we can follow up as this problem relates to ASP.NET Core?

I would be great to know the version of the runtime you're targeting as well as the exact SDK version.

[gafter]

That may have been fixed in dotnet/roslyn#37915 which will be in Visual Studio 2019 update 4.

[gafter]

Closing as fixed in 16.4 due to dotnet/roslyn#37915. Please reopen if that is not in fact fixed.

[tmat]

@gafter I think this might be a different issue than the one addressed by dotnet/roslyn#37915, since BC37255 is report by the metadata writer when the assembly user string heap overflows.

In VS 2015 the compiler did not correctly check the size of the strings and might have produced an invalid assembly if the total string size exceeded the limits allows by ECMA335 specification.

To avoid this error, I'd recommend to store large strings (or large quantities of strings) to embedded resources instead of string literals.

[BeelineDevelopers]

Closing as fixed in 16.4 due to dotnet/roslyn#37915. Please reopen if that is not in fact fixed.

16.4 Preview 4 still has this issue. It increases the maximum combined length of string over 16.3.8 but it doesn't solve the problem entirely. As you increase the number of strings in 16.4 preview 4 the issue comes back.

Is there a way to fix it altogether?

Thanks in advance.

[gafter]

Is there a way to fix it altogether?

This is a limitation of the specification for the assembly file format. We would need to revise that to lift the limitation.

If you have large string literals that you need in your program, you can move them to resources so that they do not take up space in the string table.

[BeelineDevelopers]

Is there a way to fix it altogether?

This is a limitation of the specification for the assembly file format. We would need to revise that to lift the limitation.

If you have large string literals that you need in your program, you can move them to resources so that they do not take up space in the string table.

We do not have large strings but many strings across many .cshtml files and combining them all exceeds the threshold apparently.

Aside from defining it in the resources, which I assume will impact performance, are there other ways that won't affect performance but it still is able to compile and function?

What's involved in revising the limitation? Can it be configurable? What is it set at now?

Thanks in advance for your help.

[gafter]

The #US "user string" heap in an assembly has a "Size" that is stored as 4 bytes. There are no plans for an overhaul of the assembly file format. If we were to embark on a project of that scale, I would expect rollout of all of the affected tools to take several years.

The only other thing I can suggest is to break the program into several assemblies.

[BeelineDevelopers]

The #US "user string" heap in an assembly has a "Size" that is stored as 4 bytes. There are no plans for an overhaul of the assembly file format. If we were to embark on a project of that scale, I would expect rollout of all of the affected tools to take several years.

The only other thing I can suggest is to break the program into several assemblies.

Thanks for your response.

If I had a .NET Core website with thousands of pages and each page would have variables defining the content of the site, for instance a title variable which is used in the <title> tag, keyword tag, open graph tags and in the h1 tag, how would I set up the project(s) to get around the size limitation of the concatenation of all these variables?

[CyrusNajmabadi]

Why not store them in external files (like standard .net resource files) and have your code load it from that? Then the strings aren't in your dlls themselves, but they're just effectively in xml files that can be effectively any size.