vs2022の診断をインラインで表示する が便利だっていう話

vs2022の解像度足りない問題

テストエクスプローラーは出しておきたい
コンテナウインドウも出しておきたい
ターミナルも。。。
エラー一覧も。。。
出力も。。。

ということでエディター領域の下側にエラー一覧とか置きがちなんですが、エディター領域の下側って覇権争いが激化しているので、 診断をインラインで表示する オプションが便利でした。

インラインで表示される都合上、コード書いてるところにやや干渉しがちなので右端に出す設定が個人的におすすめです。

おしまい。

デスクトップを導入した

パワーが足りなかったのでデスクトップを急場しのぎで導入した

実際に導入したのは5月なので2か月以上前になります。

なぜ導入したのか

  • dockerやIDEをヘビーに使う場面が増えてきたため、ramが不足がちになってきた。
  • thinkpad x1 yoga gen6の1185G7だとシングルコアの性能は問題ないがマルチコアのコア数が心もとなくなってきた。

の2点が主な理由です。

構成

case

www.amazon.co.jp

ケースはNZXT H1にしました。 ライザーケーブルだと性能が落ちるとよく聞きますが、そもそも、gen4 PCIEの帯域をフルに生かすような使い方をするわけでもないので、デスクに置いたときに不快にならないことを重要視しました。 綺麗な筐体なので外観は良いですが、意外と大きかったので配置がしにくかったです。
750w電源と簡易水冷のクーリングシステムがついているのは良かったです。
あと、 筐体内のケーブリングがやりやすいと感じましたが、最近のケースはみんなそんな感じなのかは普段組み立て業をするわけではないのでわからなかったです。

M/B

www.amazon.co.jp

H1はフロントヘッダーのUSB 3.2 gen2x2を接続したかったのでこのM/Bになりました。
高さのあるM/Bだったので簡易水冷のケーブルがきつくて閉まらないかな?と思いましたが無事組み上げは出来たので問題ありませんでした。
RaptorLakeも対応できるM/Bのはずなので、多少の強化が可能なのは魅力です。
WifiBlueToothはアンテナつけないと接続が微妙だったのは残念でした。

CPU

www.amazon.co.jp

CPUはAlderLakeの12700にしました。
スリム型のケースなので簡易水冷とはいえ、Corei9だと冷やしきれるのかわからなかったというのが主な理由です。
K付きを選択するほどシングルコアの性能を求めてはいなかったのと、iGPUはあったほうが何かと便利なのでこの選択になりました。

cinebench とか

巷で出回っているスコアと同等なので、問題なく冷やせていますし、簡易水冷の恩恵もあって静かです。 (シングルが若干遅いかも?)

ram

www.amazon.co.jp

DDR5をとりあえず使いたかったので、32GBを2枚差しました。
ramの余裕は心の余裕

SSD

www.amazon.co.jp

安定の980Proの2TBです。
gen4 SSDだと決定版な気がします。

graphics

www.amazon.co.jp

5月はまだgraphic cardがやや高値傾向だったので、3060 Tiのそこそこ品質のものにしました。(それでも5月時点だと75kとかだった。今はもっとお安いですね😨)

2か月くらい利用してみて

良かったこと

パワーが上がった

悪かったこと

それ以外

まとめ

冗談抜きに、デスクトップを導入してみて、改めてx1 yogaの細かい部分の完成度の高さを感じました。
14インチラップトップだと日本で売ってもらえる64GB ramの端末がprecision 5470 くらいしかなさそうなので(ExpertBookは相変わらずのおま国ですし……。)8月中旬に64GB ramオプションが追加されるという話だったのでそれを待とうと思います。

dotnet format が動かない話に動きがあった話

しばらくの間、dotnet formatが動いてない

github.com

上記Issueを引いたものの、SDKのバージョンをフォールバックする等のワークアラウンドを取る業に時間を割く余裕もなかったので放置気味だった。

github.com

6.0.202 SDKにて解消するというお話なので、首を長くして待っている。

dependabotの依存アップデートで除外Projectの設定方法がわからない話

自動生成するようなMock Projectをslnに含めたいが、依存アップデートには含めたくない問題

dependabotの依存アップデートをしたところで、自動生成ツール側が対応してくれないと結局またロールバックしてしまうので、ignoreしたいものの、dependabotのdocを読んでも、あくまでignoreするのはpackageに関する設定のように読める。

archiveされたProjectではあるものの、基本的にはslnに含めているなら依存アップデートを行うのがWayのように読める

github.com

なるほど、そりゃそうだろうなあという気持ち。 一方で、自動生成ツールでのMoq Api生成等を行っている場合、ローカルでのdebuggingは、Multi Startup構成等で行えるようにしておきたい欲もある。

ひとまず推移的な依存の依存元を複数設定書くようにした

下記を見る限り、Projectsというよりは複数設定を書くべしなWayのよう。 github.com

一方でdotnetは推移的な依存については、勝手に参照見てくれるようなので、test Projectがあるものについてはtestを依存アップデートに設定しておけば大体事足りるように見えている。
完全に雰囲気でやっているので、時間をとれたらまた改めて整理してみる予定。

VisualStudio2022のテストエクスプローラーがうまく駆動しなかった場合の修繕

普段VisualStudio2022でテスト実行をしている勢が、テストエクスプローラーがうまく動かない問題に遭遇した話

尚、お昼の仕事をしているときに出てきた現象なので残念ながら文字のみでお送りする。

前提条件

xUnit ASP.NET Core Mvc 6 VisualStudio2022 Pro

まずは dotnet test を叩いてみる

テスト自体は普通に動く模様。

出力ウインドウでテストからの出力を確認する

Microsoft.VisualStudio.LiveShare のマニフェスト定義が参照に一致しない 旨のエラーが出てきた。

拡張機能の更新を行う

VisualStudio2022の、[ 拡張機能 ] => [ 拡張機能の管理 ] => Live Share 2022 の更新を選択することで対応可能。

感想

若干ワークアラウンド感があるので、覚えとかなきゃなという気持ち。