Dangl.Blog();

Installing .NET 9 Alongside Older Versions on Ubuntu 22.04

Fri, 29 Nov 2024 11:29:43 Z

With the recently release .NET 9, Microsoft has changed how they're publishing packages for Linux distributions. Previously, there was a Microsoft managed package repository available from which you could easily install different .NET versions, making it especially easy for CI agents to keep multiple .NET versions installed and updated.

However, starting with .NET 9, Microsoft no longer provides a feed for their distributions. So if you need the SDK or just the runtime, you need to use a feed managed by Canonical (the company behind Ubuntu). The problem is, there's no feed on which you can get multiple versions, e.g. .NET 8 and .NET 9 combined. Also, you can't just install from two different repositories, since the packages will have mutually exclusive dependencies, prohibiting you from installing .NET 8 and 9 at the same time. Also, the Ubuntu repositories seem to be a bit behind, so you could have to wait up to one week to get the latest updates for your SDKs.
I didn't properly dive into the reasons behind this change, I think it's mostly Microsoft wanting to integrate their .NET distribution into more official channels, but from a developer perspective, that doesn't seem very ideal for me.

So, yesterday evening, I tried to figure out how to get .NET 9 running while keeping all the other versions installed. Even though they're out of support, sometimes you just need to update an on-off CLI tool with a bugfix or new feature without having to update the whole project and the CI pipeline. Also, since both .NET 8 and .NET 9 are still in active support, we plan to also run tests for our products on both - so having them all on our CI agents was required.

There was no way that I found how to work with feeds, but luckily, you can just use the dotnet-install.sh script for manual SDK installations. I found it pretty easy to use, but there's a gotcha: If you've already got some .NET versions installed, they're probably by default in a different directory than what the installation script uses. In that case, though, before installation, you can simply run dotnet --list-sdks to get an output like this:
dotnet --list-sdks
6.0.428 [/usr/share/dotnet/sdk]
7.0.410 [/usr/share/dotnet/sdk]
8.0.404 [/usr/share/dotnet/sdk]

Here, we see that .NET is installed to /usr/share/dotnet, which we can then pass to the installation script as directory like this:
./dotnet-install.sh --install-dir /usr/share/dotnet --channel 9.0

Running dotnet --list-sdks again should now list .NET 9 as well, and you're good to go. There's no need to set any more environment variables. The only thing to keep in mind is that you now have to manually update .NET via the install script, since apt-get won't do those for the .NET 9 sdk now.

Happy developing!

ASP.NET Core Locally Serving Outdated Dev Certificate

Wed, 17 May 2023 20:19:36 Z

Today, I was trying to run one of our apps locally. It's a fairly small service, that's only receiving updates every few months, and all the testing and deployment happens in CI, so it hasn't been run locally for quite some time. But, when I started it, it tried to serve an expired certificate, so Chrome showed me a warning about the site not being secure.

With ASP.NET Core, the development workflow is quite nice. You can easily use self signed certificates for working with localhost, and dotnet takes care of managing all that. Yet, somehow, it served me a certificate that expired almost three years ago. Even after regenerating the dev certificates locally, I had the same error, so I looked into the configuration.

Turns out, I had this configuration option set in the user secrets on that machine: kestrel:certificates:development:password

User secrets are a way of managing not really sensitive but developer or machine specific configs for ASP.NET Core projects. The option above, with using a set password for a certificate, resulted in the app not automatically choosing the current dev certificate but instead one that expired long ago. So, quick fix when you know where to look😀

Happy encrypting!

Cancel Obsolete Http Requests in Rx.NET with the Switch Operator

Thu, 30 Jan 2020 19:51:54 Z

Using Observables in Rx.NET is a super fun and efficient way to organize data flows in your applications. While it's widely used for front end development - it's basically a core part of Angular - it's actually a great library to use in any projects where you're using loosely coupled services and state management.

One of these use cases is having a filtered list. Imagine you've got a small app that shows you some table, along with a single text field for filtering. Imagine also that this list is fed from some asynchronous source, so it's not an in memory filter operation but maybe the response from a Http call.

Now, when you start typing in this box, what should happen? In the simplest case, without delays or checks, every letter typed in that filter box sends a Http request. That's probably a bit of an unoptimized approach, but it should work. This could look something like the following:

What's actually happening is that you're creating a stream of events in your code. Whenever you change the url, you're sending a request. When that request finishes, you're updating the list. The problem now comes when the requests don't come in the order they've been sent. Your user might have typed pizza, deleted that and then again typed pasta. If the first request, for really any reason, was delayed, you might have the situation where you're sowing pizza results to pasta guys!

To resolve this, you want to track which requests have been sent and discard all but the latest one. In rxjs, you'd be using the switchMap operator. In Rx.NET, it's simply called Switch and expects you to either provide a Task or another IObservable:

What's happening here is that only the latest call will come through. So when you've got more than one request running at the same time, you're never again getting stale data.

If you want to dive deeper into this, you can take a look at the source code for LightQuery, which uses this approach in conjunction with CancellationTokens. I'd also like to thank Brandon for providing a great answer at StackOverflow, which really goes into detail!

Hope you're going to have fun with Rx.NET!

Accessing the Revit API in Callbacks from Other Threads

Tue, 21 Jan 2020 11:41:25 Z

Just this week, I've been doing some work with a plugin for Autodesk Revit. The general idea of the plugin is to show a window which basically just wraps a Chromium embedded browser to display a web UI and interact with the Revit API. The interaction itself is pretty straightforward - with CefSharp, you can bind JavaScript objects in the browser to .NET objects in the plugin and thus access Revit features.

We've implemented that by having a singleton on the .NET side that listens to commands from the browser. The first, possibly naive approach, was to simply call our code whenever we got a message:

However, this didn't work. While all the data was transferred correctly, whenever we accessed certain features of the Revit API, we got a SEHException from unmanaged code in Revit. A quick Google search yielded this bit of info: "SEHExceptions are always indications of a bug in Revit.". Ok, we thought, but that's super basic stuff we're accessing, there's probably not an undiscovered bug with Revit here.

Luckily, debugging this gave us a bit more info: The API is working correctly when accessed from the main thread, but throws when accessed by another one. So even though we weren't doing any UI operations, this seemed to be the root cause of our issue. Since you also can't invoke something on the main thread in Revit, with Application.Current.Dispatcher not being set, we fell back to using the UIApplication.Idling event and a stack to invoke our methods on the main thread:

This cost us a few hours, so I hope it's helpful to others!

Happy integrating!

Handling DateTimeOffset in SQLite with Entity Framework Core

Tue, 15 Oct 2019 12:07:18 Z

Recently, ASP.NET Core 3.0 was released, along with all it's supporting libraries like Entity Framework Core. In the process of migrating Dangl.Identity over to the new version, I discovered that some integration tests failed with this message:

System.NotSupportedException : SQLite cannot order by expressions of type 'DateTimeOffset'. Convert the values to a supported type or use LINQ to Objects to order the results.

The error message is pretty clear - SQLite with Entity Framework Core 3.0 does no longer support some operations when using DateTimeOffset properties in database models, as specified in the official Microsoft Guidelines on limitations with SQLite.

The recommendation to switch to a supported type is great, but what to use? Falling back to regular DateTime, you'll lose the time zone information. Even if you're storing only UTC dates, while ensuring you're never making an error anywhere you touch dates, Entity Framework will always return a DateTimeKind.Unspecified when retrieving values from the database. While you can work around that with some conversion via an EntityMaterializerSource, this feels awkward and error prone.

Luckily, aptly named user bugproof on GitHub posted a great snippet that attaches a built-in converter for all properties in your database model. Here's how I've implemented it in my database context class:

The only drawback is that the conversion only supports up to millisecond precision, but for most uses cases this is likely not a problem. In case you're comparing values, simply trim the last three digits from your values in your test code and you're good to go:

Happy modelling!

Impact of O(n²) Runtime in Practice - With Before & After Results

Fri, 14 Jun 2019 13:44:33 Z

With AVACloud, we're providing a hosted SaaS service for our GAEB & AVA .Net Libraries, a project calculation module & data exchange format for the construction industry.

Among the paid service, there are some free offerings for AVACloud for limited use cases. With that, users often convert from the various data formats to Excel. In our monitoring, we noticed some irregularities from the free service. Conversions usually take just tens or a few hundreds of milliseconds. But we had some that took about half an hour, way to long for any one user to be happy.

Luckily, we've been contact by the user and were asked for assistance. After a bit of investigation and profiling, we quickly found the culprit - we had a part in the conversion process that had O(n²) runtime:

The graph above shows the run time of the complete conversion process by the amount of elements within a parent container. It's a pretty nice O(n²) graph, at least visually, not so much for actual users😊

The thing is, this wasn't really noticed anytime before. In practice, service specifications for construction projects look like this:

So while real construction projects often have up to a few hundred of positions, sometimes even a few thousand, they're structured in a tree so that each container itself only has at most tens of child elements.

The offending part of the code actually worked on the level of a single container. It did perform a validity check when adding a new element, by checking against all siblings. This wasn't a problem until one day, a customer had a single container with over 40.000 elements that really triggered this...

The fix was rather easy, it basically just amounted to introducing a cache. And thus, the performance quickly became linear:

In that case, the dotted red line is the previous, O(n²) runtime, while blue represents the situation after the fix. Even more impressive is a zoomed view, which shows just how massive the difference from such an oversight can be:

In hindsight, the error was very obvious. It wasn't noticed because typical data sets were always small enough so this never really was a problem, until it one day was... Luckily, the fix could be implemented very quickly, and I got a satisfied user and some material for a blog post out of it😊

Happy optimizing!

Transform your ASP.NET Core Website into a Single File Executable Desktop App

Thu, 21 Mar 2019 16:34:07 Z

Using web technologies to create desktop apps has been around for quite some time now, with frameworks like Electron being mature and used in lots of products, such as Spotify and Slack. I've only ever used it for side projects, until finally this week a customer asked me if I could provide a desktop application of our popular WebGAEB converter. Of course I could! So I sat down at my computer and made an ASP.NET Core MVC app into a desktop app, bundled as a single executable file.

This approach works by bundling everything together - your frontend, sometimes even your ASP.NET Core backend server and it's own embedded browser. This has been a bit polarizing in the last years among various communities. It's great for developer productivity, but it's also a very wasteful way to use a computers resources.

However, I'm leaning heavily towards productivity to be able to quickly build features our users care about. I could have built a dedicated .NET WPF app from scratch, or I could just use Electron and be done in two hours. That's what I'd like to share with you in this blog post.

Build Script

The following is the complete build target for Nuke Build. You're free to use something else to orchestrate your build, but even if you're unfamiliar with this tool, you'll see that it's quite straightforward:

I'll explain the script step-by-step, but I will skip the trivial parts, like copying the files to the output directory. If anything is unclear, please leave a comment!

Configure Electron.NET

Electron.NET is an integration for the the Electron package with ASP.NET Core. It's got a great documentation at it's project site, so I'm not going to deeply into the details.

When you set up your ASP.NET Core project, you're using the Electron.NET package to instrument the interaction with the Electron shell. The result will be a self contained deployment that bundles the Kestrel server into your app.

The Dangl.WebGAEB solution uses a Standalone configuration which sets up some things differently in contrast to the web deployment. For example, I'm using embedded services instead of calling a REST API. This heavily depends on your app as a whole and is not covered in this post.

Build a Single Executable File with Warp

While Electron itself is cool and all, it's Node.js heritage really shows: After the app is created, you'll have a folder with tons of files. This isn't a problem if you're doing some big business app with an installer, but I simply want a single executable file, .exe for Windows in my case. I remembered the Warp project, which I've read about some time ago. This tool takes a folder, bundles it into a single executable file and lets you specify an entry point.

Change the Generated Exe to Hide its Console Window

One drawback to this approach is that warp internally starts your ASP.NET Core application, which itself is a console host. The final Electron window is then again launched from your ASP.NET Core server. This means there will be an additional console window present, besides your app. This won't fly with users, so it has to be disabled.

Truth is, I'm not really familiar with how this works. But there's some metadata in executable files on Windows. One of them is whether or not an .exe should show it's console host. Unfortunately, this isn't configurable until .NET Core 3.0, so we have to find another way. Fortunately, there's a great wiki page on the AvaloniaUI GitHub page. It's explain how the editbin.exe utility, which is included in Visual Studio, can be used to patch your executable. So just go find editbin.exe in your Visual Studio installation folder and you're good to go!

Upload your Artifacts

Your final result will be a single executable file. Which contains your ASP.NET Core backend, the Kestrel webserver, your frontend, and last but not least, a full web browser. I see where the critics saying this is wasteful are coming from, but it just works amazingly well😊

This example is pushing the artifacts, along with some documentation, to DanglDocu. There, my customers get notified about new releases and can download it. For you, that's probably different!

The Result

You can check out the online version of WebGAEB. It's basically the same as the GAEB converter on this site, except it's in German. The cleverly named "Desktop Edition" looks like this and runs 100% locally:

Happy packaging!

Remove Duplicate Enum Entries in Swagger Documents with NSwag in ASP.NET Core

Thu, 03 Jan 2019 20:18:36 Z

NSwag and NJsonSchema are great tools that make it super easy to integrate Swagger / OpenAPI specification documents in your ASP.NET Core apps.

Basically, you simply define your web server backend and then all your API endpoints and models are automatically available for anyone to generate clients in their favorite language.

In such scenarios, NSwag is often configured to use a StringEnumConverter, meaning that enum values are meant to be serialized as strings when they're sent over the wire. However, there's one nasty thing that's allowed by the C# specification when it comes to this:

You might actually have two different string representations that both match an internally used integer identifier. That becomes a problem when you're using string serialization for enumerations but track them internally by their integer id.

In NJsonSchema, for example, there's a small bug that would lead to TemporaryRedirect being serialized twice in this case. That's sometimes not a problem, but strongly typed languages like C# or Java will fail to compile the generated client code.

To solve this, you can simply remove these distinct values in a PostProcess action when you're setting up NSwag for your ASP.NET Core application:

Happy serializing!

Accessing NuGet Package Paths in Your .NET SDK Based csproj Files

Wed, 21 Nov 2018 16:52:50 Z

With the switch to the SDK based *.csproj format for Visual Studio projects, the file format was greatly improved. One of the biggest new features is the usage of PackageReference to simply reference NuGet packages with a single entry. In contrast to the old way, all NuGet packages are typically downloaded to some default folder, usually %USERPROFILE%\.nuget\packages.

Recently, with the latest Visual Studio 2017 V15.9, the GeneratePathProperty was introduced. It allows you to define a build variable that holds the path to the NuGet package folder. It's useful if you want to access files in the NuGet package in your build steps. This could be, for example, running a CLI tool or, in my case, copying some files from the package to your output path.

For example, the xBim toolkit is an Open Source collection of libraries that let you work with digital building models. Some of the more compute intensive operations are performed via a C++ dll that is loaded at runtime. For this, xBim requires the compiled dlls to be present in the output folder so it can find and load them.

In my xbim-meets-angular demo, I have a small component that lets you upload IFC building model files, which are then tesselated and displayed right in the browser. For this, I want the C++ dlls to be copied to the build and publish output directories. I used to have a PowerShell build script do that, but now it's really simple to do with the project system itself:

Both libraries, for x86 and x64, are copied to the build and publish output in this snippet. No other code is required! You just need to set GeneratePathProperty="true" on the package reference, then the variable $(PkgXbim_Geometry) will point to the path of the package - including its version. Dots in the package name are simply replaced with underscores, so the variable for the package Xbim.Geometry becomes PkgXbim_Geometry.

There's one small thing, though: Currently, it seems to work only for project types using the Microsoft.NET.Sdk.Web SDK, regular ones don't work yet. But support is just around the corner. In the meantime, you can simply use dotnet build instead of MSBuild if you're compiling for the classic .NET framework.

Happy building!

Integration Testing In Memory Compiled Code with Roslyn - Visual Studio 2017 Edition

Sat, 03 Feb 2018 16:12:43 Z

Have you ever written code to generate code? Probably.

Have you ever written proper integration tests for that? Probably not.

This is a follow up post to last years article, which was still about the now deprecated project.json format

Everyone's done it - write code that writes code. Be it for converting from an esoteric Domain Specific Language, generating from a set of known data or for any other reason. It happens a lot, it's useful a lot, but it's not tested a lot. Testing such code has always been inconvenient, did involve a lot of disk IO and quite often relied on scripts and manual work. Luckily, with dotnets Roslyn compiler, there are NuGet packages for code analysis and compilation available that make all of this so easy!

The complete sample repository is available at GitHub. Here are the interesting parts:

It starts with the CodeGenerator which does what it's name implies - it creates code. In this case, it's a simple class that has one method: AddIntegers().

This InMemoreCompilation.Tests.csproj is a regular, xUnit enabled, project configuration file. There is a reference to the Microsoft.CodeAnalysis.CSharp package. That one will bring the Roslyn API to your project.

The actual integration test class is quite big, so let's break it down into it's functional units:

GenerateCode() does just that - it gets the string representation of the sourcecode
CreateCompilation() takes the sourcecode, adds assembly references and turns it into a CSharpCompilation object
CompileAndLoadAssembly() now invokes the Roslyn API to compile onto a MemoryStream, then loads it and makes the content available
Finally, CallCalculatorMethod() uses reflection on the newly generated assembly and invokes the AddIntegers() method

This is a really interesting approach on tackling code generation. While I got the initial bits to set this up from Tugberk Ugurlus blog, I've had a project of my own where I did some heavy code generation (for correcting Xml documents) where I needed that. There's also code that works both in .Net Core and the full .Net framework.

Happy compiling!

xUnit Tests Not Recognizing Target Framework Microsoft.NETCore.App 2.0

Thu, 30 Nov 2017 11:05:26 Z

My preferred unit testing framework for .Net Core, xUnit, has had quite a few changes for the 2.3 release. One of them was how the tests libraries themselves are executed and how the framework version was determined.

This becomes a problem when you have multiple frameworks for version 2.0 installed, e.g. 2.0.0 and 2.0.3. The compiler sets the version of .Net Core App to 2.0 when you target netcoreapp2.0, but then fails to resolve it to 2.0.0. livarcocc explains it here. You'll receive error messages like this when you attempt to run xUnit:

This isn't a bug within xUnit, but rather with the dotnet CLI, but xUnit still has a patch for this planned. In the meantime, you can set the RuntimeFrameworkVersion attribute in your *.csproj file to a fixed version when running tests for netcoreapp2.0:

Happy testing!

Building Hacky but Free Graphs and Charts in Xamarin.Forms with Chart.js

Tue, 31 Oct 2017 18:12:31 Z

Just recently, I bought a used Mac Mini to tip my toes into mobile development. After doing a bit of research, there's mostly three viable options for doing cross-platform mobile development: Either React Native, Cordova or Xamarin. I figured that due to my knowledge in C#, Xamarin would be a nice fit. However, there's way less components and libraries than in the node eco system, which is especially true for charts. There are commercial options available, but I didn't find a free, open source charts library.

But there's help: In Xamarin.Forms, you can easily use a WebView to display, well, web or Html content. It works surprisingly well, and you can even extend it to communicate between your .Net code and JavaScript in the Browser. So I tried it out and threw a bit of a proof-of-concept together:

The Xaml for the page is quite simple. It's just a WebView that's bound to the ReportHtml property of the ViewModel.

Then there's the ViewModel:

It's a bit long, since I've cramped everything in a single file. To summarize:

Build a valid Html document
Include Chart.js
Add your Chart.js configuration

The sample requires some adjusting before you can use it. It's using PropertyChanged.Fody and Dan Siegels great Prism Template Pack, so check these repos out if something isn't clear with the code.

After that, you see this page:

Happy charting!

Using ANTLR4 MSBuild Tasks in Visual Studio 2017 and with the Dotnet CLI

Fri, 11 Aug 2017 23:52:06 Z

With the latest 4.6.5-beta001 release of ANTLR4 for C#, it's finally easy again to work with ANTLR grammars in Visual Studio. Since the introduction of the project.json format, you had to write custom scripts to generate your lexers and parsers, cluttering your workspace with lots of generated code. Not anymore! It's now as simple as adding Antlr4 items to your csproj file, point them to your grammar files and the MSBuild process takes care of it. Generated files are again stored in the obj/ folder and don't mess with your project structure.

Here's an example of the new build tasks:

You can use the optional PropertyGroup and set Antlr4UseCSharpGenerator to true to circumvent the Java tooling altogether and rely on the new, native C# code generation. This process works seamlessly both from within Visual Studio 2017 as well as the dotnet CLI. I've got a demo project for you to dive right in on GitHub.

Remember, you only have to use the pre-release Antlr4.CodeGenerator as a build time dependency, the runtime can be kept at the latest stable version, not blocking you if you have to use stable versions or create packages of your own.

Happy parsing!

EntityFrameworkCore.Sqlite in a Full .Net Framework xUnit Class Library

Thu, 29 Jun 2017 10:15:36 Z

While migrating a still project.json based project to Visual Studio 2017s *.csproj format, an integration tests project gave me a bit of a headache:

It's been a class library project that used the Microsoft.AspNetCore.TestHost package for integration testing API calls. Since I wanted to make use of a relational database for data integrity and validation, I chose to use Microsoft.EntityFrameworkCore.Sqlite as database provider. After migration, however, I got a lot of System.DllNotFoundException telling me that sqlite3.dll could not be loaded.

I have been unable to find any real cause for the issue, but it's got something to do with the SQLite NuGet package dlls not being copied to the output directory when targeting the full .Net Framework in a class library. Kinda, sorta, somehow. It comes up in issues where people couldn't run dotnet ef CLI commands without a startup project.

Luckily, I could fix it:

I made a copySQLiteDlls.ps1 script that copied the required Dlls in a Dependencies folder in the solution root

I added the Dlls to be included in the output on compilation in the *.csproj file:

Just make sure to run the first script after a package restore or before running your tests and you should be fine. There should now be an x64 and x86 folder in your output directory containing the sqlite3.dll files.

Happy integration!

Integration Testing In Memory Compiled Code with Roslyn

Fri, 07 Apr 2017 19:20:49 Z

Have you ever written code to generate code? Probably.

Have you ever written proper integration tests for that? Probably not.

There is now a follow up article that uses the latest .Net project format in Visual Studio 2017. This post is still displaying the now deprecated project.json configuration

The complete sample repository is available at GitHub. Here are the interesting parts:

It starts with the CodeGenerator which does what it's name implies - it creates code. In this case, it's a simple class that has one method: AddIntegers().

This project.json is a regular, xUnit enabled, configuration file. There is a reference to the Microsoft.CodeAnalysis.CSharp package. That one will bring the Roslyn API to your project.

The actual integration test class is quite big, so let's break it down into it's functional units:

GenerateCode() does just that - it gets the string representation of the sourcecode
CreateCompilation() takes the sourcecode, adds assembly references and turns it into a CSharpCompilation object
CompileAndLoadAssembly() now invokes the Roslyn API to compile onto a MemoryStream, then loads it and makes the content available
Finally, CallCalculatorMethod() uses reflection on the newly generated assembly and invokes the AddIntegers() method

Happy compiling!

Using xBim Geometry Conversion in the New Asp.Net Project Format

Thu, 02 Feb 2017 16:38:19 Z

Recently at work, we were evaluating a few options to render building models in the browser. Building Information Modeling (BIM) in interoperability scenarios is done via Industry Foundation Classes, mostly in the STEP Physical File format. The schema is quite huge and complex with all the things you have to consider, so we were glad to find the xBim open source project on GitHub. They've got both projects to visualize building models in the browser with WebGL as well as conversion tools to create the binary-formatted geometry mesh. To achieve that, native C++ libraries are dynamically loaded (so no .Net Core compatibility) which must be present in the bin folder. The C++ libraries are expected either in the same folder as the application binaries or in a x64 (or x86, respectively) sub folder (See here for more details). In regular projects, the xBim.Geometry NuGet package adds a build task to copy the dlls into the build output folder, but this doesn't work with the new tooling. You can, however, get it to work in Visual Studio 2015 by taking care of supplying the interop dlls yourself.

Add a PowerShell file to the root of your project that takes care of copying the C++ dlls from the NuGet package cache to your project:

Now you need to define three things in the project.json file:

A precompile command that invokes the above PowerShell script before each build. That comes with the side effect of breaking incremental build, but there's no way around that currently.
buildOptions:copyToOutput:mappings entry to copy the interop dlls to the build output folder
publishOptions:mappings to copy the interop dlls to the publish output folder (and I have no idea why this doesn't already take the buildOptions into account, but that's the way it is I guess)

Here's a (shortened) project.json file with the configuration:

I've created a small sample web app that's also available on GitHub. This app already makes use of Angular 2 and the TypeScript version of xBimWebUI which isn't yet merged in the original repository, so you should take a look at my fork until it's accepted.

Happy meshing!

Running xUnit Tests for Multiple Frameworks

Wed, 28 Sep 2016 22:27:18 Z

Say you're building some class library with the intent to be used in multiple frameworks, like .Net Core and .Net (Full). Since NETStandard still hasn't really gotten off yet (and I think you should be waiting for 2.0 before you can use it as sole target), you may want to have your tests run for every supported framework.

With xUnit, that's actually quite easy! Just have your test projects project.json file target multiple frameworks like in the example below:

{
  "dependencies": {
    "xunit": "2.2.0-beta2-build3300",
    "dotnet-test-xunit": "2.2.0-preview2-build1029",
  },
  "testRunner": "xunit",
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        }
      }
    },
    "net461": {}
  }
}

Then run dotnet test and you'll see that both framework targets are being compiled and run:

dotnet test

Compiling Dangl.Calculator for .NETStandard,Version=v1.4
...
Compiling Dangl.Calculator.Tests for .NETCoreApp,Version=v1.0
...
=== TEST EXECUTION SUMMARY ===
   Dangl.Calculator.Tests  Total: 168, Errors: 0, Failed: 0, Skipped: 0, Time: 0,521s
...
Compiling Dangl.Calculator.Tests for .NETFramework,Version=v4.6.1
...
=== TEST EXECUTION SUMMARY ===
   Dangl.Calculator.Tests  Total: 168, Errors: 0, Failed: 0, Skipped: 0, Time: 0,324s
SUMMARY: Total: 2 targets, Passed: 2, Failed: 0.

The dotnet test runner takes care of compiling the project both for .NETCoreApp,Version=v1.0 and .NETFramework,Version=v4.6.1 and runs the test suite for each. It also works with code coverage, so branches from conditional compilation are covered as well.

Happy Testing=)

Missing Encoding in .Net Core Apps

Mon, 26 Sep 2016 21:23:54 Z

So, today, while migrating a project to .Net Core, I've encountered a failing unit test that told me this:

Code page 1252 ist the Western European standard code page, but I was obviously missing it. That's where I found svicks post on StackOverflow, which basically explained what went wrong:

In .Net Core, available encodings need to be registered before you can access them.

First, you need to import the System.Text.Encoding.CodePages dependency and define a compilation value (I chose NETCORE) in your project.json:

"frameworks": {
    "netcoreapp1.0": {
      "imports": [
        "dnxcore50",
        "portable-net45+win8"
      ],
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.1",
          "type": "platform"
        },
        "System.Text.Encoding.CodePages": "4.0.1"
      },
      "buildOptions": {
        "define": [ "NETCORE" ]
      }
    },
    "net461": {}
  }

Next, register the provider from within your code via conditional compilation:

#if NETCORE
                    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
#endif

Happy Encoding=)