DEV Community: assaadfrs

Fixing MSBuild NU5019 Errors in Multi-Targeting .NET Projects: A Complete Guide

assaadfrs — Tue, 09 Sep 2025 08:43:18 +0000

TL;DR

Getting NU5019: File not found when packaging multi-targeting .NET projects? The issue is that $(TargetFramework) doesn't resolve properly during dotnet pack. Solution: Use a custom MSBuild target with hardcoded framework paths instead of static ItemGroups with variables.

<Target Name="IncludeAdditionalFiles" BeforeTargets="_GetPackageFiles">
  <ItemGroup>
    <None Include="..\OtherProject\bin\$(Configuration)\net47\OtherProject.dll">
      <Pack>true</Pack>
      <PackagePath>lib\net47\OtherProject.dll</PackagePath>
    </None>
    <None Include="..\OtherProject\bin\$(Configuration)\net9.0\OtherProject.dll">
      <Pack>true</Pack>
      <PackagePath>lib\net9.0\OtherProject.dll</PackagePath>
    </None>
  </ItemGroup>
</Target>

Have you ever encountered the dreaded NU5019: File not found error when trying to create NuGet packages from multi-targeting .NET projects? If you're building projects that target multiple frameworks and want to bundle multiple DLLs into a single package, you've probably run into this frustrating issue.

In this post, I'll walk you through the exact problem I encountered and the solution that finally worked.

The Problem

I was working with a solution containing two projects:

MyProject.Core (VB.NET project, multi-targeting net47 and net9.0)
MyProject.Utils (C# project, also multi-targeting net47 and net9.0)

My goal was to create a single NuGet package from the VB.NET project that would include both the VB.NET and C# DLLs for each target framework.

Initially, I tried the "obvious" approach in my .vbproj file:

<ItemGroup>
  <None Include="..\MyProject.Utils\bin\$(Configuration)\$(TargetFramework)\MyProject.Utils.dll">
    <Pack>true</Pack>
    <PackagePath>lib\$(TargetFramework)\MyProject.Utils.dll</PackagePath>
  </None>
  <None Include="bin\$(Configuration)\$(TargetFramework)\MyProject.Core.dll">
    <Pack>true</Pack>
    <PackagePath>lib\$(TargetFramework)\MyProject.Core.dll</PackagePath>
  </None>
</ItemGroup>

But when I ran dotnet pack, I got:

error NU5019: File not found: 'C:\...\MyProject.Utils\bin\Release\MyProject.Utils.dll'

The Root Cause

The issue was that $(TargetFramework) doesn't resolve correctly during the packaging phase in multi-targeting scenarios. Instead of resolving to net47 or net9.0, it was resolving to an empty string, creating invalid paths like:

❌ bin\Release\MyProject.Utils.dll (missing framework folder)

Instead of the correct paths:

✅ bin\Release\net47\MyProject.Utils.dll

✅ bin\Release\net9.0\MyProject.Utils.dll

The Solution: MSBuild Target Approach

After trying several approaches, the solution that worked was to use a custom MSBuild target instead of static ItemGroups. Here's what I implemented:

<Target Name="IncludeAdditionalFiles" BeforeTargets="_GetPackageFiles">
  <ItemGroup>
    <!-- Include C# project DLLs only (VB.NET DLLs are included automatically) -->
    <None Include="..\MyProject.Utils\bin\$(Configuration)\net47\MyProject.Utils.dll">
      <Pack>true</Pack>
      <PackagePath>lib\net47\MyProject.Utils.dll</PackagePath>
    </None>
    <None Include="..\MyProject.Utils\bin\$(Configuration)\net9.0\MyProject.Utils.dll">
      <Pack>true</Pack>
      <PackagePath>lib\net9.0\MyProject.Utils.dll</PackagePath>
    </None>
  </ItemGroup>
</Target>

Why This Works

Target Timing: BeforeTargets="_GetPackageFiles" ensures our target runs at the right time during the packaging process, after the build is complete but before NuGet collects the files to pack.
Explicit Framework Paths: Instead of relying on the problematic $(TargetFramework) variable, we use hardcoded framework identifiers (net47, net9.0).
No Duplicates: Since MSBuild automatically includes the primary project's output DLLs, we only need to explicitly include the additional C# project DLLs.

Bonus: Fixing MSB4057 GetTargetPath Errors

While working on this, I also encountered MSB4057: The target "GetTargetPath" does not exist in the project errors. This happens when using SDK-style projects that are referenced by other projects (especially ASP.NET websites).

The fix is to add this target to any project experiencing the error:

<Target Name="GetTargetPath" Returns="@(_FakeOutputPath)">
  <ItemGroup>
    <_FakeOutputPath Include="$(MSBuildProjectDirectory)\$(OutputPath)\$(_InstallerTargetFramework)\$(AssemblyName).dll" />
  </ItemGroup>
</Target>

The Result

After implementing these changes:

✅ dotnet pack succeeds without NU5019 errors

✅ Package contains all DLLs for both target frameworks:

lib/net47/MyProject.Core.dll
lib/net47/MyProject.Utils.dll
lib/net9.0/MyProject.Core.dll
lib/net9.0/MyProject.Utils.dll ✅ No duplicate file warnings ✅ Single NuGet package with bundled dependencies

Key Takeaways

Don't rely on $(TargetFramework) during packaging in multi-targeting scenarios - it may not resolve as expected.
Use MSBuild targets for dynamic file inclusion instead of static ItemGroups when dealing with complex packaging requirements.
The timing of MSBuild targets matters - BeforeTargets="_GetPackageFiles" is the sweet spot for packaging customizations.
Multi-targeting projects need special handling when you want to bundle outputs from multiple projects.

Alternative Approaches Considered

Before settling on this solution, I tried:

Framework-specific ItemGroups with conditions
Different target timing (BeforeTargets="GenerateNuspec")
Using Exists() conditions (failed due to timing issues)

None of these worked reliably. The target-based approach with explicit framework paths proved to be the most robust solution.

Have you encountered similar MSBuild packaging issues? What solutions worked for you? Let me know in the comments!

If this post helped you solve a similar problem, give it a ❤️ and consider sharing it with others who might be struggling with the same issue.

Tags: #dotnet #msbuild #nuget #packaging #multitargeting #csharp #vbnet

Fixing Blazor 404 Errors When Using Razor Class Library Pages

assaadfrs — Sat, 05 Jul 2025 09:13:26 +0000

Have you ever created a Blazor page in a Razor Class Library (RCL) only to get a frustrating 404 error when trying to navigate to it? You're not alone! This is a common issue that catches many developers off guard. Let me walk you through the problem and the solution.

TL;DR

Problem: Blazor pages in Razor Class Libraries return 404 errors even when AdditionalAssemblies is configured in Routes.razor.

Solution: Add .AddAdditionalAssemblies() to your Program.cs routing configuration:

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddAdditionalAssemblies(typeof(YourRCL.SomeComponent).Assembly);

You need to configure additional assemblies in both Routes.razor AND Program.cs for RCL routing to work properly.

The Problem

I had a Blazor Server app (BlazorApp1) that referenced a Razor Class Library (RazorClassLibrary1). In the RCL, I created a simple page:

@page "/page1"

<PageTitle>Page 1</PageTitle>

<h1>Page 1</h1>

<div class="my-component">
    This component is defined in the <strong>RazorClassLibrary1</strong> library.
</div>

I configured the AdditionalAssemblies in my Routes.razor file:

@using System.Reflection
<Router AppAssembly="typeof(Program).Assembly"
        AdditionalAssemblies="new[] { typeof(RazorClassLibrary1.Component1).Assembly }">
    <Found Context="routeData">
        <RouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)"/>
        <FocusOnNavigate RouteData="routeData" Selector="h1"/>
    </Found>
    <NotFound>
        <PageTitle>Not found</PageTitle>
        <LayoutView Layout="typeof(Layout.MainLayout)">
            <p role="alert">Sorry, there's nothing at this address.</p>
        </LayoutView>
    </NotFound>
</Router>

Everything looked correct, but navigating to /page1 still returned a 404 error. Frustrating!

The Investigation

To debug this issue, I created a diagnostic page that showed me what routes were being discovered:

@page "/debug"
@using System.Reflection
@using Microsoft.AspNetCore.Components.Routing

<h3>Debug Routes</h3>

<h4>Main Assembly Routes:</h4>
<ul>
@foreach (var route in GetRoutes(typeof(Program).Assembly))
{
    <li>@route</li>
}
</ul>

<h4>RCL Assembly Routes:</h4>
<ul>
@foreach (var route in GetRoutes(typeof(RazorClassLibrary1.Component1).Assembly))
{
    <li>@route</li>
}
</ul>

@code {
    private List<string> GetRoutes(Assembly assembly)
    {
        var routes = new List<string>();

        foreach (var type in assembly.GetTypes())
        {
            var routeAttributes = type.GetCustomAttributes<RouteAttribute>();
            foreach (var attr in routeAttributes)
            {
                routes.Add($"{type.Name}: {attr.Template}");
            }
        }

        return routes;
    }
}

The debug page showed that the /page1 route was being discovered from the RCL assembly, but the router still wasn't finding it at runtime.

The Solution

The issue was that while the Router component was configured with AdditionalAssemblies, the routing system in Program.cs wasn't aware of the RCL assembly.

The fix is to also register the additional assemblies in Program.cs:

using BlazorApp1.Components;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseAntiforgery();

app.MapStaticAssets();
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddAdditionalAssemblies(typeof(RazorClassLibrary1.Component1).Assembly);  // 👈 This is the key!

app.Run();

Why This Works

The problem occurs because:

The Router component in Routes.razor handles client-side routing within the Blazor app
The MapRazorComponents in Program.cs handles server-side route discovery and registration
Both need to know about the RCL assemblies for the routing to work properly

By adding .AddAdditionalAssemblies() to the MapRazorComponents call, we ensure that:

The server-side routing system discovers all routes from the RCL
The routes are properly registered with the ASP.NET Core routing system
The Blazor router can successfully match and render the pages

Complete Working Configuration

Here's the complete working setup:

Program.cs:

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddAdditionalAssemblies(typeof(RazorClassLibrary1.Component1).Assembly);

Routes.razor:

@using System.Reflection
<Router AppAssembly="typeof(Program).Assembly"
        AdditionalAssemblies="new[] { typeof(RazorClassLibrary1.Component1).Assembly }">
    <Found Context="routeData">
        <RouteView RouteData="routeData" DefaultLayout="typeof(Layout.MainLayout)"/>
        <FocusOnNavigate RouteData="routeData" Selector="h1"/>
    </Found>
    <NotFound>
        <PageTitle>Not found</PageTitle>
        <LayoutView Layout="typeof(Layout.MainLayout)">
            <p role="alert">Sorry, there's nothing at this address.</p>
        </LayoutView>
    </NotFound>
</Router>

Project Reference in BlazorApp1.csproj:

<ItemGroup>
  <ProjectReference Include="..\RazorClassLibrary1\RazorClassLibrary1.csproj" />
</ItemGroup>

Key Takeaways

Both client and server routing need to know about RCL assemblies - Configure both Routes.razor and Program.cs
The diagnostic page technique is invaluable - Create a debug page to verify route discovery
This applies to any additional assemblies - Not just RCLs, but any external assemblies containing Blazor components

This solution has saved me hours of debugging, and I hope it helps you too! Have you encountered this issue before? What other Blazor routing gotchas have you discovered?

Found this helpful? Give it a ❤️ and share it with your fellow Blazor developers!