はてなブックマーク

はじめに dotnetはその仕組み上、普通に構築すると多数のアセンブリを伴う実行ファイルとなる場合が多い。 これはウェブアプリとして展開する場合等は問題にならないが、コンソールアプリケーションとして展開したい場合、不便になることが多い。 そこで、dotnetではシングルファイルのバイナリとして生成物をまとめる機能がついているが、dotnet-5.0でどうなっているか、使う上でポイントとなる部分を書いていこうと思う。 事前知識: msbuildのプロパティについて 記事中msbuildのプロパティについて言及するが、設定方法がいくつかあるので、簡単に書く。 msbuildプロパティについては他にもいくつかルールがあったりするが、詳細は公式ドキュメントを見てほしい。 プロジェクト単位のプロパティ プロジェクト単位でプロパティを設定する場合、ビルド時にコマンドラインから指定する方法と、予めpro

はじめに C#でコンソールアプリを作成する場合、少し凝ったことをするとなると、引数の処理というのはどうしても必要になる。 この手のパッケージはnugetを探すと色々見つかるが、その中でもパターンマッチングっぽく使えるCommandLineParserについて書く。 CommandLineParser 特徴 F#で使われることも考慮しているためか、パターンマッチのように書けるAPIになっている。 後のコンセプトとしては、細かいことを考えずに使える事を重視しているとのこと。 公式wiki 基本的な使い方 参照は NuGetパッケージ で オプションクラスの定義 オプションを格納するための器として、クラスを定義する。 以下のようなクラスを定義する。 // using CommandLine; enum Hoge { X, Y, Z } class Options { // 基本的な形式 [Opt

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 特に必要に迫られたという事ではないが、デバッガについて色々調べている過程で、標準以外のnetcoreデバッガを見つけたので記事にしておく。 リポジトリリンクは以下。 https://github.com/Samsung/netcoredbg vscode上のnetcoreappデバッグについて さて、vscodeでのC#アプリのデバッグはomnisharp-vscodeという拡張が担当しているが、これがどういう仕組みで動いているかというと、C#用デバッガが、Debug Adapter Protocol(DAP)というHTTP(

はじめに dotnet core 3.0より、IValueTaskSourceの素として使えそうなManualResetValueTaskSourceCoreなるクラスが追加されたようなので、使い方等を書く。 IValueTaskSource自体については、 http://tooslowexception.com/implementing-custom-ivaluetasksource-async-without-allocations/ が詳しい。 この記事は、単純にライブラリから渡されたValueTaskをawaitするという場合には特に意識するところではないが、 例えば非同期Queueの処理結果を通知したい場合等、今まではTaskCompletionSourceを使っていたような場面で参考になると思う。 今回使ったソースは https://github.com/itn3000/val

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに .NET Coreで、イベント情報収集のためにSystem.Diagnostics.DiagnosticSourceというものが追加された。 一応公式文書として DiagnosticsSource User's Guideはあるが、日本語リソースはあまりなく、かつガイドでも若干自分が知りたいことについてわかりにくい部分があったので記事を書こうと思う。 DiagnosticSourceにはさらにActivityというものも存在するが、記事が長くなるのでこれはまた別の機会に。 DiagnosticSourceとは 簡単に言うと、動作

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今や.NET系言語を開発するのに必需品となったNuGetだが、気が付くとパッケージキャッシュフォルダが数～数十GB溜まってしまう。 パッケージキャッシュフォルダは MSのドキュメントによると、デフォルトは%userprofile%\.nuget\packages(win)、あるいは$HOME/.nuget/packages(mac,linux)とのことで、気が付くとシステムドライブがまずいことになってたりすることもある。 対処療法的にはdotnet nuget locals global-packages -cで定期的にクリア

始めに Microsoftは、ローカルで使えるストレージライブラリのFASTERというものを開発している。 このFASTER、最初はキーバリューストアであるFasterKVのみ提供していた。しかし、バージョン2019.10.31.1より、FasterLogという、データの追記に特化した機能が追加された。 少し触ってみると、今自分が実現したい機能を丁度良くカバーしてそうなので、使い方や注意点を書いておく。 FasterKVは論文も発表されているので、特徴や理論的な裏付け等が知りたければそちらも参照のこと。 論文(PDF) 日本語解説 今回紹介するFasterLogは、FasterKVで使用しているストレージ機能のベース部分を利用した、追記と範囲検索に特化したものとなる。 なお、FasterLogは今もなおインターフェイスの更新が行われており、この記事で書かれていることと微妙に差異があるかもし

はじめに C#というか.NETの世界では、外部プロセスを起動する際にSystem.Diagnostics.Processを使用するということになっている。 このProcessクラスには非同期イベントベースで標準出力をやり取りするためのAPIが存在するが、意図しない動作になる場合があるので要注意という話。 Processの非同期APIについて 非同期で標準出力、エラー出力を受け取り、かつ非同期でプロセス終了を待ちたい場合、以下のようにする。 ProcessStartInfoを以下のように設定する UseShellExecute=false RedirectStandardOutput=true RedirectStandardError=true Processをnewする(Startはしない) Processを以下のように設定する OutputDataReceivedにコールバック登録 E

はじめに この記事では、System.Threading.Channelsについて、色々と性能検証をしてみたので、その結果を書く。 この検証結果はあくまでも自分のコードの中でという条件付きなので、実際に使う際は性能比較は当然必要だが、何かの指針になれば幸い。 System.Threading.Channelsって何?という人は、System.Threading.Channelsを使うにて解説ページを書いたので、まずそちらを参照のこと。 テストコードについての指摘は随時歓迎。 検証項目について さて、今回検証したのは以下の項目。 BlockingCollectionとの比較 SingleReader/SingleWriter設定時の性能差 AllowSynchronousContinuationsオンオフの性能差 BlockingCollectionとの比較 役割として最も重複すると思われる

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マルチスレッドでの非同期データ受け渡しライブラリのSystem.Threading.Channels(corefxlabにあったころはSystem.Threading.Tasks.Channels)が、corefxに統合され、この度4.5.0-rc1としてリリースされたので、 さすがに大きな変更はないだろうと踏んで使い方などを書く。 参考: corefxlabにあったころの記事 何ができるようになるか 非同期でのプロデューサー・コンシューマーパターンを作るのがより容易になる。 特徴としては以下のようになる 順序は必ずFIFO(

始めに HttpClientをマルチスレッドかつ高負荷で回す時、少々ハマった点があったので、注意するべき点について書く。 シングルスレッドの場合 https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ にもある通り、できる限り一つのHttpClientインスタンスで使いまわすという方法で問題はない。 実際自分もこういう風に使っていた。 マルチスレッドの場合 しかし、マルチスレッドでこれを行うと少々厄介なことになる。 実際に以下のようなメソッドを適当なWindowsマシン上で実行してみよう。(要dotnet-sdk-2.0以上) using System; using System.Net; using System.Linq; using System.Net.Http; using System.Threading.T

背景 Visual Studio Code(vscode)でRustコードを書く際、選択肢としてあるのが vscode-rust だったが、最近はあんまり実装に時間取れないからrls-vscode使ってね(意訳)という事なので、そちらを使うことにする。 注意 RLSは2017/12月現在まだα開発段階なので、仕様が変わる場合や、致命的なエラーが出る場合もあるので注意。 何かあったら、rustup update nightlyで取得できる最新版で直るのを待つか、ソースから何とかするしかない。 Rust Language Server(RLS)とは 言語開発をする上で、IDEやエディタに補完機能、構文解析等の機能を統一的に提供するために定められた language server protocol のRustのための実装。 公式リポジトリは https://github.com/rust-lan

この記事はASP.NET Advent Calendar 2015の12日目です。 はじめに ASP.NET5 では、アプリケーションの設定にweb.configを固定で使うのではなく、開発者が設定元を選択することができる。 そのためのフレームワークがMicrosoft.Extensions.Configurationであり、ソースは下記URLに公開されている。 https://github.com/aspnet/Configuration 公式ドキュメントは以下 https://docs.asp.net/en/latest/fundamentals/configuration.html ただし、部分的に実際のソースと異なっていたりするので、適宜読み替えが必要。 なお、2015/12月時点でリリースされているcoreclr-rc1をベースに解説していくので、 将来的に仕様変更が入るかもしれ