Multi-targetting .Net Framework and .Net Core in a single project

A 15-second guide and 15-minute walk through

You have a .Net Core project, whether a netstandard library, or a netcore app, and you'd like it to be available for consumption by a net40 or net45 application?

’s easy!

Step 1: Open the csproj file and replace the line:

<TargetFramework>netcoreapp2.0</TargetFramework>

with

<TargetFrameworks>netcoreapp2.0;net45</TargetFrameworks>

Save and build, and you're done!

Well, maybe. Seriously though, for a project with no dependencies this one step may be all you need to do. There is a massive and impressive compatibility between .Net framework 4.x and .Net Core.

For when that doesn't just work, this page goes through the complications and the further steps you may need. We will take a netcore csproj file as the start, and make it also build for a netframework target.

The simplest way to do the reverse—to make an older netframework project multi-target—is to first migrate it to a netcore project then carry on from here. Honest. The new csproj file is a fraction of the complexity of the old-style projects, and it handles both NetFramework and NetCore very simply. A first-migrate-to-core approach is much simpler and faster than trying to make an old-style project file handle dotnetcore (if it were even possible).

These are the steps in outline:

  1. Learn about conditional sections in your csproj file, so that you can declare different dependencies for each target. Create two conditional sections, one for netcore. and one for netframework.
  2. Optionally, add a boilerplate section to your project to enable the netframework target to build on mono for linux or macos.
  3. Discover what explicit references to framework dlls the netframework target requires, and add each one as a <Reference /> in the netframework conditional section.
  4. Discover what NuGet dependencies for your project are different on netcore vs netframework. Put a <PackageReference /> for each target in the respective conditional section. It's possible that you have a dependency on something that isn't available for both your targets. If so, you're probably stuck, unless you can somehow code round the missing dependency.
  5. Deal with code that doesn't compile on all targets. Most likely this will be :
    • language features such as async/await for which the C# compiler relies on access to .Net framework 4.5 and later. Polyfills are sometimes possible.
    • framework classes and methods not available in your target. Most notable might be HttpClient, which first appeared in net45, but also for instance HostingEnvironment.QueueBackgroundWorkItem() (net452 and later) and Type.GetTypeInfo() & PropertyInfo.GetCustomAttribute() in net45 and later. In fact HttpClient for Net40 on Windows is available on Nuget in the System.Net.Http package. Type.GetTypeInfo() is mostly easy to polyfill. Your mileage will vary.

You can go through these steps in a simplistic, “try to build;fix the next error; repeat” way.

1. Change TargetFramework to TargetFrameworks

Open your csproj file, either by right-clicking on it in Visual Studio, or in another Editor.
The first step is to replace the line:

<TargetFramework>netcoreapp2.0</TargetFramework>

with

<TargetFrameworks>netcoreapp2.0;net45</TargetFrameworks>

Notice that the plural TargetFrameworks has an s.

How, you ask, do I know what the valid target names are? This, and many other questions about multi-targetting are answered in https://docs.microsoft.com/en-us/dotnet/core/tutorials/libraries.

2. Create conditional sections in your csproj file

Here's a csproj file for a typical small project:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="xunit" Version="2.4.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\PredicateDictionary\PredicateDictionary.csproj" />
<ProjectReference Include="..\TestBase\TestBase.csproj" />
</ItemGroup>
</Project>

Add new <ItemGroup> elements with Condition attributes:

<ItemGroup Condition="$(TargetFramework.StartsWith('netcore'))" >
</ItemGroup>
<ItemGroup Condition="$(TargetFramework.StartsWith('net4'))" >
</ItemGroup>

Later, if you add more references to a project after multi-targetting you will almost certainly have to manually re-edit the csproj file to get the new references into the right conditional block. The MSBuild file format is very editable, so long as you have a basic grasp of xml. You can add, combine and reorder ItemGroups and PropertyGroups as you wish, and add any amount of properties and conditions.

But now, try to build.

2½. (Optional) Support building the netframework target on mono for linux or macos

In my case working on a Mac, my next error is

error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack … etc …

…which is resolved with a 'boilerplate' section provided by https://github.com/dsyme (Thanks Don!). Add this to your csproj file:

<PropertyGroup Condition="$(TargetFramework.StartsWith('net4')) and '$(OS)' == 'Unix'">
<!-- When compiling .NET SDK 2.0 projects targeting .NET 4.x on Mono using 'dotnet build' you -->
<!-- have to teach MSBuild where the Mono copy of the reference asssemblies is -->
<!-- Look in the standard install locations -->
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/Library/Frameworks/Mono.framework/Versions/Current/lib/mono')">/Library/Frameworks/Mono.framework/Versions/Current/lib/mono</BaseFrameworkPathOverrideForMono>
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/lib/mono')">/usr/lib/mono</BaseFrameworkPathOverrideForMono>
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/local/lib/mono')">/usr/local/lib/mono</BaseFrameworkPathOverrideForMono>
<!-- If we found Mono reference assemblies, then use them -->
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net40'">$(BaseFrameworkPathOverrideForMono)/4.0-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net45'">$(BaseFrameworkPathOverrideForMono)/4.5-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net451'">$(BaseFrameworkPathOverrideForMono)/4.5.1-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net452'">$(BaseFrameworkPathOverrideForMono)/4.5.2-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net46'">$(BaseFrameworkPathOverrideForMono)/4.6-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net461'">$(BaseFrameworkPathOverrideForMono)/4.6.1-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net462'">$(BaseFrameworkPathOverrideForMono)/4.6.2-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net47'">$(BaseFrameworkPathOverrideForMono)/4.7-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net471'">$(BaseFrameworkPathOverrideForMono)/4.7.1-api</FrameworkPathOverride>
<EnableFrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">true</EnableFrameworkPathOverride>
<!-- Add the Facades directory.  Not sure how else to do this. Necessary at least for .NET 4.5 -->
<AssemblySearchPaths Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">$(FrameworkPathOverride)/Facades;$(AssemblySearchPaths)</AssemblySearchPaths>
</PropertyGroup>

And build again.

3. Discover what explicit references to framework dlls the netframework target requires

My next error is

error CS0012: The type 'Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

The error tells me exactly what reference and version I need for my netframework section. Add it like this:

<ItemGroup Condition="$(TargetFramework.StartsWith('net4'))" >
<Reference Include="System.Runtime" Version="4.0.0.0" />
</ItemGroup>

For my next builds, I get similar errors for System.Threading.Tasks, and System.Collections, so I add them the same way.

<ItemGroup Condition="$(TargetFramework.StartsWith('net4'))" >
<Reference Include="System.Runtime" Version="4.0.0.0" />
<Reference Include="System.Threading.Tasks" Version="4.0.0.0" />
<Reference Include="System.Collections" Version="4.0.0.0" />
</ItemGroup>

At this point, if your NuGet dependencies are compatible with both your netcore and netframework targets you may be done! The big news here is that most of your NuGet dependencies are compatible with both. All of the most downloaded NuGet packages are either multi-targeted, or have packages for each target.

4. Discover what NuGet dependencies for your project are different on netcore vs netframework

If some of your NuGet dependencies don't work for both platforms, then put the dependencies in the conditional section for netcore. Then find the right package versions for netframework.

Nuget dependencies are represented as <PackageReference /> elements, so in my case I move these into the netcore section:

<ItemGroup Condition="$(TargetFramework.StartsWith('netcore'))" >
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="xunit" Version="2.4.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
</ItemGroup>

Now I make Visual Studio (or Rider) help me sort out the NuGet dependencies for the netframework target, by temporarily single-targetting:

<TargetFramework>net45</TargetFramework>

I build, and my next error is:

error CS0246: The type or namespace name 'Xunit' could not be found (are you missing a using directive or an assembly reference?)

which I can easily resolve in Visual Studio or JetBrains Rider via “Manage NuGet Packages” to add a NuGet reference to xunit. The IDE adds a single <PackageReference />, but puts it in an unconditional <ItemGroup> so I manually move it to the netframework conditional ItemGroup. Now my ItemGroups look like this:

<ItemGroup Condition="$(TargetFramework.StartsWith('netcore'))">
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
</ItemGroup>
<ItemGroup Condition="$(TargetFramework.StartsWith('net4'))">
<Reference Include="System.Runtime" Version="4.0.0.0" />
<Reference Include="System.Threading.Tasks" Version="4.0.0.0" />
<Reference Include="System.Collections" Version="4.0.0.0" />
<PackageReference Include="xunit" Version="2.4.1" /> <!--  <== I manually moved this line into this section-->
</ItemGroup>

I build again. If there are more NuGet references, I add them in the usually way. Once all NuGet dependencies are sorted, I change back to multi-target again

<TargetFrameworks>netcoreapp2.0;net45</TargetFrameworks>

And now it all builds and works! Furthermore you find with UnitTest projects that Visual Studio, JetBrains Rider and the dotnet cli all recognise and run the tests twice, once on each platform.

When coding, once you have a multi-target project, it may be confusing the first time you hit a compile error on one target whilst the other target is fine. But you will find that both Visual Studio and JetBrains Rider are somewhat multi-target aware, and looking again at the error output you can tell which target is erroring.

As of 2019 no IDE will automatically add differing NuGet dependencies for multi-targets, but they will happily handle projects that you have manually edited, and they will correctly process conditional sections.

The final csproj file looks like this. It builds both framework and netcore targets, and works on Windows, on macOs with mono 5, and on Linux with mono 5.

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netcoreapp2.0;net45</TargetFrameworks>
<IsTestProject>true</IsTestProject>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\PredicateDictionary\PredicateDictionary.csproj" />
<ProjectReference Include="..\TestBase\TestBase.csproj" />
</ItemGroup>

<ItemGroup Condition="$(TargetFramework.StartsWith('netcore'))">
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.1" />
<PackageReference Include="xunit" Version="2.4.1" />
</ItemGroup>
<ItemGroup Condition="$(TargetFramework.StartsWith('net4'))">
<Reference Include="System.Runtime" Version="4.0.0.0" />
<Reference Include="System.Threading.Tasks" Version="4.0.0.0" />
<Reference Include="System.Collections" Version="4.0.0.0" />
<PackageReference Include="xunit" Version="2.4.1" />
</ItemGroup>

<PropertyGroup Condition="$(TargetFramework.StartsWith('net4')) and '$(OS)' == 'Unix'">
<!-- When compiling .NET SDK 2.0 projects targeting .NET 4.x on Mono using 'dotnet build' you -->
<!-- have to teach MSBuild where the Mono copy of the reference asssemblies is -->
<!-- Look in the standard install locations -->
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/Library/Frameworks/Mono.framework/Versions/Current/lib/mono')">/Library/Frameworks/Mono.framework/Versions/Current/lib/mono</BaseFrameworkPathOverrideForMono>
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/lib/mono')">/usr/lib/mono</BaseFrameworkPathOverrideForMono>
<BaseFrameworkPathOverrideForMono Condition="'$(BaseFrameworkPathOverrideForMono)' == '' AND EXISTS('/usr/local/lib/mono')">/usr/local/lib/mono</BaseFrameworkPathOverrideForMono>
<!-- If we found Mono reference assemblies, then use them -->
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net40'">$(BaseFrameworkPathOverrideForMono)/4.0-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net45'">$(BaseFrameworkPathOverrideForMono)/4.5-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net451'">$(BaseFrameworkPathOverrideForMono)/4.5.1-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net452'">$(BaseFrameworkPathOverrideForMono)/4.5.2-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net46'">$(BaseFrameworkPathOverrideForMono)/4.6-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net461'">$(BaseFrameworkPathOverrideForMono)/4.6.1-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net462'">$(BaseFrameworkPathOverrideForMono)/4.6.2-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net47'">$(BaseFrameworkPathOverrideForMono)/4.7-api</FrameworkPathOverride>
<FrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != '' AND '$(TargetFramework)' == 'net471'">$(BaseFrameworkPathOverrideForMono)/4.7.1-api</FrameworkPathOverride>
<EnableFrameworkPathOverride Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">true</EnableFrameworkPathOverride>
<!-- Add the Facades directory.  Not sure how else to do this. Necessary at least for .NET 4.5 -->
<AssemblySearchPaths Condition="'$(BaseFrameworkPathOverrideForMono)' != ''">$(FrameworkPathOverride)/Facades;$(AssemblySearchPaths)</AssemblySearchPaths>
</PropertyGroup>
</Project>

5. Deal with code that doesn't compile on all targets

This part is the most work and may involve trade-offs. See https://docs.microsoft.com/en-us/dotnet/core/tutorials/libraries#how-to-multitarget for the constants to use to conditionally compile code.

Fortunately people have been doing this for decades, and there are plenty of C# examples on NuGet, so I add only a couple of brief notes for beginners.

Polyfills for Type.GetTypeInfo() & PropertyInfo.GetCustomAttribute()

In dotnet core, System.Type.GetTypeInfo() provides methods which, under Framework 4, you would call directly off the System.Type itself. In fact GetTypeInfo() exists in Net45 onwards, so I've only used this for targetting net40:

//Conditional compile
#if NET40
/// <summary>
/// Extension methods to ease net40«--»netstandard code sharing.
/// Backfill netstandard/net45 methods not found in Net40
/// </summary>
public static class MultiTargetShims
{
/// <summary>Shim for <c>GetTypeInfo()</c>, returns the <see cref="Type"/> instead</summary>
/// <param name="type"></param>
/// <returns><paramref name="type"/></returns>
public static Type GetTypeInfo(this Type type) => type;

/// <summary>Shim for <c>GetCustomAttributes&lt;T%gt;</c>
/// using <see cref="MemberInfo.GetCustomAttributes(Type,bool)"/> </summary>
/// <typeparam name="T"></typeparam>
/// <param name="this"></param>
/// <returns>
/// <c><![CDATA[@this.GetCustomAttributes(typeof(T),true).Cast<T>().FirstOrDefault()]]></c>
/// </returns>
public static T GetCustomAttribute<T>(this PropertyInfo @this) where T : Attribute
{
return @this.GetCustomAttributes(typeof(T),true).Cast<T>().FirstOrDefault();
}
}
#endif

A Polyfill for DBNull

This polyfill using runtime type checking rather than conditional compilation. It's only needed if NetStandard 1.3 or earlier is one of your targets, all other targets define System.DBNull.Value.

/// <summary>
/// Polyfill because NetStandard 1.3 has no System.DBNull
/// even though NetFx has it since v1.1
/// </summary>
class DBNull
{
/// <summary>
/// Polyfill for <c>System.DBNull.Value</c>, because
/// NetStandard 1.3 is missing System.DBNull,
/// even though NetFx has it since v1.1
/// </summary>
public static readonly object Value
= Type.GetType("System.DBNull")
?.GetField("Value",
BindingFlags.Public | BindingFlags.Static)
?.GetValue(null);
}

Polyfill for FastExpressionCompiler

I use the NuGet package FastExpressionCompiler, which requires Net45 or NetStandard1.3. For Net40, I replace it with just the framework Expression.Compile(). Each file that references CompileFast() has a conditional using statement:

#if NETSTANDARD1_3 || NET45
using FastExpressionCompiler;
#endif

And I add an extension method with the negated conditional expression:

#if !NETSTANDARD1_3 && !NET45
public static class MultiTargetShims
{
/// <summary>Replace FastCompiler with <see cref="Expression{TDelegate}.Compile()"/></summary>
/// <param name="expression"></param>
/// <typeparam name="T"></typeparam>
/// <returns>T</returns>
public static T CompileFast<T>(this Expression<T> expression) => expression.Compile();
}
#endif

There's a limit of course. Sometimes you just have to draw a line, and say the cost of supporting certain targets is too high.

Using async/await on Net40

I've never done this. Instead, I've been satisfied to target net45. But the BCL Team say it can be done with the async targeting pack, if you look on that page for the Issue 'When targeting .NET 4'.

Publishing to NuGet

If you dotnet pack a multi-targeting project, you see it builds all targets, and puts them all in a single nuget package. What could be easier?

dotnet pack TestBase

Restore completed in 38.18 ms for /Users/chris/Source/Repos/TestBase/TestBase/TestBase.csproj.
TestBase ->
/Users/chris/Repos/TestBase/bin/Debug/net40/TestBase.dll
TestBase ->
/Users/chris/Repos/TestBase/bin/Debug/netstandard1.6/TestBase.dll
Successfully created package
'/Users/chris/Repos/TestBase/bin/Debug/TestBase.4.1.4.3.nupkg'.
Successfully created package
'/Users/chris/Repos/TestBase/bin/Debug/TestBase.4.1.4.3.symbols.nupkg'.

The nupkg includes all information about the dependencies for each target. Upload your nupkg to NuGet and voila! NuGet shows the world what platforms you have published and lists dependencies for each platform at the bottom of your NuGet page, in that familiar NuGet way:

Dependencies

.NETFramework 4.0
  • ExpressionToCodeLib (>= 2.7.0)
  • Newtonsoft.Json (>= 7.0.1)
NETStandard 1.6
  • ExpressionToCodeLib (>= 2.7.0)
  • FastExpressionCompiler (>= 1.7.1)
  • NETStandard.Library (>= 1.6.1)
  • Newtonsoft.Json (>= 9.0.1)
  • System.ComponentModel.Annotations (>= 4.4.1)

( Bonus tip: if you also add NuGet metadata in your csproj file then the title, description, version, release notes etc will all show correctly too. )

What versions should I aim for?

You should read the table on The Net Standard Page to understand what NetStandard means, and what compatibility there is between versions of netframework and netcore.

I learnt some of the pain points of multi-targetting when making https://github.com/chrisfcarroll/TestBase multi-target. After first trying for “everything on net40 and netstandard 1.3 or 1.6” I quickly found that wasn't achievable. For instance, AdoNet on netcore is only really viable from netstandard2 onwards. HttpClient was only easy on netstandard 1.6 and net45. I concluded it made sense to target different things in each component, according to what dependencies they have.

I heartily commend these opinions as a basis for deciding what to target:

1. It's really much cheaper–in fact, barely any work at all–for someone to rebuild their net40 project on net45 than it is for you to dual-code for net40 plus a later target.

2. netstandard 1.x and netcore 1.x were, frankly, beta products for people on the bleeding edge. Again, it is really much cheaper for someone to move a netcore 1.x / netstandard 1.x projects to netcore 2 than it is for you to code to the deficiencies of netcore 1.x. Most people on netcore 1.x were doubtless glad to upgrade to net core 2 & netstandard 2 as soon as it came out. Netcore 2/netstandard 2 is the point at which multi-targetting becames easy, because API parity is very close to 100%.

3. You don't need to multi-target at all if you can just deploy netstandard2. It's true that the .Net Standard Page suggests there have been some issues with netstandard2 on frameworks earlier than net472. I'm not aware they have been widespread or even real issues. The 'issues' I know of are this –https://github.com/dotnet/standard/issues/545–kind of thing which, if we're brutal, boil down to “the output is a bit messy and it offends my sense of tidyness.”

TL;DR

* netstandard2 alone as a single target is the cheapest and simplest option.
* net45 and netstandard2/netcore2 is the sane and happy medium when you want multi-target.
* If your code also just builds and works on net40 or netcore1.x then great, target them. If not, don't waste your life on it.

14 thoughts on “Multi-targetting .Net Framework and .Net Core in a single project”

  1. Hi! The article is pretty amazing and informative. I wonder we cannot have multi targeting for the .Net core 3.1 and .Net 4.x . Have you tried?

    1. Hi, yes, it all works just the same way. If you start with netcore 3.1 installed then instead of <TargetFrameworks>netcoreapp2.0;net45</TargetFrameworks>, you will have <TargetFrameworks>netcoreapp3.1;net45</TargetFrameworks>

  2. Chris-

    Just the right insights at just the right time … Thanks for knowing, for the effort to share in such a succinct and effective way, and for the generosity of spirit all that implies. You taught me something.

    ++Best regards,
    dovbenmen

  3. Thank you for an extremely useful article.

    The how to go about to tackle the task, for example the bit about if you have a 45 project, start by making it core, and THEN do a multitarget.

    This is JUST what I needed at this point

  4. Pingback: [c#] csproj로 .NET Core 클래스 라이브러리를 어떻게 다중 대상으로 지정합니까? - 리뷰나라
  5. I use the following sdk csproj to target net7 and net48 webapp in a single csproj.

    net7.0;net48
    disable

    bin
    enable

    bin
    enable

    bin
    Library
    false
    false
    false
    disable

    You can then switch between net48 or net7 just by using a modified web.config. For net48 use your old web.config, and for net7 use a slightly modified web.config that point to the dll in the right place:

  6. Thank you Chris for this awesome article.

    Still haven’t been able to compile my project but its getting there 🙂

Comments are closed.

Multi-targetting .Net Framework and .Net…

by Chris F Carroll read it in 18 min
14