コンテナサポートを追加するで追加した Dockerfile ファイルと、コンテナオーケストレーターサポートの追加で追加された Dockerfile が微妙に違う

こちらはプロジェクトの追加時、もしくはコンテナサポートの追加時に追加される Dockerfile
パスの指定にダブルクオートがある

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 9080
EXPOSE 44372

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["../WebApplication3/WebApplication3.csproj", "../WebApplication3/"]
RUN dotnet restore "../WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/../WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

コンテナオーケストレーターサポートの追加で追加された、もしくは上書きされた Dockerfile は、パスの指定にダブルクオートが無い

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 9080
EXPOSE 44372

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ../WebApplication3/WebApplication3.csproj ../WebApplication3/
RUN dotnet restore ../WebApplication3/WebApplication3.csproj
COPY . .
WORKDIR /src/../WebApplication3
RUN dotnet build WebApplication3.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish WebApplication3.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

ん?ソリューションフォルダーからの相対位置に空白がある状態で、コンテナオーケストレーターサポートを追加したらどうなるんだろう。
docker build は普通に通るので問題ないのか。

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 9701
EXPOSE 44374

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY test test/WebApplication4/WebApplication4.csproj test test/WebApplication4/
RUN dotnet restore test test/WebApplication4/WebApplication4.csproj
COPY . .
WORKDIR /src/test test/WebApplication4
RUN dotnet build WebApplication4.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish WebApplication4.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication4.dll"]
広告
カテゴリー:Docker タグ:

Visual Studio 2017 15.8でdocker-composeを利用する場合は、コンテナオーケストレーターレーターサポートからdocker-compose.ymlを追加する

Visual Studio 2017 バージョン 15.8 で Docker サポートを有効にした ASP.NET Core のアプリケーションを作ったら、docker-compose.yml が自動的に追加されなかったのでメモ

Visual Studio Tools for Docker と ASP.NET Core」の「アプリにコンテナー オーケストレーター サポートを追加する」を参照すると、下記のような記載が追加されていた。

Visual Studio 2017 バージョン 15.8 以降では、指示された場合にのみ、オーケストレーション ソリューションが追加されます。 ソリューション エクスプローラーでプロジェクトを右クリックして、[追加] > [Container Orchestrator Support](コンテナー オーケストレーター サポート) の順に選択します。 Docker Compose と Service Fabric という 2 つの異なる選択肢が提供されています。

MSDNにある通り、プロジェクトのプロパティー > 追加 > コンテナオーケストレーターサポートを選択し、
DockerComposeの追加1

Docker Compose を選択すると、
DockerComposeの追加2

ベースイメージを Windows にするか Linux にするかを尋ねられるのでOSを選択する。
DockerComposeの追加3

ソリューションに docker-compose が追加され、スタートアッププロジェクトに設定される。
DockerComposeの追加6

こんな感じの docker-compose.yml が追加される。

 version: '3.4'

services:
  webapplication1:
    image: ${DOCKER_REGISTRY}webapplication1
    build:
      context: .
      dockerfile: WebApplication1/Dockerfile

複数のプロジェクトに対してコンテナオーケストレーターサポートを追加すると、docker-compose.yml に設定が追加されるので、必要に応じてdepends_onを設定すればよい。

version: '3.4'

services:
  webapplication1:
    image: ${DOCKER_REGISTRY}webapplication1
    build:
      context: .
      dockerfile: WebApplication1/Dockerfile

  webapplication2:
    image: ${DOCKER_REGISTRY}webapplication2
    build:
      context: .
      dockerfile: WebApplication2/Dockerfile
カテゴリー:ASP.NET, Docker タグ: ,

ReSharperの Type in comment は日本語だとちょっと使いにくい

ReShaper 2018.2 で Type in comment という機能が追加されています。
https://blog.jetbrains.com/dotnet/2013/01/14/respeller-a-spell-checking-plugin-for-resharper/

この機能を有効にすると、あらかじめ登録された辞書に基づいてタイプミスがないか指摘してくれるのですが、日本語の場合分かち書きがうまくできていないこともあり、単語の単位が微妙です。

デフォルトのInspectionレベルはSuggestionなので、ビルド自体には影響はないのですが、気になり場合は無効にする場合は、Action Indicatorから Do not Show を選択すれば消えてくれます。
サジェスチョンの無効

ReSharperのOptionsから、Spelling issues の Typo in comment を変更してもいいですね。
ReSharperの設定

カテゴリー:Visual Studio, 未分類 タグ:

dotCoverでテストカバレッジが表示されない場合、JetBrainsフォルダーのCoverageDataフォルダーを削除すると解決する

ReSharperを導入してもらたので、UnitTestのカバレッジ表示にdotCoverを使っています。
UnitTestのカバレッジをとったら、UnitTestSessionsウインドウにこんなエラーが表示され、Unit Test Coverageウインドウにカバレッジが表示されなくなってしまいました。

Coverage analysis: Processing coverage snapshots: スナップショットのパス failed: Unknown storage type

キャプチャ

今回はここで触れらているように、%temp%\JetBrains\ReSharperPlatformVs14\vAny\CoverageData フォルダーをリネームしたところ、表示できるようになりました。
https://dotnettools-support.jetbrains.com/hc/en-us/community/posts/360000167744-Continuous-Testing-Failed-to-Process-Coverage-Results-The-given-key-was-not-present-in-the-dictionary-

カテゴリー:Visual Studio タグ:

C# 7 値の破棄

SignalR Coreのサンプルを見ていてTaskをawaitせずに返却しているところで、宣言もなく “_” にTaskを受けているところがあり、ドキュメントバグか?と思い実際コードにしてみても問題なく動く。

public ChannelReader Counter(int count, int delay)
{
    var channel = Channel.CreateUnbounded();</code>

    // We don't want to await WriteItems, otherwise we'd end up waiting
    // for all the items to be written before returning the channel back to
    // the client.
    _ = WriteItems(channel.Writer, count, delay);

    return channel.Reader;
}

https://docs.microsoft.com/ja-jp/aspnet/core/signalr/streaming?view=aspnetcore-2.1

??と思って調べてみたらC#7でこんな機能が入ったんですね。
https://ufcpp.net/study/csharp/datatype/declarationexpressions/#discards

カテゴリー:未分類

Static field in generic type

ReShaperさんがこんな警告を上げていたので調べてみた。

キャプチャ

Static Field in generic type

Static Fieldがジェネリックで使われていると、、、ふむ、、、なんとなく、ジェネリックで作られた型ごとに静的フィールドが作られるのかな?

2014年のneueさんの記事が引っかかった。→ジェネリッククラス内の静的フィールドの挙動について

 

カテゴリー:未分類

Windows 10 April 2018でChromeが固まる場合、かたまったPCにリモートデスクトップするとなおるかも。

この記事(Windows 10 April 2018 UpdateでChromeがフリーズする問題が発生 – 解決方法も)とか、この記事(Win10の4月末更新でChromeがフリーズする不具合、5月8日の更新で対応。MSは一時対処法も紹介 https://japanese.engadget.com/2018/05/04/win10-4-chrome-5-8-ms/)とか触れられている、Windows 10 April 2018 を当てるとWindowsが時たま固まるっていう現象

うちでもちょこちょこ出ているんだけれど、記事中にあるショートカットを実行しても改善されず。
ふと、固まったPCに他のPCからリモートデスクトップして見たら無事復旧しました。
多分、内部でディスプレイドライバーが初期化されるからだと思う。

カテゴリー:未分類