'C# Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals

When I add a static string property to my class that returns a long string I get this error.

In the same project I have added lots of string properties over 20k chars, but when I create another property returning a string and build the project I get this error.

How can I increase that limit? I tried to use Stringbuilder but same happens.



Solution 1:[1]

Just want to bring my recent experience to the table.

There is not much information around if you search the net for CS8103 error. And most information is not entirely precise.

We ran into this yesterday, in a large C# solution.

As I understand this compile error, the problem is the total length of all compile time defined strings concatenated.

I interprets this as the compiler puts all strings in a massive datablock, and then when a given string is referenced, it indexes into this (or similar).

So try to understand it as all your strings defined in cs files - concatenated to one. If this string becomes too large - we risk runtime errors as the Roslyn issue above explains.

All strings in code, all that is inside double quotes count.

public void Main() {
    Console.WriteLine("test");
    string test = "AnotherTest" + " " + "run";
}

A program like above has 4 + 11 + 1+ 3 = 19 => "testAnotherTest run"

Our assembly reached the limit yesterday when merging a feature branch into master. That was the famous drop that makes the cup run over.

There seems to be no workaround, but to split your large assembly into smaller pieces, or move large block of strings into resources or other external files.

We verified this by commenting out a large portion of legacy code - and we could compile again.

Our solution was to refactor a specific area out of the large assembly, and create a new assembly for this.

I know, soo much text - but thought this deserved a thorough explanation, as it was quite hard to figure out what caused the problem.

And given the sparse information else where, this is not a common problem. But it stops the production line, and no one can compile until a solution is fixed.

Solution 2:[2]

I guess its a new compiler in VS2015, which restricts too much use of string literals.

See EmitErrorTests line 329: http://source.roslyn.codeplex.com/#Roslyn.Compilers.CSharp.Emit.UnitTests/Emit/EmitErrorTests.cs

The solution is to not overflow your heap. Try to get the total memory your program (if its already using too much) by

long totalHeapMemoryUsed  = GC.GetTotalMemory(false);

Try to not use static strings, but limit it to local scopes (function or class scope), or use Resources.

Solution 3:[3]

Try to move long strings into Resources

In my case I had huge migration SQL scripts. This issue was resolved after I moved them into Resources

Solution 4:[4]

We had this problem because we are using entity framework code first migration.

We use these migrations to run SQL scripts to update the database. These scripts can be large sometimes.

Over time the files accumulate and eventually, we got this error. Hiding the old sql scripts from the project essentially fixed this problem.

Solution 5:[5]

Add these two lines of code to your project's .csproj file. The error must get fixed.

<RazorCompileOnBuild>false</RazorCompileOnBuild> <RazorCompileOnPublish>false</RazorCompileOnPublish>

Solution 6:[6]

I managed to fix this issue by adding the following (*ed lines) in the .csproj file:

 <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    *<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
    *<PreserveCompilationContext>true</PreserveCompilationContext>
    <UserSecretsId>165df0cf-51ff-4f1e-b880-d98a9de58bc2</UserSecretsId>
 </PropertyGroup>

Btw, my project is a .net core app with support for MVC - Razor

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 ankhansen
Solution 2
Solution 3 DonSleza4e
Solution 4 Rosdi Kasim
Solution 5 The Karan Pargaien
Solution 6 Venugopal M