DEV Community: Jim Borden

Learning About Cryptography through Pain

Jim Borden — Sun, 12 Jul 2020 13:43:27 +0000

Due to a history that could be an entire series on its own, I recently found myself with the following task: A C++ implementation that would be able to perform crypto and X509 operations using keys provided by something that wrapped the implementation (in this case C# and Java). I have been taking on the C# challenge and I realized that when things go wrong in crypto, you are usually only left with a bunch of garbage bytes and no clue as to how you got there. Here is what I've realized about the shortcomings of .NET Standard 2.0 and its comparable platforms. There seems to have been improvements made for 2.1 and .NET 5, etc, but for now I will point out some things I've learned after banging the wall for a while.

So the operation I have been focused on is creating a valid X509 certificate for use with a server that uses TLS. Currently the library is focused on the RSA algorithm, which for those unfamiliar is an algorithm which is asymmetric, meaning that two unique keys are used. One is kept secret, and the other is distributed freely. If a piece of data is encoded with one of the keys, it can be decoded with the other. The logic for performing all the actual encoding, and construction of the certificate was done in C++, but the key operations were delegated out to the platform wrapping the implementation (C# here). The operations that need to be performed are as follows:

Extract the public key data in DER format
Sign using the private key (This is so that the private key material does not need to be provided to the C++ implementation, and if possible can be generated in a way that never exposes it to the user)
Decrypt using the private key (Same reasoning as 2)

Aside from those operations, the rest can be performed in C++. So let's begin on the journey. The first operation, extracting the public key, immediately gave me problems.

The current class to use for these operations seems to be RSACryptoServiceProvider and it has no method to export to DER format. There also doesn't appear to be any class that can encode it to DER, so this had to be written by hand. ASN1 is quite confusing to work with, but I was able to write it entirely thanks to an answer from Stack Overflow. There are export methods on the class, but they are only proprietary encodings for use with the Win32 crypto APIs.

The bulk of the pain came from the sign operation. The C++ library actually does something kind of funky first as a sanity check. It will send a sentinel value to be signed, and then attempt to verify it to make sure that the public key associated is actually capable of working with the signed data. That sounds simple enough, but to explain the reason it is not it is necessary to step back and give a brief primer about how signatures work in RSA.

Firstly, RSA cannot encode anything that is longer than its key. It also cannot encode anything that is shorter than its key. This is because it's actually not looking at the data as a set of bytes but rather a gigantic number that is represented by those bytes. It then performs some clever math on that number, and the encoded bytes are the result of representing THAT number. To reverse this, you take the resulting number, and do the same clever math but with the parameters of the other key and you will arrive back at the same gigantic number, and thus the original bytes.

The primitive operation of RSA signing is the same as RSA decryption (that does not mean that they are the same thing, but they use the same encoding process at some point). But that means that you can only encode a relatively small amount of data (256 bytes, for example, using a 2048 bit key. Actually less because of padding, which is coming up in a minute). So what do you do when you want to sign something bigger? The answer lies in the steps that come BEFORE the encoding of the data using RSA. Instead of encoding the data itself, a hash of the data is encoded. A number of algorithms are supported for hashing via RSA, but SHA256 is a commonly used one. SHA256 is a 256 bit hashing algorithm, which means that it will reduce any arbitrarily large set of data into 32 bytes in a way that is unique, but non-reversible (it's actually not strictly unique, but that's part of the game. It is unique enough that finding a non-unique hash is exceptionally hard. Usually once it is found, it starts to become time to move on to the next algorithm that is newer).

But wait, now the data is 32 bytes and it is too small! This is no good either. The answer is to fill up the other 224 bytes with padding data. The padding data has to be defined and agreed upon otherwise it will be impossible to tell what is padding and what is not. But now that things are the correct length things can be encoded and decoded properly.

This is where the first puzzling problem comes in. For the reasons described above, when using RSA you need to say "I am using RSA with X hashing algorithm." However, the first thing that came back from the C++ library was a request to encode something with RSA and using no hash algorithm. I dislike reading long RFCs and I'm sure this is in there somewhere but apparently this means to skip the hashing part, and just encode the received data directly, because it is already less than or equal to the maximum length able to be encoded.

Very well, that just means skip straight to the encoding portion, which as I mentioned before is the same as the decrypt function. So I tried calling Decrypt on the RSACryptoServiceProvider class on the data I received. Nope, it threw an exception. Probably because it was expecting to get readable data on the other side (It can tell if the data is valid or not because of the padding scheme used). It is decrypting something after all. That's disappointing. Apple's signature API has a mode to sign without a hash function, and Java has the NONEWithRSA mode in its Signature.getInstance method, but C# has apparently left this out so there is no way to do this with SignData or SignHash either.

Furthermore, the Decrypt method forces you to use a padding mode, meaning that it can only accept unpadded data. If I try to pass in data that I manually padded I get an exception again because the data is too long to encode (since it is trying to re-add the padding). However, I began to wonder how complex the RSA encoding operation actually is. It's actually surprisingly simple. The bulk of the work comes from calculating the parameters to work with, but using the parameters is another story. Excellent!

So there are three main numbers involved with encoding and decoding: The modulus (n), the private exponent (d) and the public exponent (e). There is a lot of complex math to get these numbers, but the result is that any number m can be transformed into c using m ^ d mod n and then transformed back to the original m using c ^ e mod n. So I just have to repeat the first part of this operation in my "raw signature" method.

Since these numbers have to be very very VERY large in order to provide security, normal integer primitives won't cut it. long is, after all, a 64 bit number and it is recommended to have a number that is at least 2048 bits in order to be secure. The way to work with such numbers in C# is to use the BigInteger class. It even has a constructor that accepts byte[] directly, great!

So I manually padded the bytes I received, and then passed them into a BigInteger which even, conveniently, has a ModPow method for doing exactly what I described above. So I did that using the parameters from the key and was meant with instant success.

Just kidding, it didn't work at all! Often I would get exceptions saying that the exponent needed to be a positive number. Well duh, why isn't it? Well it turns out the answer lies in our old friend endianness. As a review, endianness determines what order to read bytes when a numeric value is represented by more than one byte. Little endian will read from the end of the block to the beginning, and big endian will read from the start to the end. The bytes stored in the parameters of the key are in big endian, but BigInteger wants little endian. This means that the bytes have to be reversed first before being used (.NET Core 3, and perhaps .NET Standard 2.1 have fixed this by adding an endianness option to BigInteger). Furthermore, once the math is done, the resulting bytes have to be reversed a second time to get them back into big endian.

Ready to work now right? YES, well...sometimes. BigInteger not only works with little endian, it works with signed little endian meaning that it will interpret the bytes using the two complement (a method for representing negative numbers in binary). In order to stop this, a 0 needs to be appended to the end of the last byte is higher than 0x80 to avoid it being falsely interpreted as a negative number. Furthermore, on the way back out this 0 might still be there and so before sending it to C++ the zero needs to be trimmed before reversing the bytes and sending them.

Finally after all that, the weird "no hash algorithm" method of signing was working. However, the resulting certificates were all invalid. I was still using another path for signing when an actual algorithm was specified, because that is what is supported in C#. So what was going wrong? Come to find out that there are two methods on RSACryptoServiceProvider: SignData and SignHash. The former will hash the data first before signing it, and the latter will just sign it directly (which makes me wonder why the latter takes a hashing algorithm as an argument. It doesn't need to hash anything, after all. I suppose it uses it to try to check that it actually received something of the valid size?). The C++ library was sending me hashes to sign, not arbitrary data, and I was using the wrong one! Switching to the correct one (SignHash) fixed that but it took me a while to figure out what the difference was.

Step 3 had no problems at all, as a call to Decrypt was all that was needed but hours and hours got spent on steps 1 and 2. I'm hoping that this information can help someone who might be in a similar position at some point. Happy cryptoing!

Git commit info in your build

Jim Borden — Thu, 07 Mar 2019 05:00:12 +0000

For quite a long time I've been generating git commit info for use inside my assemblies at work but I've been doing it in a roundabout fragile way. I found a library that includes an MSBuild task to do it for me called GitInfo. I was skeptical at first but it was literally the easiest thing I could possibly do.

All you need to do to use it is add the Nuget package. Behind the scenes what it does is generate a new target for MSBuild to run which adds another autogenerated file based on a template. It's nothing too fancy, but it takes care of a lot of annoying things for you like trying to locate the git executable and running various git commands to extract useful information. Auto generated files are like the ones that get automatically generated when you have XAML files in your project (*.g.cs). They wind up in your "output" directory and don't interfere with your git staging area. But because it is compiled source, all you need to do is call into a static class to get all the juicy git info. Personally, I use ThisAssembly.Git.Commit which is the short commit hash. However, there is a whole lot more to play with.

Check it out!

Multi Targeting

Jim Borden — Thu, 07 Mar 2019 04:54:39 +0000

Couchbase Lite .NET runs in a lot of different places, that means:

.NET Framework on Windows
.NET Core on Mac, Windows, Linux
Xamarin iOS
Xamarin Android
UWP

Currently, the structure is that the entire library is a .NET Standard 2.0 library with some platform specific features provided via dependency injection. However, there have been some kinks with this approach, so I decided to take a look at what I would have to do in order to make it a multi target project instead.

First I will start off with a definition of what multi targeting is. Until recently, every .NET project has been based off of a certain runtime such as .NET Framework, or Xamarin iOS and the artifacts are for that runtime. .NET Standard was introduced as a way to provide one fake runtime that actually ran on a bunch of different ones but this takes things one step further. Instead of one target framework, the project will target many and during compile it will compile outputs for each one of them. So if you had .NET Framework and Xamarin iOS, you would get both outputs from one project.

Does this sound like the old PCL days? Well that seems to be where it got its cue from. Back in the PCL days, library authors would use a trick called "bait and switch" in which they wrote a shell interface to be reference via the portable library and relied on an implementation detail of NuGet that would cause it to choose the most specific implementation for a given runtime. That way, if a "portable" and ".NET Framework" version were in the same package, .NET Framework would prefer the latter variant. If a non-supported platform came along then it would simply throw exceptions on that platform since that was what was actually being generated in the "bait" assembly.

This approach was pretty well received and has now pretty much become official. The multi target project is a tool to help with this in that it can generate many platforms at once to package into a NuGet package. So let's get into exactly what it takes to get started.

STEP ONE: Create a global.json file next to your solution. The contents will be as follows. The version should be whatever highest version is available (which at the time of writing is 1.6.68):

{
    "msbuild-sdks": {
        "MSBuild.Sdk.Extras": "1.6.68"
    }
}

This step enables you to create a new project type that adds onto the current .NET Core SDK. This is needed because .NET Core does not, and may not ever, support Xamarin, UWP, and others out of the box. This SDK was written by Oren Novotny who authors many things that are amazing in the .NET universe so you can trust that it won't just fade away.

STEP TWO: With that in place, you need to hand edit your .csproj file to use this SDK instead of the default one. Just replace the first line


<Project Sdk="Microsoft.NET.Sdk">

with

<Project Sdk="MSBuild.Sdk.Extras">

STEP THREE: The final step, find your <TargetFramework> entry, and change it to a semicolon separated <TargetFrameworks> entry (plural). For example

<TargetFramework>netstandard2.0</TargetFramework>

becomes

 <TargetFrameworks>netstandard2.0;netcoreapp2.0;net461;uap10.0.16299;MonoAndroid80;Xamarin.iOS10</TargetFrameworks>

That's it! Now when you compile, you will find that your bin/Debug or bin/Release folder will contain several entries, one for each of the frameworks you are targeting. You can even use platform specific code, but you need to either only include it when compiling for the framework that supports those functions (more advanced and outside the scope of this article) or guard the source with #if blocks. As a hint, the above definitions will be automatically added for each of the target frameworks in order:

NETSTANDARD2_0 and NETSTANDARD
NETCOREAPP2_0 and NETCOREAPP
NETFRAMEWORK and NET461
UAP_10_0_16299
__ANDROID__ and a ton of android API level specific androids
__IOS__

Happy cross platforming!

What's new in C# 7.3?

Jim Borden — Thu, 26 Apr 2018 02:25:13 +0000

Visual Studio 15.7 Preview 3 has shipped initial support for some C# 7.3 features. Let's see what they are!

`System.Enum`, `System.Delegate` and `unmanaged` constraints.

Now with generic functions you can add more control over the types you pass in. More specifically, you can specify that they must be enum types, delegate types, or "blittable" types. The last one is a bit involved, but it means a type that consists only of certain predefined primitive types (such as int or UIntPtr), or arrays of those types. "Blittable" means it has the ability to be sent as-is over the managed-unmanaged boundary to native code because it has no references to the managed heap. This means you have the ability to do something like this:

void Hash<T>(T value) where T : unmanaged
{
    fixed (T* p = &value) { 
        // Do stuff...
    }
}

I'm particularly excited about this one because I've had to use a lot of workarounds to be able to make helper methods that work with "pointer types."

Ref local re-assignment

This is just a small enhancement to allow you to assign ref type variables / parameters to other variables the way you do normal ones. I think the following code is an example (off the top of my head)

void DoStuff(ref int parameter)
{
    // Now otherRef is also a reference, modifications will 
    // propagate back
    var otherRef = ref parameter;

    // This is just its value, modifying it has no effect on 
    // the original
    var otherVal = parameter;
}

Stackalloc initializers

This adds the ability to initialize a stack allocated array (did you even know this was a thing in C#? I did :D) as you would a heap allocated one:

Span<int> x = stackalloc[] { 1, 2, 3 };.

Indexing movable fixed buffers

I can't really wrap my head around this one so see if you can understand it

Custom fixed statement

This is the first I've seen this one, and it is exciting for me! Basically, if you implement an implicit interface (one method), you can use your own types in a fixed statement for passing through P/Invoke. I'm not sure what the exact method is (DangerousGetPinnableReference() or GetPinnableReference()) since the proposal and the release notes disagree but if this method returns a suitable type then you can eliminate some boilerplate.

Improved overload candidates

There are some new method resolution rules to optimize the way a method is resolved to the correct one. See the propsal for a list of the.

Expression Variables in Initializers

The summary here is "Expression variables like out var and pattern variables are allowed in field initializers, constructor initializers, and LINQ queries." but I am not sure what that allows us to do...

Tuple comparison

Tuples can be compared with == and != now!

Attributes on backing fields

Have you ever wanted to put an attribute (e.g. NonSerializable) on the backing field of a property, and then realized that you then had to create a manual property and backing field just to do so?

[Serializable]
public class Foo {
    [NonSerialized]
    private string MySecret_backingField;

    public string MySecret {
        get { return MySecret_backingField; }
        set { MySecret_backingField = value; }
    }
}

Not anymore!

[Serializable]
public class Foo {
    [field: NonSerialized]
    public string MySecret { get; set; }
}

What is git rebase?

Jim Borden — Fri, 20 Apr 2018 11:41:13 +0000

You can think of git commits like a long chain. Each time you make a commit, you add one more link in the chain. The problem is that sometimes that chain can split into two chains like this:

D
|
C   C2
|   |
B --
|
A

What most people do when they want to move C2 back into the original chain is what is called a merge and it looks like this:

E
|  \
D   |
|   |
C   C2
|   |
B --
|
A

In which E is a commit which combines the changes of C, D, and C2 into a new commit . However, with branches and then branches off of branches this can quickly lead to a spaghetti looking history. Instead, let's see what happens when you switch to the branch with commit C2 (let's call it 'dev') and run rebase on the main line (let's call it 'master'). So

git checkout dev
git rebase master

C2
|
D
|
C
|
B
|
A

This history is much cleaner now, as C2 was simply moved to the end of the line. This is what rebase does. Note that master is still pointing to 'D', and dev is pointing to the new 'C2' location.

The Couchbase Lite .NET Pipeline

Jim Borden — Fri, 20 Apr 2018 02:19:53 +0000

I'm fairly proud of the pipeline I have managed to set up for myself working as the developer of Couchbase Lite .NET. The more automation you can have, the easier your life is and I'm also looking for ways to expand this so if anyone has any suggestions please let me know. I'm considering Gerrit as well, but the normal flow seems awfully verbose for a single developer. It would be nice to have commit validation though! Hopefully someone can take away something from the setup I have made as well!

Here is a diagram of the start to end flow at a high level:

So, let's start with what everyone knows. I have just made a commit to the repo

Our official builds of Couchbase Lite .NET are based on a manifest containing the repos and branches needed and where to check them out. This manifest format is from the Google tool repo. There is a script that we have that detects changes in key repos inside the manifest and if there are changes triggers a new source scrape. It runs as a Jenkins job (as do all the other downstream jobs). The source scrape will pull down all of the repositories needed at the correct commit and compress them all into a GZipped tarball for archiving (similar to the "download zip" feature of GitHub, except it works across multiple repos). This source is then uploaded to a NAS (Network Access Share) machine and available on an internal HTTP server.

And so this commit has resulted in a source scrape for build number 129 for version 2.1.0. This source scraping job then triggers a downstream job to build. The build job will pull the newly created source, and run the build script on it to produce a Nuget package. This is done once for the Enterprise Edition, and once for the Community Edition. These packages are then uploaded to our internal feed, hosted by a Proget server installation.

Should this build be the lucky one, this is exactly what will be shipped. There are no further changes to the assembly whatsoever. However, the process is far from over. The reason that I upload the packages to the nuget feed at this point is because I want to detect any packaging mistakes, and ensure that the packages that go out are usable. So the packaging itself is also in essence being tested.

Once the upload is finished, the next downstream job is triggered. This is the unit testing job. The term "unit test" is used horrendously loosely here as I don't have any standards for making actual units. It's more just a collection of stuff that I want to make sure works (not sure what to call it) and stuff that failed before that was reported. The tests are run on .NET Core Windows, .NET Core macOS, .NET Core Ubuntu, UWP, iOS simulator, and Android emulator. Each suite is run twice: The first is building from source a debug build of the community edition and running the tests on that. The debug builds have lots of extra asserts that detect failures more quickly. If those pass then a release build is made of the unit tests using the package from the feed that was just inserted. On .NET Core Windows only an extra run is done to gather code coverage data.

If this passes, then the packages are all promoted to a separate feed. This feed is reserved for packages that passed the first round of automated testing. Our QE team can be confident that packages pulled from this feed are sane. The next step is triggered after that, which is a build of the QE test server application for .NET Core, UWP, Xamarin Android, and Xamarin iOS. The test server application is an internal tool we use that will accept commands over HTTP so that it can be involved in orchestration with separate processes and programs. The reason that this is done is for the next step.

The final step in the pipeline process is a set of functional testing. This means that we need to start up a program (or several) running Couchbase Lite, and also orchestrate instances of Sync Gateway and Couchbase Server and hook them up to run against each other to test replication scenarios. A typical run will look like this (carried about by a python client running pytest on a machine separate to the below ones):

Install Couchbase Server (machine 1 / one time)
Install Sync Gateway (machine 2 / one time)
Ensure Sync Gateway and Couchbase Server are shut down
Start Couchbase Server
Clear Couchbase Server bucket data
(optional) Prepopulate Couchbase Server bucket data
Start Sync Gateway with a config pointing to the Couchbase Server bucket
Download and install the Test Server app (machine 3)
Start the test server app
Confirm everything is listening on the correct port
Begin issuing commands to both setup scenarios, and confirm correct results
Stop the test server app

This is very intensive and even simple scenarios can take minutes per test (as opposed to milliseconds for unit testing). After this point a report is generated and saved regarding the pass / fail results and what went wrong.

When it comes time to release a DB (developer build) to our prerelease feed, it's almost as simple as moving a package from our internal feed to our external one. There is one step in between which unzips the package, changes the nuget version and then rezips it so that it shows up with the proper identifier on a Nuget feed (e.g. 2.1.0-db001). When GA time comes, in addition to other testing kicked off manually by the QE team, the process is the same except that instead of moving it to the prerelease feed, it gets moved to nuget.org and its version gets changed to a non-prerelease version (e.g. 2.1.0).

Automation is very nice, and saves a lot of time and helps you catch things more quickly. I hope I can get even more automated in the future!

New Features in C# 7.1 and 7.2

Jim Borden — Thu, 19 Apr 2018 06:15:31 +0000

I haven't counted exactly but I must have around a decade of .NET experience at this point. I love working with .NET and C#, and I get excited to see new features in the language. The latest major released version of C# is version 7, with two minor releases being 7.1 and 7.2. I'll talk about the new features of 7.1 and 7.2, and then go over some of the features I am excited about for future versions.

C# 7.1

Async Main

Remember a couple versions ago when C# introduced the async and await keywords? I sure do, that was one of the best features I could have asked for. It was also dangerous unless you realize how it works. The async function being awaited would return early until it is ready to pick up at a later point, and the caller would continue as if the function containing the await had finished, unless that caller also had an await. So it's easy to see how you would get "await-infected" all the way up your stack. Then you got to main() which was required to be void and you were out of luck. No more! Now you can have an asynchronous main() that is automatically handled by the CLR. It looks like this:

static async Task<int> Main() or static async Task Main() (which represent asynchronous int and void respectively). Happy asynching!

Default Literal Expressions

At a high level there are two types of objects in C#: structs and classes. The difference being that structs are not allocated on the managed heap and all their memory is simply laid out starting from whatever address they occupy then and there. This means that it does not make sense the have a null struct since null is obviously not on your current stack, and never will be. However, when using generic methods this meant that it was awkward to initialize a variable of generic type T because you didn't know what a suitable "default" value should be. Enter the default(T) syntax. If you write default(<type>) then you will get the compiler chosen default value for whatever type you've chosen. This can get messy though, since nobody wants to look at something like default(Tuple<string, KeyValuePair<string, object>>). Now you can shorten this to simply default without the type argument and it will be inferred from the variable type. A small change but a nice touch!

Inferred Tuple Element Names

C# 7 introduced a fun new way to make tuples. I'm not sure many people liked making a tuple and then remembering what Item1 and Item2 on the tuple was. So instead, now you can write a block like this:

var name = "Jim";
var age = 32;
var pair = (name: name, age: age);

// Now access via pair.name and pair.age

Now this has been improved upon to simply this:

var pair = (name, age);

// Now access via pair.name and pair.age
// automatically named from the variable names

Compiler Options /refout and /refonly

If you remember back to the Portable Class Library (PCL) days, some people required platform specific functionality in order for their library to work, but they wanted their library to be usable from other PCL that targeted the same subset of platforms as they did. They couldn't compile it as a PCL, though, because they used platform specific API that wasn't present in the defined PCL API set. So what they did instead was trick the NuGet client by putting in a shim that did nothing as a PCL library, and also put in the actual assemblies for each platform they supported under their target moniker (e.g. net461, xamarinios, etc). Since NuGet always prefers a platform specific assembly, what would happen is that when they installed it on their top level project NuGet would pull out the correct platform assembly, but when they compiled their PCL it would be compiling against the shim. Since they both had the same version and everything else looked identical the .NET compiled happily overwrote the shim version with the real one at the top level and everything worked out. This was coined "bait and switch."

Well, it was such a good trick that it actually got legitimized. Have you ever wondered what a reference assembly is? It is exactly the "shim" I talked about above. It is pretty much like a header file for C or C++ in that it defines what API is available without actually implementing it. It is used for when a library otherwise cannot target .NET Standard and needs to have a per platform assembly, but still wants to be usable from shared .NET Standard libraries. Now, there are compiler options to automatically generate this reference assembly for you. /refout will specify where to write the automatically generated reference assembly, and also compile the implementation. /refonly will only compile the reference assembly.

C# 7.2

Reference Semantics with Value Types

Reference semantics were introduced in C# 7 as a well to reduce the number of copies made when returning values and such. For example, instead of returning a copy of an item that is inside of an array, you can directly return the same object that is in the array. These modifications have been extended to work with structs and resulted in the following new modifiers:

in Specifies that you want to pass a struct by reference, but the caller cannot modify it
ref readonly returns a struct by reference as an object that may not be modified
readonly struct creates a struct that can never be modified once created
ref struct deserves an article of its own, but basically means that it can never be allocated on the managed heap. The main motivation is for the awesome new Span<T> class which also deserves its own article.

Non-Trailing Named Arguments

This one is meant to give meaning to all those literal true false and null objects that you pass in your code. So for example if you have something like

public void Log(bool verbose, string message, object arg)

You could now make the call a little bit clearer by changing the following line to the second line:

Log(true, "Foo", 42);
Log(verbose: true, "Foo", 42);

Leading Underscore in Numeric Literals

This is a very small one that makes a readability improvement. Before when you used a numeric literal, it could not begin with an underscore and so you ended up with 0b0101_0101 which is hard to read. Now you can put in better spacing with 0b_0101_0101

private protected Access Modifier

This one was debated about for years with an all out war emerging in the community. Nobody could agree on what to name it and so in the end it was decided to go with the same as managed C++. This angered some but I don't care because I want to use it. What this new access modifier means is that any element declared with this will be visible to subclasses, but only if those subclasses are in the same assembly as the base class. This is very useful for me in the following situation:

internal sealed class Hidden
{

}

public abstract class Visible
{
    protected Hidden HiddenObj { get; private set; }
}

This will fail to compile because a subclass of Visible has a property it can see, which is of a type it cannot see because Hidden is internal. The only remedy until now was to make the property internal instead of protected which meant lots of noise when dealing with the type inside the assembly. Now with private protected It can be invisible to both other types in the same assembly, and subclasses outside the assembly.

Moving My Blog Home!

Jim Borden — Thu, 19 Apr 2018 05:33:03 +0000

Hello Everyone,

I recently discovered this site and I think it will get way more visibility than my old blog did. You can find it here (along with a duplicate of my first post here). So therefore I am going to put a note there (not that anyone will probably notice) and start writing things here instead! Hope I can post something interesting.

A .NET Glossary

Jim Borden — Wed, 18 Apr 2018 01:01:30 +0000

.NET has evolved greatly since its induction way back in the early 2000s and at this point it is beginning to rival Java in the ways it can be deployed. This post is meant to be a simple list of terms that get thrown around so hopefully things can make a little more sense to those unfamiliar.

.NET Framework: This is the name for the original implementation of the .NET runtime and libraries that ran exclusively on Windows. It begin with version 1.0, then went to 1.1, 2.0, 3.0, 3.5, 4.0, 4.5 before the ecosystem explosion. Since then the release have been more frequent and more patch-like. The current version as of this writing is 4.7.1.

Mono: This is what I commonly refer to as the the “great long-running reverse engineering game.” Several companies, all fronted by the same individual, made it their goal to bring an implementation of the .NET runtime and libraries to Linux. After they achieved that, they went on to Macintosh, and eventually wrote implementations for many platforms including iOS, Android, and various gaming consoles. This seems to be heading for replacement by .NET Core.

Xamarin: Xamarin is the name of the company that eventually ended up with the rights to the Mono source. They are now owned by Microsoft but spent a good number of years independently maintaining Mono, with a focus on mobile devices. Their most popular frameworks are Xamarin iOS and Xamarin Android which are runtime / library implementations designed to run on iOS and Android respectively.

.NET Core: This is the official Microsoft attempt to bring the .NET runtime and libraries across various flavors of desktop platforms. It has a great command line interface and ability to publish non-runtime dependent applications so that if desired it can run in an environment without a .NET runtime installed at all.

.NET Standard: Due to the fact that so many variations of runtimes trying to accomplish the same thing are in existence, the .NET Standard is a list of API that an implementation must support to claim support for a given version of the .NET Standard. Thus, if you compile against the .NET Standard, your library can run on any runtime that conforms to that standard, and any future ones as well.

UWP: Universal Windows Platform is Microsoft’s attempt to unify phone, tablet, and desktop with one code base that targets it all. It is a sandboxed environment that produces self contained applications that are designed to be distributed on the Windows Store.

Roslyn: You might have seen this term flying around. This is the name of Microsoft’s latest C# compiler environment. It is open source and available as a prebuilt library so that any application can gain access to the powerful C# compilation and analysis methods that Visual Studio uses.

.NET Native: This is an AOT (ahead of time) compiler for UWP that will precompile .NET IL (intermediate language, which is the compiled form of .NET assemblies that is consumed by the .NET runtime) down into native code (either x86, x64, or ARM) designed to run on the Windows operating system. This gives large performance gains on memory / resources constrained devices.

ASP .NET: This is Microsoft’s framework for building server side applications designed to be interacted with via HTTP calls. It is Windows only, but it’s newer and younger sibling ASP .NET Core is designed to run cross platform.

.NET Runtime: This is the engine that is responsible for hosting applications written in .NET. It is a C++ program designed to allocate managed memory, perform garbage collection, and load .NET assemblies into and out of its address space and subsequently compiling them on demand for execution by the host operating system.

.NET Framework Libraries: These are the libraries that provide basic functionality as a platform. Things such as string operations, file I/O, threading, etc are provided by these libraries. They were historically bundled with a given release of the .NET Framework, but these days they are modular and distributed out of band.

Assembly: This is the term for a binary image containing instructions that are executable by the .NET runtime (as opposed to a binary image containing machine instructions that are executable by the operating system).