The art of simplicity

A fter referencing a .NET Standard 2.0 project in a .NET 4.8 ASP.NET MVC project, the project failed ant runtime with the following error message: CS0012: The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Whoops! Let me explain how I fixed the problem. The solution – Part I I first tried to add the NETStandard.Library nuget package to the .NET 4.8 project but that didn’t made the error disappear.(Although I come back to this in Part II below). So I removed the nuget package again and instead I did the following: I manually edited the csproj file and added the following reference: I also updated the reference and set Copy Local=true After doing that the error disappeared and the application ran successfully on my local machine. Victory… … or not? After committing the updated project, a colleague conta...

While working on updating a (very old) existing .NET application, I noticed the following message in the build output: FastUpToDate: This project has enabled build acceleration, but not all referenced projects produce a reference assembly. Ensure projects producing the following outputs have the 'ProduceReferenceAssembly' MSBuild property set to 'true': 'C:\projects\Example.Data\bin\Debug\netstandard2.0\Example.Data.dll'. See https://aka.ms/vs-build-acceleration for more information. (Example.Business) Build acceleration; that was a topic I had talked about before . It is a feature of Visual Studio that reduces the time required to build projects(as you already could have guessed). Because the mentioned projects where targeting .NET Standard 2.0, some extra work is required to make build acceleration work. Before .NET 5 (including .NET Framework and .NET Standard), you should set ProduceReferenceAssembly to true in order to speed incremental builds. S...

While working on some class library code in C#, I noticed deprecation warnings in Visual Studio for the following NuGet packages: NuGet Gallery | Microsoft.AspNetCore.Http.Abstractions 2.2.0 NuGet Gallery | Microsoft.AspNetCore.Authentication.Abstractions 2.2.0 A look at the NuGet website confirmed this: But what now? It looked like that no alternative was mentioned anywhere… I first tried to just remove these 2 packages but now my library no longer compiled!? In the end I was able to solve it by adding a framework reference to Microsoft.AspNetCore.app inside the csproj file of my class library:

If you are new to the decorator pattern, let me start with a short explanation: Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. A common use case for decorators is to implement Aspect Oriented Programming (AOP) which allows you to implement cross-cutting concerns like logging, caching, … There are multiple ways to implement this pattern, you can manually implement it, use your DI container , use a source generator to write the boilerplate code or use a dynamic proxy that wraps call to the original class. It’s this last approach I want to focus on in this blog post. You could use the great  Castle.DynamicProxy library but for simpler use cases, there is a built-in alternative through the System.Reflection.DispatchProxy class. Let’s have a look at a small code example on how to use this class. First we need to create a Decorator class that ...

When trying to convert a Word document to PDF through the Telerik Document Processing libraries I got the error message below when I tried to convert a Word document containing a high-res image: System.InvalidOperationException   HResult=0x80131509   Message=FixedExtensibilityManager.JpegImageConverter cannot be null. The .NET Standard does not define APIs for converting images or scaling their quality. In order to export images different than Jpeg and Jpeg2000 or ImageQuality different than High you will need to reference the Telerik.Documents.ImageUtils assembly/NuGet in your project and to set its basic implementation to the FixedExtensibilityManager.JpegImageConverter property or to create a custom one inheriting the JpegImageConverterBase class. For more information go to: https://docs.telerik.com/devtools/document-processing/libraries/radpdfprocessing/cross-platform   Source=Telerik.Documents.Fixed   StackTrace:    at Telerik...

After creating a new project in Visual Studio to use for my unit tests, I added the following NuGet packages: <PackageReference Include="xunit" Version="2.4.0" /> < PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" /> However adding the second package resulted in the following warning message: Package 'xunit.runner.visualstudio 2.4.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project. So what did I do wrong? I wasn’t really thinking when creating my new project and my muscle memory made me click on a .NET Standard Class library. This is of course a great choice if you just want to build a library, but not ...

Although IAsyncEnumerable is a part of the C# 8 release and C# 8.0 is supported on .NET Core 3.x and .NET Standard 2.1 , this doesn’t have to mean that you cannot use this feature in .NET Core 2.x or the full .NET Framework. We’ll start with the following (failing to compile) code in a .NET 4.7 project and try to make it work: A .NET Standard 2.0 project doesn’t know the IAsyncEnumerable interface. So the first thing we need to do is to install the compatibility NuGet package Microsoft.Bcl.AsyncInterfaces . Now the compiler finds the IAsyncEnumerable interface but Visual Studio still complains because we are targeting C# 7.3 and asynchronous streams is a C# 8 feature. We can fix this but this requires that the following things are installed on our computer: .NET Core SDK 3.0 or MSBuild Tools 2019 Visual Studio 2019 or VSCode If these requirements are met we can update our project file and tell the compiler to use C# 8 as the language version: Unload the ...

After introducing the dynamic keyword in my .NET core codebase, the project failed to compile with the following error message: Error      CS0656 Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create' SOFACore.Messaging              C:\Projects\SOFACore\SOFACore.Messaging\MessagingModule.cs     To fix it I had to add the Microsoft.CSharp nuget package. This package is necessary to use the C# dynamic data type in a .NET Standard library.

One of the tricks I applied when creating .NET applications was introducing a GlobalAssemblyInfo.cs file. This class contained all the shared assembly information and was referenced in the AssemblyInfo.cs file of all my projects. It allowed me to update the general settings like AssemblyVersion in one place. However in .NET Core/.NET Standard, the AssemblyVersion.cs file no longer exists.Instead you can specify these settings using the Package tab of your project settings. But what if you want to still share some settings among your projects? You can still do this by adding a shared project file: Step 1 – Add a solution folder to your solution. Step 2 – Right click on the solution folder, choose Add –> New Item –> Text File. Rename the text file to GlobalAssemblyInfo.proj. Step 3 -  Open the proj file and add the settings you want: Step 4 – Add the settings to your other projects. For each project, right click on your project, choose Edit Projec...

The NHibernate team is back on a roll! After a previous announcement where they released the long awaited(pun intended) async/await support, they are back again with some other great news. NHibernate 5.1 is released with the support of .NET Core 2.0 and .NET Standard 2.0. I’m missing way too many features in EF Core, so I’m glad that at least we got another option back.

One of the nice additions to the .NET documentation is the API Browser . It gives you a quick and easy way to find a specify method or function throughout multiple versions of .NET(Core). It is not limited to the Base Class Library but also includes search options for specific SDKs like Xamarin, Azure, Roslyn …

In .NET Standard projects, there is an AssemblyInfo class built-in , so you no longer need a separate AssemblyInfo.cs file in your project Properties. But what if you want to use the InternalsVisibleToAttribute ? This was one of the attributes I used a lot to expose the internals of my Assembly to my test projects. Turns out that it doesn’t matter really where you put this attribute. It is applied at the assembly level, so you can include in any source code file you like. Using the AssemblyInfo file was just a convenience. So what I did, was creating an empty .cs file and add the following code:

In a ‘classic’ .NET project, you have an AssemblyInfo.cs file. This file contains all kind of information about your assembly After upgrading a classic .NET project to .NET Standard, I started to get errors about some of the properties inside the AssemblyInfo.cs file: A .NET Standard project already has the AssemblyInfo information built-in. So after upgrading you end up with 2 AssemblyInfo specifications, leading to the errors above. The solution is to remove the original AssemblyInfo.cs file in the Properties folder. Remark: If you want to change the assembly information, you now have to use the Package tab inside your Project Properties .

With the release of .NET Core 2.0 and the .NET Standard 2.0 specification, it’s time to check if I can retarget some of my old libraries to .NET Standard 2.0. The tool you need is the .NET Portability Analyzer: https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer After downloading and installing the Visual Studio extension, it is time to configure it first: Open the project you want to analyze in Visual Studio Go to Tools –> Options and click on the .NET Portability Analyzer from the left menu Select your Target Platforms and the Output formats of the generated report and click OK . Now you can right click on a specific project or your solution and choose Analyze Assembly/Project Portability . After the analysis has completed you’ll get a report that contains a nice summary, a long list of details and a list of missing assemblies:

After installing Visual Studio 2017 Update 15.3 and the .NET Core 2.0 SDK I thought I was finally ready to ‘upgrade’ some of my projects to .NET Standard 2.0. I right clicked on my project, selected Properties and tried to change the Target Framework on the Application tab. Unfortunately I didn’t see a .NET Standard 2.0 option in the list. OK, let’s try a different approach. I right clicked on the project and choose Edit .csproj file and updated the TargetFramework to netstandard2.0 directly in the project file This worked but resulted in a set of strange error messages when I tried to compile a .NET Core project that was referencing this library. In the end it turned out that I had a global.json file that was the root cause of my problems. The global.json file defines which version of the .NET Core SDK to use: { "sdk": { "version": "1.0.0" } } When you run dotnet new or dotnet build , the dotnet host looks in the current fol...