Overview

Avalonia is inspired by WPF but it does not try to stay compatible with WPF or any other XAML stacks. The project uses own dialect of XAML, with the biggest difference in a way it handles styles. It is not only dropped the idea of resource dictionaries, but also uses CSS-like concept of selectors for applying styles.

This is an example how the simple window and a styled control look like with Avalonia. Looks familiar, but there are twists to make WPF developers confusing from time to time. Experience with CSS will definitely be helpful to catch the new concepts.

This code works on top of .NET Core, allowing development of desktop applications for Windows, Linux and macOS. Based on the execution platform, Avalonia uses different platform-specific implementations and rendering engine.

Usage

Getting started is extremely easy. There is a Visual Studio extension which adds Avalonia templates to VS and brings visual designer for Avalonia XAML.

Alternative approach is to use Avalonia templates for .NET Core and create new application via dotnet new command.

Build generates a normal .NET Core project which can be deployed as any other .NET application. For a simple application development experience is surprisingly smooth. Now it is time to try Avalonia with a larger project to understand the gaps and any issues with running the app on different platforms.

Results of running compatibility analyzer on an enterprise-grade code base will be unspectacular. These types of applications heavily use XML configuration and ConfigurationSection which are not part of .NET Standard, they often depend on WCF and they use WinForms or WPF for UIs. From my experience, even for UI-less libraries, about 20% of code is not transferrable between .NET Core and .NET Standard.

Windows Compatibility Pack for .NET Core aims to fill this gap.

Compatibility pack is a set of packages which provide the missing APIs and allow to share more code between the platforms. UI libraries are still missing, but back-end developers should be happier now.

Compatibility pack solves the problem of missing APIs by combining type-forwarding and re-implementation approaches.

When an API exposed by the compatibility pack is used in .NET Framework execution environment, the type is forwarded and an existing .NET Framework implementation is used. However, for .NET Core, the pack provides new implementation.

It is important to understand, that Windows Compatibility Pack does not bring all these new features to other platforms. It allows to use missing APIs, but some of them are only for Windows platform, because even re-implemented code still depends on Windows.

Windows Compatibility Pack for .NET Core is not a permanent solution which will stay in codebase forever. Intention of the pack is to build a temporary bridge, allowing adoption of .NET Core to a greater extend. However, in the long term the goal stays the same – replace outdated APIs and features of .NET with newer .NET Standard-compatible alternatives.

Continuous deployment

The biggest difference between the traditional desktop software development and Web/cloud software development processes is the way software is delivered to the customers. While it looks like the need to have an installer as well as the user’s involvement in the installation process conflicts with the Ops component of DevOps, it also provides a hint how desktop software should evolve to stay actual.

Instead of using heavy monolithic installers, modern desktop applications may use some modular approaches allowing partial update of the software when such updates are available. Also, user’s involvement may be limited to just an acknowledgment or restarting of the application. Modern browsers, Visual Studio and some other applications provide a good example of this approach.

Technology-wise implementation of continuous deployment for desktop application is a no-brainer. Frameworks and tools such as Windows Store, Squirrel or Dropcraft make it easy to implement.

Continuous Integration

Part of the continuous deployment is the continuous integration. Web applications have no exclusivity there – source control, build and artifact management systems are widely adopted by all type of projects. In reality, most of the desktop-related companies which claim practicing of DevOps, do just continuous integration. They are organizing DevOps teams, hiring DevOps specialists and ask them to maintain source control and build servers - where is Dev here? Sounds more like a job description for an admin…

Title renaming is easy but does not solve the goal – ultimate responsibility of the developer for the developed feature, from the moment of developing it, to building and deploying to the customers. DevOps are still outsiders for the development team, somebody who are easy to blame for the failed builds or request to do unwanted maintenance work.

To follow DevOps approach, there is no need to organize new teams or increase budget for new roles – training, mentoring and shared responsibility for the CI pipeline will do the work as well.

Performance and usability monitoring

Monitoring of the user activities is a controversial topic for the desktop applications, while it is a normal practice in Web. Despite the uncontrolled nature of execution environment, hardware variety and difficulties with receiving customer feedback, performance monitoring solutions are not common in desktop software.

Use of telemetry information is one of the DevOps practices underutilized in desktop applications. Level of acceptance for sharing telemetry information varies from user to user and from industry to industry, so applications may provide different solutions for gathering and transferring telemetry data, acceptable for the end users. Unlike Web applications, where collection of telemetry is usually fully automated and hidden from the user, it is a good idea to let user of desktop application to control when and what is shared. An easy way to opt-out, ability to review the data before transferring, public data usage policy – all such approaches may increase acceptance of the monitoring by the users.

Is there a place for DevOps in desktop software development?

Yes! DevOps is as relevant for desktop applications as it is for Web and cloud solutions. Properly tuned continuous integration pipeline will lead to a stable, deployable build, which can be easily pushed to the customers and monitored for the user experience and performance, to guide product improvements.

If you are interested in the topic, here are the details about the upcoming meetups:

• September 26: Toronto .NET UG
• September 27: Kitchener .NET UG
• September 28: London .NET UG
• October 19: North Toronto UG

Additional resources for the presentation:

• .NET Standard overview
• .NET Standard specification
• Additions to the csproj format for .NET Core
• NuGet pack and restore as MSBuild targets
• How to use new features of MSBuild 15 with .NET Framework projects

With the release of C# 7.1, Main method can be async as well. This is just a syntactic sugar - compiler will rewrite the code to apply the same workarounds as before, but at leas for developers code will look much nicer:

static async Task Main(string[] args)
{
   ...
   await DoWork();
   ...
}

Recently, I was very surprised to learn that VS 2017 supports .editorconfig out of the box, allowing to control setting per-project, by committing this file in repository. Here is an example file:

root = true

[*]
end_of_line = crlf
insert_final_newline = true
trim_trailing_whitespace = true

# 4 space indentation
[*.cs]
indent_style = space
indent_size = 4

These settings are standard not only for VS but also for many other editors, allowing to easily share the same setting across the different code editing applications.

Naming conventions and style are stored in the same file, so they are easily separable between the projects. However, these settings are not standard and will be ignored by other applications.

This feature is great and I only wish to learn about it earlier, it is definitely under-communicated.

CSVHelper is a simple library which allows to work with CSV file in a strongly-typed manner and eliminates the need of manually parsing the text.

Exporting data to CSV

public class Animal
{
   public string Name { get; set; }
   public string Color { get; set; }
   public int Age { get; set; }

   public static void ExportToCsv(string fileName, IEnumerable animals)
   {
      using (var textWriter = new StreamWriter(fileName))
      using (var csv = new CsvWriter(textWriter))
      {
         csv.WriteRecords(animals);
      }
   }
}

In addition to storing the rows as the batch, library allows to store them one-by-one, which is useful for the large number of rows:

csv.WriteRecord(animal);
csv.NextRecord();

Reading CSV

Reading of information from CSV is equally simple:

public static IEnumerable ImportFromCsv(string fileName)
{
   using (var textReader = new StreamReader(fileName))
   using (var csv = new CsvReader(textReader))
   {
      return csv.GetRecords();
   }
}

Similar to writing to CSV, reading from CSV can be performed row-by-row as well.

It may not provide all the features of EPPlus, but is capable to handle the core manipulations with spreadsheets.

var workbook = new XLWorkbook();
var ws = workbook.AddWorksheet("data");
ws.Cell("A1").Value = 2;
ws.Cell("A2").Value = 2;
ws.Cell("A3").SetFormulaA1("=A1+A2");

Console.WriteLine(ws.Cell("A3").Value);
workbook.SaveAs("calculations.xlsx");

However, even when the new schema includes a concept of version, work is required to keep the schema in a health state, have a migration procedure and some tooling to automate the maintenance tasks.

FluentMigrator C# library provides all the needed tools to solve those problems. It provides a syntax to define the versioned schema, it provides a way to migrate databases from version to version and it includes tools to automate the tasks, during the development, deployment and in the field.

Schema

The core concept of FluentMigrator is a migration. Migration is a class which has a version and two methods Up() and Down(). Up() is responsible to migrate the target database from the previous version, to the version defined by the migration. Down() is responsible for the opposite operation – downgrading the database to the previous version.

[Migration(10)]
public class AddNotesTable : Migration
{
      public override Up()
      {
            Create.Table("Notes")
                  .WithIdColumn()
                  .WithColumn("Body").AsString(4000).NotNullable()
                  .WithTimeStamps()
                  .WithColumn("UserId").AsInt32();
      }

      public override Down()
      {
            Delete.Table("Notes");
      }
}

Instead of using SQL, migrations are defined using fluent C# syntax. This approach makes the migrations almost independent from the concrete databases, hiding the differences in SQL between them.

Migration version is defined using MigrationAttribute. Attribute accepts a number, which will be used by a migration executor to sort all the defined migrations and execute them one by one.

In addition to the schema definition, migrations can also include data seeding.

[Profile("Development")]
public class CreateDevData: Migration
{
      public override Up()
      {
            Insert.IntoTable("User").Row( new
                  {
                        Username = "devuser1",
                        DisplayName = "Dev User1"
                  });
      }

      public override Down()
      {
            // empty, not using
      }
}

This example also demonstrates an idea of profiles – an ability to selectively execute some migrations to have, for example, a seeded database for development or testing.

Execution

All migrations are usually grouped in on assembly and can be executed using the various provided tool. FluentMigrator provides CLI, NAnt, MSBuild and Rake migration runners.

Migrate.exe /connection "Data Source=db\db.sqlite;Version=3;" /db sqlite /target migrations.dll

This code demonstrates usage of CLI tool to execute the migrations from migrations.dll for the database defined via the connection string using sqlite driver. Runner automatically detect the current database version and applies only the required migrations.

FluentMigrator is published under Apache 2.0 license and available at GitHub and NuGet.

This post provides a step-by-step guide on installing and configuring TeamCity. The starting point is a clean Ubuntu 16.04 LTS server, and the goal is to run TeamCity server, build agents and PostgreSQL on this system using Docker containers. Additionally, the server and the agents are configured to support .NET Core project builds. This solution can be equally easy deployed on a local system or in cloud, like Azure or AWS.

For use of TeamCity in production environment, it is recommended to use an external database for storing the configuration data. For the described case, I use PostgreSQL running in a Docker container as well. So, the full stack includes five Docker containers, one for PostgreSQL, one for TeamCity server and three for the build agents. PostgreSQL database and all the data generated by TeamCity are persisted on a local drive using Docker mounted volumes.

Installing Docker

If you are starting from a clean system, you will need to install Docker and Docker Compose first. The detailed instructions on installing Docker for Ubuntu are available at https://docs.docker.com/engine/installation/linux/ubuntu/ and to install Docker Compose use apt-get:

sudo apt-get install docker-compose

Folder structure

I use /srv folder as a root folder for all the data related to TeamCity builds and here is the full hierarchy of folders you will need to create inside of /srv:

• /srv/docker is used to store docker-compose.yaml file (see below for more details)
• /srv/postgresql/data is used to persist the PostgreSQL database
• /srv/teamcity/agents/00X/conf contains the corresponding agent’s configuration
• /srv/teamcity/data is mounted to the TeamCity container to provide a persistent storage for the database drivers, plugins, etc.
• /srv/teamcity/logs contains TeamCity’s logs

When the folders are created, we are ready to define the stack.

Docker containers

Create a docker-compose.yaml file in the /srv/docker folder and paste the following content

It configures the stack of the required containers. The configuration is self-explanatory and I’d like to highlight just a couple of things:

• All containers are based on the latest version of the corresponding images. It is okay for experimenting and demo, but for the production environment you may want to replace :latest tag with the a particular version of the image to use.
• PostgreSQL password, user name and the database information will be needed later, to connect PostgreSQL with TeamCity.
• The default TeamCity port is 8111, however sometimes it is disabled by IT and the cloud-based server will not be available. The configuration demonstrates how to remap TeamCity from port 8111 to 8080 for the public access.
• While the PostgreSQL and TeamCity server instances are directly based on the official images, the TeamCity build agents are based on an image created (and available on Docker Hub) by me. This image is based on a JetBrain’s build agent image, but also includes installation of the .NET Core SDK (1.0.4 at the moment), allowing to use it for building and executing .NET Core applications.

The only required change for the file is a correct PostgreSQL password and if it is updated, save the file, close it and start the configured stack by running

docker-compose up -d

It will download all the required images and start the containers. We are ready to open and configure TeamCity.

TeamCity first start

In a browser, open TeamCity site. There is nothing special about configuring TeamCity running in Docker comparing with a conventional deployment, so these instructions are provided just for the completeness of the guide and based on a version 2017 of TeamCity.

On the first page, just click Proceed, the data directory is properly configured already.

Now you need to connect TeamCity with the running instance of PostgreSQL. But before, you need JDBC drivers – they are not shipped with TeamCity. In terminal, open /srv/teamcity/data/lib/jdbc and put downloaded drivers here, for example by executing

sudo wget https://jdbc.postgresql.org/download/postgresql-42.1.1.jar 

Back to the browser and click Refresh JDBC drivers – TeamCity should detect the newly installed drivers and allow you to connect to the database.

Provide the required information (use database name, user name and the password defined in the docker-compose file) and click Proceed. If you are receiving a connection error, verify that the database host name is entered without ‘http’ and the host allows access to port 5432 for PostgreSQL (most likely will be blocked if the instance is hosted by Azure or AWS).

On the next page accept the agreement, create an administrative account and you are ready to use TeamCity.

Using TeamCity for building .NET Core project

After the start, three build agents shall be detected by TeamCity automatically, but marked as Unauthorized. They need to be authorized manually.

So far, we managed to configure and launch TeamCity and connect the build agent. The last step, before creating a new build project, is to install .NET Core plugin. This step is optional, as you can run .NET Core tasks from the command line runner, but the plugin simplifies steps definition by adding a dedicated .NET Core runner.

The plugin can be downloaded at plugins.jetbrains.com and can be installed via TeamCity UI – just open Administration\Plugins List page and upload the plugin. To enable the plugin, TeamCity requires restart and, unfortunately, there is no way to do it from the UI, so you need to use console again, go to /srv/docker and do

docker-compose stop
docker-compose up -d 

After that, the plugin is installed and the agents are capable to use it (see the agent’s properties)

That’s it – now you are ready to create a TeamCity project and configure the first build.

Conclusion

This guide demonstrated an approach for deploying a Docker-based TeamCity setup for running .NET Core build. It is based on a free version of TeamCity and allows an easy cloud deployment.

For me this happened when I tried to use ILMerge for Dropcraft CLI tool and merge in one executable all the Dropcraft libraries, which use LibLog, and Serilog. As the result, merged executable did not produce any logs. No exceptions, no warnings – just empty screen.

After a short LibLog code review, I found the root cause - Type.GetType() calls. LibLog uses GetType calls to probe availability of the different logging frameworks and it uses assembly qualified type names, like Type.GetType("NLog.LogManager, NLog").

Here the issue, in the ILMerged executable there is no NLog assembly. LibLog is not able to detect any logging framework and silently ignores all logging calls. Solution is easy - if GetType call for an assembly qualified type returns null, call GetType for the type only.

Type.GetType("NLog.LogManager, NLog") ?? Type.GetType("NLog.LogManager");

After the change, assembly perfectly works with and without merging. An example of the fully modified LibLog file is available in the Dropcraft repository.

Welcome Dropcraft. Based on the version 4 of NuGet, it provides a high-level package management API and enables various scenarios of using NuGet packages in the applications. Going beyond just package installations, updates and uninstallations, Dropcraft includes a runtime API for the installed packages discovering and a simple extensibility framework, which is based on NuGet packages.

The main features of Dropcraft

• Packages installation (update, uninstallation) from the local and remote sources to any target folder.
• Package management API and a reference implementation of the command line tool.
• Configurable package resolution and deployment strategies.
• Runtime API which allows to discover installed packages, package dependencies and initialize the packages.
• Package-based application extensibility model (i.e. NuGet packages as plugins). Runtime application composition.
• Framework extensibility via the deployment and runtime hooks. Packages are able to expose event handlers to track all Dropcraft activities and modify the hosting application behavior.

Scenarios, where Dropcraft may be useful

• Deployment and management of individual NuGet packages in test environment and in production.
• An internal tool packaging using NuGet packages and deployment to target PCs.
• A custom installer which build the final product directly from NuGet packages.
• NuGet package-based plugin infrastructure.

Get started

The easiest way to try Dropcraft is to use dropcraft.exe command line tool. It is built using public Dropcraft APIs and can be used as a framework usage example by itself.

dropcraft.exe install "bootstrap/3.0.0" --path "c:\DemoApp" -s "https://api.nuget.org/v3/index.json" --framework net461

This command instructs Dropcraft to install bootstrap v3.0.0 package from NuGet.org to c:\DemoApp\ folder. It automatically resolves all the dependencies, downloads the packages and installs them

Installing packages...
0 product package(s) found and 1 new package(s) requested
Versions are confirmed
2 package(s) are resolved
        2 package(s) to install
        0 package(s) to update
bootstrap/3.0.0 downloaded
jQuery/1.9.0 downloaded
bootstrap/3.0.0 installed
jQuery/1.9.0 installed
Installation complete.

As the result, C:\DemoApp contains Content, Scripts and fonts folder from the bootstrap and jQuery packages. Dropcraft followed the instructions and installed Bootstrap 3.0.0, which is pretty old. So, the following command will update it

dropcraft.exe install "bootstrap" --path "c:\DemoApp" -s "https://api.nuget.org/v3/index.json" --framework net461

Installing packages...
2 product package(s) found and 1 new package(s) requested
Versions are confirmed
2 package(s) are resolved
        0 package(s) to install
        2 package(s) to update
bootstrap/3.3.7 downloaded
jQuery/1.9.1 downloaded
bootstrap/3.0.0 uninstalled
jQuery/1.9.0 uninstalled
bootstrap/3.3.7 installed
jQuery/1.9.1 installed
Installation complete.

Dropcraft automatically resolved the latest version for the packages and upgraded them. Similarly, Dropcraft can install additional packages, downgrade or uninstall exiting ones.

Advanced scenarios

Previous example demonstrated used of the unmodified NuGet packages with Dropcraft. To enable more advanced scenarios, Dropcraft introduces an additional package manifest file, which can be included in the package by its author.

Package manifest allows to notify Dropcaft about package’s initialization method, allows packages to intercept various Dropcraft events and participate in the application composition.

Dropcraft defines a lightweight application composition model based on an extensibility point concept. Any package is able to define one or many extensibility points which will be linked with the corresponding extensions exported by other packages. It allows to create a chain of extensibility points/extensions and build application from packages like from the Lego blocks.

Dropcraft WPF demo app demonstrates this concept. It consists from the several NuGet package which can be installed separately or all together. First command installs a package with the common interfaces, an executable and the application’s main window. It uses two package sources – NuGet.org and MyGet.org

dropcraft.exe install "Dropcraft.WpfExample.App" "Dropcraft.WpfExample.Shell" "Dropcraft.WpfExample.Common" --path "c:\DemoWPF" -s "https://www.myget.org/F/dropcraft/api/v3/index.json" -s "https://api.nuget.org/v3/index.json" --framework net461

The resulting application is just an empty window. Next command adds some functionality by installing an extension – text editor.

dropcraft.exe install "Dropcraft.WpfExample.Editor" --path "c:\DemoWPF" -s "https://www.myget.org/F/dropcraft/api/v3/index.json" -s "https://api.nuget.org/v3/index.json" --framework net461

Text editor defines a new extensibility point – editor command – and there is Dropcraft.WpfExample.Commands package which exports two command. So the next step is to install it

dropcraft.exe install "Dropcraft.WpfExample.Commands" --path "c:\DemoWPF" -s "https://www.myget.org/F/dropcraft/api/v3/index.json" -s "https://api.nuget.org/v3/index.json" --framework net461

The final result is the application composed from the packages where all the packages are loosely coupled through the interfaces and the composition is facilitated by Dropcraft. The framework takes care about the order of the packages initialization, runtime extensions registration and other scenarios common in the pluggable applications.

Conclusion

• GitHub repository: https://github.com/Dropcraft/Dropcraft
• NuGet packages: NuGet.org

Dropcraft provides APIs which can be used by applications to incorporate NuGet functionality. It enables a wide range of scenarios, from direct manipulation with NuGet packages, to package-based plugins and runtime application composition.

While the release 0.2.1 is compiled for .NET 4.6.1, Dropcraft libraries target .NET Standard and are going to support .NET Core in the future releases. Similarly, future release will support ASP.NET Core in addition to the desktop applications.

While these features are primarily advertised (and work out of the box) for .NET Core projects, they can be used with .NET Framework 4.x projects too, assuming you have Visual Studio 2017 installed.

Restore

Restore task invocation is simple and is equivalent to the NuGet restore command

msbuild "path" /t:restore

If you will try to execute the command for an existing .NET Framework project with some NuGet packages referenced, it will do nothing. The exact message is “Nothing to do. None of the projects specified contain packages to restore”. MSBuild restore does not recognize packages.config. Instead, it expects to see all the NuGet references inside of the .csproj files.

This feature can be enabled via the NuGet Package Manager options. You may need to remove and add again referenced packages to switch csproj to the new way of referencing packages.

As the result, the MSBuild should be able to perform the restore command successfully.

Pack

MSBuild pack command is the direct replacement for the NuGet pack. While MSBuild still supports .nuspec files, it can also build the package based on the project properties, or the command line parameters, without spec.

Similar to the restore command, pack does not work out of the box for .NET Framework projects. To support this command, some MSBuild tasks need to be imported in the project. It is done automatically for the .NET Core projects, but requires some modifications in csproj for the .NET Framework projects.

First change is to import NuGet related build tasks.

<Import Project="$(MSBuildSDKsPath)\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets" />

MSBuildSDKsPath variable points to C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks folder and is a part of the new MSBuild concept - SDK - which allows dynamically delivered build process extensions.

With this change, MSBuild is ready to do the pack. However, if you will try, it will complain about missing fields – ID and Authors. This fields can be defined using MSBuild properties or from the command line. For example, the command line may look like

msbuild /t:pack /p:PackageId=MSBuildTestLib /p:Authors="Andrei Marukovich"

And when defined in csproj

<PropertyGroup>
    <PackageId>MSBuildTestLib</PackageId>
    <Authors>Andrei Marukovich</Authors>
    <BuildOutputTargetFolder>lib\net461</BuildOutputTargetFolder>
</PropertyGroup>

BuildOutputTargetFolder is a property which should be used in this case to instruct MSBuild which framework folder to use for the build output. Without this line, the project assemblies will go in the root of .nupkg \lib folder. For the additional information about using the MSBuild properties for controlling the packing process and defining the package metadata, see Additions to the csproj format for .NET Core.

After these final changes, the modified .NET Framework project will allow to restore the packages and to be packed as a NuGet package using MSBuild, without involving NuGet.exe, and will continue to work in Visual Studio 2017.

With the provided code, application will fail when any conflict will appear. For the problematic packages, meta information will not be resolved, and the resolve result for the associated GraphNode will be null.

The simplest approach to solve the conflicts is to use Analyze() method of GraphNode class. This method returns analysis result which contains information about the issues. There are three types of issues: cycle dependencies, version downgrades and versioning conflicts, and all of them are detected by GraphNode.Analyze().

While the cycle dependencies and versioning conflicts are most likely will lead to the application failure, version downgrades can be handled. Downgrade means presence of the required package with a version lower than a version of one of the resolved packages. In this situation, the dependency resolver adds both packages and marks package with the lower version as a downgraded package. It can be used by the application to decide next action: allow downgrade or fail.

This post demonstrates one of the ways of incorporating the NuGet libraries in an application. Dave Glick, an author of Wyam’s, has a great introduction to NuGet v3 APIs and I recommend to read his posts before continuing, however it is not required. The NuGet usage approach described in this post is different from the approach reviewed in the mentioned articles. When applied, it allows to create .NET Standard compatible libraries and incorporate the NuGet tooling not only in .NET Framework applications, but also in .NET Core solutions.

NuGet 3 uses a zillion of libraries. Unlike NuGet 2, composed from just a few libraries, NuGet 3 design is based on multiple small libraries. For example, the post’s sample code uses nine libraries. Another note about the API – it is still in development. Post is based on version 3.5.0-rc1-final of NuGet and before the release some APIs may change.

Top level NuGet libraries used by the solutions are NuGet.DependencyResolver and NuGet.Protocol.Core.v3.

Workflow

The logical workflow is similar to NuGet restore command and from the developer perspective it includes the following phases:

• Prepare package sources
• Identify a list of packages to install. This is a list of top level packages, requested by user or application.
• Request NuGet to discover dependencies for the targeted packages
• Install the target packages and recursively install dependencies with help of NuGet

Main concepts

• PackageSource identifies packages feed. NuGet understands local (file system-based) and remote package sources.
• SourceRepository is a combination of PackageSource and various services to retrieve specific resources (metadata, dependencies, etc.)
• Context usually plays a role of operation’s configuration and operation’s cache. Examples are SourceCacheContext, RemoteWalkContext
• RemoteDependencyWalker discovers all dependencies for the provided package
• LibraryRange uniquely identifies a library (package) with Name, VersionRange and LibraryDependencyTarget, which is the library type (Package, Project, etc.). Library type plays an important role in the way the dependencies are resolved in the sample code.
• LibraryDependency is a list of dependencies for the concrete library
• IProjectDependencyProvider is a special library provider which allows to submit custom libraries in RemoteDependencyWalker and makes the whole workflow possible.

Prepare package sources

The following code adds the official NuGet feed as the package source and registers the sources in the RemoteDependencyWalker’s context.

var resourceProviders = new List>();
resourceProviders.AddRange(Repository.Provider.GetCoreV3());
 
var repositories = new List
{
    new SourceRepository(new PackageSource("https://api.nuget.org/v3/index.json"), resourceProviders)
};
 
var cache = new SourceCacheContext();
var walkerContext = new RemoteWalkContext();
 
foreach (var sourceRepository in repositories)
{
    var provider = new SourceRepositoryDependencyProvider(sourceRepository, _logger, cache, true);
    walkerContext.RemoteLibraryProviders.Add(provider);
}

Identify a list of packages to install

RemoteDependencyWalker accepts only one root library to calculate the dependencies. In case of the multiple root target libraries, they should be wrapped inside of a fake library and IProjectDependencyProvider allows to include the fake library in the dependency resolution process.

IProjectDependencyProvider defines SupportsType method, which allows to control library types handled by the class and GetLibrary method which is expected to return the library object.

The trick is to define the fake library as a LibraryDependencyTarget.Project and only accept this type of libraries to be resolved by ProjectDependencyProvider. So, when RemoteDependencyWalker will ask for the instance of the fake library, it can be constructed with the list of targeted libraries as dependencies. For example, the following code assumes that two NuGet libs are the targeted libraries to install.

public Library GetLibrary(LibraryRange libraryRange, NuGetFramework targetFramework, string rootPath)
{
    var dependencies = new List();
 
    dependencies.AddRange( new []
    {
        new LibraryDependency
        {
            LibraryRange = new LibraryRange("NuGet.Protocol.Core.v3", VersionRange.Parse("3.0.0"), LibraryDependencyTarget.Package)
        },
        new LibraryDependency
        {
            LibraryRange = new LibraryRange("NuGet.DependencyResolver", VersionRange.Parse("3.0.0"), LibraryDependencyTarget.Package)
        },
    });
 
    return new Library
    {
        LibraryRange = libraryRange,
        Identity = new LibraryIdentity
        {
            Name = libraryRange.Name,
            Version = NuGetVersion.Parse("1.0.0"),
            Type = LibraryType.Project,
        },
        Dependencies = dependencies,
        Resolved = true
    };
}

Dependency discovery

When all preparations are done, RemoteDependencyWalker can start to discover the dependencies

walkerContext.ProjectLibraryProviders.Add(new ProjectLibraryProvider());

var fakeLib = new LibraryRange("FakeLib", VersionRange.Parse("1.0.0"), LibraryDependencyTarget.Project);
var frameworkVersion = FrameworkConstants.CommonFrameworks.Net461;
var walker = new RemoteDependencyWalker(walkerContext);
 
GraphNode result = await walker.WalkAsync(
    fakeLib,
    frameworkVersion,
    frameworkVersion.GetShortFolderName(), RuntimeGraph.Empty, true);
 
foreach (var node in result.InnerNodes)
{
    await InstallPackageDependencies(node);
}

The provided code does more than the dependencies discovery. It defines the supported .NET framework version and it iterates through the result to install the packages.

Installing the packages

And now application is ready to install the discovered packages

HashSet _installedPackages = new HashSet();
 
private async Task InstallPackageDependencies(GraphNode node)
{
    foreach (var innerNode in node.InnerNodes)
    {
        if (!_installedPackages.Contains(innerNode.Key))
        {
            _installedPackages.Add(innerNode.Key);
            await InstallPackage(innerNode.Item.Data.Match);
        }
 
        await InstallPackageDependencies(innerNode);
    }
}
 
private async Task InstallPackage(RemoteMatch match)
{
    var packageIdentity = new PackageIdentity(match.Library.Name, match.Library.Version);
 
    var versionFolderPathContext = new VersionFolderPathContext(
        packageIdentity,
        @"D:\Temp\MyApp\",
        _logger,
        PackageSaveMode.Defaultv3,
        XmlDocFileSaveMode.None);
 
    await PackageExtractor.InstallFromSourceAsync(
        stream => match.Provider.CopyToAsync(
            match.Library,
            stream,
            CancellationToken.None),
        versionFolderPathContext,
        CancellationToken.None);
}

As the result of execution, all resolved packages will be de-duplicated and installed in D:\Temp\MyApp[package-name] subfolder. Each package subfolder includes .nupkg, .nuspec and libraries for all supported frameworks.

And that’s it. The provided code demonstrates the whole workflow. There are tons of small details hidden behind this simple demo, but it should be enough for staring your own experiments. Fill free to comment if you have any questions.

(var name, var color, _) = new Cat();

Underscore here represents a value to discard, similar to out variables. However, what I would really like to see from the pattern matching is the following:

if (x is Cat (var name, var color, _)) { }

to match x as Cat and deconstruct it to extract name and color. Or

if (x is Cat (var name, var color, 2)) { } 

to match x as two years old Cat, and extract the rest if it is true. Or may be

If (GetCat() is (_, var color, 3)) { }

to match and deconstruct the Cat object returned by GetCat()

All these constructs bring together pattern matching, tuples and deconstruction and allow to develop even more condensed code.

To support pattern matching, C# 7.0 extends use of is and case keywords and allows to use constants and types as the patterns. The simple use of the pattern matching is to match a value against some constant:

public void UltimateQuestion(object x)
{
   if (x is 42)
   {
      Console.WriteLine("This is the answer");
   }
}

More interesting use is to test for the type and to create a new variable of that type

public void UltimateQuestion(object x)
{
   if (x is null)
      return;

   if (!(x is int i))
      return;

   Console.WriteLine(i < 42 ? "Ask one more time" : "42 is the answer");
}

Similarly, patterns can be matched using switch statement:

switch (animal)
{
   case Dog d:
      break;
   case Cat c when c.Color == "White":
      break;
   case null:
      Console.WriteLine("No animal");
      break;
   default:
      Console.WriteLine("Unknown animal");
      break;
}

Notes

Unlike Haskel or Elixir where pattern matching is engraved into the language, C# implementation of pattern matching does not feel at the moment fully integrated with the language. It could be because of the limited number of patterns available to use or a loos link between pattern matching and deconstruction, but anyway it is a promising start which requires some improvements in the next releases.

Similar to the previous release – C# 6.0 – new release is not focused on a single flagship feature and introducing several smaller features. One of the most exiting of these features (at least for me) is out variables. Initially this feature was planned for 6.0 release but was cut shortly before the release.

Code which is similar to the following snipped is extremely common in all types of C# application:

public string ReformatDouble(string val)
{
   double x;

   if (double.TryParse(val, out x))
   {
      return $"{x:F4}";
   }

   return $"{x}";
}

Sometime out variable is not even needed, because the single propose of the code could be testing parsing of the value:

public bool IsDouble(string val)
{
   double x;
   return double.TryParse(val, out x);
}

With the new “out variable” feature this code can be significantly simplified:

public string ReformatDouble(string val)
{
   if (double.TryParse(val, out var x))
   {
      return $"{x:F4}";
   }

   return $"{x}";
}

One interesting point here is the scope of the variable. Unlike variable i defined in the following loop for (var i = 0; i < 10; i++) {}, x continues to exist even outside of if (…) {} construct.

When out variable is not needed, code can be simplified even more - variable can be discarded:

public bool IsDouble(string val)
{
   return double.TryParse(val, out _);
}

Happy parsing!

Tooling

Tooling and integration with Visual Studio are surprisingly good. VS2017 support is in preview, but even the preview extension is pretty stable. C#-based Lambdas can be deployed and tested directly from Visual Studio, with a couple of clicks. Lambda tools can also be used from .NET Core CLI, which enables command line-based Continuous Integration and Continuous Deployment scenarios.

Deployment

C# Lambdas support two main workflows – simple Lambda Function and serverless application hosted by Lambda. While the first case is simple, the serverless model is more interesting as it allows to host the whole ASP.NET Core Web API site in Lambda. In this case, AWS tools, with help of CloudFormation, deploys and configures API Gateway endpoint and Lambda which routes all requests to the corresponding Web API controllers/actions. In the same time, Web API site can still be run locally for testing purposes. This model provides a huge productivity boost comparing with a traditional model when Lambda shall be deployed to AWS first and only then can be tested.

AWS Developer blog provides tutorials on creating a new C# Lambda or converting existing ASP.NET Web API site in Serverless application. While the tutorials are well written, they miss a couple of important points:

• AWS Lambda does not support .NET Core 1.1 – this is a design decision to support only LTS versions of .Net Core (netcoreapp1.0 at the moment)
• Sometimes, first publish of C# Lambda may not wire Lambda and API Gateway properly. In this case, calling Lambda from the associated gateway will results in a security error. The easy way to fix it, is to open API Gateway resource associated with the Lambda and save it, even without changes. It fixes the missing security items.
• The guide describing migration of the existing Web API site does not mention a couple of additional changes, which are required. Default .NET Core Web application template uses Microsoft.NET.Sdk.Web as a SDK. However, this SDK references libuv runtime component which is missing on AWS and raises runtime exception. This is a known issue in .NET Core and was recently fixed in v1.1 but not available in production. To avoid this issue, Web application for Lambda shall use Microsoft.NET.Sdk instead (and set EXE as an output type).

Performance

Performance of the solution is yet to be profiled, but the quick measurements show performance enough to proceed with the spikes. Latency for the cold Lambda (which is almost not relevant as you may use some techniques to keep Lambdas warm) is about 5s for the “Hello World” type of API and the average latency for the warm Lambdas is about 80ms.

If you are interested in Xamarin technologies, Xamarin team is going to be in Toronto to speak about the new features delivered as part of Visual Studio 2017 release, cloud connectivity for the mobile apps and the mobile DevOps story. You will also have a chance to participate in a panel discussion and ask your questions.

The event will take place on Thursday, April 13th at Microsoft Toronto Office (suite 1201, 222 Bay Street) from 10am to 1pm, lunch provided.

For registration, email Catherine Kerr with your name and contact details. Spaces are limited.

Agenda

• 10:00AM - App Innovation (Why Mobile? Why Now? Why Innovate?)
• 10:30AM - Delivering Great Mobile Experiences (Common challenges and approaches / Cloud connected apps / Mobile DevOps overview)
• 11.15AM - Mobile DevOps Demo
• 12:00PM - Panel Discussion / Q&A
• 12:30PM - Lunch
• 1:00PM - Close