この記事はC# Advent Calendar 2025 18日目の記事です。
N.Mです。C#にはNAudioというMITライセンスの音声処理ライブラリがあります。これをローカルでビルドし、ローカルのソースとしてNuGetで利用できるようにしたのですが、調べてもあまり情報が無く、苦戦したのでアドベントカレンダーの記事として書くことにしました。
発端
作っているWPFのアプリで、特定のプロセスからの音声をそのまま流すということが必要になりました。(この話については翌日の記事に書きます。 [C#] WebView2から出る音声を画面共有で流す)
色々調べると、Windowsではまさに特定プロセスの音声をキャプチャする仕組みがあり、サンプルが公開されていました。
Application loopback audio capture
NAudioにも2025年11月時点で、すでにその仕組みを利用した機能が実装されていました。しかし、まだmainブランチにはマージされておらず、 process-audio-capture という別ブランチにある状態です。
Implement Wasapi Process Specific Audio Capture
さらにいうと、2025年11月時点でnuget.orgにあったNAudioパッケージの最新版が、2023年9月ごろの2年前のバージョンでした。通常であればNuGetでnuget.orgからパッケージをインストールすれば良いのですが、こうした事情から自分のPCでビルドし、それをWPFアプリのプロジェクトで使えるようにする必要が出てきました。1
環境
OS: Windows 11 Home (24H2)
Visual Studioのバージョン: Visual Studio 2022 (Ver. 17.12.3)
必要だった手順
NAudioをローカルでビルドし、ローカルのソースとしてNuGetで利用できるようにするために、以下のような手順が必要でした。
- NAudioのソースコードのクローン
- Visual StudioでNAudioソリューションのビルド
- パッケージファイル (.nupkg)を1つのフォルダに集約
- パッケージファイルを含むフォルダをNuGetのローカルソースとして登録
- WPFアプリのプロジェクトへのNAudioのインストール
Step1. NAudioのソースコードのクローン
GitHubのNAudioのリポジトリからクローンします。今回、 process-audio-capture のブランチで実装されている機能を使うので、ブランチを指定してクローンします。
以下のコマンドで該当するブランチを直接クローン出来ます。(参考)
git clone -b process-audio-capture https://github.com/naudio/NAudio.git
もしくは、GitHub Desktopでクローンとブランチの変更を行うのでも問題ありません。(自分はGitHub Desktopを利用しました。)
Step2. Visual StudioでNAudioソリューションのビルド
クローンしてきたリポジトリのフォルダに、すでにVisual Studioのソリューションファイル NAudio.sln があるので、そのソリューションファイルをReleaseモードでビルドします。
ビルドが成功すると、 NAudio フォルダや NAudio.(子ネームスペース) フォルダ (例: NAudio.Core など) 内の bin\Release フォルダ内に .nupkg ファイルが作成されます。
トラブルシューティング: Windows 10 SDK (10.0.18362) が無いことによるエラー
NAudioのビルドにはWindows 10 SDKが必要なので、Visual Studio InstallerでWindows 10 SDK (10.0.18362)をインストールしてください。
トラブルシューティング: 資産ファイル 'project.assets.json' が見つかりません。
コマンドプロンプトでリポジトリのフォルダに移動し、そこで以下のコマンドを実行してください。(完了するまで数分かかることもありました。)
dotnet restore
Step3. パッケージファイル (.nupkg)を1つのフォルダに集約
Step2でビルドが完了すると、2025年11月時点では以下の .nupkg ファイルが生成されているはずです。
(NAudioのリポジトリフォルダ)\NAudio\bin\Release\NAudio.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Asio\bin\Release\NAudio.Asio.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Core\bin\Release\NAudio.Core.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Extras\bin\Release\NAudio.Extras.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Midi\bin\Release\NAudio.Midi.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Uap\bin\Release\NAudio.Uap.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.Wasapi\bin\Release\NAudio.Wasapi.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.WinForms\bin\Release\NAudio.WinForms.2.1.0-beta.1.nupkg(NAudioのリポジトリフォルダ)\NAudio.WinMM\bin\Release\NAudio.WinMM.2.1.0-beta.1.nupkg
どこでも良いのでフォルダを1つ作り、上記の9つのファイルをそのフォルダにコピーします。自分はNAudioのリポジトリのフォルダに NAudioLocal というフォルダを作り、そこにコピーしました。
Step4. パッケージファイルを含むフォルダをNuGetのローカルソースとして登録
以下のコマンドで、Step3で作成したフォルダをNuGetのローカルソースに追加します。
(最後のNAudioLocalはローカルソースのラベルなので、任意の名前で問題ありません。)
dotnet nuget add source "(Step3で作成したフォルダへの絶対パス)" -n NAudioLocal
自分は以下のようなコマンドを入力しました。
dotnet nuget add source "(NAudioのリポジトリフォルダ)\NAudioLocal" -n NAudioLocal
注意
Step3で作成したフォルダのパスは絶対パスで入力するのが安全です。相対パスで入力する場合、NuGet側のフォルダ (%APPDATA%\NuGet) からのパスとして認識されます。
Step5. WPFアプリのプロジェクトへのNAudioのインストール
WPFアプリのプロジェクトを含むソリューションファイルをVisual Studioで開きます。WPFアプリのプロジェクトを選択した状態で、「プロジェクト」→「NuGetパッケージの管理」をクリックし、プロジェクトのNuGetパッケージ管理画面を開きます。
以下のように操作することで、画像のようにローカルでビルドしたNAudioのパッケージが表示され、プロジェクトにインストールできます。
- 「パッケージソース」で
NAudioLocal(Step4でローカルソースに設定したラベル)を選択する - 「プレリリースを含める」にチェックをつける
ローカルのNAudioがインストールされると、WPFアプリのプロジェクトで使用したかったNAudioの機能を使用できるようになりました。
トラブルシューティング: nuget.orgからのパッケージが優先されてしまう
ここまでの操作や設定で、ローカルにあるNAudioがインストールされるはずですが、 2 もしnuget.orgからのパッケージが優先的にインストールされてしまう場合は、 パッケージソースマッピング を設定します。NuGetパッケージの管理画面にあるパッケージソースマッピングの「構成する」ボタン(画像の赤枠で囲ったボタン)を押すことで、パッケージソースのマッピング設定画面を開くことができます。Visual Studioのオプションから開くこともできます。
その設定画面で以下のようにパターンとソースの組み合わせを追加します。
- パッケージパターン:
NAudio, ソース:NAudioLocal - パッケージパターン:
NAudio.*, ソース:NAudioLocal - パッケージパターン:
*, ソース:nuget.org
注意
3つ目のパッケージパターン: *とソース: nuget.orgの組を設定しないと、NAudio以外のパッケージをnuget.orgからインストールできなくなります。
まとめ
今回、ローカルでNAudioのソースコードをビルドし、それをローカルのソースとしてNuGetで利用できるようにしてみました。
NAudioもそうですが、C#ライブラリの最新機能を使いたいが、まだ公開されたNuGetのパッケージには反映されていないというケースはあると思いますので、そういう時に今回の方法が使えそうかと思います。
-
別のプロジェクトで使えるようにするには、生成されたdllをプロジェクトで参照できるようにすればよく、いくつか方法はあると思いますが、今回はローカルのソースとしてNuGetで追加できるようにしてみました。 ↩
-
NuGetにあるIssue を軽く見ている限り、複数ソースに存在するパッケージをインストールしようとすると、昔は一番先にレスポンスのあったソースからパッケージをインストールするような挙動だったようです。今も特に設定していないとその挙動になると自分は認識しています。(さすがにネットワークを介さないローカルのパッケージが最速で来るはずで、ローカルにあるものがnuget.orgよりも優先されそうだと思います。) ↩


