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)
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.
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.
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" (
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.
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.
That may have been fixed in https://github.com/dotnet/roslyn/pull/37915 which will be in Visual Studio 2019 update 4.
Closing as fixed in 16.4 due to https://github.com/dotnet/roslyn/pull/37915. Please reopen if that is not in fact fixed.
@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.
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.
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.
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.
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.
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
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.
Note: these questions are better suited to something like gitter/discord.
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.
Thanks for the tip!
Is there any performance implications going that route (resource files) vs. having them in variables? In our scenario, even milliseconds count. I would think reading the file would be a hit to performance but maybe after that it's OK since it would be cached in memory?
Is there any performance implications
Yes. Measure.
In our scenario, even milliseconds count.
Measure.
but maybe after that it's OK since it would be cached in memory?
Maybe. Measure. This is your domain, so you will need to evaluate what the performance is and what is acceptable.
As mentioned above: these questions are better suited to something like gitter/discord. Try gitter.im/dotnet/roslyn Or discord.gg/csharp
Is there any performance implications
Yes. Measure.
In our scenario, even milliseconds count.
Measure.
but maybe after that it's OK since it would be cached in memory?
Maybe. Measure. This is your domain, so you will need to evaluate what the performance is and what is acceptable.
True.
But, in general, in your expert opinion, is there a performance degradation using resources vs. variables on a website which in your opinion is not negligible.
As mentioned above: these questions are better suited to something like gitter/discord. Try gitter.im/dotnet/roslyn Or discord.gg/csharp
Closing as fixed in 16.4 due to dotnet/roslyn#37915. Please reopen if that is not in fact fixed.
Still getting this error trying to build an ASP.NET Core 3.1 application in VS2019 16.4.2.
Error CS8103 Combined length of user strings used by the program exceeds allowed limit. Try to decrease use of string literals.
Microsoft Visual Studio Professional 2019
Version 16.4.2
VisualStudio.16.Release/16.4.2+29613.14
Microsoft .NET Framework
Version 4.8.03752
Installed Version: Professional
ASP.NET and Web Tools 2019 16.4.457.38025
ASP.NET and Web Tools 2019
ASP.NET Web Frameworks and Tools 2019 16.4.457.38025
.net core >= 2.1 && < 3
This can be accomplished using the property RazorCompileOnBuild in the .csproj file:
@ferbalu22 I think you are confirming that this is fixed in .net core 3.
This issue is still not fixed.
I have tried Visual Studio Pro 2019 (16.5.5) and .NET Core 3.1
As soon as I add few Views to an ASP.NET Core project, the build fails.
Its strange that no enterprise has reported this. I fail to understand how can an enterprise product be migrated to .NET Core if this issue is not resolved.
Having few hundred views in a enterprise project is a very common scenario.
I have started feeling that .NET Core is more of a playing ground for Microsoft. It's not meant or mature enough for enterprise development.
Moving to aspnetcore as this discussion is primarily about razor implementation, not the C# compiler.
might have produced an invalid assembly if the total string size exceeded the limits allows by ECMA335 specification.
@tmat \ @gafter out of curiosity, what is this size limit?
2^24 bytes. Literals are UTF16 encoded, so 8M characters.
Hi All,
We are stuck in the middle. For one of our solution, we have migrated most of the apps to .NET Core. But this issue is preventing us to go live with all the apps in .NET Core.
It has become a night mare and comes with huge cost in maintaining two versions of the system.
Awaiting some positive solution.
The right fix for this would involve razor codegeneration to stash string literals in to a resx file and changing WriteLiteral calls to use these resx strings. Implementing this is going to be a fair bit of work - the code generation would need to add this feature and we would need to change the SDK to express multiple outputs produced per cshtml file.
In the meanwhile, app developers have a few options to work around this:
a) Consider manually stashing literals in to resx files. This would follow the same pattern as using view localization and it's likely you could repurpose the existing localization APIs for this.
b) Another alternative would be to extracting large chunks of HTML in to separate files and emitting these out at runtime:
c) Yet another option that's already been described here is to turn off build time compilation and rely on runtime compilation. Runtime compilation compiles individual views in to separate assembly. This makes it less likely to reach the 8M limit for strings. To disable build time compilation,
<PropertyGroup>
<RazorCompileOnBuild>false</RazorCompileOnBuild>
</PropertyGroup>
Follow https://docs.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-3.1&tabs=visual-studio#enable-runtime-compilation-in-an-existing-project to learn about enabling runtime compilation.
I got this error too on a desktop application project, I'm using VS 2019 with .Net framework 4.5.2, can anyone help?
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
</PropertyGroup>
Most helpful comment
.net core >= 2.1 && < 3
This can be accomplished using the property RazorCompileOnBuild in the .csproj file: