Using Type.GetType with .NET Core / Dynamically Loading .NET Standard Assemblies in .NET Core

The Type.GetType() method lets us load a type from the file system at runtime without needing compile time references. Because of the way that assemblies are loaded in .NET Core, this behaves differently than it did in .NET Framework.

Update Jan 13, 2020: The Type.GetType() method has not changed, but runtime behavior regarding assembly loading has changed. That doesn't negate the workaround shown here, so feel free to keep reading. For more information see the next article: Type.GetType() Functionality Has Not Changed in .NET Core.

Short Version
In .NET Framework, calling Type.GetType() with an assembly-qualified name...

• Loads the specified assembly from the file system
  Note: "from the file system" is observed behavior, but technically not correct -- see the followup article mentioned above for more details. 
• Returns a Type object

In .NET Core, calling Type.GetType() with an assembly-qualified name...

• Does *NOT* load the specified assembly from the file system
• If the assembly is not already loaded, GetType() returns null
• If the assembly is already loaded, GetType() returns the Type object

This means that we need to take extra steps in .NET Core in order to use Type.GetType() with .NET Core applications. And things get more interesting if we are loading .NET Standard assemblies.

Note: The code for this article comes from my talk on C# interfaces (IEnumerable, ISaveable, IDontGetIt: Understanding .NET Interfaces). The code is in 2 separate GitHub repositories. The .NET Framework code is at GitHub: jeremybytes/understanding-interfaces. The .NET Core code is at GitHub: jeremybytes/understanding-interfaces-core30.

In the spirit of "the fastest way to get a right answer is to post a wrong one", I'm putting down my thought processes in solving an issue. If there is an easier way (such as setting a flag or adding a config setting), please let me know in the comments.

Why Dynamically Load Types?
I have used dynamic loading of types for 2 primary scenarios: (1) swapping one set of functionality for another, and (2) plugging in business rules. In either of these scenarios, we do not need to have the specifics of the dynamically loaded types available at compile time. Things can be figured out at run time.

In the first scenario (and the code sample we'll look at today), I have changed out data-access code from one system to another. For example, to get data from a SQL database, a web service, or some other location. This is particularly helpful when there are multiple clients using the same application with different data storage systems.

In the second scenario, I deployed an application with the option of adding or changing certain business rules at a later time. The business rules follow a specific interface and are stored in a separate assembly (or multiple assemblies). At runtime, the application loads the business rules from the file system. This made it easy to update existing rules, add rules, or remove rules without needing to recompile or redeploy the application; only the business rule files were affected by updates.

Dynamic Loading with .NET Framework
I ran across this issue when I was moving a WPF application from .NET Framework 4.7 to .NET Core 3.0. We'll start with code from the .NET Framework repository mentioned above (GitHub: jeremybytes/understanding-interfaces), specifically the "completed" code in the "04-DynamicLoading" project (completed/04-DynamicLoading).

This application dynamically loads a data repository that can get data from a text file (comman-separate values (CSV)), a web service (HTTP/JSON), or a SQL database (SQLite local db). The application does not know anything about these data repositories at compile-time. Instead, it loads a repository from the file system based on configuration.

Here is the code that dynamically loads the repository (from the RepositoryFactory.cs in the PeopleViewer project):

The "GetRepository" method returns IPersonRepository -- this is the interface that represents the data repository.

The first line of the method gets the assembly-qualified name from configuration. Here's the configuration section for the CSV Repository (from the App.config file of the PeopleViewer project):

This lists the assembly-qualified name for the repository. This consists of the following parts:

• Fully-qualified Type Name: PersonRepository.CSV.CSVRepository
• Assembly Name: PersonRepository.CSV (this is "PersonRepository.CSV.dll" on the file system)
• Assembly Version: 1.0.0.0
• Assembly Culture -- this is used for localization (which we haven't implemented here)
• Assembly Public Key Token -- this is used for strongly-named assemblies (which we haven't implemented here)

The next line in our method makes a call to Type.GetType() with this assembly-qualified name. GetType will find the assembly on the file system (by default, it looks in the same folder as the executable). Then it loads the assembly and pulls out the information for the Type object.

Activator.CreateInstance will create an instance of the Type using a default constructor. In this case, it will be a CSVRepository.

The last 2 lines cast the new instance to the correct interface and return it.

Getting the Repository Assemblies
One other piece is that we need to get the CSVRepository assembly to the executable folder somehow. The project does not have any compile-time references to the assembly, so we need to do this manually.

We have the repositories (and all of their dependencies) in a folder at the solution level called "RepositoriesForBin" (you can look at the contents of RepositoriesForBin on GitHub). Here's a bit of a screenshot from Windows File Explorer:

This snippet shows the "PersonRepository.CSV.dll" file that we're using here. In addition, we have files for the web service repository, the SQL database repository, and all of the dependencies for those repositories.

To get these into the executable folder, the PeopleViewer project has a post-build step. (It's kind of buried in the PeopleViewer.csproj file on GitHub -- it's easier to look at this in the Visual Studio project properties). Here is the post-build section of the project properties:

This copies files from the from the "RepositoriesForBin" folder to the output folder (including any sub-folders).

For more information on build events, take a look at "Using Build Events in Visual Studio to Make Life Easier".

Running the Application
When we run the application, we get data using the CSV repository (which gets data from a text file on the file system).

Changing the Data Source
If you're curious about how the dynamic loading works. Shut down the application and open the executable file in File Explorer (this is in the PeopleViewer/bin/Debug folder).

Run "PeopleViewer.exe" by double-clicking it from File Explorer. You will see the same results as above.

Shut down the application, and then edit the "PeopleViewer.exe.config" file on the file system using your favorite text editor. Comment out the section for the "CSV Repository" and uncomment the section for "SQL Repository". Save and close the file.

Now when you re-run the application, it will use the SQL database instead of the text file.

In real life, we would not be doing this on a single machine. However, think of the scenario where we have multiple clients. For each client, we give them just the assemblies that they need for their particular environment. If a new client has a different data store, that's fine. We create a repository assembly and give it to that client. We do not need to recompile the application or deal with multiple versions deployed at different client sites.

Anyway, on to .NET Core.

Converting to .NET Core
For the .NET Framework project, the WPF application (PeopleViewer) is a WPF application. The web service (People.Service) is an ASP.NET Core 2.2 API. The interface project (PersonRepository.Interface) is a .NET Standard 2.0 project. All of the repository files are .NET Standard 2.0 as well.

Part of the reason for using .NET Standard project for many things is that I knew I would be moving the WPF application to .NET Core once .NET Core 3.0 was released. And that's what I did.

I moved the WPF application and the web service to .NET Core 3.0. And I moved the libraries (including the repositories) to .NET Standard 2.1.

One other thing I did with this application was change all references from "Repository" to "Reader". Since the operations for the repositories are read-only, the term "reader" is more appropriate.

The completed code is on GitHub (jeremybytes/understanding-interfaces-core30), specifically in the "completed/04-DynamicLoading" folder. Note that this repository has the completed code, so you won't be able to follow along with the interim code (you can contact me for details if you'd really like to follow along).

Broken Code in .NET Core
Unfortunately, if we take the "GetRepository" method (now called "GetReader") straight across, the code does not work.

If we run the application, we get an exception:

The "Activator.CreateInstance" method is giving us an ArgumentNullException. This means that the "readerType" variable that we have here is null.

"GetType" is not returning what we want. Here are the values of "readerTypeName" and the "readerType" in the debugger:

This shows that the "readerTypeName" variable is populated with the assembly-qualified name that we expect. So that's fine.

But the "readerType" that is returned from the GetType method is null.

GetType does not automatically load an assembly in .NET Core like it does in .NET Framework.

Frustration and Reasoning
This is where I went through a bit of frustration. When checking the documentation for "GetType", there is currently (as of Jan 5, 2020) no indication that it works differently. Here is a screenshot of the beginning of the "Remarks" section for Type.GetType (link (which will hopefully be updated by the time you read this): https://docs.microsoft.com/en-us/dotnet/api/system.type.gettype?view=netcore-3.1#System_Type_GetType_System_String_):

Note that I do have ".NET Core 3.1" selected for the Version. Here is the start of the "Remarks" text:

"You can use the GetType method to obtain a Type object for a type in another assembly if you know its assembly-qualified name, which an be obtained from AssemblyQualifiedName. GetType causes loading of the assembly specified in typeName." (emphasis mine)

So, according to the documentation, this should work.

Assembly Loading and Unloading
The reason that this does not work is that the assembly loading mechanism was changed for .NET Core. This was done for a couple of reasons. First, we can set up different assembly load contexts; this lets us load different versions of assemblies into different contexts in the same application. This was not really possible before. Second, we can unload assemblies after we're done with them. Again, this is something that was very difficult to do before.

Manually Loading an Assembly
In getting this to work, my first step was to manually load the assembly by hard-coding the value. Here is the code for that.

Before calling the "GetType" method, this code loads the CSV assembly into the context using "AssemblyLoadContext.Default.LoadFromAssemblyPath". This will load the assembly into the default context (which is the main one that the application uses). The parameter is the assembly file name with the full path.

For the path, there is an assemblyPath variable that is set to the current location of the executable (AppDomain.CurrentDomain.BaseDirectory) with the file name appended (PersonReader.CSV.dll).

This gets us a working application:

But it is of limited usefulness since the CSV reader assembly is hard-coded.

A Different Approach
At this point, I figured that I could try to parse the file name out of the assembly-qualified name that we already have in the configuration file, or I could take a different approach.

When we manually load an assembly into the context like we did above, we also get a reference to that assembly. This means that instead of using "GetType" to locate a type, we can poke into the assembly directly using reflection.

For this approach, I made a few changes to configuration, output folders, and code.

Note: this is not the final version of the code, but you can find it by looking at a particular commit in GitHub: commit/49dc7a33d8071e9eef83d9e1a1d7bba5c3de50cb.

New Configuration
Rather than having the full assembly-qualified name of the type, I created settings for just the parts that I needed. Here is the new configuration (in the App.config file for the commit mentioned above):

Now we have a "ReaderAssembly" key with a value of "PersonReader.CSV.dll" -- the name of the file on the file system. We also have "ReaderType" which is "PersonReader.CSV.CSVReader" -- the fully-qualified name of the reader type.

New Output Folder
In addition, since we will no longer rely on "GetType" being able to find files in the executable folder, I decided to move the reader files to a separate sub-folder in the output. This makes it easier to keep track of the reader assemblies, particularly if we need to remove or change the files.

Along with the new output folder comes updated post-build steps. These are in the PeopleViewer.csproj file for the commit mentioned above. Here is the view from Visual Studio, which is a bit easier to read:

This has 2 copy steps. The first step copies files from the "AdditionalFiles" folder into the output folder. This folder contains the data files that are used by the readers, specifically People.txt (for the CSV reader) and People.db (for the SQL reader).

The next step copies files from the "ReaderAssemblies" folder to a "ReaderAssemblies" subfolder in the output. This contains the dlls for the readers along with the dependencies.

New Code
Along with the new configuration and output location, we have some new code to dynamically load the specified data reader. This is in the ReaderFactory.cs file for the commit mentioned above:

Let's walk through this code.

First we get the "ReaderAssembly" value from configuration. As a reminder, this is "PersonReader.CSV.dll".

Next, we create the full directory path to that file by taking the "BaseDirectory" (where the executable is), appending the new "ReaderAssemblies" subfolder, and then adding the name of the file.

As a side note, the "Path.DirectorySeparatorChar" will pick the correct character for the operating system. So in Windows, it will use the backslash; in Linux and macOS, it will use the forward slash.

Notice that after calling "LoadFromAssemblyPath", we store the return value as "readerAssembly". This is the assembly that we just loaded.

The next step is to get the "ReaderType" from configuration. As a reminder, this is "PersonReader.CSV.CSVReader".

Next we get the reader type out of the loaded assembly. This code uses a little bit of LINQ to reflect into the assembly. "ExportedTypes" is a collection of all of the publicly visible types that are in the assembly. In the query, we go through the types and try to find one that matches the value from configuration. If the type is not found, this method returns null.

The rest of the method is what we had before. Once we have the Type, we can use the Activator to create an instance, and then we cast it to the appropriate type.

Working Code (sort of)
This code seems like a good approach. We can use configuration to decide which assembly and type to load. And when we run the application, it works!

The CSV reader works just fine, but we run into a problem if we try to use one of the other reader types.

Let's update the configuration to use the web service reader. (In the App.config file for the commit mentioned above, comment out the CSV section and uncomment the Service section):

This sets the values for "ReaderAssembly" and "ReaderType" to "PersonReader.Service.dll" and "PersonReader.Service.ServiceReader" respectively.

Unfortunately, this breaks the application. If we run the application and click the button, we get an exception:

This is a "file not found" exception. And the details tell us that it is trying to load the assembly for Newtonsoft.Json version 12.0.0.0. The service reader has a dependency on Newtonsoft.Json.

That brings us to the next problem: loading dependencies.

Assembly Dependencies
In searching for a solution, I came across a tutorial about adding plugin support: Create a .NET Core application with plugins.

This tutorial addresses dependencies. Unfortunately, the described solution does not work for the current code. In the section "Plugin target framework recommendations" we see the following (screenshot and text in case it gets updated):

"Because plugin dependency loading uses the .deps.json file, there is a gotcha related to the plugin's target framework. Specifically, your plugins should target a runtime, such as .NET Core 3.0, instead of a version of .NET Standard. The .deps.json file is generated based on which framework the project targets, and since many .NET Standard-compatible packages ship reference assemblies for building against .NET Standard and implementation assemblies for specific runtimes, the .deps.json may not correctly see implementation assemblies, or it may grab the .NET Standard version of an assembly instead of the .NET Core version you expect." (emphasis mine)

This plugin solution relies on ".deps.json" files to resolve dependencies. And there's our first problem.

.deps.json
The .deps.json file has the dependencies for an assembly. For example, when we build the PeopleViewer application, we get the following output:

In addition to the PeopleViewer.exe (which calls PeopleViewer.dll), we also have PeopleViewer.deps.json. By looking inside this file, we can see the following:

This has a "dependencies" section that shows a dependency on "PersonReader.Interface" version 1.0.0. (This is the interface project that we saw above). Because this is included, that assembly can be loaded along with the PeopleViewer assembly.

But our data reader assemblies do not have .deps.json files:

These assemblies are .NET Standard assemblies. As noted in the plugin tutorial, the dependencies for .NET Standard assemblies cannot be generated without knowing what .NET environment it will be running under. For example, the service reader may need a different version of Newtonsoft.Json when run from .NET Framework compared to running in .NET Core.

Options
To go down the path of the sample plugin architecture, I would need to change the data reader projects to .NET Core from .NET Standard. That is not something that is always practical depending on how the projects are being used.

Additionally, the plugin architecture seemed to be quite a bit more than I needed for this application.

Since all of the reader assemblies and dependencies are in a separate folder, I can take a different path. Instead of trying to figure out how to get the dependencies to load automatically, I can just load them manually.

Manually Loading Assemblies
In the previous code, we manually loaded the one data reader assembly based on configuration. To load the dependencies, we will load all of the assemblies that are in the "ReaderAssemblies" folder.

Here is the code for a "LoadAllAssemblies' method (from the "ReaderFactory.cs" file for the commit mentioned above):

In the first line, we build the path to the "ReaderAssemblies" folder.

Next, "Directory.EnumerateFiles()" will give us an enumeration of all the file names that match our search criteria. In this case, we ask for all files that end with ".dll". Also, we only search the top folder (not any subfolders).

Then we use "foreach" to loop through all the file names and load them into the default context. If there are any files that can't be loaded, then we just skip them.

Assumption
This has the assumption that all of the .dlls in this folder are ones that we want to load. This is a bit easier to do since we have a separate folder. If the reader assemblies were still in the root folder (like we had initially), I would be much more reluctant to try this approach.

Working Code
To get the code working, we call "LoadAllReaderAssemblies" at the top of our factory method (from the "ReaderFactory.cs" file for the commit mentioned above):

And now the application works with the service data reader as well:

Note: If you run this application yourself, you will also need to start the service. To start the service, open a command prompt to the "People.Service" folder and type "dotnet run". For more information on .NET Core services, check out this tutorial: Get Comfortable with .NET Core and the CLI.

Duplicated Code
With the updated solution in place, we have some unnecessary code. Let's take another look at the "GetReader" method (same as above):

In this case, the reader assembly gets loaded twice. When we call "LoadAllReaderAssemblies", everything in that folder is loaded, including the one for the data reader.

Then the next lines are concerned about getting a reference to the "Assembly" object that represents the reader assembly. To do this, we end up loading the data reader assembly a second time.

Rethinking the Solution
Let's go back to the initial problem: Type.GetType() does not automatically load an assembly.

But we saw that it still works when we manually loaded the assembly. Remember this code?

When we manually loaded the "PersonReader.CSV.dll" assembly, GetType worked just fine.

Now that we are loading the reader assembly and all of its dependencies, we can go back to that solution.

Back to Square One
With a better understanding of what's going on, we can go back to where we were initially. We can take our original code and add "LoadAllReaderAssemblies" to the top. Here is that code (in the ReaderFactory.cs file in the final code):

With this, we also need to go back to the original configuration (from the App.config file in the final code):

After all of the assemblies are loaded, GetType returns the Type object that we expect, and the rest of the code works as expected.

Running the application with this configuration gets data from the CSV text file:

And we can change the configuration to use the service:

Wrap Up
So we took a bit of a roundabout way to get back to where we started. But we learned some things along the way.

• With .NET Core, we need to explicitly load assemblies.
• With dynamically-loaded .NET Standard assemblies, we need to explicitly load any dependencies.

There are also some things to look into further.

• Using .NET Core (or other specific framework) projects gives us a .dep.json file that specifies dependencies.

Moving to .NET Core is pretty smooth for the most part. But there are things that pop up that can be frustrating. Eventually we'll have all of those things catalogued, and conversions will be easier.

Happy Coding!

C# 8 Interfaces: Static Main -- Why Not?

When taking a closer look at C# 8 interfaces, we come across static members. Last time we looked at using static fields and methods in an interface. But things get stranger. An interface can have a "static Main" method, which means that this is a valid application:

Okay, so there's technically more to it than this, but still: Yikes!

A static Main method lets us put the entry point to an application in an interface.

Let's take a look at this example to see what it means.

The code for this article is available on GitHub: jeremybytes/interfaces-in-csharp-8. Specifically, this uses the "StaticMain" project.

Note: this article uses C# 8 features which are not available in .NET Framework 4.8. For these samples, I used Visual Studio 16.4.1 and .NET Core 3.1.100.

Static Main
The static Main method is the entry point to an application. In a C# console application, this is generally in the "Program" class. And if you create a new console application using the .NET Core template, you get the following code:

Personal Note: One really sad thing about this template is that it fills in the "Hello World!" for you. So this takes all the fun out of building your first application.

The same is true of ASP.NET Core web applications and APIs. Here's the "Program" class that was created using the "webapi" template:

There is a bit more to the "Program" class than what is seen here, but the "Main" method is the entry point. When we start up the application, it runs "Main".

Static Main in an Interface
With C# 8 we can have static members in an interface. We can also create a "static Main" method in an interface.

Here is an interface that has a static Main method: "IHelloWorld" (from the IHelloWorld.cs file in the StaticMain project on GitHub):

The "Main" method has the same signature as the prior samples from a console application and an API application.

But instead of this method being in the Program class, it is in an interface.

The Shortest Program Class
When we have an interface with a static Main method, it leads to the world's shortest Program class (from the Program.cs file):

This is a valid C# console application (and it actually does something).

Running the Application
Let's see it work. From the command line (open at the project folder), we can type "dotnet run" to run the application.

And if we pass in a command line argument, we see that also works.

Note: When running a console application (or other application) with "dotnet run", we can pass arguments through by adding 2 dashes (--). Everything after those 2 dashes will show up in the "args" parameter on the "Main" method.

So we have a working application that has an empty body for the "Program" class.

"Program" is not Needed
So the "Program" class is empty, and it isn't doing any thing. Do we need it?

No, we don't.

If we remove the "Program" class entirely, the console application still works. That is because the "static Main" method is the entry point to the application; the "Program" class is not the entry point. The "Program" class is used as a convention, but we can use a different class (or interface) as the entry point to the application.

Developers expect to see the entry point inside the Program class. 

Keep that in mind if you are considering something different.

Multiple Entry Points
If we create another interface that has a "static Main" method, we get a compiler error. Here's the message:

"Program has more than one entry point defined. Compile with /main to specify the type that contains the entry point."

This restriction is not new; we've always had this if we tried to define multiple entry points. The difference is that it can apply to interfaces now, too.

This also means that if we have a "static Main" in the Program class, we cannot also have one in an interface (unless we use the compiler switch mentioned in the error message, and that's beyond the scope of this article).

Sure. Why Not?
As mentioned in previous articles (Static Members and Public, Private, and Protected Members), I'm still processing these changes and how they should influence my code.

Right now, I'm still holding onto the idea that interfaces are abstractions. But when we're talking about static members, we really lose that. So if we're talking about putting the entry point of an application into an interface... Why not?

Unfortunately, that is the design decision that came from Microsoft. If you check the Language Design Notes from Oct 17, 2018 (https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-10-17.md#main-in-an-interface), you'll find this gem:

"Main in an interface? No reason why not."

Translation: "No point in steering now."

Just Because You Can...
Just because you can do something doesn't mean that you should do something. I'm pretty hard-pressed to come up with a scenario where the entry point of an application would need to come from an interface. (I'll just brace for everyone supplying me with edge-case examples.)

The deeper I get into the changes to interfaces, the more concerned I get. I think that we've lost the meaning for what an interface is.

But there is nothing that forces us to use these features. So if we make the decision, we can continue to use interfaces as abstractions in our code. Even if we do this, it's important to understand what is possible because we may end up using libraries that *do* use these new features. I'm still hoping for the best at this point.

Happy Coding!

C# 8 Interfaces: Static Members

When taking a closer look at C# 8 interfaces, we have a new capability: interfaces can have static members (including static fields).

Static members give us the ability to run code from an interface without an instance of that interface.

This functionality is similar to how static members work in classes. Let's take a look at an example to show what we can and can't do with static interface members.

The code for this article is available on GitHub: jeremybytes/interfaces-in-csharp-8.

Note: this article uses C# 8 features which are not available in .NET Framework 4.8. For these samples, I used Visual Studio 16.4.1 and .NET Core 3.1.100.

Statics
When we create a static member on a class, we can use that method without creating an instance of that class.

Here's an example that takes the square root of a number and then outputs it to the console along with the current time:

This "Sqrt" (square root) method is a static method on the Math class. So we can take the square root of a number without creating an instance of the Math class.

The same is true of "Console.Writeline" and "DateTime.Now" (although DateTime is a struct rather than a class).

We won't get into whether using "static" is a good idea or not. Static members cause particular difficulty when unit testing. For a look at a workaround that is necessary when using "DateTime.Now" take a look at this article: "Mocking Current Time with a Simple Time Provider".

Today we will look at the mechanics of what is possible by using static members.

An Interface with Static Members
The code for this sample is in the StaticMembers project on GitHub. For this sample, we have a static factory that will return us a data reader.

Here is a summary of the code for the interface (from the IReaderFactory.cs file in the StaticMembers project):

We'll look at the details of what this does in a moment. For now, we'll note that  our interface has 3 members: a private static field, a public static field, and a public static method.

Static Methods on an interface *must* have an implementation. 

Static Fields do not need to be initialized by default (but it's probably a good idea).

Just like with static members on classes, we can call these members without an instance:

The first line sets the "readerType" field, and the second line calls the "GetReader" method. These all happen without having an implementation/instance of the "IReaderFactory" interface.

We'll dig into the details of this in a bit. Let's take a look at the application at large and then dive into the interface members and calling code.

Project Overview
The project is a console application. Here is the project in the solution explorer:

The "DataReaders" folder has the code for the data readers that the factory will create.

The "Factories" folder has the interface that we saw above (as well as a class-based implementation).

The "People.txt" file contains data that is used by one of the readers, and "Program.cs" is the console application itself.

As with most samples, this code is highly simplified. This factory-based approach is a bit complex for a single-project console application. I'd be more likely to use something like this if I had multiple projects and needed to do some type of dynamic loading of dependencies. But we'll take this code "as is" to look at the technical capabilities.

Let's start by touring the data readers.

Data Reader Interface and Implementation
In the "DataReaders" folder, we have an "IPeopleReader" interface. Here's the code for that (from the IPeopleReader.cs file):

This interface has 2 methods. The first gets a collection of "Person" objects, and the second gets an single "Person" based on an identifier. The "Person" class is defined in the "Person.cs" file. It contains a collection of read-write properties and an override of the ToString method. You can check the file in the GitHub project if you'd like details.

We have 2 implementations of this interface. The first is "HardCodedPeopleReader" (from the HardCodedPeopleReader.cs file):

This class implements the "IPeopleReader" interface, so it has the 2 methods. The "GetPeople" method returns a hard-coded list of Person objects. You can check the file on GitHub if you'd like the details.

The second implementation is "CSVPeopleReader" (from the CSVPeopleReader.cs file):

This class also implements "IPeopleReader". But it gets data from a text file in comma-separate values (CSV) format. (This is the "People.txt" file at the root of the project.)

The code is a bit more complex since it is loading and parsing data from the file system. Again, you can check out the GitHub project if you're curious about specific implementation.

The Factory Interface
So let's go back to the factory interface: "IReaderFactory". Here is the detail code (from the IReaderFactory.cs file):

The overall idea of this factory is that "GetReader" will give us a data reader instance based on the "readerType" field. The "savedReader" field will hold the instance so that the data reader is not re-created each time.

The "readerType" public static field contains the type for the data reader we want to use. It is defaulted to the "HardCodedPeopleReader" that we saw above.

Initialization and Implemetation
As noted above, the static fields do *not* need to be initialized. Here we have initialized one but not the other. However, the static method *must* have an implementation.

These requirements make sense if we think about them. A public static field can be set from outside of the interface code (we'll see exactly that below). A private static field can be set from somewhere inside the interface.

But a static method cannot be implemented from outside the interface since it is part of the interface itself. So static methods must have an implementation supplied when they are declared in the interface.

Note: it looks like it's possible to have an external implementation, but we won't get into that here; "extern" has its own set of concerns.

The GetReader Method
Let's walk through the "GetReader" method to see how it works.

First, the "if" statement will check to see if the value stored in the "savedReader" private static field has the same type as the "readerType" public static field. If it matches, then the method will return what is in the saved data reader field.

If the "savedReader" value does not match (or is empty), then then a little bit of reflection is used ("Activator.CreateInstance") to create an instance of the type from the "readerType" static field.

If "CreateInstance" is not able to create an instance (for example, if the constructor requires a parameter), then this will throw an exception that we let bubble up.

After the instance is created, we cast it to "IPeopleReader" using the "as" operator. If the cast is unsuccessful, this does not throw an exception. Instead, it returns null.

The result is assigned to the "savedReader" private static field. This will either have a valid "IPeopleReader" or a "null".

Next we do a null check. If the "savedReader" field is null, then we throw an InvalidOperationException that provides the type of the reader and notes that it does not implement the correct interface.

If we get to the last line of the method, then the "savedReader" private static field should have a valid value. So the last step is to return that value.

This gives us a method that will either return a valid "IPeopleReader" instance or throw an exception.

Calling Static Members
Calling static members on an interface works just like calling static members of a class. The code in the "Program.cs" file is a console application that uses the factory.

Here is the "DisplayPeople" method from the Program.cs file:

The first line uses the static "GetPeople" method on the "IReaderFactory" interface. Since this is a static member, we do not need an instance of an implementation of the interface.

The rest of the method uses the data reader that is returned from the static method: (1) printing the type to the console, (2) calling "GetPeople" on the data reader, (3) displaying the resulting collection, (4) printing any exceptions to the console.

The "DisplayPeople" method is used in the "Main" method of the program (also from the Program.cs file):

The first section calls "DisplayPeople" and will use the default data reader (i.e., "HardCodedPeopleReader"). Here are the results from that first section:

The next section sets the "readerType" public static field to use "CSVPeopleReader". Note that since "readerType" is a "Type", we need to use "typeof()" to get the proper value for the field.

After setting the "readerType", calling "DisplayPeople" again gives us different results:

This data comes from the "People.txt" file and has an extra record ("Jeremy Awesome").

The last section sets the "readerType" field to an invalid value ("Person"). This will trigger the exception handling code:

A Note about Static Fields
This interface has 2 static fields, one public and one private. This is a significant change to interfaces. In C# 7 (and before), interfaces could only contain properties, methods, events, and indexers -- fields were *not* allowed.

The reason for the exclusion of fields is that they hold data that belongs to a particular instance. Something similar could be said for constructors and destructors -- these are implementation details that do not belong to the abstraction.

But *static* fields are different. A static field does *not* belong to an instance. This is not instance-related data; this is data that belongs to the interface itself. This also means that there is only one value for a field. If we have 2 classes that implement an interface with a static field, both classes share that value (more accurately, they share access to a single value).

If the static field is public and assignable, that means that anything can change that value -- including implementing classes or code that has nothing to do with implementation (like in our console application).

Because of the possibility of assignment from multiple sources, we need to be very careful about using public static fields. The value could be changed out from under us at any time. This would lead to unexpected behavior.

Static Fields as Parameters
This sample shows how a static field can be used as a parameter for other members of the interface. These parameters do not need to be restricted to static methods; instance methods can use them as well.

Static fields can be used to parameterize default implementations for non-static members. The Microsoft docs site has a tutorial that shows this: https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/default-interface-methods-versions#provide-parameterization.

I'll have to admit that I'm not a huge fan of the example shown in the prior link -- primarily because this code is complex enough to step pretty far outside the bounds of what we have traditionally called an "interface". This is something that I mentioned in a prior article (C# 8 Interfaces: Public, Private, and Protected Members), specifically when looking at private members.

This view is still subject to change. On one side, there are people who are pushing for interfaces as abstractions, and on the other side, there are people who are pushing for interfaces as implementation. I'm not sure where we'll end up (or where I'll specifically end up). We need to have discussions about how to take things forward in a way that most developers can be successful.

The Same Thing with a Class
All of the static member functionality that we've seen in this example can be accomplished with a class. The sample project contains a class that does just that: ReaderFactory.

Here is the code from the ReaderFactory.cs file:

The body of the class is identical to the body of the interface that we saw above. And the console application can be updated to use this class instead of the interface, and it will operate just the same.

Class or Interface?
As mentioned above, we won't get into the pros and cons of static members in this article. We are just looking at what is technically available to us.

Since the code shown here includes only static members, I would probably lean toward a class for this particular code. If there were closely-related abstract members, then I might lean toward an interface (or maybe just an abstract class).

For now, I'm exploring what is possible with interfaces in C# 8. But I'm still thinking of interfaces as abstractions (for now).

Wrap Up
Static members in interfaces are quite a change from C# 7:

• Interfaces can have static members
• Static methods must have implementation
• Static fields are now allowed
• Static fields do not need a default value (but probably should have one)
• Static fields can be used to provide parameters for other members

There are a lot of changes to interfaces in C# 8. Even with "static" there is more to explore. For example, it is possible to create static constructors in an interface. I still need to take a closer look at what this means and why we might need to do that.

Keep exploring, keep learning. Once we get the technical details down, we can start trying new techniques to see where they lead us.

Happy Coding!

Tutorial: Get Comfortable with .NET Core and the CLI

The Short Version
I've created a walkthrough to get started using .NET Core and the command-line interface (CLI). It's available on GitHub:

github.com/jeremybytes/core-cli: DemoWalkthrough.md

This is based on a presentation that I've given a couple of times this year.

Update Jul 2021: A .NET 5 version of this walkthrough is also available: https://github.com/jeremybytes/dotnet50-cli.

The Longer Version
.NET Core is the future of .NET. If you come from a .NET background, you're used to using .NET Framework with Visual Studio. .NET Core has some differences that are worth getting to know.

.NET Core has a big emphasis on using a command-line interface (CLI). A primary reason for this is its cross-platform nature. Using the CLI and Visual Studio Code, we can write .NET applications using the same development environment on Windows, Linux, and MacOS.

Even if you're strictly a Windows developer, it's good to understand the command line so that you can use the visual tools more effectively. I find myself switching among Visual Studio 2019, the command line, and Visual Studio Code depending on what I'm doing. By understanding the command-line tools, we can pick the best/easiest option for what we're doing at the time.

This walkthrough will get you started with .NET Core and get you ready to dive deeper into the environment.

Level
Introductory

Target Audience
The .NET developer who has been using .NET Framework with Visual Studio.

If you have been wondering about .NET Core and how the environment differs from the .NET Framework that you've been using, then you'll get lots of good info and tips from this.

If you've been using .NET Core on a regular basis, you won't get as much out of it.

Goals
Get comfortable using .NET Core from the command line.

• Create new projects (web service, unit tests, console application).
• Run a web service in a self-hosted environment.
• Add a reference to another project.
• Run unit tests.
• Add a NuGet package.
• Create a solution and add projects.

Along the way, we'll also see how the project system differs in .NET Core compared to .NET Framework. We'll also use the built-in dependency injection that comes with ASP.NET Core.

Links
The full repository with the completed sample code can be found here: https://github.com/jeremybytes/core-cli-30.

The walkthrough is at the root level of the project in the Walkthrough.md file.

The Walkthrough is a Markdown (.md) file. If you do not already have a favorite Markdown viewer, you can just look at it directly on the GitHub site.

Screenshots
Here's a few screenshots of what you'll find along the way.

Running the Service:

Output from the Service:

Running Unit Tests:

Test Results (with a failing test):

Running the Console Application that calls the Service:

Using Dependency Injection on the API Controller:

Check It Out
If this sounds interesting, be sure to take a look:

Walkthrough: Get Comfortable with .NET Core and the CLI

Happy Coding!