Why are breakpoints not being set in .cshtml files in Visual Studio 2026, and what steps can I take to resolve this issue?

[JafferHussain]

Hello,

I am trying to set breakpoints for debugging in a .cshtml file in my Umbraco 13 project using Visual Studio 2026, but the breakpoints are not being set. I receive the following notification:

“A breakpoint could not be inserted at this location.”

I also created a new Umbraco 17 project and encountered the same issue there. However, when working with a plain MVC project, I am able to set breakpoints without any problem.

I referred to the following link and understood that this might be an issue related to Umbraco:
https://developercommunity.visualstudio.com/t/11047278

Could you please guide me on how to resolve this issue?

Thanks in advance.

[ShekharTarare]

Hi @JafferHussain

Please add this on your .csproj file:

<ItemGroup Condition="'$(DesignTimeBuild)' == 'true'">
  <AdditionalFiles Include="**\*.cshtml" />
  
  <CompilerVisibleProperty Include="MSBuildProjectDirectory" />
</ItemGroup>

You may need to rebuild your solution and restart Visual Studio to force the design-time build context to refresh. After that, your breakpoints should bind normally in .cshtml files.

I just did a quick Umbraco 13 setup and tried it. Without this I was getting the same issue, after adding that code, I was able to add the breakpoint:

Here are some resources I found while looking into this:

Breakpoints is not working in Razor files *.cshtml - Umbraco template

VS 2026 Insiders: breakpoints can't be set inside @functions blocks in Razor Views when using Roslyn Cohost server for Razor

While checking why it fails, I got this from AI:
Visual Studio 2026 introduced a new editor architecture (the Roslyn Cohost server) which relies on a Razor Source Generator to handle IntelliSense and debugger bindings. For this generator to correctly map your .cshtml code to the runtime debugger, it requires all Razor files to be explicitly passed to the compiler as AdditionalFiles.

Standard ASP.NET Core MVC projects handle this mapping automatically under the hood via the base web SDK. However, Umbraco templates currently do not include the specific MSBuild logic the new editor expects. Because the editor cannot compute the target paths for your views, it fails to bind the breakpoints and throws the “A breakpoint could not be inserted at this location” error.

While it is technically a workaround rather than the permanent architectural fix (which would need to come from an official Umbraco or Microsoft SDK update), it uses standard, best-practice MSBuild logic.

Here is why you don’t need to worry about deploying this code:

The Magic of DesignTimeBuild

The most important part of that fix is this line: Condition="'$(DesignTimeBuild)' == 'true'"

In Visual Studio: When Visual Studio loads your project to provide IntelliSense, map debuggers, and show error squiggles, it runs a background evaluation called a “Design-Time Build.” During this phase, the condition is true, so the .cshtml files are fed to the new Razor editor engine, fixing your breakpoints.

In Production/CI Pipelines: When you actually compile your app to deploy it (using dotnet build, dotnet publish, or clicking “Build” for a release), this is a “Real Build.” During a real build, DesignTimeBuild is false.

Because of this condition, the compiler completely ignores the workaround when generating your final binaries. It has zero impact on your compiled application’s performance, file size, or runtime behavior.

Hope it helps!