パスワードを忘れた? アカウント作成
15479057 story
プログラミング

Visual Studio 2022が正式にリリース 53

ストーリー by nagazou
リリース 部門より
マイクロソフトは8日、統合開発環境「Visual Studio」の最新版「Visual Studio 2022」を正式にリリースした。Visual Studio 2022は、シリーズ初の64ビットネイティブなソフトウェアとしてリリースされ、これにより大容量メモリへの対応と高速化が実現されている(Visual Studio BlogPublickeyCNETASCII.jp)。

発表イベントに登壇したMSプログラムマネジメント CVPのアマンダ・シルバー氏は、Visual Studio 2022は大規模システムの開発においてもパフォーマンスを発揮するとしている。また実行中のアプリケーションに対して迅速にコードを反映できる「ホットリロード」機能も強化された。Visual Studio 2022では、ほぼすべてのアプリでホットリロードが可能になったとしている。また同日に発表となったNET 6にも対応している。
  • ってどうなったのかと思ったら,きちんと開発続いていたんですね。
    2016年リリース当時はGUIアプリが作れずがっかりした覚えがあるのですが。
    最近全く弄ってなかったのでインストールしてみようかしら?

    https://visualstudio.microsoft.com/ja/vs/mac/ [microsoft.com]
    ここに返信
  • by Anonymous Coward on 2021年11月10日 14時41分 (#4149323)

    入れてみました。
    .NET Core 5 で作成した小さいプロジェクトを開いてみましたが、下位プロセス含めると
     2019: 1.5GB
     2022: 2.0GB
    ぐらいで、やはりメモリ使用量が増えています。
    特に64bit化した devenv は1.5倍ぐらいに増えていますね。
    Chrome で調べ物しながら開発するなら、メモリは最低 8GB、推奨 16GB って感じですか。

    ここに返信
    • by Anonymous Coward

      デバッグ実行したときのことを考えると8GBはさすがに…

      # あとReSharperも結構リソース奪っていくので最近はRiderの方が軽くて良い

      • by Anonymous Coward

        5 クラスぐらいの小さいコンソールツールのプロジェクトでこれなので、もっと大きいプロジェクト、GUI 込みのプロジェクトなんかは開くだけでもカツカツですね。
        そこにデバッグ実行でアプリ自体のメモリ使用、デバッガなんかも考えると実質最低 16GB になるか……。
        ソース解析なんかでかなりCPUも喰うし、開発マシンは順当にスペック上げていかないと開発効率が落ちそう。

      • by Anonymous Coward

        当方メモリ16GBでページングファイルなし & RamDisk使ってる環境にて。
        試しに ASP.Net Core MVC の簡単なページ作ろうとしたらデバッグ中にメモリ不足警告が出て、ウソだろと思いながらRamDiskの容量削る羽目に遭った。タスクマネージャー見たら1プロジェクトで4GBとか普通に喰ってるし、16GBは最低ラインだと思う。

        小規模でオーソドックスな開発なら2017を使うのが穏当かも。1プロジェクト数百MBで済むので5つくらい開きっぱなしで平行開発しても問題が出ず仕事しやすかった。

        2015 は C# の文法が古いのでお勧めしかねる。

        • by Anonymous Coward

          もしかしてソリューションの意味で「プロジェクト」という単語を使ってる?
          私は、Visual Studio 2019 で、20個ぐらいのプロジェクトを含むソリューションを
          開いていますが、普通に数百MB程度ですよ。

    • by Anonymous Coward

      VSのGitを使ってないなら(他のGitクライアント使ってるなら)、統合Gitをオフにするだけで結構違うね。

      どっちにもある機能だからメモリ使用量増加って話にはあんまり関係ないと思うけど。
      一応2022で機能強化してるみたいだし、その分分析にCPUもってかれてるかもしれないし、使ってないならオフにしてみるのも手かも。

  • by Anonymous Coward on 2021年11月10日 14時49分 (#4149329)

    許してください、まだまだ案件でWindows Formが多いんです…(過去アプリのUIそのままで機能追加・改修しろとか)

    ここに返信
    • by Anonymous Coward

      せめてWPF Canvasにアンカー相当があれば、段階的にというかいったんガラだけ移行して
      浸透させていくとかもできたかもしれないけど、

      (MVVMとかは置いといて)WPFでサクッとツール作れず、
      デザイン移植しづらくて、アニメーションとか別に求めてないし、結果触れてる人も増えてこないので
      選択肢として出しにくいんだよな。

      OSSとか世界向けだと見栄えも綺麗にしたくもなるけど、即日欲しいツールとか作るために
      Gridレイアウトとか調整してると時間がもったいなくなっちゃったりも。
      (変に凝るための)選択肢が少ないというのがむしろWinFormsのメリットになってしまっている気がする。

      # それにしてもVS2019が.NET6サポートしないとは思わなかった。

      • by Anonymous Coward

        「MVVMとか別にして」ならば、それは慣れの問題なだけです。

        • by Anonymous Coward

          新規ならそうなんだけど、既存のものを持っていくときめんどくさいのは画面なので。

      • by Anonymous Coward

        WPFのレイアウタは、なにも考えなくても適当に配置して動くのが良いんでは?
        GridやCanvasなんぞ使わず、作るだけなら StackPanelだけでやればよろしい。

        • by Anonymous Coward

          StackPanelはマージン切っていくのが大変。
          WinFormsもStackPanelだったやつならいいけど。

          Canvasがある程度適当に配置して動くが、マージン固定ができない。

          一応Gridで分割せずに1セルでやるのが一番近いんだが、
          それならCanvasにマージン固定する機能つけてくれればいいのにと思う。
          うーん、Gridで 1セルでとりあえず導入してしまうかなぁ。

          • by Anonymous Coward

            マージンはスタイルで一括指定してイレギュラーなのは個別指定すればデザイナでチマチマ配置するよりもずっと楽でしょ

            • by Anonymous Coward

              新規ならそれでいいけどね。
              いや、それでもWindowがStackPanelなのはあんまり想像できないんだけど。
              縦のスタックパネルで行ごとに横のスタックパネル積むとかか?

              元コメのように、「過去アプリのUIそのままで」みたいな状況においての話なので、
              スタイル定義し始めると時間かかる(というか、そんな綺麗にスタイルで一括指定できる様になってないな)

              とにかく開発のベースをWPFとかに持っていき、そこからWPFらしい形に直していくって感じで段階移行するのが狙いなので。
              習熟したメンバーが移行するわけではない。

              それにWPFのスタイル…というよりはリソース定義が最初がめんどくさいしなぁ。
              リソースをもうちょい簡潔に描かせてくれりゃいいんだけど。

              • by Anonymous Coward

                StackPanelは一番多用するだろ
                https://qiita.com/Kosen-amai/i... [qiita.com]

              • by Anonymous Coward

                なので リソースやらスタイルやら考えずに、StackPanelで並べればOKって話だよ。
                StackPanelの一番シンプルな(何も面倒なことせず部品並べるだけ)って構成にすれば、いわゆる箇条書き状態になる。
                ゲーム画面とか、凝った物はもちろん無理だが、世の中の入力画面やら結果画面とかは、だいたいStackPanelだけでいい。

                既存画面と同じレイアウトでという話ならCanvasで座標固定で配置すればいい。
                スタイルやリソース定義は楽をするために使うものであって、書かなきゃ出来ないようなものは何一つないぞ。

              • by Anonymous Coward

                特にStackPanelが一番っていう説得力はない。
                一番でもないし、Gridで覆われてる(WindowがStackPanelではない)、StackPanelつかったがために余白作ってる。

                StackPanelがうまく使えば便利なものだというのは知っているが、リンク先の最初のウィンドウは今ひとつ。
                二つ目は部分的なので効果的と言えなくもないけど。
                StackPanelは横に広がってしまうからね。最初のVisualStudioのプロジェクト作成ダイアログとかと比べればいい。

                「過去アプリのUIそのままで」っていう元々の話にも合わない。

                これは昔見か

              • by Anonymous Coward

                言ってることはわかる。ありがとう。
                でもその辺はもう通ったの。

                > スタイルやリソース定義は楽をするために使うものであって
                はわかるんだけど、その前でスタイルについて愚痴ってたのは、そのもう一個前で
                >>マージンはスタイルで一括指定して
                って言われたから。
                さらに、StackPanelを推されたけど、StackPanel使ってしまうとスタイルでマージンつけていくのが結構めんどくさい(左上位置もマージン入力したりしないといかんし、自由に動かないからね)様に思うっていうのが発端。

                > Canvasで座標固定で配置すればいい。
                Canvasだと左上は固定できる。Anchor相当があればこれでいいと思った。でもないという話をしていた。
                「それならCanvasにマージン固定する機能つけてくれればいいのにと思う。うーん、Gridで 1セルでとりあえず導入してしまうかなぁ。」

                Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。

              • by Anonymous Coward

                GridはStackPanelを置くエリアを分けるために使うもの。
                Gridに通常のコントロール直置きはあまりやらない。

                その動画のやつはWPFで作れば楽だったろうに。無駄な労力使ってんなー。

              • by Anonymous Coward

                > Canvasで右下のマージンを簡単に固定できるならば教えて欲しい。

                えっと……。
                もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか?

                # Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。

              • by Anonymous Coward

                > えっと……。
                > もしかして、Canvas.Right / Canvas.Bottomをご存じないのでしょうか?

                えっと……。
                もしかしてCanvas.LeftとCanvas.Rightを同時に使えないのをご存知ないか、
                Gridセルなどでの右下マージン固定とかWinnFormsのAnchorの機能をご存知ないのでしょうか。

                > # Canvasなんて滅多に使うものじゃないと思う。StackPanelとかで詰め直した方が、後々楽。

                ・・・さすがにもう最初から読んでとしか言えん。

          • by Anonymous Coward
            Anchor{Top|Bottom|Left|Right}プロパティを持ったPanelのサブクラスか添付プロパティか何かを自作してWindowのResizedイベントあたり拾って自分でMarginを設定し直す、というのが正攻法かなぁ・・・?
            • by Anonymous Coward

              そこまでするコストに見合ったメリットがないんだよなぁ

            • by Anonymous Coward

              そうねぇ、ただ別の回答もついているようにコストがね。

              一度作ってしまえばいいのだけど、
              (Gridを真似てMerginの固定で済ますにせよ)デザイナ周りとかどうなるのか見てみないとなんとも言えない。
              探せばありそうだし、どこで妥協するか次第ではあるけど。

              そんなこんなも含めて、CanvasはなんでMergin固定できるようにしてくれなかったのかと。

      • by Anonymous Coward

        MVVMだとバインディング先はドコ?を探すのにgrepに行き着く。
        CでWindow作ってた頃に退化してる💢

        整合性とか排他とか参照関係を厳密に管理するなら使わんほうがいいかも?

        #見た目だけ全力注がれてデータ整合性とか同期とか排他とか破綻してるやつ再設計ちゅー

    • by Anonymous Coward
      WPFとかWinUIとか先進的なようで不便
      というかフレームワークとして低階層すぎるのか

      もうそろそろxamlを人間に書かせようとするのやめて欲しいですね
      あんな前提知識必須な構造物は人間が書くものじゃないと思うんですが
      • by Anonymous Coward

        いにしえの「ほーむぺーじ作成ツール」と大差ないカオスになるのは目に見えてるな…

      • by Anonymous Coward
        MS「そもそもXAMLを人間が書くわけないだろ。てゆうか Expression Blendで書けるようにしたのに何で誰も使ってないんだよ」
        • by Anonymous Coward

          .NET 3.5の時代のWPFは、内部でメモリ不足やスタックオーバー起こすとエラーや例外の出力すらなく表示しないので、Pathを手書きしてメモリ使用量を調整する必要があったけどな、、、

        • by Anonymous Coward

          Blendなんか誰が使ってんのよ

        • by Anonymous Coward

          Creature HouseやMetacreationsのころのExpressionをください。

      • by Anonymous Coward

        WPFデザイナとかあるよね?

        ちょっと複雑なことしようと思うと破綻しそうになるけど、ユーザーコントロールに分割するのが正しいかもしれない。
        面倒だから前提知識調べてXAML直接書いてるけど。

      • by Anonymous Coward

        そこで補完ライブラリが出るのがJava。
        出ないのが.net
        そんな文化。

        • by Anonymous Coward

          Javaの場合、補完ライブラリがあって、ようやくWPFとかWinFormの廉価版になるかどうかって程度の利便性しかないからな、、、
          .NETの場合は、フレームワークそのものには手を入れたくなるほど変なところがないので、ユーザーコントロールとかのライブラリだけですんでしまう。

          • by Anonymous Coward

            Run anywhereを標榜してるのと、とりあえずWindowsで動けばいいのとの違いはあるとはいえ
            JavaのUI周りはグダグダだったね

    • by Anonymous Coward

      WinForm vs WPF vs UWP(or Uno Platform) vs MAUI

    • by Anonymous Coward

      .NET 5ですらまだ使ったことないのにもう6かよ・・・

      #主にVS2017、ケースに応じて2012/2015を使ってる

      • by Anonymous Coward

        あまり古い開発環境を使うのはそれのランタイムのサポート(セキュリティフィックスを含む)がいつ終了になるかと考えるとすこし怖くありませんか?

        • by Anonymous Coward

          中間言語ではなく機械語にコンパイルするので問題ありませんとか?

        • by Anonymous Coward

          .NET Core系はLTSでもサポート期間が短すぎるからあっというまに終了する。
          どんどん乗り換えなきゃいけない自転車操業をやる羽目になるのが確定するから、そっちの方が恐ろしい。

          • by Anonymous Coward

            .NETは他のプラットフォームに比べると、実行環境やライブラリ/フレームワークのバージョンやを上げたときに
            破壊的変更で手を入れないといけなくなったり、実際に問題が起きたりする可能性は比較的穏やかな方。
            単体テストとE2Eテストを完備して自転車から降りず段差で躓かないよう走り続けられるように整備した方が良い。

        • by Anonymous Coward

          これが笑っちゃうことに、
          VS2015のサポートは一応 2025/10/14。

          一方 .NET 6のサポートは LTSで3年なので、 2024年11月。

          それならせめてRoslyn積んでるのにはビルドぐらいはできる様にしておいて欲しかったよなぁ。
          特に今回だけは初のLTSで、.NET Frameworkのバージョン番号より超えて、
          わざわざWinFormsまで移植して移行を促す下地もそろったんだから
          商売的な観点で普及第一って意味で今回だけは2017/2019くらいはビルド可能ぐらいにしてくれてたら嬉しかったなぁ。

          デバッグ機能とか新たな便利な補助機能は当然新しい環境だけでいいんだけど。

          VSCode使えってことなのかな。

          (自分は2022使えるしVSCodeでもまぁべつにいいので個人的にはこまらないが、
          仕事場で使えないのがしんどいのよね。
          当然サポートされてないから.NET Coreが選択肢に挙げにくくなるし。)

      • by Anonymous Coward

        .NET 5は非LTSだから実戦投入は見送った。.NET Core 3.1から.NET 6に上げる予定。なお、Formsアプリではない。

    • by Anonymous Coward

      適した方をつかえばいいとおもうよ。

    • by Anonymous Coward

      環境をきちんと縛れば、WPFより軽くていいと思う。(自分で書いて自分で使う、アマチュアの感想です

    • by Anonymous Coward

      ようし、パパPowerShell/WinFormでばりばり書いちゃうぞー。
      と思ったらPerl/Tkで事足りる案件だった。残念。

  • by Anonymous Coward on 2021年11月10日 19時36分 (#4149561)

    Backwards compatible Down to Windows 10 1809と謳ってるけど元々reunionはwin10と10Xの共通化でwin11はMSの都合で勝手に分離したんだよね。
    ほんとにwin10 H21H2がwin11 H21H2になっただけで内部バージョンも10のままだしフレームワークとツールキットくらいそりゃ同じもん動くだろうよと思う。

    これからはwin sdkとapp sdkの二刀流になるけどいつものように飽きてすぐに止められると困るんで頑張って続けてほしい。

    ここに返信
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...