ピン留めされたアイテム

Abstract

私は、C# (.NET 8) で YouTube / Twitch 配信のコメントビューワーをつくっています。

レポジトリ : https://github.com/usagiga/kaeru
プロジェクト(v1開発) : https://github.com/users/usagiga/projects/2

このスクラップでは、自分の復習の目的として、コメントビューワーをつくる作業を通して得た知見についてまとめます。

Topics

このスクラップでは、主に以下のようなトピックを扱います。

C# / .NET 8
- Windows Forms
- ASP.NET Core
GitHub Actions
配信プラットフォーム(YouTube Live / Twitch)

それぞれについて、Comparison や Best Practice なんかが書かれる予定です。

Disclaimer

このスクラップの内容は、usagiga 個人の推測が多分に含まれます

usagiga 4ヶ月前に更新

環境構築について

開発環境

OS

Windows 11
Ubuntu on WSL
- git や GitHub CLI の操作につかう
- ターミナル(Alacritty)やシェル(bash/fish)、パッケージマネージャーなどのエコシステムがいいかんじ
- 一連のスクラップでは Ubuntu 22.04 を使っている

ソフトウェア

Visual Studio 2022 Community
- .NET のインストール、デザイナの操作につかう
JetBrains Rider
- ソースコードの記述につかう
- Visual Studio との機能的差異は多くない
  - Roslyn Analyzer や JetBrains AI / GitHub Copilot は他のエディタ同様
  - Diagram や Local History、スペルチェックなど細かいところに手が届くのでべんり
  - Rider はデザイナに制約がある。デザイナのみ Visual Studio を推奨
    - .NET Framework は利用可
    - WPFはプレビューのみ可
    - .NET / .NET Core Desktop Application は利用不可
    - .NET MAUI / WinUI 3 (Windows App SDK) は詳細不明
- Visual Studio を使うかどうかは好みでよい
Alacritty
- WSL の操作につかう
- コマンドプロンプトでもいいけれど、設定ファイルも含めてマルチプラットフォーム対応なのがうれしい
.NET SDK / CLI
- ビルド、テスト、NuGet パッケージの管理、フォーマットにつかう

導入方法・操作方法

特筆すべきでない、いくらかの項目は省略。

Ubuntu に .NET SDK をインストール

公式の手順に従う。

要約すると、以下の操作を実行すればよい。

$ declare repo_version=$(if command -v lsb_release &> /dev/null; then lsb_release -r -s; else grep -oP '(?<=^VERSION_ID=).+' /etc/os-release | tr -d '"'; fi)
$ wget https://packages.microsoft.com/config/ubuntu/$repo_version/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
$ sudo dpkg -i packages-microsoft-prod.deb
$ rm packages-microsoft-prod.deb
$ sudo apt update
$ sudo apt install dotnet-sdk-8.0

(現在、Ubuntu のデフォルトの apt レポジトリには .NET 8系の SDK が存在しないため、Microsoft のレポジトリから取得している。)

Git / GitHub の設定

Credential Helper の設定
- GNOME Keyring は依存が少なく、べんりな機能が多数
- store はファイルベースの Credential Helper。ファイルに生文字列で保存されるけれど、設定がとにかく楽
- cache はインメモリの Credential Helper。永続化されないのがつらい
Personal Access Token (PAT) の設定
- PAT を作り慣れている人は手動でぽちぽち
- ↑がめんどうな人、GitHub CLI を使う予定の人は gh auth login するとスムーズ
- GitHub Actions を使う場合、Fine-Grained PAT では Workflows の Read / Write 権限、Classic PAT では workflow 権限を付与すること。これがないとワークフローの yml ファイルが push できない

usagiga 4ヶ月前に更新

音声合成ソフトウェア

読み上げ機能で利用する、音声合成ソフトウェアについてです。

前提 : API の選定について

音声合成ソフトウェアが備える API には以下のようなものがあります。

HTTP
- おなじみのやつ
- REST API を備えているものもある
- JSON を使う場合、 System.Text.Json や Newtonsoft.Json がべんり
- リクエスト・レスポンスの表現能力が高く、処理結果の受け取りやエラーハンドリングがしやすい
CLI インタフェース
- コマンドライン引数を指定して exe ファイルを実行するもの
- 処理結果の解釈やエラーハンドリングに難がある
- 手軽
  - System.Diagnostics の Process クラスを使うだけ
WCF、ICP
- Windows 固有の通信方法
ソケット通信
- ローレベルな通信方法

実際に試してはいないのであくまで推測ですが、多くのソフトウェアが HTTP の API を備えること、通信方式として人気がありドキュメントも多いことなどから、HTTPを使うようにすると開発がしやすいのではないかと思います。

AquesTalk 系

いわゆるゆっくりボイスのことです。

棒読みちゃん

プロプライエタリ
2024年現在も AquesTalk (旧版)がつかえる
コメントビューワの読み上げ機能のバックエンドとして利用されていることが多く、辞書や設定が充実した環境を持っているユーザーも多い(はず)
API
- CLI ( RemoteTalk.exe )、Socket、HTTP、ICP が利用できる
- C# (.NET Framework？) でのサンプルコードが付属

Softalk

プロプライエタリ
2022年ごろ、AquesTalk に関する機能が削除された
旧バージョンを持っている人はそのまま運用可能
API
- CLI から利用できる

VOICEVOX / COEIROINK

春日部つむぎ、四国めたん、ずんだもん、小夜、つくよみちゃん、リリンちゃんなどのことです。

OSS
- VOICEVOX のコアを組み込みたい、トラブルシューティングがしたいなら直にソースコードを読むのがいい
  - 各モジュールのコードを読む前に、全体構成を知りたい場合はここから
- COEIROINKv2 はプロプライエタリ
API
- HTTP での REST API がある
- Headless でよいなら、 Docker Image もある

ボイスロイド / CeVIO / VOICEPEAK / その他

結月ゆかり、さとうささら、小春立花などのことです。
対応予定がまだ先だったのであまり調べていません。

プロプライエタリ
API
- なし
- AssistantSeika を使えば、CLI や HTTP、WCF で利用できるようになる
  - VOICEVOX、COEIROINK、棒読みちゃんなどさまざまなものに対応しているので、これだけで実装してしまうのもいいかもしれない

usagiga 4ヶ月前

.NET、 C# の情報源

.NET、.NET Core、.NET Framework や、
C# のバージョンごとの差異は以下の記事が目録としてちょうどよさそうでした。

また、C# の言語仕様、.NET Framework など古くからある標準ライブラリのリファレンスとしては
未確認飛行C さんが読みやすく、充実していてよいと思います。

https://ufcpp.net/

usagiga 4ヶ月前

テストフレームワーク

ユニットテスト

MSTest
NUnit
xUnit

があるらしいです。
あまり細かく比較していないのですが、人気があって便利らしい xUnit を選びました。

比較に関しては、この記事が読みやすかったです。

E2E テスト

UWP、WinForms、WPF、Win32 API でつくられたアプリケーションの E2E テストではこれを使うことになるそうです。使うことになったら追記します。

Web アプリでのユニットテスト/E2Eテスト

Blazor や ASP.NET Core を使う予定なら、bUnit や Playwright for .NET が便利だそうです。
このあたりは使うことになったら追記します。

usagiga 4ヶ月前に更新

xUnit でのテストの書き方

チュートリアル

この記事が xUnit での単体テストの書き方のチュートリアルです。

Visual Studio ですが、GUI でのチュートリアルもあります。

お作法

公式ドキュメントを見る限り、お作法のようなものがありそうです。

ProjectName.Tests のようなプロジェクト名を使う
ProjectName.UniteTests.HogeFuga のような名前空間を使う

他のプロジェクトを見た限りでも、公式記事でのお作法を踏襲しているようでした。

リファレンス

リファレンスらしいリファレンスはありません。

一応、公式サイトに NUnit / MSTest との比較記事がべんりです。
公式の情報の中ではよくまとまっていて、リファレンス的に使うことができます。

https://xunit.net/docs/comparisons

また、 xUnit は JUnit と似た思想で作られているため、JUnitやその派生フレームワークを熟知している方は、同じような機能がないかを検索すると手っ取り早いと思います。

usagiga 4ヶ月前

Roslyn Analyzer について

概要

静的解析プログラムです。
IDE との統合が進んでおり、コード編集中に Warning を出してくれるすごいやつです。
また、自分で静的解析を作り込むこともできます。

このスライドは Unity での説明ですが、概要やカスタムアナライザについてよくわかります。

どうやって使うか

使ったら追記します。

usagiga 4ヶ月前に更新

GitHub Actions について

CI も回しておきましょう。

ワークフローの設定

手軽な例で言うとこんな感じになるかと思います。

name: .NET

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  test:
    strategy:
      matrix:
        configuration: [Debug, Release]
    runs-on: ubuntu-latest
    steps:
      # Initializing Build Environments
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.x
          cache: true
          cache-dependency-path: '**/packages.lock.json'

      # Run build
      - name: Build
        run: dotnet build

      # Run test
      - name: Test
        run: dotnet test

なお、このワークフローの実行に際しては、プロジェクトの設定で EnableWindowsTargeting ^[1] と RestorePackagesWithLockFile ^[2] を true にしておき、LockFile をレポジトリに含める必要があります。

TestProject.csproj

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <OutputType>WinExe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <!-- ... -->
        <EnableWindowsTargeting>true</EnableWindowsTargeting>
        <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    </PropertyGroup>

</Project>

Dependabot / CodeQL の設定

GitHub が提供している脆弱性やエラー検知のシステムである Dependabot や CodeQL は .NET プロジェクトにもあります。設定しておくといいかもしれません。

CodeQL はなぜか実行できなかった。今度また試してみます

脚注

Windows 以外のプラットフォームで Windows 向けのプロジェクトをビルドするためのもの。 ↩︎
ロックファイルはキャッシュを有効化する際に必要になる。このオプションはそのロックファイルを生成するためのもの。プロジェクトを編集すると自動的にロックファイルが生成されるので、それをレポジトリに含めればよい。 cf. https://github.com/actions/setup-dotnet/issues/471 ↩︎

usagiga 4ヶ月前

.NET CLI の主なコマンド

GitHub Actions やローカルで、テストやビルドを実行したいときは、.NET CLI を使うとよいでしょう。以下のようなコマンドが特に便利です。

dotnet test ... テスト
dotnet build ... ビルド
dotnet format ... フォーマッタ
dotnet restore ... 依存関係やツールをダウンロード・インストールします。npm install に近いものです
dotnet watch <command> ... ホットリロードで指定したコマンドを実行

なお、.NET CLI コマンドを使わなくても、IDEのテストやビルドのボタンを押すでもよいとは思います。

usagiga 4ヶ月前に更新

今後かくこと

非同期処理
- 非同期メソッド
- 非同期ストリーム
イベント処理
YouTube Live Streaming API について
- 配信可能な権限がないユーザーでは API が叩けない可能性がある(？)
MVVM アーキテクチャ