日曜プログラミング

休日趣味でやってるプログラミング関連記事をダラダラと

Windows GraalVM で Clojure 製CLI ツールの native-image 作ってみた

GraalVM 20.0.0 になって native-imageWindows 対応が experimental はまだ取れてないが improves significantly な状態になったそうなのでそろそろどうかなと試してみた。

自分の native-image の理解

  • JDK, JRE 無しで単体動作する exe が作れる
  • JVM 起動時間が無いためプログラムの起動が速い
  • 起動後の動作については JVM で動作するものと比べ必ずしも速いとは限らない
    • 検証した人によればむしろ遅いらしい

他でも言われているが、これならJava(Clojure)製アプリの配布が大分楽になる。開発ではないが仕事で必要に応じてちょこちょこ CLI ツールを作っていた自分にとっては前から気になっていた。

ビルド完了までの手順

Graal VM 本体 JDK11 インストール

公式GithubからWindows版のgraalvm-ce-java11-windows-amd64-xx.x.x.zipをダウンロード(xx.x.x は最新版。今回は 20.0.0)

これを展開したフォルダのbinを PATH に通しておく。 自分は既に入れている OpenJDK13 と競合しないよう JAVA_HOME 環境変数を GraalVM の方へ切り替え、PATH%JAVA_HOME%\bin を設定した。

java -version で表示される中に GraalVM が見えていれば OK。

Native Image コンポーネントインストール

GraalVM 20.0.0 リリースノート によると Native Image コンポーネントは GraalVM をインストールしたフォルダの bin 以下にある gu 経由でインストールしてねとあるのでそれに従う。gu ってのは GraalVM Updater の事らしい。

公式ドキュメントInstallation from Catalogの項目によると以下でダウンロード・インストールまでしてくれる。

gu install native-image

他にどんなコンポーネントが入れられるのかはgu availableで一覧が出る。 Windows だと 20.0.0 時点では native-image のみの模様。他 OS だと Ruby とかのコンポーネントあるのかな?

Visual Studio 2019 インストール

native-image で単体動作する exe を作るにはどうやら C/C++ コンパイラが必要らしく、また Windows では コンパイラで exe を作るのに必要なヘッダ、ライブラリをあらかじめ指定した状態で立ち上がる開発者用コマンドプロンプトから native-image を 実行する必要があるみたい。

で、これらを満たすにはこの記事時点だと Visual Studio 2019 をインストールする必要がある。

ただこの辺りは上手く動いた推測で話しているので間違っていたり余計な手順があるかもしれない。

実際の手順

  1. Visual Studio 2019インストーラダウンロード
  2. インストーラ起動後、ワークロードC++によるデスクトップ開発を選択

サイズがデカいのでしばらく待つ。

lein-native-image のインストール・設定

leiningen のタスクで native-image を生成してくれる lein-native-image と言うプラグインが既にあるのでありがたくこれを使わせてもらう。

今回テストしたツールのproject.cljはこんな感じ。多分これが最低限の設定。 ツールとしては詳細は書けないが複数ファイルの CSV を読み込んでゴニョゴニョするもの。Clojure 1.9 なのは元々 Java7 JRE で動かす事を想定していたため。

(defproject native-image-test "1.0.0"
  :plugins [[io.taylorwood/lein-native-image "0.3.1"]]

  :dependencies [[org.clojure/clojure "1.9.0"]
                 [org.clojure/data.csv "1.0.0"]
                 [commons-io/commons-io "2.6"]]
  :main ^:skip-aot native-image-test.core
  :target-path "target/%s"

  :profiles {:uberjar 
             {:aot :all
              :native-image
              {:opts ["--initialize-at-build-time"]
               :jvm-opts ["-Dclojure.compiler.direct-linking=true"]}}})

native-imageに渡すオプションの--initialize-at-build-timeはこれを付けないとコンパイル途中で以下のワーニングが出て exe が生成されても JDK が無いと動かないものになるので必須。

Warning: Aborting stand-alone image build due to unsupported features

JVM の方に渡すclojure.compiler.direct-linking=trueコンパイル時間改善になるらしいので付けておく。 他にもオプション設定が色々あるが とりあえずはこれだけ追加している。

Reflection への対処

さて、どんな Java コードも生成できるわけではないようで、 色々と制限があるみたい。

その一つが Reflection で、自分は Clojure で開発する際あまり気にせずに作っていたが、今回 native-image 実行時に初めてつまづいた。

具体的には Clojure コードで *warn-on-reflection*true にしてコンパイル時に出る Reflection warning を放置して lein native-image を実行するとコンパイル途中で以下のワーニングが出て JDK に依存する exe しか生成されない。

Warning: Aborting stand-alone image build due to unsupported features

今回の場合は自分が書いたコードで発生していたもので何の型を受け取るか分かっていたのでタイプヒントを付けて Reflection warning を解消する事で解決できた。

これが外部ライブラリで出るようだったら面倒かも。一応 手動作成した設定ファイルで明示的に指定する 方法もあるみたいだが極力この方法は避けたいところ。

ビルド

  1. 64bit 向け開発者用コマンドプロンプトの起動
    • VS2019 を前述の手順でインストールするとスタートメニューに色々な種類のコマンドプロンプトが出るが、インストールした GraalVM は 64bit 版なのでx64 Native Tools Command Prompt for VS 2019を選択して起動
  2. そこで lein native-image 実行
    • それなりに時間がかかるのでしばらく待つ。

比較

実行時間の計測

ファイルをいじったりするものだったら Clojure-main の中の処理全体を time マクロで囲ってしまうのが手軽だがここらで UNIXtime コマンドのように Windows でも外部から実行時間を測る方法がないものかと調べてみた。

PowerShellMeasure-Command が良さそう(参考)

と言うわけで以下の名前がtimeにならないバッチファイルを PATH の通った所に用意した(時刻設定をする同名 DOS コマンドがあるので)。

@echo off
powershell -C (Measure-Command {%*}).TotalMilliseconds

batch からさらに別のプロセス呼び出すようなのは別プロセス実行分の時間は測れないのとカレントパスの exe の場合 .\ を明示的に指定する必要があるがそこはまあ良しとする。

結果比較

lein uberjarして作ったstandalone版のファイルサイズと実行時間は以下。

Java7 JRE native-image
ファイルサイズ 4.41MB 10.3MB
実行時間 1563.58ms 418.89ms

一見ファイルサイズが増大してるが、JRE7フォルダのサイズが122MBな事を加味すれば 相当小さくなっている。

実行時間も速い。ただ、これはもともと CPU 時間を大して使わないプログラムなので 大部分は起動時間が短縮された事が大きいと思う。Java プログラム特有の起動時のモタつきなく動くのはちょっとした感動。

プログラム本処理部分動作の動作やメモリ使用量がどうかなども気になる所ではあるがそれはまた別の気が向いた時にでも。

ビルドできるまでに調べた事

以下はここまでの手順に到達するまでの調査経緯メモ。興味なければ飛ばして構わない。

最初はVS2019インストールする前にlein-native-imageのインストール・設定のみ終わらせてlein native-imageを実行したのだが、以下のエラーが出てつまづいた。

Error: Unable to compile C-ABI query code. Make sure native software development toolchain is installed on your system.
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1
Failed to create native image

初っ端にエラーが出た後ググると以下がすぐ出た。

Unable to compile C-ABI query code #1258

Windows SDK for Windows 7 をインストールして SDK 開発者用コマンドプロンプトから実行すると良いとの事。自分の環境は Windows10 だし Windows 10 SDK でいいだろと入れてみたものの見当たらない。

Windows 10 での開発者用コマンドプロンプトってどうなってんのと探してみると Windows 7.1 SDKが開発者用コマンドプロンプトが含まれてた最終バージョン らしく、それ以降は Visual Studio の方に含まれてるらしい。どこからかは不明。直前リンクにあるトピだと少なくとも VS2015 以降はそうなってるっぽい。

また、Visual Studio 用開発者コマンド プロンプト って何なのと言うのも気になってみてみると、 公式ドキュメント によれば、

それは、特定の環境変数を自動的に設定するコマンド プロンプトです。

との事。

しかしこの辺の事は 公式ドキュメントの Prerequisites 辺りに書いてくれんのかなあ。どう書くと良いのか決めかねてるからまだ experimental なのかね。

Clojure の Java interop で可変引数メソッドを呼び出す方法

例えばSomeClassと言うクラスのsomeStaticMethodの引数が String first, String... moreな場合。

(SomeClass/someStaticMethod first (into-array String [more...]))

more は渡したい引数分だけ要素を突っ込む。例ではスタティックメソッドになってるがインスタンスメソッドも別に変わらない。

ググるこことか割とすぐ出てくる話題ではあるのだが自分でもしばらく書いてないと忘れてたのでメモ。

しかし前回記事から 3 年近く空いてたんだなあ。

Excel で F2→Enter によるセル再評価をまとめて実行する

セル選んで F2→Enter するとセルが再評価されて書式変わったりするが、 これを大量のセルでまとめて実行する方法があるのかググってみたら見つかったのでメモ。

マクロ組んでもできなくもないが、区切り位置指定ウィザードでまとめて実行できる。

www.relief.jp

ウィザード実行前に再評価したいセルはあらかじめ選択しておく事。

spacemacs お試し中

最近 spacemacs の設定にハマってる。

ハマってると言うのはあんま良い意味ではなく、しばしばエディタの学習曲線でネタ的に良く挙がる 以下比較イメージ中にある emacs の状態。

https://qph.ec.quoracdn.net/main-qimg-05d71c622593cb4e8654e7eb4cd5c8fb-p

emacs設定の底なし沼にハマると中々抜け出せないんだよなあ。

じゃ今までの自分の emacs 設定そのままにして spacemacs なんか使わなきゃいいじゃんと言われそうだが、

  • より大きな括りで elisp 拡張機能がまとめられた layer で拡張関連のアップデート管理が楽になりそう
    • el-get ですら設定をめんどくさがってた自分には助かる
  • Evil と言う emacs 上での Vim エミュレーション機能 + spacemacs の SPC 始動でのキーバインド体系見直しによる より高効率なキーボード主体の操作ができそう

辺りに期待を持ってるので、まだガラッと変わったキーバインド覚えたり初期設定に色々と苦労してる段階だけど しばらくはいじってみようと思う。元々はそろそろ ClojureScript を勉強しようかなと 調べてたはずが完全に脱線しちゃってるけど、趣味的にやってるしいいか。

ある程度自分なりに設定が固まってきたら改めて記事として上げようと考えてる。

ASP.NET アプリを IIS に配置する(ただし一度パッケージングしてからのやり方)

はじめに

2017/01/23 加筆修正

自分でおさらい的に見返してて足りない部分があったのを追加した。

  • Web 公開ウィザードで Web Deploy Package 作成時複数ファイル出来上がる事などを追加
  • インポートをどこでやるのかを書くのを忘れていたので追加

やりたい事の要点

  • 前回作った ASP.NET Web API を使う最低限の構成の ASP.NET アプリをローカルで一度パッケージングしてから(ここ大事) そのパッケージを使って IIS に配置・ホスティングしたい

経緯的なもの

さて、前回の記事ASP.NET Web API の最低限の構成となるものが何なのかは理解できてローカルではあるが動作確認も取れた。

次はこれをリモートの IIS が動く Windows サーバに配置してホスティングするにはどうすれば良いのか次に調べだした。

ただ、アプリの配置には条件があり、一旦インストーラとか zip とかパッケージ的なものをローカルで一度固めて それをリモートの IIS が動くサーバに転送して配置する必要がある。

Visual Studio から直接リモートの IIS に接続してアプリを配置する方法はググるとすぐに見つかる。 Visual Studio Web プロジェクトの公開ウィザードっぽいもの*1を使った方法である。 ただこの最初に見つかる方法は Visual Studio から直接サーバに繋いで配置するやり方でこの方法は今回の自分の状況では使えない。

自分が望む条件ももう少し調べると同じウィザード画面で Web Deploy Package を選択すればできそうなのだが、 実際の IIS への配置までの手順を通してやったものが何故か中々見つからず調べるのに少し骨が折れた。

まあ一応 MSDN でそれっぽいのが見つかったが

https://msdn.microsoft.com/ja-jp/library/dd483479(v=vs.100).aspx

クドいし自分が知りたい事以外の情報が多すぎる・・・。

多分今回の目的に一番合うのは英語だが以下の記事の方がよりシンプルだと思う。

https://msdn.microsoft.com/en-us/library/dd465323(v=vs.110).aspx

今回は本当にトライ&エラーの果てに自分のこの記事でまとめた方法にたどり着いた感じで、 (と言っても別にトリッキーな方法を使った訳でもなく単に必要な情報をピックアップするのに手間取っただけ) 作業メモ的な側面がいつもより強いかも。

手順概要

  1. Visual Studio 2015 の Web 公開ウィザード(?) で Web Deploy Package を作成する
  2. アプリ配置前 IIS 設定(必要なら)
  3. IIS マネージャーから作成した Web Deploy Package をインポートする

Visual Studio 2015 の Web 公開ウィザード(?) で Web Deploy Pakcage を作成する

  • Visual Studio 2015(以下 VS2015) で動作確認済の ASP.NET Web アプリプロジェクトを開く
  • ソリューションエクスプローラでプロジェクトの所を右クリック -> 公開(B)

  • Web 公開ウィザード(?) で以下のように進める

    • プロファイル
      • カスタム選択
        • プロファイル名は適当に決める。残りの設定が終われば以後このカスタムプロファイルを選択。
    • 接続

      • Publish Method は「Web Deploy Package」を選択
      • Package Location は適当に選ぶ。複数のファイルができるのでソリューションフォルダ直下に out とか作ってそこ指定した方がいいかも。
      • IIS でのサイト名を決める。これも面倒なんでプロジェクト名と同じにした。
    • 設定

      • Configuration は Relese で。サーバ上でデバッグしたい場合は Debug の方が良い気がするが未確認。
      • File Publish Option で Precompile during publishing に何となくチェック
        • これも別にチェック入れなくても支障はない気がする。挙動が速くなりそうな気がしたので。

ここまで設定して「発行」を押すと、指定した Package Location の中に結構色々なファイルが生成される。 ただ、この後のインポートで必要なのは生成された zip ファイルのみ。 一応念の為サーバへ全部を持っていこうと全体を zip してみたら 約4MBだった。結構サイズでかいんだな。

アプリ配置前 IIS 設定(必要なら)

配置サーバ環境

  • Windows Server 2008(英語版)
  • IIS 7.5
    • IIS .NET 4.0 モジュールはインストール済っぽい。後述の手順で選べたからというだけで、ちゃんとした確認方法は未確認。

手順などで単語が英語多めになるけどご勘弁。

Default Application Pool の .NET Version 変更

IIS Manager を開き、Default Web Site の Application Pools で DefaultAppPool の .NET Framework Version を v4.0.30319 に変更する。 または新たに Web Site を追加して DefaultAppPool を v4.0.30319 にする。

これをやらないと WebAPI に対応する URL にいくらアクセスしても HTTT 404 エラーが返ってくるので大事。

IIS マネージャーから作成した Web Deploy Package をインポートする

  1. Default Web Site 右クリック -> Deploy -> Import Application...
  2. 何やらインポートウィザードらしきものが出て、パッケージファイルを選択しろと出るので、Web 発行ウィザードで生成された zip を選択
  3. インポートするファイル選択など出るが、特に何もせず次へと押していく

動作確認は URL を前回の Localhost から今回配置したリモート IIS への URL に変えるだけなので割愛。

グチ

全く・・・この情報にたどり付くのにほぼ丸一日かかった。 これかもしれないと気づいたリンクは こちらで、 そのリンク先は探している途中で既に通っていた(読んでいるとは言ってない) MSDN のチュートリアル記事 の中に書いている事に後で気づきさらに疲れた。。。

網羅的に全部書くのはそれはそれでいいんだけどもう少し分かり易いサマリーと言うか項目まとめも付けてくれんかねえ。

*1:公式名称は良く分からない

Java, Clojure くらいしか知らない自分が ASP.NET 上で動く Web サービスをイチから作る

はじめに

前回の記事 で NuGet の使い方から始まったのはこいつを使いたかったから。

.NET上で動き、IIS 上でホスティングする Web サービスを作る必要性が出てきて、 現状.NET 界隈を調べた感じ ASP.NET Web API.aspx) 使って作るのが 一番良さそうに思った。

Visual Studio 2015 だとプロジェクトテンプレートがあり、最初それを参考にすればいいかなと思ってたのだが、 見てるとどうも結構 ASP.NET Web API とは直接関係ないものも結構入っていて C#/ASP.NET 未経験の自分は混乱した。

時間はかかるかもしれないが、こりゃまずイチから作った方が良さそうな気がしたので 改めてその方向でググると日本語でバッチリの記事が見つかった。

読んでみて雰囲気は分かるが、細かい部分でなぜそうなるのかが分からない部分がかなり多くつまづいた。 2,3程度ならその場でちょっと調べて済ませようと思ったが、 かなり調べる事になったので、作業の流れには添いつつも自分の知識が不足してる面を補足的にメモする事にした。

なお、上記記事は動作確認までしか試してない。 これは単に自分がまず知っておくべきなのはそこまでかなと思っただけ。

実行環境

手順概要

ASP.NET Web API を使った最低限のコードを動作させるには以下の手順を踏む必要がある。

# 手順 元記事該当セクション
1 ASP.NET 空 Web アプリプロジェクトを作る プロジェクトの作成
2 外部ライブラリの依存性の解決 必要な参照の追加
3 WebAPI 初期設定を行うクラスファイルを用意する Global.asaxの追加
4 Global.asax に初期設定コードを記述する Global.asaxの追加
5 実際の API となるコントローラクラスの追加 動作確認
6 動作確認 動作確認

自分の理解のため、やや冗長ではあるが元記事より項目を細分化した。 この記事では以降、手順の方でタイトルを書いていく。

ASP.NET 空 Web アプリプロジェクトを作る

Visual Studio 2015 のメニューから ファイル -> 新規作成 -> プロジェクト で ASP.NET Web アプリケーション -> Empty で 空のプロジェクトが作成される。 この時点でそこそこいくつかフォルダやファイルが出来ているが、今回は必要そうなもの以外は無視して 何もしない事にする。

外部ライブラリの依存性の解決

他言語環境でのパッケージマネージャでは依存性の解決とか呼んだりするアレ。

ツール -> NuGet パッケージマネージャー -> ソリューションの NuGet パッケージの管理 から出る画面左上の検索ボックスにMicrosoft.AspNet.WebApiを検索すれば出てくる完全一致のもの (多分検索結果の一番上に出ると思う) にチェックしてインストールすれば良い。

前回の記事にあったように、一度ダウンロードしたものはキャッシュとして指定場所に保存されている。

WebAPI 初期設定を行うクラスファイルを用意する

ASP.NET WebAPI でこの役割を担うのがグローバルアプリケーションクラスであり、 ファイル名はGlobal.asaxと決まっている模様。

Global.asax 自体は ASP.NET WebAPI 専用と言うわけでもなく、ASP.NET 登場当初からあった ASP.NET Web アプリのグローバル設定を持たせるためのファイルらしい。 (@ITの参考記事)

Visual Studio から追加した場合、実際に WebAPI 初期化処理を書く場所となるメソッドである Application_Start だけでなく 他にも色々と追加されるが、今回は不要なので Application_Start メソッドのみ残し他は削除した。

Application_Start が呼び出されるタイミングなどは以下の記事が参考になった。 - ASP.NETのライフサイクルの仕組み - このサイトによると ASP.NET Web アプリが呼び出される最初の一回だけらしい。MSDN でもどっかで見たような気がするけどブックマークしとくの忘れた。

Global.asax に初期設定コードを記述する

元記事では必要ファイルの追加とコードの内容だけ書いてかなり短く済ませており、C#/ASP.NET 経験者には十分なのかもしれないが、 自分はかなり分からない部分がありここで色々調べた。

疑問1: App_Start フォルダ作成は必須なのか?

Visual Studio デフォルトで用意されている ASP.NET Web API プロジェクトテンプレート作成する方法では確かに作られているが stackoverflow での同様の質問と回答 を見る限りでは、別に ASP.NET アプリを動作させるための必須フォルダと言うわけでもなさそう。 回答に書かれているリンク先ブログにもっと詳しく書かれてそうな記事があったが、 自分はひとまず必須かそうでないかだけを知りたかっただけなので今回は読んでいない。

疑問2: WebApiConfig クラスとその Register メソッドは必須なのか?

英語だが、MS公式サイトにある一文が最も分かり易かった。

In an ASP.NET application, configure Web API by calling GlobalConfiguration.Configure in the Application_Start method. (引用元)

疑問に対する答えとしては別に必須ではない、となる。

元記事でのRegisterは結局は初期設定を持つ GlobalConfiguration.Configurationプロパティ.aspx) を引数に渡して書き換えているだけで、名前は極端な話 foo.bar でも動作的には問題なさそう。 *1

対して MS 公式にある方はラムダ式を使ってもっと直接的に書き換えているので、自分の練習も兼ねて今回はラムダ式を使った方法で書き直した。

動作確認

元記事にあるように Visual Studio で Web API Controller クラスを追加すると、 動作するための最低限のテンプレートも入っていて、動作確認だけであれば全くいじる必要はない。

Visual Studio のプロジェクトを実行すると localhost でセルフホスティングする Web サーバが立ち上がってブラウザがそこの URL を開く模様。 ただ、アクセスするURL http://localhost:<port>/ は HTTP 403 forbidden エラーが出る。 これで動作確認失敗と言うわけではなく、登録した ValuesController クラスにアクセスする URL ではないと言うだけ。

Fiddlerを使って http://locahost:<port>/api/values の URL に対して HTTP GET リクエストを出すと、結果がちゃんと返ってきた。 面白いのは Chrome に同じ URL を入れると XML で返ってきて、 Fiddler で Content-Type: application/json ヘッダを付ける (元の記事のやり方)で返すと JSON 形式で返ってきている所。

ASP.NET WebAPI は色んなメッセージング形式に対応しているとだけ聞いていて今回調べていたが ようやく少し実感できたかもしれない。

ちなみに元の記事で使っていた Fiddler は自分も興味があったから使ってみただけで 今回の結果を見たいだけであればブラウザアクセスするだけで間に合う。

調べた時に気にはなったが試してないもの

*1:Java のようにクラス名は大文字からという規則はあるかもしれないがそれは言語仕様レベルの話でまた別

leiningen しか使った事のないやつによる NuGet の使い方メモ

はじめに

最近は仕事上の理由からちょっとずつ .NET 関係を調べております。

今日は NuGet のお話。 NuGet は .NET 開発におけるパッケージマネージャー。 JavaMaven に近いポジション?Maven はほとんど使った事ないのでイメージだけで言ってます。

まともに使ってきたものは leiningen しかないのでその中でよく使ってきた機能が NuGet ではどうすればできるのかの観点だけでメモ。パッケージマネージャーを使うと何が嬉しいのかという話はこの記事ではしない。 その辺のメリットはググればいくらでも出てくる記事に任せる。

NuGet に関する網羅的な情報は公式ドキュメントの方にある。

インストール

参考

VisualStudio 拡張版と CLI

NuGet には VisualStudio 2015 上で動作する Visual Studio 拡張版と 単体で動作するコマンドライン(CLI)版の二つが存在する。

NuGet の全機能を使えるのは CLI 版のみらしい。プロジェクト毎に依存ライブラリを解決しつつイ ンストールしてくれるだけで良いのならVisual Studio 拡張版で良さそう。

CLI 版のインストール

ここから Windows x86 Commandline の latest exe をダウンロードし、 PATH の通った所にコピーするのみ。

以降は NuGet CLI についてのみのメモ。 *1

Visual Studio 拡張版のアップデート

Visual Studio 2015 には既に同梱されているとの事だが、今回使おうと思っている CLI 版と バージョンは合わせておいた方が良いかと思いこちらもアップデート。

公式トップにデカデカとある Install NuGet をクリックしてダウンロードされた Visual Studio 拡張ファイル(vsix)をダブルクリックしてインストールするだけ。

アップデート前のバージョンが何だったかは控えておらず失念。 *2

バージョン確認

CLI

> nuget
NuGet Version: 3.5.0.1938
usage: NuGet <command> [args] [options]
Type 'NuGet help <command>' for help on a specific command.

(以降各サブコマンドの簡易説明があるが省略)

Visual Studio 拡張版

メニューの - ツール->拡張機能と更新プログラム から開かれるダイアログで NuGet で検索して出てくる「NuGet パッケージマネージャー」を選択すると、 右にバージョン情報など出るのでそこで確認。 *3

今回自分が入れたのは 3.5.0.1996 だった。一番下の表記が CLI 版と微妙に違うけど大丈夫なんかな?

設定一覧

個別設定なら nuget config で行けそうだが、一覧をコマンドラインで見る方法は見つからず。 設定ファイルとその適用順に関しては公式のこちら に詳しく書いてある。

おおまかなイメージ的にはグローバルとプロジェクト単位それぞれで設定を持てるみたい。 設定が被っている場合の適用順はプロジェクト単位から優先して適用されるっぽい。

VisualStudio で表示・変更できる設定は?

%APPDATA%\NuGet\NuGet.Config にある。Visual Studio 2015 の GUI で変更した設定はこのファイルに反映される。 なお、これは CLI 版でもグローバル設定と言う扱い。

ちなみに Visual Studio 2017 及び NuGet 4.0 以降では Visual Studio のバージョン別に全ユーザに適用される設定も 持てるようになったとか。

パッケージの生成的なものはあるか

少しドキュメント探してみた感じだと lein uberjar 的なコマンドなさそうだなあ。

いや、nuget pack と言う一見それっぽいのはあるんだが、これで生成可能なパッケージは lein uberjar がカバーする範囲とは少し異なり、 外部ライブラリとか Visual Studio 拡張向けのパッケージ生成は可能だが、 Java の jar のような単体アプリとしても動作するようなパッケージを作る場合が見当たらなかった。

ローカル PC にパッケージリポジトリを持たせる

leiningen での依存関係の解決でのデフォルト動作のように、ライブラリを探しに行く時に ローカル PC に保持したリポジトリを探し、なければそこにダウンロードしてインストールする動作を NuGet でもやりたい。

と思って調べてみると、どうも NuGet 2.8 以降ではデフォルトでそういう動作になってるらしい

NuGet ではこういうのを local cache と呼ぶようで、CLI 版だと nuget locals all -list で確認できる。

上記コマンドで出てくるパスの中を実際に確認してみると確かにあった。 自分は NuGet パッケージは Visual Studio 2015 拡張版 NuGet 経由でしか入れてないので恐らく同じ挙動をしていると思われる。

ちなみに特に何も設定しないのにこの項目上げたのはググった時に最初に出てきた情報がプロジェクト毎にしか持てないというのが先に来てたので。 時間が経てばこの辺りの情報が上に来るようになるのを期待し敢えて書いておくことにした。

依存関係の解決

上記の挙動である事が分かったので、これは Visual Studio 上の GUI を使って利用したいライブラリを選んでインストールすれば良い。 CLI でも多分 nuget install を使えば可能だと思うが未検証。

まとめ

特に細かいカスタマイズもせず、外部ライブラリを利用するだけであれば Visual Studio 拡張版で十分だと思った。 公式のダウンロードで Visual Studio 拡張版をトップに持ってくる意図が何となく分かった。

*1:パッケージマネージャーを使った事があるなら、VS 拡張版は特に説明不要な気もする

*2:Visual Studio は再インストールするにはかなりサイズがデカいのであまり再検証する気にもならない

*3:余談だがメニューをたどれば出てくるようなものに対してスクショを貼り付けるのは個人的に記事スペースの無駄だと思う。 全くの PC 初心者向けと言うのならまだしも開発系でもたまにあるのが個人的にあまり好きじゃない。