Docker on Windows: drives sharing hint

Related to Docker for Windows (as far as I know), short hint for drives sharing: if you use AD account to secure workstation, after password change drive sharing stops working. You need to go to Docker settings, un-share drives, Apply, then share them again (providing new credentials). Weird, does it store my password somewhere in it's guts? PS: eventually you may need to remove the image you were using and download/rebuild it again.

Runnning .NET Core app on Amazon EC2, part 2

I am running .NET Core apps on Amazon EC2 new images, the part 1 is here.
In Part 1 I got the app running using simple Nginx configuration, but apart from Nginx, there are other options. This should not be full web server, since all the requests are processed by Kestrel already, so just a proxy or load balancer could fit. I was told Traefik is a good option, so let's try it.
Traefik is a dynamic load balancer that integrates with different infrastructure orchestrators, but we need only simplest static config and that's quite simple to do - go get the Traefik:

sudo wget -O /usr/local/bin/traefik "https://github.com/containous/traefik/releases/download/v1.6.0-rc3/traefik_linux-amd64"

Make it executable:

sudo chmod +x /usr/local/bin/traefik

Create config file:

sudo mkdir /var/traefik
cd /var/traefik/
sudo nano simple.toml

And put following content in it:

[entryPoints]
        [entryPoints.http]
        address = ":80"
[file]
[backends]
        [backends.back1]
                [backends.back1.servers.s1]
                url = "http://localhost:5000"
[frontends]
        [frontends.front1]
        backend = "back1"
        [frontends.front1.routes.site]
        rule = "Host:ec2-34-241-215-56.eu-west-1.compute.amazonaws.com"

Create and start .NET Core application as daemon (described here)
And now it is left to start reverse proxy, it also could be run as daemon but I'll simply run from console:

sudo /usr/local/bin/traefik --configFile=/var/traefik/simple.toml

And that's it! Additional perk of Traefik is its Let's Encrypt integration, but I was not able to configure that for my EC2 instance-based app despite spending a couple of hours, so maybe that's the quest for the next time. Don't forget to stop/terminate EC2 instances after trying, or that may cost you some money if you are above the free tier or not using it.

Runnning .NET Core app on Amazon EC2, part 1

Recently, Amazon announced a new AMIs with .NET Core, based on Amazon Linux 2 and Ubuntu. Those come pre-configured with .NET Core 2.0, PowerShell Core 6.0, and the AWS CLI.
I was curious, how hard it is to use them to host web applications built using .NET Core?
The thing with .NET Core web apps is that you need a reverse proxy to serve the app, which runs in Kestrel. In this part I will be using Nginx as a reverse proxy and will try to do that with both Amazon Linux 2 and Ubuntu.

Running .NET Core in Docker container

I was following news about both Docker and .NET Core for quite a while, so decided to try to combine them in single experiment. I’ll describe there my experience doing that, mainly the information for my attempt has been taken from this Channel9 video.
The idea: run the .NET Core simple application (hello world) in a Linux container provisioned by Docker ecosystem.

SourceTree

I decided to try SourceTree DVCS client (I saw an advertisement made by someone, I don’t really remember who that was). And it made me like console.

It looks pretty, has nice UI, but somehow it make me feel pain when using it. At first, its slow - and I'm not talking about huge repos, remote repos, digging deep in history or something like that. Switching focus between latest revisions in history view is done with noticeable lag (all other operations are not faster). Sometimes I'm able to see 2 loading icons when switching focus to next revision. This makes exploring history a little bit painful.

At second, it is not convenient for me to see which branch is my current. [pic here]. Its name is bold in branches list, but branches list does not give much without history. It is also marked bold in history (and a tiny icon overlay), but that does not make much difference, since the history has a lot of bright colors - just having a bold name is not enough (let alone the icon overlay - on my 24" monitor I almost never notice it).

At third, when working with Mercurial, it does not allow to see active branches only - the ones that were not merged into the default branch. I could see either all branches or current branch only, which requires me to change filtering dropdown at the top.

Next, how would you know which branches are local and which are remote? There is no signs for that.

After all, I end up with TortoiseHG (it has its own issues, but at least it is fast).

By the way, here is what Google suggests

C#6, sugar

Here I will cover some of the new features of C# 6, which is not released yet, but the features set seems to be stable enough. I’m interested in all the ways I could write code more effective – less typing, more power. Ok, I could generate the code with Resharper or whatsoever, but why even bother? Lets get rid of the code that does not provide value.
All those features does not require new CLR, they are just syntactic sugar (by the way, the whole C# is just a syntactic sugar for IL), so I decided to take a look what they compile to.
I used Jon Skeet’s post as a reference.

Read-only properties initialization

At the first glance they should compile into field initialization – and they are. There are two options, init property in place or in constructor:

public class AutoProps
{
    public string InitInPlace { get; } = "HasThisVal";
    public string InitInCtor { get; }
    public AutoProps()
    {
        InitInCtor = "from ctor";
    }
}

The major difference there is that init in place looks like field initialization, which does not allow you to use instance members) and behaves that way too. Well, I asked dotPeek to tell me what does he think about that, and here is how the code looks like after decompilation:

public class AutoProps
{
  [CompilerGenerated]
  [DebuggerBrowsable(DebuggerBrowsableState.Never)]
  private readonly string \u003CInitInPlace\u003Ek__BackingField;
  [CompilerGenerated]
  [DebuggerBrowsable(DebuggerBrowsableState.Never)]
  private readonly string \u003CInitInCtor\u003Ek__BackingField;

  public string InitInPlace
  {
    get
    {
      return this.\u003CInitInPlace\u003Ek__BackingField;
    }
  }

  public string InitInCtor
  {
    get
    {
      return this.\u003CInitInCtor\u003Ek__BackingField;
    }
  }

  public AutoProps()
  {
    this.\u003CInitInPlace\u003Ek__BackingField = "HasThisVal";
    base.\u002Ector();
    this.\u003CInitInCtor\u003Ek__BackingField = "from ctor";
  }
}

And, they both are actually initialized in constructor, the difference is only in the order.

Automatically-implemented properties initialization

The same as in place initialization for read-only properties.

Expression-bodied members

That is a shorthand for read-only properties, operators and methods – which consist from a single statement. That’s basically is shorter way to write method body – and there is no surprises in compilation results.

nameof

Finally, no need to maintain string literals while logging, throwing e.t.c. Compiles into string literal (concatenating with surrounding strings if necessary).

Dictionaries initialization

The new dictionaries initialization syntax does not look very different:

public Dictionary<string, int> CreateDictionaryOldWay()
{
    return new Dictionary<string, int>() {
        {"a", 1},
        {"b", 2},
        {"b", 4},
        {"c", 3}
    };
}
public Dictionary<string, int> CreateDictionaryNewWay()
{
    return new Dictionary<string, int>()
    {
        ["a"] = 1,
        ["b"] = 2,
        ["b"] = 4,
        ["c"] = 3
    };
}

The major difference is in the code it compiles to, while the old way initialization compiles to Add method calls -

Dictionary<string, int> dictionary = new Dictionary<string, int>();
dictionary.Add("a", 1);

the new way uses indexers instead -

Dictionary<string, int> dictionary = new Dictionary<string, int>();
dictionary["a"] = 1;

Using for static classes

Now it is possible to reference static classes in using directive – and this will bring fields, methods and properties of that class into scope without necessity of referencing them with class name. Compiles into fully qualified names (local members have higher precedence when resolving the member). You are free to include two classes with same member names in usings, but you will not be able to use those members – compiler would not be able to detect which one you want to use.

String interpolation

That is quite complicated feature, from the point of implementation. Compiles to a string.Format call with a bit of auxilliary code.
From

public string GetSentence(string p1, int p2)
{
    return "here I am \{p1}, \{p2}";
}

to

public string GetSentence(string p1, int p2)
{
  string format = "here I am {0}, {1}";
  object[] objArray = new object[2];
  int index1 = 0;
  string str = p1;
  objArray[index1] = (object) str;
  int index2 = 1;
  // ISSUE: variable of a boxed type
  __Boxed<int> local = (ValueType) p2;
  objArray[index2] = (object) local;
  return string.Format(format, objArray);
}

Null propagation

Simple and effective way to hide null check, however I’m not sure that having a lot of null checks is a good sign.

As the name implies, that is a shortcut for an expression that could result in null value and thus applicable for reference types (nut also supports Nullable struct).

Compiles to a series of null checks, from

class Node
{
    public Node Child { get; set; }
    public int Data { get; }
}
class NullPropagation
{
    public int? GetInfo(Node n)
    {
        return n?.Child?.Data;
    }
}

to

internal class NullPropagation
{
  public int? GetInfo(Node n)
  {
    int? nullable;
    if (n == null)
    {
      nullable = new int?();
    }
    else
    {
      Node child = n.Child;
      nullable = child != null ? new int?(child.Data) : new int?();
    }
    return nullable;
  }
}

.NET is Open Source

Well, the trend of the latest years resulted in .NET going open source. That is pretty amazing, now it is possible to see what is there under the hood, without searching info in blogs and Q&A.
We've got reference source repository, which is intended to serve as a reference, located at https://github.com/Microsoft/referencesource
The new development will be in https://github.com/dotnet/corefx, it already has some libraries uploaded and the rest will come soon.
I decided to take a look into reference source, and the first place I went to was mscorlib assembly. Some notes on internals:

• Extensive use of Code Contracts there
• Some of the classes` internals do not match coding standards (or I comprehended the rules incorrectly)
• There is non-generic static class Nullable :) that is a container for static methods operating on nullables. I’m just curious what is the reason having it? There is no such thing for DateTime, for example.
• mscorlib, System.Web, System.ServiceModel are the monsters, taking more than 17 Mb of code each.
• largest file with code is System.Web.Services\System\Web\Services\Description\ServiceDescriptionSerializer.cs which seems to be obfuscated. It takes about 668KB.
• Task class is more than 6600 LOC
• Not only XML verbose, but its handling routines also – XLinq.cs from System.Xml.Linq\System\Xml\Linq has over 9k LOC and 390 KB size. It’s actually 3rd biggest file that contains code.

What's interesting is that it is now easier to go and look at what the class does inside in case of any doubts. From the other hand, that is an abstraction leak - you are not supposed to take into account actual implementation. However, according to a law of leaking abstractions, sometimes that’s inevitable.