2

I am starting a new Project with Blazor Asp.NET Core 3.1 and all the cool new shiny fancy stuff. But for one interface to a client I still need a solution that supports WCF and thereby supports net framework 4.8.

So if I set my api Project (so far net standard 2.0) to net standard 2.1 I get the error Net Framework does not support netstandard 2.1.

Question 1: Is there a way to still support nullable types in net framework? (Or a viable way to support wcf in net core - I need wcf since a libary I need hosts one) Question 2: If not: Could I create a second net standard 2.0 Project besides my new net standard 2.1 project which still supports the old Net Framework and compiles the non nullable types to a assembly that can be loaded by net framework? Then I could use the Non-Nullable Libary all netcore projects and the net Standard 2.0 version for my WCF Service.

Question 3: Some better Ideas?

Pavel Anikhouski
  • 21,776
  • 12
  • 51
  • 66
Michael P
  • 241
  • 3
  • 8
  • https://www.meziantou.net/how-to-use-nullable-reference-types-in-dotnet-standard-2-0-and-dotnet-.htm – DavidG Nov 29 '19 at 09:39
  • I think you can add a Tag in the csproj File of your .Net Framework project and set it to "8.0". To enable nullable types you also have to add the Tag and set it to "enable". Nevertheless, this will only work if you use Visual Studio 2019 (not sure which dedicated version) and you will not be able to use the full set of changes from C# 8. (e.g. default interface implementation will not work). – rekcul Nov 29 '19 at 10:01
  • Thanks GSerg, didn't find the post beforehand. My Solution is a bit different so I posted the answer below – Michael P Nov 29 '19 at 12:58

1 Answers1

0

Edit: Thanks to @JohnSkeet for pointing out a easier Solution:

Replace in the csproj of your Net Standard libary the TargetFramework with TargetFrameworks

<TargetFrameworks>net461;netstandard2.1</TargetFrameworks>

Info: Net461 is the first netFramework version supporting Net Standard 2.0 libraries.

If you need net framework or netcore specific references you can as he pointed out use MS Build Actions in your csproj file https://github.com/googleapis/gax-dotnet/blob/8c5682ad53f5d93716df5ab762c6ce4790edad72/Google.Api.Gax/Google.Api.Gax.csproj#L25

<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <Reference Include="System.Net.Http" />
</ItemGroup>

The only reason below to use my old solution if you are dead set that you only want to use the Visual Studio UI and not modify the csproj with a texteditor for custom references or NuGetPackages.

Thanks Greetings Michael

Old Solution

Hello I think I found a solution to my Problem:

  • Create a Shared Project Named MyLibrary.Api (A Shared project since a .NET Standard 2.0 and a .NET Standard 2.1 Project in the same folder cause errors https://github.com/dotnet/sdk/issues/2720)

  • Also the Shared Project should have the name of the root namespace, since Shared Projects can't have default namespaces and all new files get the name of the project as namespace.

  • Add a .Net Standard Class Library MyLibrary.Api.Core and Change its Target to to Net Standard 2.1 in (For .NET Core Projects)

  • Reference MyLibary.Api under Add-Reference->Shared Projects, now at compiliation all Files of the Shared Project get compiled into MyLibrary.Api.Core.

  • Add a .Net Standard Class Library MyLibrary.Api.NetFramework, Leave it at Target Net Standard 2.0 (This is for Net Framework Projects

  • Also add a refererence to to MyLibrary.Api Shared Project.
  • Add the latest Version of Microsoft.Net.Compilers NuGet Package to the NetFramework Project

For testing:

  • Add a NetCore Console Project MyLibrary.Console.Core and reference the MyLibrary.Api.Core.
  • Add a netFramework Console Project MyLibrary.Console.NetFramework and reference MyLibrary.Api.netFramework. Set the .NET Framework Version to at least 4.6.1 because lower versions do not support .Net Standard 2.0 Projects.

Now Activate C# 8.0

Now in all Projects in the .csproj File (Except the MyLibrary.Api Shared Project) add to the first PropertyGroup LangVersion and Nullable (Nullable is not nessary it just turns on nullable types by default, if you don't add it you need to add in Every code file with #nullable enabled):

  <PropertyGroup>
    <LangVersion>8.0</LangVersion>
    <Nullable>enable</Nullable>
    ...

In the .NET Framework Project I added a new PropertyGroup Section with LangVersion but I think that is not nessary.

Hope this also helps others.

My Solution at people who want to use NetStandard 2.1 Advantages for their .net core projects but still want to use a version of the library in .NET Framework and can even use nullable types in .NET Framework.

Also this way you compile two dlls. One for NetFramework and one for .NET Core in NetStandard 2.1

Michael P
  • 241
  • 3
  • 8
  • 2
    It looks like you're making this much more complicated than you need to. You can create a single class library with `net40;netstandard2.1`, set LangVersion to 8.0 and enable nullable reference types. – Jon Skeet Nov 29 '19 at 12:59
  • But when I make just one Project I can't add seperate references to the NetStandard 2.0 and 2.1 Project seperatly? For Example the Reference to Microsoft.Net.Compilers just for the Net Standard 2.0 Project? – Michael P Nov 29 '19 at 13:03
  • You can use conditions in MSBuild files - see https://github.com/googleapis/gax-dotnet/blob/8c5682ad53f5d93716df5ab762c6ce4790edad72/Google.Api.Gax/Google.Api.Gax.csproj#L25 for example. – Jon Skeet Nov 29 '19 at 13:23
  • Thanks for that. So either it is two 2 Class Projects and a Shared Project or I use MSBuild in the .csproj Files. I am about to Migrate my big Project where I also got the following Error: Package Microsoft.EntityFrameworkCore 3.0.0-preview5.19227.1 is not compatible with net40 (.NETFramework,Version=v4.0). There I followed the target frameworks approach first and can decide if I want to use MSBuild or 3 Projects. – Michael P Nov 29 '19 at 13:36
  • You're already using MSBuild. The csproj files *are* MSBuild files. It's not like I'm suggesting anything unusual in the project files - just adding a condition in the reference. No extra libraries needed or anything like that. – Jon Skeet Nov 29 '19 at 18:32
  • I ended up doing it your way, the entity framework error came from selecting net40 instead of net461. Yes I know that csproj is ms build and I agree with you doing it the ms build way is easier. Also so far most git packages still support net framework and core so mostly it is not nessesary to have ms build conditions The only last reason to use the old approach is the UI reason maybe if I open a coworker project I don't check first if the csproj has been modified in texteditor. Figuring out how to add a reference conditionally can be difficult. But therefore are documentation and Readme.md :) – Michael P Nov 30 '19 at 21:33