Windows TerminalにPowerShell Coreを追加する

issueも出ているので、賞味期限は短いブログになるはずです(笑)。

Windows Terminalの初期プレビューが公開されました。Windows 10 1903を入れておかないといけませんが、ビルド環境がなくてもストアからインストールできます。

www.microsoft.com

ANK以外の環境だと日本語周りとかうまく動かない点も多いようですが、ぼちぼち使っていきます。インストールすると、Ubuntu(WSL1), cmd.exe, Windows PowerShellの三つの環境がプリインストールされています。PowerShell Coreも入れたいなぁ、と思ったので、Settingsを起動、jsonファイルを編集します。

(追記)
どうもPowerShell Core 6.2.xを入れていれば最初から認識されるようです。私は更新さぼってて6.1.1のままだったのでこの技が必要になりました。Terminal入れるまえに更新するといいようです。 (/追記)

余談ですが、settingsで単なるjsonが開くとは知らなかった＆jsonを関連付けしていなかったので、結構困りました。VS Codeでもなんでも関連付けておいてください。

profilesセクションの配下に以下の設定をコピペします。フォントサイズはちょっと大きめに変えました。

        {
            "acrylicOpacity" : 0.5,
            "background" : "#012456",
            "closeOnExit" : true,
            "colorScheme" : "Campbell",
            "commandline" : "pwsh.exe",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 16,
            "guid" : "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
            "historySize" : 9001,
            "icon" : "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png",
            "name" : "PowerShell Core",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : "%USERPROFILE%",
            "useAcrylic" : false
        },

迷ったのがguidとiconでこれどこからとってくるんだろうと思ったら、GitHubの別のissueに載ってました。Windows 10に登録されているiconのms-appxのURLそのままでいいようです。

これでPowerShell Coreも起動します。Settingsに登録すると、アイコンは即時反映されますが、起動はしないようなので、Terminalsを再起動してから使ってください。

github.com

もうちょっといっぱいプロファイルにいれてよ、というissueは立っています。あと、PowerShell Coreをscoopで入れている人はこれやっても認識しないというissueもたっています(scoop使ってないので、確認していません)。

github.com

見てわかる通り、guidの値はこのissueからもらってきました。

Scott Hanselman氏のブログもご参考に

www.hanselman.com

Visual Studioでのビルド時にCOMコンポーネントでエラーが出る場合の対処

Visual Studio 2017(15.9.13)で発生しています。ある程度大いC++プロジェクトをビルドすると、突然こんなエラーが出るようになりました。

1>------ ビルド開始: プロジェクト: , 構成: Debug Win32 ------
1>エラー HRESULT E_FAIL が COM コンポーネントの呼び出しから返されました。
1>エラー:エラー HRESULT E_FAIL が COM コンポーネントの呼び出しから返されました。

一度このエラーが出ると、OS再起動、ソリューションクリーンアップとフルビルドしてもダメでした。Developer Communityにも報告されているので、そこそこ頻繁に出るようです。

developercommunity.visualstudio.com

Visual Studio 2019で同じソリューション開いても(toolsetやSDKはVS2017のままアップグレードしない)ビルドはできます。

最初についていた回避方法はこんなものでした。

1. Developer Command Prompt for VS2017を管理者として実行する。
2. "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PublicAssemblies"に移動する
3. gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll と実行する

自分の場合、上記の方法では直らなくて困っていたんですが、先日あらたな回避方法が追加されて、これで直りました。

1. ソリューションファイルのあるフォルダーにある.vsフォルダー(隠しフォルダーです)を削除
2. bin/objフォルダーを削除

やっぱりVSが変な挙動する場合、.vsフォルダーを削除するというのが鉄板の回避方法のようです。拡張機能なら拡張機能のキャッシュフォルダーを削除する。

Azure DevOps 2019/6/10の更新

Azure DevOps Sprint 153リリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回はスケジュールもcronの形式で書けるようになったのが大きいですね。UIでのビルドスケジュールは廃止の方向だそうなので、今から慣れておくといいと思います。

Windowsでやってきた人にはcronの書式ってつらいんですよね。順番が逆なので、しばしば間違えます。Unixのcronは次いつ動くのかも出てこないので…。ただ、ワンライナーで定期的に動くスケジュールを書けるというのは便利だと思います。

作業項目のテキストファイルのオンデマンドプレビューや、添付ファイルを含めたコピーは助かります。

前回のSprint 152でhosted pipelineのイメージ更新しなかったんですね。Pythonのバグによりバージョンダウンさせたと書いているけど、何が問題だったんだろう。

ではまた三週間後。

Translate to Japanese to Azure DevOps release note ...

de:code 2019 DT51でいただいたAzure DevOpsの質問

はじめに

www.microsoft.com

de:code 2019に参加いただいた方、今回のお話を振っていただいた日本マイクロソフトの皆様ありがとうございました。セッション中にsli.doというサービスも使ってQ&Aをうけていたのですが、こちらでも補足します。

https://www.microsoft.com/ja-jp/events/decode/2019/default.aspx

TFS2017のNuGetパッケージ管理機能を使っているのですが、120プロジェクトを含むソリューションに対して復元と更新を実行すると2時間以上かかります。TFS2017での対策と、バージョンアップによる改善が期待できるか教えてください。

docs.microsoft.com

パッケージの全バージョンを常時公開していると、クライアントからのクエリー取得に時間がかかります。そういう場合、このdelete and recover packageのように自動的に古いバージョンのパッケージを削除するようにしてください。

もちろん、保守の都合上、古いのがないと困る、という場合は新しいバージョンには新しいフィードを作って、そちらから取得するようにしたほうがいいんじゃないかなと思います。

TFS 2018からだと思っていたのですが、TFS2017でもあるようですね。

Azure DevOpsを他の新規テナントに紐付けて作るにはどうしたらいいでしょうか？

このお話は、組織アカウント(Azure AD)ベースで作るという前提です。Azure ADに紐づけるにはいくつかのパターンがあります。

1. 自社組織のAzure ADに作る
2. お客さんが管理しているAzure ADにつくる
3. 新規にAzure ADを作ってAzure B2Bで入る

1もしくは2を選ぶ場合、どちらかの組織がAzure ADゲストログオンを認める必要があります。これは組織ポリシーによるので、どちらがいいとは言えませんが、プロジェクト終了時にAzure DevOpsごと納品する前提であれば、1は選べません。

また、Azure ADのゲストユーザーライセンスには上限があるので、そこを超えないかどうかも確認が必要です。

3のAzure B2Bでのログインはおおむねいいのですが、二つほど欠点があります。

• Teamsが使えない(現在の仕様だそうですので、Slack使ってください)
• Azure AD P1/P2を使う場合、本体テナントとは別にP1/P2の料金がかかる

後者は考えてみればその通りで、P1/P2ラインセンスはテナント単位でかかります。最初に合意しておけばいいのですが、そうじゃない場合後出しで結構お金のかかるP1/P2の話し出すと怒られるので、気を付けましょう。

Azure DevOpsをお客さんのところで使う場合、ある程度以上のAzure ADの知識が前提になってしまうので、注意してください。

運用段階に入ったプロジェクトにAzure DevOpsを導入することで得られる恩恵を教えてください。

私個人の考えですが、運用段階に入ってから使う場合、運用で困っているポイントだけで使うのがいいと思います。CI/CDでmacOSが必要だけど、macOSのCI探してるとか、リリースが温かみのある手作業だけど、開発環境くらいは自動化したいとか。

ただし、Azure DevOpsに含まれるサービスを単独で使う場合、競合サービスと比べると見劣りするところは確かにありますので、無理に使わなくてもいいとは思います。ライセンスがあるから、まずやってみるとかでいいんじゃないでしょうか。

TFSの書籍などおすすめの資料はありますか？

会場では英語でもいいとのことだったので、ちょうど出ています。

www.visualstudiogeeks.com

www.packtpub.com

www.oreilly.com

自分も書こうと思いつつ、あるていどは書いているのですが…ペース早いですね。

Githubとどう使い分けます？

GitHub便利ですね。GitHubでホストされているOSSにコミット(PR, issue)するならGitHub使うしかないと思います。GitHub用に公開されているAzure BoardsとAzure Pipelinesのアプリがありますね。

github.com

github.com

GitHubに足りないところをちょっと補う感じです。Boardsとissue/Projectsはどうするのよ？というところですが、大規模開発でチームが複数あってひとつのおおきなプロダクトを作る場合、GitHubのリポジトリをあっち見てこっち見てというのは正直つらい。

APIでOrganization全体のProjectみるようなダッシュボード作ればいいのかもしれませんけど、Azure Boardsだとそういうのができます。ステークホルダーも横櫛で通してみやすくなるのと、チーム単位でバックログ見やすくできるので、そういうところはたぶんメリットだと思います。

Azure Pipline を使用して Azure リソースをデプロイする方法についておすすめはありますか？

最初はARMテンプレート、WebAppsでいいなら普通にタスクでもいいと思います。すごくいい記事がいっぱいあるので、おすすめです。

tech.guitarrapc.com

tech.guitarrapc.com

Azure DevOpsのサポートを日本語でうけるにはどうしたらいいでしょうか？

Azure DevOpsからのサポートは普通にMSのサポート対象です。Webから簡単に入力できるサポートは例えば、Azure DevOpsのサーバーの移行(USから東アジア)とか、手違いでだれも入れなくなったとか、そういったことであれば無料で依頼できます。

英語のみですが、機械翻訳でもちゃんと伝わります。

VSTSから、メッセンジャーなくなったので、Slackに移行したけど、いまさらながらTeamsに変えるとなんかメリットありますか?

Slackの有料プラン使っていれば安くなる、でしょうか。ほかの人からありましたが、Slackはあくまでもフロー型、Teamsはストックもできる(バックエンドのSharePointやOneDriveにファイル保存など)というところが最大の違いです。

Slack的にTeams使おうとすると、たぶん切れると思います。会社でもそういう話非常によく聞くんですが、Slackでやってること以外の使い方をしようとしないからなんですね。

Continuous Monitoring していて、パフォーマンス改善のためにリリースしたいが、すでにそのパフォーマンスアラート閾値に引っかかってリリースができない場合って起きませんか？回避する方法はありますでしょうか？

会場では一時的にアラートはずす、かなぁという回答をしてしまったんですが、例えばhotfixリリースのように緊急で回したいような場合は別のリリースパイプラインを作るという方法があります。

もちろんなんでもかんでもリリースできると困るので、branch filterを使って特定のブランチ配下にコミットされた(PRされた)ものだけリリースパイプライン実行するという方法がおすすめです。

負荷テストの未来はどうなっていますか？

2020/3にリタイアすることが決まったので、チームのブログでもほかのサービスを紹介しています。

devblogs.microsoft.com

Azure Pipeline から Azure リソース作成の際、Azure の認証はどうなるでしょうか。 Azure AD が同じではないといけないか、サービスプリンシパルを作成して ID などを別途使用できるかなど

サービスプリンシパルを作ってください、というのが回答です。デモとかではたいていAzureとAzure DevOpsの管理者権限を持っているユーザーでやってしまうのですが、本番ではそうもいかないですしね。

Slackを使っていてAzure PipelinesのService Hooksを登録するのに、パイプライン毎に登録するのがつらいのですが、まとめとか、新しいものが追加されたときに自動でついかされるようにするほうほうはありますか？

ごめんなさい。これは私も不便だと思っています。ちなみにTeamsも同じで、ユーザー単位でそれぞれのビルド定義を追加するので、結構面倒です。feedbackコマンドがあるので、そちらでフィードバックしていただければかわるかもしれません。

REST APIでそういうの作るのとかもいいんですかね…。