Multi-processor support and .Net

Core support in Windows is tied to the notion of processor groups. For historical reason, a group is made of up to 64 cores (related to affinity mask).

Until version 4.0, .Net was only using first group (ref.), thus allowing up to 64 cores but statring with 4.5, .Net optionnaly support using more than one group for TPL as answered by Stephen Toub:

“The default TPL TaskScheduler targets the .NET ThreadPool.  By default, the pool is restricted to a single processor group (, and thus to 64 cores.  However, in .NET 4.5 you can set the <Thread_UseAllCpuGroups enabled=”true”/> flag. When your computer has multiple CPU groups, enabling this element causes the runtime to distribute managed threads across all CPU groups rather than being limited to just one, and thus the default scheduler can target whatever the OS supports.  (GCCpuGroup must also be enabled for this setting to take effect.)”

This library can be usefull if more than 64 cores should be taken inti account: Multi-Processor Extensions for .NET – Home. This C++/CLI use umnanaged Win32 API to provide missing group informations.


In 2006 (long time ago), Microsoft Japan and BASCULE, a design agency, have made a Xaml demonstrator named DOMINOKEN. The app is no longuer available on Microsoft’s site (it’s a shame) but there is a video here.

Also BASCULE main page is a real GEM (completly japanese stuff). The site is slow so you have to wait but it’s worth it. Don’t hesitate to hoover mouse (for example, on BASCULE logo) and click on picture and go to the botton to click on the amphora.

Hosting .NET Core CLR in Windows native process

Really interesting sample on how to host Core CLR from native process: fancy Development – Hosting .NET Core Clr in your own process.

Because Core CLR is a work in progress, we need to grab parts from and mainly from mscoree.h.

We can dream about a Webkit/Core CLR or Spartan/Core CLR integration.

EDITED: A quick google search reminds me a major advance in Silverlight that occured in 2008 Program Silverlight with the CoreCLR. In WPF/E, E stands for everywhere (Windows and Mac with a Mono version  for Linux). It’s not a joke. But in 7 years, we lost Xaml and UI.

Delta Compression API from Microsoft

Yet another interesting MS API: Delta Compression Application Programming Interfaces.

I wasn’t aware of it until I check dependencies of (another interesting thing which will justify a blog post of it’s own). use DeltaCompressionDotNet (nuget). This is a thin wrapper around Delta Compression API.

Delta Compression API is made of two historical API: PatchAPI and MSDelta. Second one is the evolution of first one. MSDelta provides:

  • removed Windows XP support,
  • API simplified but with some loss (progression calback seems to be phased out),
  • more file format with special handling (knowing file format permits to compute delta more effectively),
  • more memory consumption mainly during delta creation phase.

DeltaCompressionDotNet is more simpler. Creating delta is as simple as:

var compression = new MsDeltaCompression(); /* or PatchApiCompression(); */
compression.CreateDelta(sourcePath, destinationPath, deltaPath);

and applying delta:

var compression = new MsDeltaCompression(); /* or PatchApiCompression(); */
compression.ApplyDelta(deltaPath, sourcePath, destinationPath);

Assembly Neutral Types: the next “little thing with big impact”

ASP.Net vNext brought us a new notion: “Assembly Neutral Types”. And it will be the next “little thing with big impact” on .Net world.

tldr: Assembly Neutral Types will be .Net way to do loose coupling.

Role, contract, facade, protocole or whatever name you choose to use must follow strong typing rules on .Net. This means you must have a reference on the assembly containing the interface or abstract class. And this mandatory reference trigger lost of stagnation or lost of boilerplate wrapping code.

An example is better than a million of word particularly in this case. Suppose we want to share a general purpose interface (“à la” ILogger). We have two solutions: wait than Microsoft declare it in .Net or take the risk that this interface becomes duplicated everywhere. None is satisfactory. Everybody agree on an ILogger interface but almost everybody declare a new one (one in each library implementing loging and one in each library hiding several loging implementation). And this is mandatory for now: a library doesn’t want to have dependency upon any other sibling.

[AssemblyNeutral] is an attribute than can be placed on interfaces (concretely any interface, struct, class without IL) to say: this “declaration” is sharable and everyone can declare the same interface (same complete name and same contents). All this declarations will be “unify to the same type” at runtime.

This mechanism use a trick made possible by Roslyn compiler (see some difficulties for other languages can apply like in F# in ASP.NET 5: The good, the bad, and the really ugly).

Assembly Neutral Types must follow some understandable rules but one of them:

“The types must match exactly! We load the first type with a matching name, if they don’t match expect chaos.”

can be complicated to follow. I just hope that this “chaos” could be properly detected If two [AssemblyNeutral] types differs, consequences can only happen at runtime. We must have a way to detect them.

For more informations:

Obviously, ANT will be integrated into .Net Core 5.