Add instructions for developing in a container #420

richlander · 2018-03-12T07:00:40Z

Added instructions for establishing a more dynamic container environment.

MichaelSimons

LGTM - Very nice addition!

MichaelSimons · 2018-03-12T13:52:36Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+
+You can [build container images to create your environment](README.md), as described in a Dockerfile. That's straightforward and the common use case with Docker. This document describes a much more iterative and dynamic use of Docker, defining the container environment primarily via the commandline. .NET Core includes a command called `dotnet watch` that can rerun your application or your tests on each code change. This document describes how to use the Docker CLI and `dotnet watch` to develop applications in a container.
+
+This approach relies on [volume mounting](https://docs.docker.com/engine/admin/volumes/volumes/) (that's the `-v` argument in the following commands) to mount the app into the container (without using a Dockerfile). You may need to [Enable shared drives (Windows)](https://docs.docker.com/docker-for-windows/#shared-drives) or [file sharing (macOS)](https://docs.docker.com/docker-for-mac/#file-sharing) first.


Nit - I'm not crazy about the wording mount the app into the container. This doesn't accurately describe what you are mounting to me as the "app" isn't created yet. How about something like app source, source code, or project?

MichaelSimons · 2018-03-12T13:56:22Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.
+
+```console
+docker run --rm -p 8000:80 --name aspnetappsample -e ASPNETCORE_URLS=http://+:80 -e DOTNET_USE_POLLING_FILE_WATCHER=1 -v c:\git\dotnet-docker\samples\aspnetapp:c:\app\ microsoft/dotnet:2.0-sdk cmd /c "cd app/aspnetapp && dotnet restore && dotnet watch run"


I think using the workdir option would be a more standard Docker approach over specifying cd in the docker run command.

MichaelSimons · 2018-03-12T13:58:30Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.
+
+```console
+docker run --rm -p 8000:80 --name aspnetappsample -e ASPNETCORE_URLS=http://+:80 -e DOTNET_USE_POLLING_FILE_WATCHER=1 -v c:\git\dotnet-docker\samples\aspnetapp:c:\app\ microsoft/dotnet:2.0-sdk cmd /c "cd app/aspnetapp && dotnet restore && dotnet watch run"


Is dotnet restore necessary with SDK > 2.1 for this scenario? It would be nice to get to a point where only a single command instruction is needed.

I also was thinking about that. The first-order reason (as you touch on) is restore the dotnet watch entrypoint. After 2.1, that's not needed. Still, it's very likely that an application will have dependencies outside of the SDK, which need to restored for this scenario to work.

Yes I understand the first-order reason for pre-2.1. Outside of that though, I wouldn't think the restore is necessary for >= 2.1 versions because dotnet run will perform an implicit restore.

Does this command work for a normal ASP.NET Core app now? Given that the aspnetcore shared framework isn't in the dotnet SDK image? Or is that included now? I thought we had moved the DOTNET_USE_POLLING_FILE_WATCHER var into one of the base images, but checking proves that not to be true. Should we do that now? There is no scenario I know of where you can rely on non-polling to have filesystem watcher work with volume mounts. It is this Docker scenario that made us add the switch in the first place.

DOTNET_USE_POLLING_FILE_WATCHER is not set in our images at the moment. IMO we should add to the 2.1.300 sdk images: aspnet/aspnet-docker#366

I vote for adding DOTNET_USE_POLLING_FILE_WATCHER to the microsoft/dotnet sdk images.

Should we just add ASPNETCORE_URLS as well? It is less obvious than the polling watcher. But if we want people to do this sort of thing then it makes sense.

Ya, let's add both. Seems like ASPNETCORE_URLS should go to the dotnet runtime image.

Given that the aspnetcore shared framework isn't in the dotnet SDK image?

Yes it is. That's why I picked the SDK image.

MichaelSimons · 2018-03-12T14:09:12Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+
+**Windows** using **Windows containers**
+
+`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.


What is not working correctly? Can you link to an issue?

MichaelSimons · 2018-03-12T14:26:26Z

samples/dotnetapp/dotnetapp/Program.cs

        {
-          message = String.Join(" ",args);
+          var message = $"    {GetMessage(args)}{GetBot()}";


Experience isn't great when you just pass in "--with-color". It would be nice to use the defaultMessage in this scenario.

MichaelSimons · 2018-03-12T14:32:21Z

samples/dotnetapp/dotnetapp/Program.cs


        WriteLine("**Environment**");
        WriteLine($"Platform: .NET Core");
        WriteLine($"OS: {RuntimeInformation.OSDescription}");
        WriteLine();
  }

-  public static string GetBot() 
+  private static string GetMessage(string[] message)


Indent styling of this method is different. Should use 4 space indenting.

natemcmaster · 2018-03-12T16:44:55Z

We should probably add instructions for how to change the bin/ and obj/ folder. Unless users are developing with Notepad or Vim, they are likely to have issues with volume mounting their source code folder into a Docker container. The SDK writes temp files into obj/ that are machine specific, so either dotnet-watch/dotnet-run will fail inside the container, or the intellisense in VS/VS Code will be broken. Or worse, it will alternate between those two broken states.

To workaround this, I set ENV RunningInsideDocker true and add a Directory.Build.props file to my projects that looks like this:

<Project>
  <PropertyGroup Condition="'$(RunningInsideDocker)' == 'true'">
    <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/docker/</BaseIntermediateOutputPath>
    <BaseOutputPath>$(MSBuildProjectDirectory)/bin/docker/</BaseOutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(RunningInsideDocker)' != 'true'">
    <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/host/</BaseIntermediateOutputPath>
    <BaseOutputPath>$(MSBuildProjectDirectory)/bin/host/</BaseOutputPath>
  </PropertyGroup>
</Project>

Unfortunately, this doesn't work with dotnet watch 2.0.0 because dotnet-watch didn't correctly determine the location of the "obj" folder until dotnet-watch 2.1.0-preview1-final.

richlander · 2018-03-12T17:55:13Z

Any thoughts on the order of the Linux container options? Same q for the unit testing doc. I'd like the first option to be the one that most people are using. We should decide what that is.

richlander · 2018-03-12T17:57:32Z

@natemcmaster Yes! I was running into this problem (a lot) and going to ask how to do this.

Why is the second case needed?

natemcmaster · 2018-03-12T18:11:56Z

You could probably do without the second case...haven't tested though. I did this b/c I wanted the output directories to be side-by-side to avoid potential overlap.

In dotnet-watch, we fixed the "obj/" folder issue. There was a hidden workaround in dotnet-watch 2.0.0 for it: https://github.com/aspnet/DotNetTools/blob/617499cd7cc448028303a8c66e54fef6ba8253e9/src/Microsoft.DotNet.Watcher.Tools/CommandLineOptions.cs#L69-L73, but this hidden switch doesn't exist in 2.1.0 since we fixed aspnet/DotNetTools#244

richlander · 2018-03-12T19:13:00Z

Sorry @natemcmaster . I get the need for the two cases now. I looked at it again.

richlander · 2018-03-13T02:56:01Z

@natemcmaster I have tried this with 2.0.x and 2.1.4. and get the following error. If I delete d.b.p, then it works. I deleted all obj/bin folders first. dotnet run still works. It is just dotnet watch run that has this issue.

C:\git\dotnet-docker\samples\dotnetapp\dotnetapp>dotnet watch run
watch : Error(s) finding watch items project file 'dotnetapp.csproj'
watch : MSBuild output from target 'GenerateWatchList':
watch :
watch :    Build started 3/12/2018 7:49:04 PM.
watch :         1>Project "C:\git\dotnet-docker\samples\dotnetapp\dotnetapp\dotnetapp.csproj" on node 1 (GenerateWatchList target(s)).
watch :         1>C:\git\dotnet-docker\samples\dotnetapp\dotnetapp\dotnetapp.csproj : error MSB4057: The target "GenerateWatchList" does not exist in the project.
watch :         1>Done Building Project "C:\git\dotnet-docker\samples\dotnetapp\dotnetapp\dotnetapp.csproj" (GenerateWatchList target(s)) -- FAILED.
watch :
watch :    Build FAILED.

natemcmaster · 2018-03-13T16:32:25Z

Yeah, this is the error I was talking about aspnet/DotNetTools#244. There are a bunch of workarounds, so pick your poison:

Add this to your .csproj file

<Import Project="obj\$(MSBuildProjectFile).dotnetwatch.g.targets" Condition="Exists('obj\$(MSBuildProjectFile).dotnetwatch.g.targets')" />

dotnet watch --msbuildprojectextensionspath ./obj/docker/ run
Upgrade your DotNetCliToolReference to https://dotnet.myget.org/feed/aspnetcore-dev/package/nuget/Microsoft.DotNet.Watcher.Tools/2.1.0-preview1-27933
Upgrade your SDK to 2.1.300-preview1 and use https://www.nuget.org/packages/dotnet-watch/2.1.0-preview1-final (dotnet install tool -g dotnet-watch --version 2.1.0-preview1-final
Wait for 2.1.300-preview2 which will have dotnet watch bundled and will have the fix for Determine value of MSBuildProjectExtensionsPath aspnet/DotNetTools#244

richlander · 2018-03-13T17:16:35Z

Ah, I thought you were saying this was fixed in 2.1.0 and that the hidden switch was removed. Did you mean 2.1.300?

natemcmaster · 2018-03-13T17:41:36Z

It will be fixed in 2.1.0, but by "2.1.0" I meant dotnet-watch v2.1.0, which ships in SDK v2.1.300. Yeah, that's confusing.

richlander · 2018-03-13T21:12:14Z

Ah, that explains why I was confused. I saw your earlier directions but didn't follow them because of the confusion. Will try your instructions now.

dsplaisted · 2018-03-13T22:29:25Z

@richlander @natemcmaster FYI, we have dotnet/sdk#867 tracking making it easier to redirect the bin and obj folders.

richlander · 2018-03-15T05:18:07Z

I've given up on making this work with 2.0. I'm going to switch to 2.1 Preview 2+ and assume that the environment variables I need are all there. This will make the experience a lot better.

richlander · 2018-03-15T20:31:26Z

This change is now done (AFAIK). Waiting on a fix for #426.

raffaeler · 2018-03-16T23:58:00Z

I did some experiments using the alpine image (nightly build) running aspnetcore (angular template). I was successful but the 'lesson learned' can be useful in the doc.

the publish layer needs nodejs and nodejs-npm packages which were not available in the alpine image (not sure for the other images). I resolved by running apk add commands
the runtime layer needs nodejs, nodejs-npm and libuv-dev packages
the csproj should set the property PublishWithAspNetCoreTargetManifest to false in order to avoid a lot of missing dependencies when running the app

I can share the multi-stage dockerfile, if you believe it can be helpful.

richlander · 2018-03-17T04:54:22Z

Yes, please do share your Dockerfile @raffaeler. @glennc is working on something similar, so it would be good to compare notes.

There might be some confusion on the goals of this particular sample. The goal is that no Dockerfile is needed.

richlander · 2018-03-17T05:05:08Z

@natemcmaster With the latest commit, the samples are finally working for me, as expected! Thanks for your offline feedback.

CTRL-C of the aspnetapp samples doesn't work well for me on macOS. Works on Windows.

raffaeler · 2018-03-17T10:42:59Z

First step: create an angular app from a developer command with 2.1 installed
Note: with the following steps, there is no solution, just a csproj in the same folder of the dockerfile

dotnet new angular
npm install
dotnet run

In order to make it work in a container, the following property group must be added to the csproj file

<PropertyGroup>
  <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

The following multi-stage dockerfile provides the instruction to build the container with an Alpine Linux distribution and Net Core 2.1 (currently in preview)

FROM microsoft/dotnet-nightly:2.1-sdk-alpine as build
WORKDIR /app

# the first step is to use just the csproj and sln (if any)
# to restore nuget packages
# COPY *.sln .
COPY *.csproj .
RUN dotnet restore

# now copy all the other files and build the app
COPY . .
WORKDIR /app
RUN dotnet build

FROM build AS publish
WORKDIR /app
# the alpine distribution doesn't come with nodejs and npm (separate packages)
RUN apk update
RUN apk add nodejs
RUN apk add nodejs-npm
RUN dotnet publish -c Release -o out

FROM microsoft/dotnet-nightly:2.1-runtime-alpine AS runtime
WORKDIR /app
COPY --from=publish /app/out ./
# nodejs and libuv-dev are required also at runtime
RUN apk update
RUN apk add nodejs
RUN apk add nodejs-npm
#RUN apk add libuv
RUN apk add libuv-dev
#
# if you see the following error ...
# «
# An assembly specified in the application dependencies manifest (basics2.deps.json) was not found:
#   package: 'Microsoft.ApplicationInsights.AspNetCore', version: '2.1.1'
# »
# ... you probably forgot to add add the following to the csproj file
#  <PropertyGroup>
#    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
#  </PropertyGroup>
# Doc on this property at:
# https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store#aspnet-core-implicit-store
#
EXPOSE 5000
ENTRYPOINT ["dotnet", "basics2.dll"]

Now the container can be built using the docker CLI

docker build -t basics2 . -f dockerfile.test2

If everything worked correctly the docker images command should show the basics2 image

Now the container can be run, specifying the port mapping and the url to listen inside the container itself.

docker run --rm -p 5000:5000 -e "ASPNETCORE_URLS=http://+:5000" basics2

It is also possible to open an interactive bash inside the container, for troubleshooting purposes

docker run --rm -p 5000:5000 -e "ASPNETCORE_URLS=http://+:5000" -it --entrypoint "/bin/ash" basics2

Please feel free to suggest/improve/modify.

richlander · 2018-03-18T19:11:33Z

Last remaining issue for this PR is #431

MichaelSimons

Looking good. I have included some suggestions.

MichaelSimons · 2018-03-20T02:36:07Z

samples/dotnetapp/dotnetapp/Program.cs

+    {
+          var defaultMessage = "Hello from .NET Core!";
+          var bot = GetBot();
+          var (message, withColor) = GetMessage(args);


To me it feels like GetMessage should be renamed to ParseArgs. If you disagree, I would suggest that GetMessage should be refactored to contain the logic to default the message when one isn't specified. In other-words GetMessage should encapsulate all of the logic around getting the message to display.

I agree. I refactored the code and didn't rename the method. My goal was to add more functionality while keeping the implementation simple. This was the simplest approach I could find.

MichaelSimons · 2018-03-20T02:43:02Z

samples/aspnetapp/README.md

-The [.NET Core Docker Sample](../dotnetapp/README.md) demonstrates more functionality, including unit testing, publishing self-contained applications and using the Alpine base image. The same techniques can be applied to ASP.NET applications.
+Looking for other samples:
+
+* [Develop .NET Core Applications in a container](../dotnetapp/dotnet-docker-dev-in-container.md)


Why is Develop .NET Core Applications in a container called out explicitly but not the other .NET Core app variations (e.g. arm, self-contained, unit testing, etc). To me, it feels like either all of other samples should be listed or all of the other ASP.NET samples plus a single reference to the .NET Core samples readme.

The same comment applies to the mirrored change in the dotnetapp readme.

MichaelSimons · 2018-03-20T02:49:20Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

@@ -0,0 +1,65 @@
+# Develop ASP.NET Core Applications in a Container
+
+Docker containers can provide a local .NET Core development environment without having to install anything on your machine. You can also use containers to augment a locally installed development environment with one that matches production. This scenario is useful if you develop on an operating system that is different than production. If you support multiple operating systems, then this approach can be even more useful.


The wording "without having to install anything" sounds like a line a used car salesman would say...lol. You need to install Docker and it would be nice to have a code editor.

MichaelSimons · 2018-03-20T02:58:35Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+
+Docker containers can provide a local .NET Core development environment without having to install anything on your machine. You can also use containers to augment a locally installed development environment with one that matches production. This scenario is useful if you develop on an operating system that is different than production. If you support multiple operating systems, then this approach can be even more useful.
+
+You can [build container images to create your environment](README.md), as described in a Dockerfile. That's straightforward and the common use case with Docker. This document describes a much more iterative and dynamic use of Docker, defining the container environment primarily via the commandline. .NET Core includes a command called `dotnet watch` that can rerun your application or your tests on each code change. This document describes how to use the Docker CLI and `dotnet watch` to develop applications in a container.


"container images" - I'm not crazy about this wording. It is confusing because it is mixing two distinctly different Docker concepts. How about just "You can build images"?

"create your environment" - I'm not sure what this is trying to convey. Perhaps describing this in more detail. Is this better?

A common use case of Docker is to containerize an application. You can define the environment necessary to run the application and even build the application itself within a Dockerfile. This document describes...

MichaelSimons · 2018-03-20T03:02:07Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.
+
+```console
+docker run --rm --name aspnetappsample -it -p 8000:80 -v c:\git\dotnet-docker\samples\aspnetapp:c:\app\ -w \app\aspnetapp microsoft/dotnet-nightly:2.1-sdk dotnet watch run


The order of the args are different for the Windows containers cmds. It would be helpful to use the same order to make it easier for the readers to pick apart the differences across the container environments.

MichaelSimons · 2018-03-20T03:06:10Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+
+## Test your application in a container while you develop
+
+You can retest your application in a container with every local code change. This works for both console applications and websites. The syntax differs a bit for Windows and Linux containers. You can see this demonstrated in [Develop .NET Core Applications in a Container](../dotnetapp/dotnet-docker-dev-in-container.md).


What do you think about removing the This works for both console applications and websites. The syntax differs a bit for Windows and Linux containers. statement here? Let the reference go into the details.

You could provide a direct link to the testing section.

richlander · 2018-03-21T17:44:08Z

They were conflicts with master. Rebased master content into this branch and pushed -f.

The content is now ready to go.

MichaelSimons

Looks good. I just have one comment.

MichaelSimons · 2018-03-21T18:12:25Z

samples/aspnetapp/aspnet-docker-dev-in-container.md

+`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.
+
+```console
+docker run --name aspnetappsample --rm -it -p 8000:80 -v c:\git\dotnet-docker\samples\aspnetapp:c:\app\ -w \app\aspnetapp microsoft/dotnet-nightly:2.1-sdk dotnet watch run


I think a previous comment I made may have been overlooked.

The order of the args are different for the Windows containers cmd. It would be helpful to use the same order to make it easier for the readers to see the differences across the container environments.

MichaelSimons reviewed Mar 12, 2018

View reviewed changes

richlander mentioned this pull request Mar 15, 2018

Add environment variables to baser images #426

Closed

This was referenced Mar 15, 2018

Add Environment variables to Dockerfiles #427

Closed

Add Environment variables #428

Merged

richlander mentioned this pull request Mar 17, 2018

CTRL-C doesn't work on ASP.NET apps with dotnet watch in docker #431

Closed

richlander mentioned this pull request Mar 19, 2018

Add instructions for building with docker #434

Merged

MichaelSimons reviewed Mar 20, 2018

View reviewed changes

richlander mentioned this pull request Mar 20, 2018

Include sample for DotNet.Watcher.Tools for development time. #394

Closed

9034725985 approved these changes Mar 21, 2018

View reviewed changes

richlander added 3 commits March 21, 2018 10:37

Add instructions for developing in a container

1496a8d

Add links to new samples

75a8984

Update instructions on directory location

0b44c57

richlander added 16 commits March 21, 2018 10:37

Update links and other text

f5a9fba

Update per feedback

d1da3e8

Final state with 2.0 - moving to 2.1

1a590ae

Update to using .NET Core 2.1 Preview 2

88acfe4

Add RUNNING_IN_CONTAINER variable back

25069a0

Rename RUNNING_IN_CONTAINER variable

40db34a

Remove RUNNING_IN_CONTAINER from instructions

b17a49d

Remove -e from docker run

ef4290b

Add DefaultItemExcludes

7199241

Add working dir to sample

7217a5f

Update command line parameters

e64ee7e

Add notes on terminating dotnet watch`

1e8e1cb

Update per feedback

524f7ef

Update per feedback

5d9a10e

Update link text

2ba0b6b

Add text on -d for #437

475c1d5

richlander force-pushed the dotnet-watch branch from 06b288f to 475c1d5 Compare March 21, 2018 17:43

MichaelSimons reviewed Mar 21, 2018

View reviewed changes

Update per feedback

a1fdaee

richlander merged commit 79844a3 into master Mar 21, 2018

richlander mentioned this pull request Mar 22, 2018

Instructions in the samples for running an ASP.NET app are not optimal #437

Closed

MichaelSimons deleted the dotnet-watch branch March 22, 2018 19:05


		You can [build container images to create your environment](README.md), as described in a Dockerfile. That's straightforward and the common use case with Docker. This document describes a much more iterative and dynamic use of Docker, defining the container environment primarily via the commandline. .NET Core includes a command called `dotnet watch` that can rerun your application or your tests on each code change. This document describes how to use the Docker CLI and `dotnet watch` to develop applications in a container.

		This approach relies on [volume mounting](https://docs.docker.com/engine/admin/volumes/volumes/) (that's the `-v` argument in the following commands) to mount the app into the container (without using a Dockerfile). You may need to [Enable shared drives (Windows)](https://docs.docker.com/docker-for-windows/#shared-drives) or [file sharing (macOS)](https://docs.docker.com/docker-for-mac/#file-sharing) first.


		Windows using Windows containers

		`dotnet watch run` is not working correctly in containers at this time. The instructions are still documented while we work on enabling this scenario.

		@@ -0,0 +1,65 @@
		# Develop ASP.NET Core Applications in a Container

		Docker containers can provide a local .NET Core development environment without having to install anything on your machine. You can also use containers to augment a locally installed development environment with one that matches production. This scenario is useful if you develop on an operating system that is different than production. If you support multiple operating systems, then this approach can be even more useful.


		## Test your application in a container while you develop

		You can retest your application in a container with every local code change. This works for both console applications and websites. The syntax differs a bit for Windows and Linux containers. You can see this demonstrated in [Develop .NET Core Applications in a Container](../dotnetapp/dotnet-docker-dev-in-container.md).

Add instructions for developing in a container #420

Add instructions for developing in a container #420

Conversation

richlander commented Mar 12, 2018 • edited Loading

MichaelSimons left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MichaelSimons Mar 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natemcmaster commented Mar 12, 2018

richlander commented Mar 12, 2018

richlander commented Mar 12, 2018

natemcmaster commented Mar 12, 2018

richlander commented Mar 12, 2018

richlander commented Mar 13, 2018 • edited Loading

natemcmaster commented Mar 13, 2018

richlander commented Mar 13, 2018

natemcmaster commented Mar 13, 2018

richlander commented Mar 13, 2018

dsplaisted commented Mar 13, 2018

richlander commented Mar 15, 2018

richlander commented Mar 15, 2018

raffaeler commented Mar 16, 2018

richlander commented Mar 17, 2018 • edited Loading

richlander commented Mar 17, 2018

raffaeler commented Mar 17, 2018

richlander commented Mar 18, 2018

MichaelSimons left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richlander commented Mar 21, 2018

MichaelSimons left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richlander commented Mar 12, 2018 •

edited

Loading

MichaelSimons Mar 12, 2018 •

edited

Loading

richlander commented Mar 13, 2018 •

edited

Loading

richlander commented Mar 17, 2018 •

edited

Loading