Visual Studio 2022が正式にリリース 53
ストーリー by nagazou
リリース 部門より
リリース 部門より
マイクロソフトは8日、統合開発環境「Visual Studio」の最新版「Visual Studio 2022」を正式にリリースした。Visual Studio 2022は、シリーズ初の64ビットネイティブなソフトウェアとしてリリースされ、これにより大容量メモリへの対応と高速化が実現されている（Visual Studio Blog、Publickey、CNET、ASCII.jp）。
発表イベントに登壇したMSプログラムマネジメント CVPのアマンダ・シルバー氏は、Visual Studio 2022は大規模システムの開発においてもパフォーマンスを発揮するとしている。また実行中のアプリケーションに対して迅速にコードを反映できる「ホットリロード」機能も強化された。Visual Studio 2022では、ほぼすべてのアプリでホットリロードが可能になったとしている。また同日に発表となったNET 6にも対応している。
発表イベントに登壇したMSプログラムマネジメント CVPのアマンダ・シルバー氏は、Visual Studio 2022は大規模システムの開発においてもパフォーマンスを発揮するとしている。また実行中のアプリケーションに対して迅速にコードを反映できる「ホットリロード」機能も強化された。Visual Studio 2022では、ほぼすべてのアプリでホットリロードが可能になったとしている。また同日に発表となったNET 6にも対応している。
そういえばVisual Studio for Mac (スコア:2)
2016年リリース当時はGUIアプリが作れずがっかりした覚えがあるのですが。
最近全く弄ってなかったのでインストールしてみようかしら？
https://visualstudio.microsoft.com/ja/vs/mac/ [microsoft.com]
メモリ使用量は順当に増えている (スコア:1)
入れてみました。
.NET Core 5 で作成した小さいプロジェクトを開いてみましたが、下位プロセス含めると
2019: 1.5GB
2022: 2.0GB
ぐらいで、やはりメモリ使用量が増えています。
特に64bit化した devenv は1.5倍ぐらいに増えていますね。
Chrome で調べ物しながら開発するなら、メモリは最低 8GB、推奨 16GB って感じですか。
Re: (スコア:0)
デバッグ実行したときのことを考えると8GBはさすがに…
# あとReSharperも結構リソース奪っていくので最近はRiderの方が軽くて良い
Re: (スコア:0)
5 クラスぐらいの小さいコンソールツールのプロジェクトでこれなので、もっと大きいプロジェクト、GUI 込みのプロジェクトなんかは開くだけでもカツカツですね。
そこにデバッグ実行でアプリ自体のメモリ使用、デバッガなんかも考えると実質最低 16GB になるか……。
ソース解析なんかでかなりCPUも喰うし、開発マシンは順当にスペック上げていかないと開発効率が落ちそう。
Re: (スコア:0)
当方メモリ16GBでページングファイルなし & RamDisk使ってる環境にて。
試しに ASP.Net Core MVC の簡単なページ作ろうとしたらデバッグ中にメモリ不足警告が出て、ウソだろと思いながらRamDiskの容量削る羽目に遭った。タスクマネージャー見たら1プロジェクトで4GBとか普通に喰ってるし、16GBは最低ラインだと思う。
小規模でオーソドックスな開発なら2017を使うのが穏当かも。1プロジェクト数百MBで済むので5つくらい開きっぱなしで平行開発しても問題が出ず仕事しやすかった。
2015 は C# の文法が古いのでお勧めしかねる。
Re: (スコア:0)
もしかしてソリューションの意味で「プロジェクト」という単語を使ってる？
私は、Visual Studio 2019 で、20個ぐらいのプロジェクトを含むソリューションを
開いていますが、普通に数百MB程度ですよ。
Re: (スコア:0)
VSのGitを使ってないなら（他のGitクライアント使ってるなら）、統合Gitをオフにするだけで結構違うね。
どっちにもある機能だからメモリ使用量増加って話にはあんまり関係ないと思うけど。
一応２０２２で機能強化してるみたいだし、その分分析にCPUもってかれてるかもしれないし、使ってないならオフにしてみるのも手かも。
Re: (スコア:0)
よーし、VSS
よーしパパ、.NET 6 で Windows Formしちゃうぞー (スコア:0)
許してください、まだまだ案件でWindows Formが多いんです…(過去アプリのUIそのままで機能追加・改修しろとか)
Re: (スコア:0)
せめてWPF Canvasにアンカー相当があれば、段階的にというかいったんガラだけ移行して
浸透させていくとかもできたかもしれないけど、
（MVVMとかは置いといて）WPFでサクッとツール作れず、
デザイン移植しづらくて、アニメーションとか別に求めてないし、結果触れてる人も増えてこないので
選択肢として出しにくいんだよな。
OSSとか世界向けだと見栄えも綺麗にしたくもなるけど、即日欲しいツールとか作るために
Gridレイアウトとか調整してると時間がもったいなくなっちゃったりも。
（変に凝るための）選択肢が少ないというのがむしろWinFormsのメリットになってしまっている気がする。
# それにしてもVS2019が．ＮＥＴ６サポートしないとは思わなかった。
Re: (スコア:0)
「MVVMとか別にして」ならば、それは慣れの問題なだけです。
Re: (スコア:0)
新規ならそうなんだけど、既存のものを持っていくときめんどくさいのは画面なので。
Re: (スコア:0)
WPFのレイアウタは、なにも考えなくても適当に配置して動くのが良いんでは？
GridやCanvasなんぞ使わず、作るだけなら StackPanelだけでやればよろしい。
Re: (スコア:0)
StackPanelはマージン切っていくのが大変。
WinFormsもStackPanelだったやつならいいけど。
Canvasがある程度適当に配置して動くが、マージン固定ができない。
一応Gridで分割せずに１セルでやるのが一番近いんだが、
それならCanvasにマージン固定する機能つけてくれればいいのにと思う。
うーん、Gridで １セルでとりあえず導入してしまうかなぁ。
Re: (スコア:0)
マージンはスタイルで一括指定してイレギュラーなのは個別指定すればデザイナでチマチマ配置するよりもずっと楽でしょ
Re: (スコア:0)
新規ならそれでいいけどね。
いや、それでもWindowがStackPanelなのはあんまり想像できないんだけど。
縦のスタックパネルで行ごとに横のスタックパネル積むとかか？
元コメのように、「過去アプリのUIそのままで」みたいな状況においての話なので、
スタイル定義し始めると時間かかる（というか、そんな綺麗にスタイルで一括指定できる様になってないな）
とにかく開発のベースをWPFとかに持っていき、そこからWPFらしい形に直していくって感じで段階移行するのが狙いなので。
習熟したメンバーが移行するわけではない。
それにWPFのスタイル…というよりはリソース定義が最初がめんどくさいしなぁ。
リソースをもうちょい簡潔に描かせてくれりゃいいんだけど。
Re: (スコア:0)
StackPanelは一番多用するだろ
https://qiita.com/Kosen-amai/i... [qiita.com]
Re: (スコア:0)
なので リソースやらスタイルやら考えずに、StackPanelで並べればOKって話だよ。
StackPanelの一番シンプルな(何も面倒なことせず部品並べるだけ)って構成にすれば、いわゆる箇条書き状態になる。
ゲーム画面とか、凝った物はもちろん無理だが、世の中の入力画面やら結果画面とかは、だいたいStackPanelだけでいい。
既存画面と同じレイアウトでという話ならCanvasで座標固定で配置すればいい。
スタイルやリソース定義は楽をするために使うものであって、書かなきゃ出来ないようなものは何一つないぞ。
Re: (スコア:0)
特にStackPanelが一番っていう説得力はない。
一番でもないし、Gridで覆われてる（WindowがStackPanelではない）、StackPanelつかったがために余白作ってる。
StackPanelがうまく使えば便利なものだというのは知っているが、リンク先の最初のウィンドウは今ひとつ。
二つ目は部分的なので効果的と言えなくもないけど。
StackPanelは横に広がってしまうからね。最初のVisualStudioのプロジェクト作成ダイアログとかと比べればいい。
「過去アプリのUIそのままで」っていう元々の話にも合わない。
これは昔見か
Re: (スコア:0)
言ってることはわかる。ありがとう。
でもその辺はもう通ったの。
> スタイルやリソース定義は楽をするために使うものであって
はわかるんだけど、その前でスタイルについて愚痴ってたのは、そのもう一個前で
>>マージンはスタイルで一括指定して
って言われたから。
さらに、StackPanelを推されたけど、StackPanel使ってしまうとスタイルでマージンつけていくのが結構めんどくさい（左上位置もマージン入力したりしないといかんし、自由に動かないからね）様に思うっていうのが発端。
> Canvasで座標固定で配置すればいい。
Canvasだと左上は固定できる。Anchor相当があればこれでいいと思った。でもないという話をしていた。
「それならCanvasにマージン固定する機能つけてくれればいいのにと思う。うーん、Gridで １セルでとりあえず導入してしまうかなぁ。」
Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
Re: (スコア:0)
GridはStackPanelを置くエリアを分けるために使うもの。
Gridに通常のコントロール直置きはあまりやらない。
その動画のやつはWPFで作れば楽だったろうに。無駄な労力使ってんなー。
Re: (スコア:0)
> Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。
えっと……。
もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
# Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
Re: (スコア:0)
> えっと……。
> もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか？
えっと……。
もしかしてCanvas.LeftとCanvas.Rightを同時に使えないのをご存知ないか、
Gridセルなどでの右下マージン固定とかWinnFormsのAnchorの機能をご存知ないのでしょうか。
> # Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。
・・・さすがにもう最初から読んでとしか言えん。
Re: (スコア:0)
Re: (スコア:0)
そこまでするコストに見合ったメリットがないんだよなぁ
Re: (スコア:0)
そうねぇ、ただ別の回答もついているようにコストがね。
一度作ってしまえばいいのだけど、
（Gridを真似てMerginの固定で済ますにせよ）デザイナ周りとかどうなるのか見てみないとなんとも言えない。
探せばありそうだし、どこで妥協するか次第ではあるけど。
そんなこんなも含めて、CanvasはなんでMergin固定できるようにしてくれなかったのかと。
Re: (スコア:0)
MVVMだとバインディング先はドコ？を探すのにgrepに行き着く。
CでWindow作ってた頃に退化してる💢
整合性とか排他とか参照関係を厳密に管理するなら使わんほうがいいかも？
#見た目だけ全力注がれてデータ整合性とか同期とか排他とか破綻してるやつ再設計ちゅー
Re: (スコア:0)
というかフレームワークとして低階層すぎるのか
もうそろそろxamlを人間に書かせようとするのやめて欲しいですね
あんな前提知識必須な構造物は人間が書くものじゃないと思うんですが
Re: (スコア:0)
いにしえの「ほーむぺーじ作成ツール」と大差ないカオスになるのは目に見えてるな…
Re: (スコア:0)
Re: (スコア:0)
.NET 3.5の時代のWPFは、内部でメモリ不足やスタックオーバー起こすとエラーや例外の出力すらなく表示しないので、Pathを手書きしてメモリ使用量を調整する必要があったけどな、、、
Re: (スコア:0)
Blendなんか誰が使ってんのよ
Re: (スコア:0)
Creature HouseやMetacreationsのころのExpressionをください。
Re: (スコア:0)
WPFデザイナとかあるよね？
ちょっと複雑なことしようと思うと破綻しそうになるけど、ユーザーコントロールに分割するのが正しいかもしれない。
面倒だから前提知識調べてXAML直接書いてるけど。
Re: (スコア:0)
そこで補完ライブラリが出るのがJava。
出ないのが.net
そんな文化。
Re: (スコア:0)
Javaの場合、補完ライブラリがあって、ようやくWPFとかWinFormの廉価版になるかどうかって程度の利便性しかないからな、、、
.NETの場合は、フレームワークそのものには手を入れたくなるほど変なところがないので、ユーザーコントロールとかのライブラリだけですんでしまう。
Re: (スコア:0)
Run anywhereを標榜してるのと、とりあえずWindowsで動けばいいのとの違いはあるとはいえ
JavaのUI周りはグダグダだったね
Re: (スコア:0)
WinForm vs WPF vs UWP(or Uno Platform) vs MAUI
Re: (スコア:0)
WinUI
Re: (スコア:0)
.NET 5ですらまだ使ったことないのにもう6かよ・・・
＃主にVS2017、ケースに応じて2012/2015を使ってる
Re: (スコア:0)
あまり古い開発環境を使うのはそれのランタイムのサポート(セキュリティフィックスを含む)がいつ終了になるかと考えるとすこし怖くありませんか？
Re: (スコア:0)
中間言語ではなく機械語にコンパイルするので問題ありませんとか？
Re: (スコア:0)
.NET Core系はLTSでもサポート期間が短すぎるからあっというまに終了する。
どんどん乗り換えなきゃいけない自転車操業をやる羽目になるのが確定するから、そっちの方が恐ろしい。
Re: (スコア:0)
.NETは他のプラットフォームに比べると、実行環境やライブラリ/フレームワークのバージョンやを上げたときに
破壊的変更で手を入れないといけなくなったり、実際に問題が起きたりする可能性は比較的穏やかな方。
単体テストとE2Eテストを完備して自転車から降りず段差で躓かないよう走り続けられるように整備した方が良い。
Re: (スコア:0)
これが笑っちゃうことに、
VS2015のサポートは一応 2025/10/14。
一方 .NET 6のサポートは LTSで3年なので、 2024年11月。
それならせめてRoslyn積んでるのにはビルドぐらいはできる様にしておいて欲しかったよなぁ。
特に今回だけは初のLTSで、.NET Frameworkのバージョン番号より超えて、
わざわざWinFormsまで移植して移行を促す下地もそろったんだから
商売的な観点で普及第一って意味で今回だけは2017/2019くらいはビルド可能ぐらいにしてくれてたら嬉しかったなぁ。
デバッグ機能とか新たな便利な補助機能は当然新しい環境だけでいいんだけど。
VSCode使えってことなのかな。
（自分は2022使えるしVSCodeでもまぁべつにいいので個人的にはこまらないが、
仕事場で使えないのがしんどいのよね。
当然サポートされてないから.NET Coreが選択肢に挙げにくくなるし。）
Re: (スコア:0)
.NET 5は非LTSだから実戦投入は見送った。.NET Core 3.1から.NET 6に上げる予定。なお、Formsアプリではない。
Re: (スコア:0)
適した方をつかえばいいとおもうよ。
Re: (スコア:0)
環境をきちんと縛れば、WPFより軽くていいと思う。(自分で書いて自分で使う、アマチュアの感想です
Re: (スコア:0)
ようし、パパPowerShell/WinFormでばりばり書いちゃうぞー。
と思ったらPerl/Tkで事足りる案件だった。残念。
appsdkとか (スコア:0)
Backwards compatible Down to Windows 10 1809と謳ってるけど元々reunionはwin10と10Xの共通化でwin11はMSの都合で勝手に分離したんだよね。
ほんとにwin10 H21H2がwin11 H21H2になっただけで内部バージョンも10のままだしフレームワークとツールキットくらいそりゃ同じもん動くだろうよと思う。
これからはwin sdkとapp sdkの二刀流になるけどいつものように飽きてすぐに止められると困るんで頑張って続けてほしい。