mamori017.log

歴史的クソブログ

リンクとして追加したコードを含むプロジェクトをAppveyorでビルドする

f:id:mamori017:20180802111441p:plain

.NET Frameworkのプロジェクトで一部のコードを別のソリューションからリンクで参照するということはよくあるケースだと思います。 GitHubでバージョン管理している.NETプロジェクトはAppVeyorを使用してビルドしているのですが、 AppVeyorでこの関係性を持ったプロジェクトをビルドするのは厳しいと、調べもせず勝手に思っていたためビルド対象から除外していました。 *1

しかし考えてみれば、AppVeyor内のビルド環境に参照先のファイルが存在するリポジトリさえクローンできればビルドは通るはず。 感覚的にはnuget restore的に、ビルド前にAppVeyor内でgit cloneしてやれば解決するじゃないかと思ったのでやってみました。

前提として、ローカル環境のビルド対象(TargetProject)リポジトリと参照先(ReferenceProject)リポジトリは同階層にいます。

設定

appveyor.ymlのbefore_build:項目に参照したいプロジェクトのリポジトリをクローンするよう追記します。これだけ。

AppVeyor setting for .NET projects with link refer ...

これでビルド対象(TargetProject)リポジトリと参照先(ReferenceProject)リポジトリがローカル環境と同様、 同じディレクトリ内に存在することになります。

ビルド

GitHubへプッシュしたらあっさりビルドが通りました。

f:id:mamori017:20180802140447p:plain

余談というか失敗

難しく考えすぎて参照するリポジトリのクローン先をビルド対象のディレクトリ内に設定していました。 クローン先ディレクトリを作成してそこを参照させようというのが狙いです。

before_build:
  - nuget restore TargetProject.sln
  - mkdir .\TargetProject\ReferenceProject
  - git clone -q --branch=master https://githostserver/ReferenceProject.git .\TargetProject\ReferenceProject

before_buildへの記述が実行されたディレクトリの状態。

./
├ /.vs
├ /TargetProject
│ ├─ /ReferenceProject(クローン先)
│ ├─ /bin
│ ├─ /obj
│ ├─ /Properties
│ ├─ Class1.cs
│ ├─ Class2.cs
│ ├─ Class3.cs
│ └─ TargetProject.csproj
└ TargetProject.sln

これではTargetProject.slnがローカルと同様の設定のまま、参照先コードのパスだけが変わってしまっているためビルドが通りません。 クローンしたファイルを認識させるにはプロジェクトファイルの構成を変更する必要があります。

参照しているコードをReference.csとすると、TargetProject.csprojの元の状態はこのようになっています。

<ItemGroup>
  <Compile Include="..\..\ReferenceProject\ReferenceProject\Reference.cs">
    <Link>ReferenceProject\Reference.cs</Link>
  </Compile>
</ItemGroup>

ローカルのビルド環境ではこの参照パスが通りますが、AppVeyorでビルドする場合はクローン先のパスが変わってしまっているので、 ソリューション構成がDebugの時はローカル環境でのビルド、Releaseの時はAppVeyorでのビルド用に設定を変更し、それぞれで参照先が異なる状態にしました。

<ItemGroup>
  <Compile Include="..\..\ReferenceProject\ReferenceProject\Reference.cs" Condition=" '$(Configuration)' == 'Debug' ">
    <Link>ReferenceProject\Reference.cs</Link>
  </Compile>
  <Compile Include=".\ReferenceProject\ReferenceProject\Reference.cs" Condition=" '$(Configuration)' == 'Release' ">
    <Link>ReferenceProject\Reference.cs</Link>
  </Compile>
</ItemGroup>

MSBuild Conditions

これでもビルドは通るのですが、参照コードの増減があるたびに.csprojを手で書き換えないといけないので、リスクがあるうえ面倒です。 appveyor.ymlに1行追加することと比べるとデメリットしかないと思うのでこの手法は取るべきではないです。 何より早く気づけという話でした。

*1:リンクで参照せず、実体をコピーしてビルドするプロジェクトを別に作成して管理とビルドをしていた。恥ずかしい。

Visual Studioのデバッグシンボルをローカルにキャッシュした

f:id:mamori017:20180607130838p:plain

某所からVisual Studioデバッグが遅いと言われたので確認してみたところ、 デバッグシンボルがローカルにキャッシュされるよう設定されていなかった。*1

これではデバッグの都度サーバーからシンボルを読み込むことになり効率が悪いので、デバッグシンボルをローカルにキャッシュするよう設定することにした。

設定方法

f:id:mamori017:20180607130833p:plain

  • ディレクトリパスを入力したら「すべてのシンボルを読み込む」をクリックする。 シンボルサーバーから読み込んだデータがキャッシュされる。

f:id:mamori017:20180607130836p:plain

  • シンボルの読み込みが終わったら[OK]をクリックする。

  • シンボルファイルの場所のリストに「Microsoftシンボルサーバー」が無い場合はサーバーの場所を指定する。

Microsoft シンボル サーバーの場所は、http://msdl.microsoft.com/download/symbols です。

シンボルを使用したデバッグ

*1:デフォルトでキャッシュされていた気がするが設定されてなかった。

ClickOnceアプリケーションの配布をGitHub Pagesでできないか試したら警告が来た

ClickOnceアプリケーションの配布はHTTPで更新ファイルを参照できさえすれば動作するはず。 それならGitHubリポジトリ上でも実現できるのではないかと思ったのでやってみました。

といっても既にGitHubでの運用を検討されている方はおられるわけで。 どうやらリポジトリにプッシュしたファイルを参照する場合、応答ヘッダが異なるため上手くいかないようです。

devadjust.exblog.jp

GitHub Pages

それなら、(多分大丈夫だろうと思いつつ)GitHub Pages上に配布ファイルを配置した場合の動作はどうなのか。

以前はリポジトリGitHub Pages用のgh-pagesブランチを切ったうえでHTMLファイルなりを配置する必要がありました。 この状態だとコードはmasterブランチ、ClickOnceで配布するファイルはgh-pageブランチへプッシュする必要があるのですが、 現在はmasterブランチ上でGitHub Pagesも管理できるようになっています。

masterブランチでGitHub Pagesを管理する方法

リポジトリのSettings→GitHub Pagesでmaster branchを選択し、リポジトリルートにdocsディレクトリを作成します。 この/docsディレクトリ配下にHTMLファイルなりを配置し、https://(user_name).github.io/(repository_name)にアクセスすると、リポジトリGitHub Pagesが表示されるようになります。

ClickOnceアプリケーションの配置

コードブランチとGitHub Pagesブランチを分ける必要が無いのであれば、ClickOnceの発行先を/docs配下に設定し、 ビルドとClickOnceのアプリケーション発行後にリポジトリにプッシュすれば大した手間もかからずアプリケーションの配布環境が構築できるはずです。

GitHub Pages用ディレクトリ(ClickOnceアプリケーションの配布環境)を含んだmasterブランチの構成を以下の状態にしてmasterブランチへプッシュしてみます。

/ClickOnceApp(master)
┝.git
┝/ClickOnceApp(アプリケーション)
┝/docs(GitHub Pages配置ディレクトリ・ClickOnce配布用)
|┝Application Files
|┝ClickOnceApp.application
|┗setup.exe
┝.gitattributes
┝.gitignore
┝ClickOnceApp.sln
┝LICENSE
┗README.md
GitHubから警告メールが届く

上記の構成でリポジトリにプッシュしたところ、ClickOnceでのアプリケーションアップデートを実施することができました。 ビルドついでに発行するだけなので手間にもならないしこれはこれで良いのではと思ったのですが、 リポジトリへのプッシュ直後にGitHubから警告のメールが届いていました。

GitHub Pagesでバイナリファイル公開しているならRelease機能を使いなさいとのこと。その通りなので何とも言えません。*1 ちなみに、リポジトリ内にバイナリファイルがあるとプッシュするたびに警告メールが届きつづけるみたいです。

The page build completed successfully, but returned the following warning for the master branch:
 
It looks like you're using GitHub Pages to distribute binary files. We strongly suggest that you use releases to ship projects on GitHub. Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software. We found the following file(s) which may be a good candidate for releases: package/setup.exe. For more information, see https://help.github.com/articles/about-releases/.
 
For information on troubleshooting Jekyll see:
 
https://help.github.com/articles/troubleshooting-jekyll-builds
 
If you have any questions you can contact us by replying to this email.

結論

ClickOnceのアプリケーション配布自体は可能だったのですが、GitHubが推奨する使用方法ではないのでやるべきではないです。

配布するアプリケーションバージョン管理が必要になったら、CodeCommitからS3にデプロイするのが現実的に考えて楽なのかなと思っています。何となく。

dev.classmethod.jp

警告でアカウントがBANされても困るのでGitHubのサポートにメールで謝っておきました。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

*1:rawgitというサービスを使えばReleaseにアップしたデータを参照できるらしい。