Introduction

Retargeting a solution from .NET Framework 4.0 to 4.5 is usually straightforward at the project level, but package references can lag behind. The typical issue is not that every package must be rewritten, but that the project needs to restore or reinstall packages so the correct assemblies and binding redirects are selected for the new framework target.

What Retargeting Actually Changes

.NET Framework 4.5 is an in-place update over 4.0, but Visual Studio and NuGet still track target frameworks in project metadata. When you switch a project from 4.0 to 4.5, you are telling the build system to prefer assemblies and compatibility profiles for net45 instead of net40 where available.

In older solutions that use packages.config, package references are often pinned in a way that benefits from reinstalling. In newer projects that use PackageReference, a restore is often enough.

Step 1: Retarget the Project

First update the project itself. In an old-style .csproj, the target framework section looks like this:

<PropertyGroup>
  <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
</PropertyGroup>

If you change the target in the Visual Studio project properties UI, this file update usually happens for you.

At this point, build once and see what breaks. Some packages will continue working immediately. Others may still point at old assemblies, old content files, or missing redirects.

Step 2: Reinstall or Restore NuGet Packages

For classic packages.config projects, the standard fix is:

Update-Package -Reinstall

Run that in the Package Manager Console for the solution or target a specific project:

Update-Package -Reinstall -ProjectName MyLegacyApp

Why this helps:

• NuGet re-evaluates package assets for the new target framework.
• Reference paths are refreshed.
• Content files and build targets are re-applied.
• Binding redirect generation becomes more consistent.

If the package already contains both net40 and net45 assemblies, reinstalling often switches the project to the correct version automatically.

Step 3: Update Packages When Reinstall Is Not Enough

Some packages simply do not support the new target well in the exact version you already use. In that case, update the package rather than only reinstalling it.

Update-Package Newtonsoft.Json

If the whole solution is moving forward and you want newer compatible versions where possible:

Update-Package

Do this carefully in older applications. A framework retarget plus major dependency upgrades can create two sources of breakage at once, which makes debugging slower.

Step 4: Watch for Binding Redirects and API Changes

After retargeting, build errors are only part of the story. Runtime failures may appear if the application config lacks needed binding redirects or if package behavior changed between framework profiles.

An app configuration file may end up with redirects like this:

1<runtime>
2  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
3    <dependentAssembly>
4      <assemblyIdentity name="Example.Library" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
5      <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
6    </dependentAssembly>
7  </assemblyBinding>
8</runtime>

If the build works but the app fails at startup, check the package references, the actual DLL versions copied to bin, and the generated redirects.

packages.config Versus PackageReference

For maintenance work on older .NET Framework solutions, packages.config is common. That is the context where Update-Package -Reinstall matters most.

If the project already uses PackageReference, the workflow is usually simpler:

• retarget the framework,
• restore packages,
• update only the packages that do not support the new target,
• rebuild and test.

The older the solution, the more likely the right answer is "retarget, reinstall, rebuild, then fix stragglers one by one."

Common Pitfalls

The most common mistake is assuming every package must be manually edited after the framework change. Usually the project retarget plus package reinstall is enough for many dependencies.

Another issue is updating every package at once. That mixes framework-retargeting problems with package-upgrade problems and makes failures harder to isolate.

Teams also forget runtime validation. A clean compile does not guarantee that assembly loading and redirects are correct when the application starts.

Summary

• Retarget the project to .NET Framework 4.5 first.
• For old packages.config projects, Update-Package -Reinstall is the usual next step.
• Update individual packages only when reinstalling is not enough.
• Check binding redirects and copied assemblies, not just compile errors.
• Treat framework retargeting and mass package upgrades as separate risks when possible.