VS Code で dotnet new console した直後の dotnet build で、生成された DLL が Norton に「Win32:TrojanX-gen [Trj]」として隔離され、以後ビルドが Access denied で失敗することがあります。原因の考え方から、最短で復旧する手順、誤検知の報告方法、再発防止の運用までまとめます。
結論：DLLなしでの「ビルド」はできない
dotnet build は、C# のソースコードをコンパイルし、実行に必要な成果物（DLL など）を出力するコマンドです。つまり「DLL を出さずにビルドする」は成り立ちません。逆に言えば、今回の問題は ビルド手順ではなく、セキュリティ製品が成果物の作成・更新を妨げていることが原因なので、まずは Norton のブロック／隔離を解消して、ビルドがファイルを書き込める状態に戻す必要があります。
起きている現象を整理する
相談内容を開発者目線で分解すると、ポイントは次の 2 段階です。
| 段階 | 何が起きているか | よく出る症状 | 原因の候補 |
|---|---|---|---|
| 最初の検知 | ビルドで生成された TestProject.dll が Norton によりブロック／隔離／削除される | 「Win32:TrojanX-gen [Trj]」などの汎用名で検知 | 誤検知、または環境要因（監視機能が強い／レピュテーション不足） |
| 継続するビルド失敗 | ビルドが DLL を上書きできず失敗する | Access denied／「書き込めない」／「ファイルが使用中」 | Norton が掴んでいる、隔離済みで存在しない、同期フォルダがロック、実行中プロセスが掴んでいる |
重要なのは、2 段階目のエラーは「結果」であり「原因」は 1 段階目ということです。先に Norton の隔離・ロックを解かないと、どれだけ dotnet build を繰り返しても同じ失敗をします。
「テンプレートで作っただけの DLL」が検知される理由
結論から言うと、こうしたケースは 誤検知（false positive）であることが少なくありません。特に Norton の検知名が「TrojanX-gen」のような “gen（generic）” 系だと、シグネチャで特定のマルウェアを指しているというより、挙動・構造・評判（レピュテーション）から広く疑わしいものを拾うタイプの検知である可能性が高いです。
開発中の成果物（bin 配下の DLL）は次の特徴があり、セキュリティ製品の監視に引っかかりやすい面があります。
- 生成された直後で「世の中での出現頻度」が極端に低い（レピュテーションが付かない）
- デバッグビルドでは最適化が弱く、メタ情報やデバッグ情報（PDB など）とセットで頻繁に更新される
- 生成・更新のたびに「未知の実行ファイル／DLL が作成された」と見える
- OneDrive 等の同期フォルダ配下だと、生成→同期→検査のタイミングが重なりロックが起きやすい
もちろん「誤検知が多い」ことと「絶対に安全」は別です。次の章の切り分けを行い、本当に感染が疑われる要素がないかも確認してください。
感染か誤検知かを切り分けるチェックポイント
「テンプレートだから安全」と決め打ちせず、最低限これだけは確認すると安心です。
.NET SDK の入手元とバージョンを確認する
まずは PC に入っている .NET SDK を確認します。複数の SDK が入っている場合もあるため、出力を控えておくと後で報告に使えます。
dotnet --info会社支給 PC などで SDK が社内配布されている場合は、配布元が正規であることも確認してください。未知の配布物だと、テンプレート自体が改変されている可能性を否定できません。
新規プロジェクトで再現するか
同じ PC・同じ Norton 設定で、別フォルダに新規作成して再現するか確認します。再現性が高いほど、誤検知の可能性が上がります。
mkdir C:\src
cd C:\src
dotnet new console -o AvTest
cd AvTest
dotnet build他のスキャナでも同様に検知されるか
Norton だけが検知し、Windows Defender など他の主要スキャナでは問題にならない場合は誤検知の可能性が高まります。逆に複数製品で同系統の検知が出る場合は、慎重に扱ってください。
怪しい NuGet パッケージを入れていないか
テンプレート直後なら通常は入っていませんが、もし dotnet add package などで追加した場合は、.csproj の PackageReference を見直してください。開発のつもりで入れたパッケージが、実は乗っ取り済みだった、という事故は現実に起きます。
最短で復旧する手順
ここからは「今すぐビルドを通したい」方向けに、効果が出やすい順で手順を並べます。上から順に潰してください。
Norton の履歴（検疫/隔離）で DLL を確認し、復元または除外する
- Norton の「セキュリティ履歴」「検疫」「隔離」といった画面で、
TestProject.dllが処理されていないか確認 - 隔離されている場合は、開発中の自分の成果物であることを確認したうえで復元
- 再発する場合は、プロジェクトフォルダー（例：
C:\src\TestProject）をスキャン除外（例外）に追加
除外は便利ですが、むやみに広い範囲を除外するとリスクが上がります。「ソース置き場」など最小限の範囲に限定するのが現実的です。
実行中のプロセスが DLL を掴んでいないか確認する
コンソールアプリを実行したまま、別ターミナルでビルドすると上書きに失敗することがあります。まずは VS Code を含め、該当プロセスを止めます。
dotnet runを止める（ターミナルで Ctrl+C）- 念のため VS Code を再起動する
- それでもダメなら PC 再起動でファイルロックを解除
ビルド生成物を掃除して作り直す（bin/obj の削除）
隔離・削除された DLL が「中途半端な状態」になっていると、以後のビルドが巻き込まれます。生成物を一度消して再生成します。
| シェル | コマンド例 |
|---|---|
| dotnet コマンド | dotnet clean dotnet build |
| PowerShell | Remove-Item -Recurse -Force .\bin, .\obj dotnet build |
| コマンドプロンプト | rmdir /s /q bin rmdir /s /q obj dotnet build |
OneDrive 配下や保護フォルダを避け、作業フォルダを移動する
ビルドは小さなファイルを頻繁に作り直します。OneDrive 同期配下（例：デスクトップ／ドキュメントが同期対象）だと、同期処理とスキャンが競合し、ロックや隔離が起きやすくなります。
| 置き場所 | おすすめ度 | 理由 |
|---|---|---|
C:\src\... | 高い | 同期や保護の影響を受けにくく、開発用の定番 |
| デスクトップ（OneDrive 同期） | 低い | 同期とスキャンが競合しやすい。企業ポリシーで保護されることも |
| ネットワークドライブ | 低い | 権限や遅延でビルドが不安定になりやすい |
移動後は、次のように作り直すのが確実です。
cd C:\src
dotnet new console -o TestProject
cd TestProject
dotnet build上書き再生成（–force）でテンプレートを作り直す
「フォルダーを消したくない」「作り直せない」場合は、テンプレート再生成の上書きオプションで復旧できることがあります（ただし既存ファイルは上書きされるため注意）。
dotnet new console --forceNorton 側で見直したい設定ポイント
Norton には複数の保護層があります。誤検知の可能性が高い場合でも、闇雲に無効化するのではなく、開発に必要な最小限の調整で切り分けるのが安全です。
除外は「フォルダ単位」で最小限に
- 除外対象は、できれば
C:\srcのような開発専用フォルダに限定する - むやみに
C:\全体を除外しない - プロジェクトごとに除外するより、開発用ルート配下に統一すると管理しやすい
定義ファイルと本体を最新化する
誤検知は、定義更新で改善することがあります。LiveUpdate 等で最新化してから再現するか確認してください。再現が消えるなら「一時的な誤検知」だった可能性が高いです。
dotnet 側でできる「切り分け」と「回避」
セキュリティ製品側が原因でも、開発者側で状況を整理しやすくする工夫があります。
出力先を変えて、ロックの影響を避ける
dotnet build は出力先を指定できます。同期や保護の影響を受けにくい場所に出すと、まず「ビルドが通るか」の切り分けができます。
dotnet build -o C:\build-outputビルドログを残して「どこで失敗しているか」を明確にする
Access denied が出ている箇所（どのファイルに、どのタイミングで書き込めないのか）を特定すると、Norton の履歴と突き合わせやすくなります。
dotnet build -v:nより詳細に追いたい場合は、MSBuild のバイナリログを取る方法もあります（後で解析できるため、社内ヘルプデスクに渡す資料としても有効です）。
dotnet build /bl:build.binlog誤検知（false positive）として Norton に報告する
新規作成した最小のコンソールアプリでも再現し、他スキャナでは問題が出ない場合は、Norton 側へ誤検知として報告する価値があります。報告時に用意すると話が早い情報をまとめます。
| 用意するもの | 例 | 目的 |
|---|---|---|
| 検知名 | Win32:TrojanX-gen [Trj] | どのルールで引っかかったか特定 |
| 対象ファイルのパス | ...\bin\Debug\netX\TestProject.dll | 成果物であることを示す |
| ファイルハッシュ | SHA-256 など | 同一サンプルかを判別 |
| .NET SDK 情報 | dotnet --info の出力 | 環境依存かの判断材料 |
| 再現手順 | テンプレート作成→ビルドの最短手順 | 調査を再現可能にする |
注意点として、会社の規定で外部へのファイル提出が禁止されている場合があります。その場合は、社内の情報セキュリティ窓口や管理部門に相談し、提出可否を確認してください。
「Visual Studio の問題？」と感じたときの切り分け
今回の操作は Visual Studio（統合開発環境）ではなく、Visual Studio Code のターミナル上の .NET CLI が主体です。そのため、原因の中心は次のいずれかになります。
- セキュリティ製品が成果物を隔離／ロックしている
- プロジェクトの置き場所（同期・保護）によるロック
- 実行中プロセスによるファイルロック
- まれに .NET SDK／テンプレートの破損
VS Code 側の不具合に見える場合でも、ログを見れば「書き込めない」ことが原因と分かることが多いです。相談先としては、Norton サポート／Windows の権限周り／VS Code の拡張機能（C# 拡張）など、切り分けに応じて適切な窓口を選ぶのが近道です。
再発防止のための運用ルール
誤検知が一度でも起きた環境は、同じ条件で再発しやすい傾向があります。開発の生産性と安全性を両立するために、次の運用が効きます。
- 開発用フォルダを固定する（例：
C:\src） - 同期対象のフォルダ（OneDrive/Dropbox 等）ではビルドしない
- プロジェクトルート全体ではなく、必要最小限の範囲で除外設定する
- Norton の定義更新と Windows Update を習慣化する
- 不明な NuGet パッケージを追加する前に、公式性・メンテ状況を確認する
- 違和感があれば、別 PC やクリーン環境で再現する（環境依存の切り分け）
よくある質問
DLL をダウンロードして差し替えれば解決しますか？
解決しません。DLL は あなたのソースコードをコンパイルした成果物なので、外部から「安全な DLL」を入手して差し替える発想がそもそも不一致です。仮に誰かの DLL を入れても、ソースと一致しないため正しく動きません。
一時的に Norton を無効化すればビルドできますか？
無効化すれば通る場合はありますが、開発 PC 全体のリスクが上がります。まずは「開発フォルダの最小限の除外」「隔離の復元」「同期フォルダを避ける」など、限定的な対策で解決するのが安全です。
会社 PC で除外設定ができません
社内ポリシーで制限されている場合、勝手な回避は避けてください。再現手順・ログ（dotnet build -v:n や /bl）・検知名をまとめ、情報システム部門に相談すると通りやすくなります。プロジェクトを C:\src のようなローカル固定フォルダに移すだけで改善することもあります。
Access denied が Norton ではなく Windows の権限に見えます
表示されるエラーは同じでも、原因が「権限」ではなく「別プロセスによるロック」や「隔離」なことが多いです。まずは Norton の履歴確認、次に OneDrive 配下を避ける、最後に実行中プロセスの停止、の順で疑うと解決が早いです。
まとめ
dotnet build は DLL を生成するのが本来の役割なので、「DLL なしでビルド」はできません。対策は、Norton が生成物を隔離・ロックしている状態を解消し、開発用フォルダや同期環境など運用面も含めて再発を防ぐことです。新規プロジェクトでも再現する場合は、誤検知として Norton に報告し、定義更新で解消されるのを待つのが王道です。
コメント