'ASP Core 3.1 Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals
I'm using Visual Studio 2019 and I have 5 or more areas in my ASP.NET Core MVC application.
When I was about to create a new controller and new razor (.cshtml
file) with dynamic layouts, menus, header and footer, I got the error shown below.
I see a lot of questions that don't have answers.
Solution 1:[1]
I just found out the answer by editing the .CSPROJ file and add the following :
<PropertyGroup><TargetFramework>netcoreapp2.1</TargetFramework>
<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>true</RazorCompileOnPublish></PropertyGroup>
and this one:
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>true</RazorCompileOnPublish>
</PropertyGroup>
Solution 2:[2]
There are two parts to this problem related to the CS8103 compiler error.
The assembly file format only supports a maximum of 2^24 bytes of string literals, which equates to around 8M UTF16 characters.
The razor view compiler translates the raw html in your view into a series of .WriteLiteral
method calls, with string literal arguments.
As per this comment on a related github issue, the best fix would involve changing the razor compiler to store these strings in an assembly resource.
While you can change your project to compile razor views at runtime. Resulting in each view being compiled to a separate in-memory assembly. Due to the extra runtime cost of this option, I can't recommend it.
Your only other option right now is to reduce the size of your literal html by hand.
You may be able to refactor common sections of your views into layouts or partial views. Or you could use the same technique as localisation to move larger sections of content to assembly resources.
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 | |
Solution 2 | Jeremy Lakeman |