MENU

SharePoint CSOMでSharePointOnlineCredentialsが見つからない原因と解決策｜.NET Standard/.NET Frameworkの違い

SharePoint

SharePoint Online に CSOM で接続しようとして SharePointOnlineCredentials を使うと、The type or namespace 'SharePointOnlineCredentials' could not be found で止まることがあります。原因の多くは「プロジェクトのターゲットが .NET Standard/.NET Core 系」な点。直し方と、参照に黄色い警告が出るケースの対処、.NET 6+ での代替案までまとめます。

目次

症状の整理：何が起きているのか

このエラーは「コードは SharePointOnlineCredentials を参照しているのに、参照している CSOM のアセンブリにはその型が存在しない」状態で発生します。多くのケースでは、NuGet の追加や using Microsoft.SharePoint.Client; の有無ではなく、プロジェクトのターゲットフレームワークが原因です。

現象よくある勘違い実際に確認すべきポイント
コンパイル時に「型／名前空間が存在しない」NuGet が足りない、using が足りないTarget Framework が .NET Standard / .NET (Core) になっていないか
参照に黄色い三角（警告）が付くVisual Studio の不具合参照 DLL の解決失敗（パス、バージョン不一致、復元失敗）
ビルドは通るが実行時に例外資格情報が間違いアセンブリ競合、Binding Redirect、認証方式（MFA/モダン認証）

原因の本命：プロジェクトが .NET Standard / .NET Core 系になっている

SharePointOnlineCredentials は、SharePoint Online 向けの CSOM（Client Side Object Model）で長く使われてきた「ユーザー名＋パスワード」での認証クラスです。一方で、CSOM には歴史的事情があり、.NET Framework 前提の API が混ざりやすいため、プロジェクトが .NET Standard / .NET（Core）だと「型が見つからない」状態になりがちです。

ポイントは次のとおりです。

  • 同じ NuGet 名でも、ターゲットフレームワークによって参照される中身（TFM別のアセンブリ）が変わる
  • .NET Standard 用に用意されたアセンブリでは、フル .NET Framework で提供される型が省かれていることがある
  • 結果として「インストールはできたのに、型が出てこない」現象が起きる
ターゲットフレームワークSharePointOnlineCredentials現実的な対応おすすめ度
.NET Framework（例：4.7.2 / 4.8）参照できるケースが多いCSOM を NuGet で入れ直して利用短期で解決したいなら高
.NET Standard / .NET（Core/5+/6+/7+/8+）見つからない／提供されないことがあるOAuth（Entra ID）前提の方式へ寄せる長期運用なら高

最短で直す：.NET Framework ターゲットに切り替えて CSOM を入れ直す

「いま動くものを作りたい」「既存の CSOM コードを最小変更で通したい」場合は、まず .NET Framework へ寄せるのが一番早いです。特にコンソールアプリやバッチ用途なら、この判断が最短距離になりやすいです。

手順：ターゲットフレームワークを確認する

Visual Studio で次を確認します。

  • プロジェクトを右クリック →「プロパティ」→「アプリケーション」
  • 「ターゲット フレームワーク」が .NET Framework になっているか
  • もし .NET Core や .NET、.NET Standard なら、SharePointOnlineCredentials が出ない原因候補が濃厚

既存プロジェクトを変更できない場合は、別で .NET Framework の新規プロジェクトを作成して、CSOM 関連コードを移植する方がスムーズなこともあります（依存関係が複雑な場合に特に有効です）。

手順：NuGet を「入れ直す」ことが重要

ターゲット変更後は、参照が中途半端に残っていると警告の温床になります。次の流れが安定します。

  1. いったん CSOM 関連パッケージをアンインストール
  2. bin / obj フォルダを削除（可能なら）
  3. NuGet の復元を実行（ソリューションをクリーン→リビルドでも可）
  4. CSOM パッケージを再インストール

導入パッケージの例としては、SharePoint Online 向け CSOM をまとめて含むパッケージ（例：Microsoft.SharePointOnline.CSOM 系）を選ぶと「片方だけ足りない」を避けやすくなります。既に Microsoft.SharePoint.Client / Microsoft.SharePoint.Client.Runtime を個別に入れている場合も、ターゲットが合っていれば型が見えるようになることがあります。

確認：最小コードでコンパイルできるか試す

まずは「コンパイルできる」状態を作るのが先です。以下は動作確認用の最小例です（パスワードの直書きは避け、実運用では安全な保管方法に置き換えてください）。

using System;
using System.Security;
using Microsoft.SharePoint.Client;

class Program
{
    static void Main()
    {
        var siteUrl = "https://<tenant>.sharepoint.com/sites/<site>";
        var userName = "user@<tenant>.onmicrosoft.com";
        var plainPassword = "********"; // 直書きは避ける

        var securePassword = new SecureString();
        foreach (var c in plainPassword) securePassword.AppendChar(c);

        using (var ctx = new ClientContext(siteUrl))
        {
            ctx.Credentials = new SharePointOnlineCredentials(userName, securePassword);

            var web = ctx.Web;
            ctx.Load(web, w => w.Title, w => w.Url);
            ctx.ExecuteQuery();

            Console.WriteLine(web.Title);
            Console.WriteLine(web.Url);
        }
    }
}

このコードで SharePointOnlineCredentials に赤線が付かず、コンパイルが通るなら「型が見つからない」問題は解消に向かっています。次に実行時の認証エラーが出た場合は、資格情報の誤りだけでなく MFA（多要素認証）やモダン認証の影響も疑ってください。

参照に黄色い三角（警告）が付く理由と、現場で効く対処

Visual Studio の参照ツリーで DLL に黄色い三角が付くのは、端的に言うと「参照先のアセンブリを解決できていない」状態です。見た目は軽微でも、ビルドや実行時に別のトラブルへつながります。

よくある原因症状優先度の高い対処
ターゲットフレームワーク不一致参照は追加できるが型が出ない／警告が消えない.NET Framework に合わせる（本記事の主題）
NuGet 復元失敗・パッケージ破損再起動やクリーンで直ったり直らなかったり一度アンインストール→再インストール、NuGet キャッシュ削除
手動で DLL を参照追加してしまったHintPath がズレて移動や CI で壊れやすい手動参照を外して NuGet 管理に寄せる
同名 DLL のバージョン競合（別フォルダや GAC）ビルドは通るが実行時に FileLoadException など参照を整理し、必要なら Binding Redirect を追加

まずやるべき定番セット

  • ソリューションを「クリーン」→「リビルド」
  • NuGet の「パッケージの復元」
  • 参照の重複（同じ DLL を NuGet と手動で二重に参照）をなくす

それでも消えないときの実務的な切り分け

黄色い警告が頑固なときは、「どの DLL を、どこから掴みに行って失敗しているか」を見るのが近道です。

  • 警告の付いた参照をクリック → プロパティで Path / Version / Copy Local を確認
  • 期待している場所（NuGet の packages フォルダや obj 配下）に DLL があるか
  • 別プロジェクトや別 NuGet が同じ名前の DLL を持ち込んでいないか

スレッド等で報告される「別ディレクトリに DLL を置き直して参照し直したら警告が消えた」という回避策は、根本原因（復元やパス解決の失敗）をマスクしているだけのこともあります。ただし、納期優先で一時回避が必要な現場では役立つこともあります。実施する場合は、最終的に NuGet 管理へ戻すことを前提にしてください（将来の更新やチーム開発で破綻しやすくなります）。

「.NET Framework を使いたくない」場合の現実解：OAuth（Entra ID）へ寄せる

SharePointOnlineCredentials はユーザー名＋パスワード前提で、モダン認証（OAuth）や MFA と相性が悪くなりやすい領域です。いまから .NET 6/7/8 を前提に進めるなら、最初から OAuth 方式へ設計を寄せる方が、後で詰まりにくくなります。

選択肢向いている用途.NET 6+ との相性ひとこと
Microsoft Graph APIファイル操作、ユーザー/グループ、Teams/OneDrive と横断した処理良い将来性が高く、トークン取得（MSAL）と組み合わせやすい
SharePoint REST APISharePoint 固有の操作（リスト/ライブラリ）を細かく叩きたい良いGraph で足りない部分を補える
PnP 系 SDK（PnP.Core SDK など）SharePoint 操作を SDK で楽に書きたい良い現場の “やりたいこと” に対して記述量が減りやすい

OAuth 化のざっくり手順（全体像）

実装レベルの詳細は環境で変わりますが、流れはほぼ共通です。

  1. Entra ID（旧 Azure AD）でアプリ登録
  2. 必要な API 権限（例：Sites.Read.All など）を付与
  3. クライアントシークレットまたは証明書でトークン取得
  4. 取得したアクセストークンで Graph / REST を呼ぶ

「ユーザーのパスワードをアプリに持たせない」設計に寄せられるため、セキュリティ面・運用面の両方でメリットがあります。特にバッチやサーバーサイド処理では、クライアント資格情報フロー（アプリ専用）を選べるのが強みです。

よくある追加のつまずきとチェックリスト

原因が .NET Standard 以外だった場合でも、次のチェックで詰まりどころを潰せます。

チェック項目見る場所意図
プロジェクトの Target Frameworkプロジェクト プロパティCSOM が想定する API を参照できる土台か確認
CSOM パッケージの入れ方NuGet（packages.config / PackageReference）手動参照を混ぜない、復元できる形に統一
参照の競合参照一覧、出力ログ同名 DLL を複数バージョン参照していないか
MFA / 条件付きアクセステナントの認証ポリシーユーザー名＋パスワード方式が通らない構成になっていないか
実行環境差（CI / サーバー）ビルドエージェントの SDK / 参照ローカルだけ動く状態を避ける

30秒診断：プロジェクト種別を見分けるコツ

「自分のプロジェクトが .NET Framework なのか .NET（Core）なのか分からない」という場合は、次のどれかで判断できます。

Visual Studio のテンプレート名で見る

作成したテンプレート例ありがちなターゲットこの問題の起きやすさ
Console App（.NET Framework）.NET Framework 4.x低い（CSOM が想定しやすい）
Console App（.NET / .NET Core）net6.0 / net8.0 など高い（型が提供されないことがある）
Class Library（.NET Standard）netstandard2.0 など高い（コンパイルで止まりやすい）

.csproj を開いて直接見る（いちばん確実）

プロジェクトファイル（.csproj）を開き、次のような記述があれば .NET Standard/.NET（Core）です。

<PropertyGroup>
  <TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>

.NET Framework の場合は、SDK スタイルなら次のようになります。

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>

古い形式のプロジェクトだと、次のような行で判別できます。

<TargetFrameworkVersion>v4.8</TargetFrameworkVersion>

なぜ「NuGet を入れたのに型が出ない」ことが起きるのか

最近の NuGet パッケージは、1つのパッケージに複数のターゲット（例：net48、netstandard2.0 など）向けの成果物を同梱していることがあります。ビルド時には、あなたのプロジェクトの Target Framework に合わせて「適合する DLL」が自動的に選ばれます。

ここで .NET Standard 側の DLL が「互換性のために一部 API を省いている」設計だと、インストール自体は成功しても、目的の型が含まれず could not be found になります。つまり、パッケージの追加＝必ずしも目的の型が入るとは限らない、という落とし穴です。

コンパイル後に詰まる：認証が通らない場合の考え方

SharePointOnlineCredentials が参照できるようになった後、実行時にサインインできないケースもよくあります。ここは「パスワード違い」だけで片付けず、テナントの認証ポリシーを疑うのがポイントです。

状況起きやすいこと現実的な対処
MFA が必須ユーザー名＋パスワード方式が通らないOAuth 方式（Graph/REST/PnP）へ移行
条件付きアクセス（場所/デバイス制限）ローカルは通るがサーバーは失敗、またはその逆実行環境をポリシーに合わせる／アプリ専用認証に寄せる
アカウントが外部/ゲスト同じ手順でも他ユーザーと挙動が違う権限とサインイン方式を確認（必要ならアプリ登録）

「今だけ通せればいい」場面で安易に資格情報を埋め込むと、運用・監査のタイミングで詰みやすいです。最終的に継続運用するなら、最初から OAuth へ寄せる判断が結果的にコストを下げることが多いです。

現場で迷ったときのおすすめルート

あなたの状況おすすめ理由
既存の CSOM 資産を最小変更で動かしたい.NET Framework + CSOM（SharePointOnlineCredentials）移植コストが低く、コンパイル問題を最短で消せる
新規開発で .NET 8 まで見据えたいOAuth（Graph/REST）または PnP 系 SDK認証・運用・セキュリティ面で長期に安定しやすい
社内ポリシーでパスワード保存が禁止アプリ登録 + 証明書（アプリ専用）秘密情報の取り扱いが整理しやすい

まとめ：結局どこを直せばいいのか

  • SharePointOnlineCredentials が見つからない最大要因は.NET Standard / .NET Core 系ターゲットであることが多い
  • 最短解は .NET Framework ターゲットにして CSOM を NuGet で入れ直す
  • 参照の黄色い警告は「解決失敗」なので、まずは NuGet 管理へ寄せて復元・競合を整理する
  • .NET 6+ を前提にするなら、SharePointOnlineCredentials を捨てて OAuth（Graph/REST/PnP）へ寄せる方が長期的に安全

まずはターゲットフレームワークを確認し、必要なら .NET Framework プロジェクトで最小コードがコンパイルできるかを試してください。そこが通れば、残りの課題（認証ポリシーや API 設計）は段階的に整理できます。

SharePoint
OAuth .NET Framework SharePoint NuGet CSOM SharePointOnlineCredentials .NET Standard

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次