時期が近いイベントだったので、両方まとめて公開します。
プロファイラーは久しぶりだったので、サンプル作成とか結構時間かかってしまいました。これで一段落なので、また自分のイベントの準備します…
時期が近いイベントだったので、両方まとめて公開します。
プロファイラーは久しぶりだったので、サンプル作成とか結構時間かかってしまいました。これで一段落なので、また自分のイベントの準備します…
Azure DevOps Sprint 237リリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。
今回はGHAzDoの改良とGitHubとの連携強化、Pipelinesの新しい権限追加がありました。
シークレットスキャンの強化が大きいですね。パートナートークンが増えました。ドキュメントに載っていますが、GitHub側とは少し違うのでご注意を。
だいぶ同じものが検出できるようになってきました。
他にもシークレットではないけど、OpenSSHとかRSA秘密鍵、各種データベースへの接続文字列(ベタ書きよくみますね)などの検出ができるようになったのも便利です。
長い長いプレビューを経て、ようやく新しいBoard Hubが既定になるそうです。こちらにしないと使えない機能がいっぱいあるので、今まであえて移行していなかった人たちは面食らうかもしれませんが、慣れましょう。この翻訳が出る頃にはオプトインしていなかった人たちへの展開が始まっている頃かなと思います。
GitHubとAzure Boardsを連携させてチケットをAB# でリンクさせている場合、pull requestへのアクセスが簡単になるのは連携させている人には嬉しいかなと思います。巨大なGitHub organizationと連携させている場合と合わせて連絡すれば使えるようになるそうなので、いつものDanさんに英語でメールしてみてください。
最後はちょっとわかりづらいかもしれませんが、Azure Pipelinesでビルドをキューに入れるとき、実行時にパラメータを指定できるのですが、今まで誰でも指定できていました。これでは例えば悪意ある人が任意の値で上書きできてしまうということで、上書きできる人の権限を明示的に指定できるようにした、という話です。
上書きできない人はあらかじめ指定されたものからしか選択できない(object型の場合)というのは便利ですね。例にもありますが、Azure VMのSKUとか指定可能にしていると、無駄に高いインスタンス指定されると困るというわけです。もちろんAzure Policyで制御してしまうという方法もあります。
Node 16がEOLになったので、依存しているタスクはビルド時警告が出るようです。タスクを提供している人は早めの移行を、利用者は更新するか、更新がなさそうであれば使用をやめるかということになります。
ではまた三週間後。
先日Visual Studio 2022 17.0 Preview 3が公開されました。新しいプレビューが公開されると、プレビュー機能のダイアログ(今はタブになりましたが)を一通り見るのですが、気になる項目が増えていました。
もちろん有効にします(非推奨とか、古い互換性のための機能でない限り原則有効にします😉)。
Visual Studioのソリューションを選択して保存時にslnxが増えています。
読み込むときにも選択肢として増えています。何が違うのでしょう。
Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio Version 17 VisualStudioVersion = 17.10.34804.81 MinimumVisualStudioVersion = 10.0.40219.1 Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "BlazorApp1", "BlazorApp1\BlazorApp1\BlazorApp1.csproj", "{BFD7AF15-7028-43D2-AC5D-1AD1B7D7C4C7}" EndProject Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "BlazorApp1.Client", "BlazorApp1\BlazorApp1.Client\BlazorApp1.Client.csproj", "{82BD4B72-63B3-4C4F-992D-09FF5586C07D}" EndProject Global GlobalSection(ExtensibilityGlobals) = postSolution SolutionGuid = {B7807233-0A06-4B9F-B06C-4A4C48D34E24} EndGlobalSection GlobalSection(ProjectConfigurationPlatforms) = postSolution {82BD4B72-63B3-4C4F-992D-09FF5586C07D}.Debug|Any CPU.ActiveCfg = Debug|Any CPU {82BD4B72-63B3-4C4F-992D-09FF5586C07D}.Debug|Any CPU.Build.0 = Debug|Any CPU {82BD4B72-63B3-4C4F-992D-09FF5586C07D}.Release|Any CPU.ActiveCfg = Release|Any CPU {82BD4B72-63B3-4C4F-992D-09FF5586C07D}.Release|Any CPU.Build.0 = Release|Any CPU {BFD7AF15-7028-43D2-AC5D-1AD1B7D7C4C7}.Debug|Any CPU.ActiveCfg = Debug|Any CPU {BFD7AF15-7028-43D2-AC5D-1AD1B7D7C4C7}.Debug|Any CPU.Build.0 = Debug|Any CPU {BFD7AF15-7028-43D2-AC5D-1AD1B7D7C4C7}.Release|Any CPU.ActiveCfg = Release|Any CPU {BFD7AF15-7028-43D2-AC5D-1AD1B7D7C4C7}.Release|Any CPU.Build.0 = Release|Any CPU EndGlobalSection GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU Release|Any CPU = Release|Any CPU EndGlobalSection GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE EndGlobalSection EndGlobal
Blazorのプロジェクトをテンプレートで作っただけのおなじみの(?)sln構成です。これをslnxにするとこうなります。
<Solution> <Project Path="BlazorApp1\BlazorApp1.Client\BlazorApp1.Client.csproj" Type="Classic C#" /> <Project Path="BlazorApp1\BlazorApp1\BlazorApp1.csproj" Type="Classic C#" /> </Solution>
簡単!.NETのプロジェクトがSDKスタイルになった時のようです。前々から「projectのGUIDや構成定義は必要なのか」とか思っていたので、すべてcsprojに行ってくれたのは助かります。ただ、これまだ始まったばかりのようで、関連付けも行われていません。
そして、当然ですが、dotnetコマンドでもサポートされていないようでビルドができません。
devenvコマンドならビルドができます(もちろんPreview版のVisual StudioのDeveloper Command Promptを起動します)。
プレビューを使わないといけないからCIで使えないし、このslnのファイル構成を当てにしている拡張機能やツールもたくさんあるでしょうから、どのくらいでデフォルト有効になるのかちょっとわからないですが、XMLになってパースしやすくなるのと、サイズが劇的に小さくなるのは非常にうれしいですね。Visual Studio 2022 17.10正式版ではサポートになるのかな?楽しみです。
先日、Windows Server Summit 2024が開催されました。録画はもう公開されています。
Windows Server 2019, 2022はおとなしめ(?)の更新だったからか、2025はかなりアグレッシブに見えます。多くはIgniteでも発表されていましたが、個人的な注目ポイント。
今年末にかけて正式リリースされるようです。Azure以外でもHotPatchが正式に提供される最初のバージョンになりそう。Arc-Enabledで使えるのかな。HotPatch技術そのものは古くWindows Serve 2003 SP1から使えていたはずなのですが、ようやく日の目を見るという感じですかね。
ただし、あくまでもOSコンポーネントだけで.NET Frameworkは対象外だそうです。HotpatchはXboxのサービスでも使われているそうです。
今まで機能レベル2016だったのがジャンプアップ。
…更新の順番どうするんだ?NUMAまで使うって、そこまで巨大なドメインコントローラーを使う話はちょっと自分では扱ったことないのですが、必要なケースもあるのでしょう。Defender for Identityのセンサーもそこそこ性能使いますしね。
Kerberosも強化。NTLM廃止に向けてLocal KDC やIAKerbもサポートされます。
OS更新するだけでNVMeが70%向上は素晴らしい。正式リリースまでには90%向上くらいまで上げるのだそうです。Azure Stack HCIで得たノウハウがLTSCにも導入されるということで、今後はStack HCIで磨いてLTSCで提供ということになるんでしょうかね。
今まで1:1しかGPU割り当てできなかったのが1:nにできるのだそうです。これは高密度のオンプレミスVDIがはかどりますね。VMwareなどではできていたので、競合に追いつく形ですね。
ちょいちょい話は聞くんですよね。英語以外のベースイメージほしい。コンテナーで使いたい人って大体日本語依存の処理(C / C++)していて、英語のベースイメージでは動かないーという話を聞くのです。
ベースイメージの削減もはかどっているそうです。
QUICをSMBで使うのだそうです。VPNが不要になる、443/tcpが使える、常時暗号化される、TLS 1.3サポートといったあたりがメリット。すべてのエディションで有効。
SMBでNTLMの認証をオフにできるオプションも提供されるのだそうです。ちょっと試してみたい。
待ってましたよ。ほかのものもいいのだけど、Windows clientで使っていてServerで使えないのは困るのです。特にWindows LTSCでもサポートしたわけですし。とはいえ、割と頻繁に更新されるApp InstallerがWindows Serverでちゃんと更新されていくのかが注目です。
組織内やプロジェクトでWinGetサーバーを立てたら構成管理が楽になりそうです。あと、Windows ServerのGitHub Action/Azure Pipelinesイメージ作成にも便利ですね。
今までWindows ServerはWi-Fiサポートしていませんでしたが、サポートするのだそうです。エッジロケーションで動く環境では必要ですしね。どのモジュールがサポートされるかはわかりませんが、NUCなどではWiFiモジュールが無駄になっていたのが使えるようになるとvPro対応のNUCを目を皿のようにして探さなくてもよくなるのかもしれません。
これはびっくりです。特にN-4サポート(Windows Server 2012 R2から2025へ移行可能)というのも。せいぜいN-2くらいだと思っていました。日本以外の世界でもそうだと思うのですが、OEMのメディアを使っている場合、キーが必要になるようで、そこで止まるようです。短い時間で更新~とか言っていたように見えますが、今自分の検証環境は5-6時間単位でかかっています。ほんとに短くなるのか試してみたい。
Arc-Enabledサーバーの場合、自動的に2025へ更新されても困るのでそういう時はコントロールする必要があるようです。PAY-AS-YOU-GOで買うSQL Server と同じ方式のようですね。一時的にオンプレミスのホストでVMを使いたいときとかホストOSに無理にDatacenterを買う必要がなくなるとかライセンスメリットがありそうです。
久しぶりに大型の更新になってリリースが楽しみです。Insiderも提供されているので、気になる人は試してみましょう。詳細は個別セッションで語られているので、そちらもご参考に。