Visual Studio 2013 の ASP.NET と Web ツールのリリースノート

[アーティクル]
06/16/2023

作成者: Microsoft

このドキュメントでは、Visual Studio 2013の ASP.NET and Web Toolsのリリースについて説明します。

内容

インストールに関する注意事項
ドキュメント
ソフトウェア要件

Visual Studio 2013の ASP.NET and Web Toolsの新機能

1 つの ASP.NET
新しい Web プロジェクトエクスペリエンス
ASP.NET スキャフォールディング
ブラウザーリンク
Visual Studio Web エディターの機能強化
Visual Studio でのAzure App Service Web Appsサポート
Web 発行の機能強化
NuGet 2.7
ASP.NET Web フォーム
ASP.NET MVC 5
ASP.NET Web API 2
ASP.NET SignalR
ASP.NET Identity
Microsoft OWIN コンポーネント
Entity Framework 6
ASP.NET Razor 3
ASP.NET アプリの中断
既知の問題と重大な変更

インストールに関する注意事項

Visual Studio 2013の ASP.NET and Web Toolsは、メインインストーラーにバンドルされており、ここからダウンロードできます。

ドキュメント

Visual Studio 2013の ASP.NET and Web Toolsに関するチュートリアルやその他の情報は、ASP.NET Web サイトから入手できます。

ソフトウェア要件

ASP.NET and Web ToolsにはVisual Studio 2013が必要です。

Visual Studio 2013の ASP.NET and Web Toolsの新機能

次のセクションでは、リリースで導入された機能について説明します。

1 つの ASP.NET

Visual Studio 2013のリリースにより、ASP.NET テクノロジを使用するエクスペリエンスを統合し、必要なものを簡単に組み合わせることができるように、一歩を踏み出しました。たとえば、MVC を使用してプロジェクトを開始し、後でプロジェクトにWeb Forms ページを簡単に追加したり、Web Forms プロジェクトの Web API をスキャフォールディングしたりできます。 ASP.NET の 1 つは、開発者が ASP.NET で好きなことを簡単に行うことです。どのテクノロジを選択しても、信頼できる基になる One ASP.NET のフレームワークに基づいて構築していると確信できます。

新しい Web プロジェクトエクスペリエンス

Visual Studio 2013で新しい Web プロジェクトを作成するエクスペリエンスが強化されました。 [新しい ASP.NET Web プロジェクト] ダイアログでは、目的のプロジェクトの種類を選択し、テクノロジ (Web Forms、MVC、Web API) の任意の組み合わせを構成し、認証オプションを構成し、単体テストプロジェクトを追加できます。

新しい ASP.NET プロジェクト

新しいダイアログでは、多くのテンプレートの既定の認証オプションを変更できます。たとえば、ASP.NET Web Forms プロジェクトを作成するときに、次のいずれかのオプションを選択できます。

[認証なし]
個々のユーザーアカウント (ASP.NET メンバーシップまたはソーシャルプロバイダーのログイン)
組織アカウント (インターネットアプリケーションの Active Directory)
Windows 認証 (イントラネットアプリケーションの Active Directory)

認証オプション

Web プロジェクトを作成するための新しいプロセスの詳細については、「Visual Studio 2013での ASP.NET Web プロジェクトの作成」を参照してください。新しい認証オプションの詳細については、このドキュメントで後述する「ASP.NET ID」を参照してください。

ASP.NET スキャフォールディング

ASP.NET スキャフォールディングは、ASP.NET Web アプリケーションのコード生成フレームワークです。これにより、データモデルと対話する定型コードをプロジェクトに簡単に追加できます。

以前のバージョンの Visual Studio では、スキャフォールディングは ASP.NET MVC プロジェクトに制限されていました。 Visual Studio 2013を使用すると、Web Formsを含む任意の ASP.NET プロジェクトにスキャフォールディングを使用できるようになりました。 Visual Studio 2013では現在、Web Forms プロジェクトのページの生成はサポートされていませんが、MVC 依存関係をプロジェクトに追加することで、Web Formsでのスキャフォールディングを引き続き使用できます。 Web Formsのページ生成のサポートは、今後の更新で追加される予定です。

スキャフォールディングを使用する場合は、必要なすべての依存関係がプロジェクトにインストールされていることを確認します。たとえば、ASP.NET Web Forms プロジェクトから開始し、スキャフォールディングを使用して Web API コントローラーを追加すると、必要な NuGet パッケージと参照がプロジェクトに自動的に追加されます。

Web Forms プロジェクトに MVC スキャフォールディングを追加するには、新しいスキャフォールディングされた項目を追加し、ダイアログウィンドウで [MVC 5 依存関係] を選択します。 MVC のスキャフォールディングには 2 つのオプションがあります。[最小] と [完全] です。 [最小] を選択すると、ASP.NET MVC の NuGet パッケージと参照のみがプロジェクトに追加されます。 [完全] オプションを選択すると、[最小依存関係] が追加され、MVC プロジェクトに必要なコンテンツファイルも追加されます。

非同期コントローラーのスキャフォールディングのサポートでは、Entity Framework 6 の新しい非同期機能が使用されます。

詳細とチュートリアルについては、「スキャフォールディングの概要 ASP.NET 参照してください。

ブラウザーリンク – ブラウザーと Visual Studio の間の SignalR チャネル

新しいブラウザーリンク機能を使用すると、複数のブラウザーを Visual Studio に接続し、ツールバーのボタンをクリックしてすべて更新できます。モバイルエミュレーターを含む複数のブラウザーを開発サイトに接続し、[更新] をクリックしてすべてのブラウザーを同時に更新できます。 Browser Link では、開発者がブラウザーリンク拡張機能を記述できるようにするための API も公開されています。

Visual Studio メニューのスクリーンショット。更新アイコンが強調表示され、ドロップダウンメニューで [ブラウザーリンクダッシュボード] が強調表示されています。

開発者が Browser Link API を利用できるようにすることで、Visual Studio と接続されているブラウザーの境界を越える非常に高度なシナリオを作成できるようになります。 Web Essentials では、API を利用して、Visual Studio とブラウザーの開発者ツール、リモート制御モバイルエミュレーターなどの統合エクスペリエンスを作成します。

Visual Studio Web エディターの機能強化

Visual Studio 2013には、Razor ファイルと Web アプリケーションの HTML ファイル用の新しい HTML エディターが含まれています。新しい HTML エディターでは、HTML5 に基づく単一の統合スキーマが提供されます。自動中かっこ補完、jQuery UI と AngularJS 属性 IntelliSense、属性 IntelliSense グループ化、ID とクラス名 Intellisense、およびパフォーマンス、書式設定、SmartTags などのその他の機能強化があります。

次のスクリーンショットは、HTML エディターで Bootstrap 属性 IntelliSense を使用する方法を示しています。

HTML エディターでの Intellisense

Visual Studio 2013には、CoffeeScript と LESS エディターの両方が組み込まれています。 LESS エディターには CSS エディターのすべてのクールな機能が付属しており、チェーン内のすべての LESS ドキュメント全体で変数と mixins に固有の Intellisense を @import 備えています。

Visual Studio でのAzure App Service Web Appsサポート

Azure SDK for .NET 2.2 Visual Studio 2013では、サーバーエクスプローラーを使用してリモート Web アプリと直接やり取りできます。 Azure アカウントへのサインイン、新しい Web アプリの作成、アプリの構成、リアルタイムログの表示などを行うことができます。 SDK 2.2 がリリースされた後すぐに、Azure でデバッグモードでリモートで実行できるようになります。 Azure App Service Web Appsの新機能のほとんどは、Azure SDK for .NET の現在のリリースをインストールするときに Visual Studio 2012 でも機能します。

詳細については、次のリソースを参照してください。

Web 発行の機能強化

Visual Studio 2013には、Web 発行の新機能と強化された機能が含まれています。いくつかを次に示します。

Web.configファイル暗号化を簡単に自動化できます。 (このリンクと次の 2 つのリンクは、MSDN のドキュメントを指しています。10/17 の 1 日の遅くまで使用できない可能性があります)。
デプロイ中にアプリケーションをオフラインにして簡単に自動化できます。
サーバーにコピーするファイルを決定するために、最終変更日ではなくファイルチェックサムを使用するように Web 配置を構成します。
FTP またはファイルシステムの発行方法と Web 配置を使用している場合は、選択した個々のファイル (Web.configを含む) をすばやく発行します。

web 展開 ASP.NET 詳細については、 ASP.NET サイトを参照してください。

NuGet 2.7

NuGet 2.7 には、 NuGet 2.7 リリースノートで詳しく説明されている豊富な新機能が含まれています。

このバージョンの NuGet では、パッケージをダウンロードするために NuGet のパッケージ復元機能に明示的な同意を提供する必要がなくなります。 NuGet をインストールすることで、同意 (および NuGet の基本設定ダイアログの関連付けられているチェックボックス) が付与されるようになりました。これで、パッケージの復元は既定で動作します。

ASP.NET Web Forms

1 つの ASP.NET

Web Forms プロジェクトテンプレートは、新しい One ASP.NET エクスペリエンスとシームレスに統合されます。 MVC と Web API のサポートをWeb Forms プロジェクトに追加し、One ASP.NET プロジェクト作成ウィザードを使用して認証を構成できます。詳細については、「Visual Studio 2013での ASP.NET Web プロジェクトの作成」を参照してください。

ASP.NET Identity

Web Forms プロジェクトテンプレートは、新しい ASP.NET Identity フレームワークをサポートします。さらに、テンプレートでは、Web Forms イントラネットプロジェクトの作成がサポートされるようになりました。詳細については、「Visual Studio 2013での ASP.NET Web プロジェクトの作成」の「認証方法」を参照してください。

ブートストラップ

Web Forms テンプレートでは、Bootstrap を使用して、簡単にカスタマイズできる滑らかで応答性の高い外観を提供します。詳細については、「Visual Studio 2013 Web プロジェクトテンプレートのブートストラップ」を参照してください。

ASP.NET MVC 5

1 つの ASP.NET

Web MVC プロジェクトテンプレートは、新しい One ASP.NET エクスペリエンスとシームレスに統合されます。 MVC プロジェクトをカスタマイズし、One ASP.NET プロジェクト作成ウィザードを使用して認証を構成できます。 ASP.NET MVC 5 の入門チュートリアルについては、「ASP.NET MVC 5 を使用したはじめに」を参照してください。

MVC 4 プロジェクトを MVC 5 にアップグレードする方法については、「 ASP.NET MVC 4 と Web API プロジェクトを MVC 5 と Web API 2 ASP.NET にアップグレードする方法」を参照してください。

ASP.NET Identity

MVC プロジェクトテンプレートは、認証と ID 管理に ASP.NET ID を使用するように更新されました。 Facebook と Google 認証と新しいメンバーシップ API を備えたチュートリアルについては、「Facebook と Google OAuth2 と OpenID を使用した ASP.NET MVC 5 アプリの作成」および「認証と SQL DB を使用して ASP.NET MVC アプリを作成し、Azure App Serviceにデプロイする」を参照してください。

ブートストラップ

MVC プロジェクトテンプレートが更新され、 Bootstrap を使用して、簡単にカスタマイズできる滑らかで応答性の高い外観が提供されました。詳細については、「Visual Studio 2013 Web プロジェクトテンプレートのブートストラップ」を参照してください。

認証フィルター

認証フィルターは、ASP.NET MVC の新しい種類のフィルターであり、ASP.NET MVC パイプラインで承認フィルターの前に実行され、すべてのコントローラーに対してアクションごと、コントローラーごと、またはグローバルに認証ロジックを指定できます。認証フィルターは要求の資格情報を処理し、対応するプリンシパルを指定します。認証フィルターでは、承認されていない要求に応じて認証チャレンジを追加することもできます。

フィルターのオーバーライド

オーバーライドフィルターを指定することで、特定のアクションメソッドまたはコントローラーに適用されるフィルターをオーバーライドできるようになりました。オーバーライドフィルターは、特定のスコープ (アクションまたはコントローラー) に対して実行すべきでないフィルターの種類のセットを指定します。これにより、グローバルに適用されるフィルターを構成し、特定のグローバルフィルターを特定のアクションまたはコントローラーに適用できないようにすることができます。

属性ルーティング

ASP.NET MVC では、の作成者 http://attributerouting.netである Tim McCall の貢献により、属性ルーティングがサポートされるようになりました。属性ルーティングを使用すると、アクションとコントローラーに注釈を付けることでルートを指定できます。

ASP.NET Web API 2

属性ルーティング

ASP.NET Web APIでは、の作成者http://attributerouting.netである Tim McCall の貢献により、属性ルーティングがサポートされるようになりました。属性ルーティングを使用すると、次のようにアクションとコントローラーに注釈を付けることで、Web API ルートを指定できます。

[RoutePrefix("orders")] 
public class OrdersController : ApiController 
{ 
    [Route("{id}")] 
    public Order Get(int id) { } 
    [Route("{id}/approve")] 
    public Order Approve(int id) { } 
}

属性ルーティングを使用すると、Web API の URI をより詳細に制御できます。たとえば、単一の API コントローラーを使用して、リソース階層を簡単に定義できます。

public class MoviesController : ApiController 
{ 
    [Route("movies")] 
    public IEnumerable<Movie> Get() { } 
    [Route("actors/{actorId}/movies")] 
    public IEnumerable<Movie> GetByActor(int actorId) { } 
    [Route("directors/{directorId}/movies")] 
    public IEnumerable<Movie> GetByDirector(int directorId) { } 
}

属性ルーティングには、省略可能なパラメーター、既定値、ルート制約を指定するための便利な構文も用意されています。

// Optional parameter
[Route("people/{name?}")]
// Default value
[Route("people/{name=Dan}")]
// Constraint: Alphabetic characters only. 
[Route("people/{name:alpha}")]

属性ルーティングの詳細については、「 Web API 2 での属性ルーティング」を参照してください。

OAuth 2.0

Web API プロジェクトテンプレートとシングルページアプリケーションプロジェクトテンプレートで、OAuth 2.0 を使用した承認がサポートされるようになりました。 OAuth 2.0 は、保護されたリソースへのクライアントアクセスを承認するためのフレームワークです。ブラウザーやモバイルデバイスなど、さまざまなクライアントに対して機能します。

OAuth 2.0 のサポートは、ベアラー認証と承認サーバーロールの実装のために Microsoft OWIN コンポーネントによって提供される新しいセキュリティミドルウェアに基づいています。または、Windows Server 2012 R2 の Azure Active Directory や ADFS などの組織の承認サーバーを使用してクライアントを承認することもできます。

OData の機能強化

$select、$expand、$batch、$valueのサポート

ASP.NET Web API OData では、$select、$expand、$valueが完全にサポートされるようになりました。 $batchを使用して、変更セットのバッチ処理と処理を要求することもできます。

$selectオプションと$expandオプションを使用すると、OData エンドポイントから返されるデータの形状を変更できます。詳細については、「 Web API OData での$selectと$expandサポートの概要」を参照してください。

拡張性の向上

OData フォーマッタが拡張可能になりました。 Atom エントリメタデータの追加、名前付きストリームおよびメディアリンクエントリのサポート、インスタンス注釈の追加、リンクの生成方法のカスタマイズを行うことができます。

型レスのサポート

エンティティ型の CLR 型を定義しなくても、OData サービスを構築できるようになりました。代わりに、OData コントローラーは IEdmObject のインスタンスを取得または返すことができます。これは、OData フォーマッタがシリアル化/逆シリアル化します。

既存のモデルを再利用する

既存のエンティティデータモデル (EDM) が既にある場合は、新しいエンティティデータモデルを構築する必要なく、直接再利用できるようになりました。たとえば、Entity Framework を使用している場合は、EF によってビルドされる EDM を使用できます。

バッチ処理の要求

要求バッチ処理では、複数の操作を 1 つの HTTP POST 要求に結合して、ネットワークトラフィックを削減し、よりスムーズでチャット性の低いユーザーインターフェイスを提供します。 ASP.NET Web APIでは、バッチ処理を要求するためのいくつかの戦略がサポートされるようになりました。

OData サービスの$batch エンドポイントを使用します。
複数の要求を 1 つの MIME マルチパート要求にパッケージ化します。
カスタムバッチ形式を使用します。

要求のバッチ処理を有効にするには、バッチ処理ハンドラーを含むルートを Web API 構成に追加するだけです。

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
        config.Routes.MapHttpBatchRoute( 
            routeName: "WebApiBatch", 
            routeTemplate: "api/batch", 
            batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer)); 
    } 
}

また、要求を順番に実行するか、任意の順序で実行するかを制御することもできます。

ポータブル ASP.NET Web API クライアント

ASP.NET Web API クライアントを使用して、Windows ストアと Windows Phone 8 アプリケーションで動作するポータブルクラスライブラリを作成できるようになりました。また、クライアントとサーバー間で共有できるポータブルフォーマッタを作成することもできます。

テスト容易性の向上

Web API 2 を使用すると、API コントローラーの単体テストがはるかに簡単になります。要求メッセージと構成を使用して API コントローラーをインスタンス化し、テストするアクションメソッドを呼び出すだけです。リンク生成を実行するアクションメソッドの UrlHelper クラスをモックすることも簡単です。

IHttpActionResult

IHttpActionResult を実装して、Web API アクションメソッドの結果をカプセル化できるようになりました。 Web API アクションメソッドから返された IHttpActionResult は、結果の応答メッセージを生成するために、ASP.NET Web API ランタイムによって実行されます。 IHttpActionResult は、Web API 実装の単体テストを簡略化するために、任意の Web API アクションから返すことができます。便宜上、特定の状態コード、書式設定されたコンテンツ、またはコンテンツネゴシエートされた応答を返す結果など、多くの IHttpActionResult 実装がすぐに提供されます。

HttpRequestContext

新しい HttpRequestContext は、要求に関連付けられているが、要求からすぐには使用できない状態を追跡します。たとえば、 HttpRequestContext を使用して、ルートデータ、要求に関連付けられているプリンシパル、クライアント証明書、 UrlHelper 、仮想パスルートを取得できます。単体テストの目的で HttpRequestContext を簡単に作成できます。

要求のプリンシパルは Thread.CurrentPrincipal に依存する代わりに要求と共にフローされるため、そのプリンシパルは Web API パイプライン内にある間、要求の有効期間を通じて使用できるようになりました。

CORS

Brock Allen からのもう 1 つの大きな貢献のおかげで、ASP.NET はクロスオリジン要求共有 (CORS) を完全にサポートするようになりました。

ブラウザーのセキュリティ機能により、Web ページでは AJAX 要求を別のドメインに送信することはできません。 CORS は、サーバーが同じ配信元ポリシーを緩和できるようにする W3C 標準です。 CORS を使用することで、サーバーが一部のクロスオリジン要求を、その他の要求を拒否しながら、明示的に許可することができます。

Web API 2 では、プレフライト要求の自動処理を含む CORS がサポートされるようになりました。詳細については、 ASP.NET Web API でのクロスオリジン要求の有効化に関する文書を参照してください。

認証フィルター

認証フィルターは、ASP.NET Web APIの新しい種類のフィルターであり、ASP.NET Web API パイプラインで承認フィルターの前に実行され、すべてのコントローラーに対してアクションごと、コントローラーごと、またはグローバルに認証ロジックを指定できます。認証フィルターは要求の資格情報を処理し、対応するプリンシパルを指定します。認証フィルターは、承認されていない要求に応答して認証チャレンジを追加することもできます。

フィルターのオーバーライド

オーバーライドフィルターを指定することで、特定のアクションメソッドまたはコントローラーに適用されるフィルターをオーバーライドできるようになりました。オーバーライドフィルターは、特定のスコープ (アクションまたはコントローラー) に対して実行しないフィルターの種類のセットを指定します。これにより、グローバルフィルターを追加した後、特定のアクションまたはコントローラーから一部を除外できます。

OWIN 統合

ASP.NET Web API OWIN を完全にサポートし、OWIN 対応ホストで実行できるようになりました。また、OWIN 認証システムとの統合を提供する HostAuthenticationFilter も含まれています。

OWIN 統合を使用すると、SignalR などの他の OWIN ミドルウェアと共に、独自のプロセスで Web API をセルフホストできます。詳細については、「OWIN を使用してSelf-Host ASP.NET Web APIする」を参照してください。

ASP.NET SignalR 2.0

次のセクションでは、SignalR 2.0 の機能について説明します。

OWIN 上に構築
MapHubs と MapConnection が MapSignalR になりました
クロスドメインサポート
MonoTouch と MonoDroid を使用した iOS と Android のサポート
ポータブル .NET クライアント
新しいSelf-Host パッケージ
下位互換性のあるサーバーのサポート
.NET 4.0 のサーバーサポートを削除しました
クライアントとグループの一覧にメッセージを送信する
特定のユーザーにメッセージを送信する
エラー処理のサポートの向上
ハブの簡単な単体テスト
JavaScript エラー処理

既存の 1.x プロジェクトを SignalR 2.0 にアップグレードする方法の例については、「 SignalR 1.x プロジェクトのアップグレード」を参照してください。

OWIN 上に構築

SignalR 2.0 は、 OWIN (.NET 用の Open Web インターフェイス) 上に完全に構築されています。この変更により、SignalR のセットアッププロセスは、Web ホステッドとセルフホステッドの SignalR アプリケーションの間ではるかに一貫性が保たれますが、多くの API の変更も必要でした。

MapHubs と MapConnection が MapSignalR になりました

OWIN 標準との互換性のために、これらのメソッドの名前はに MapSignalR変更されています。 MapSignalR パラメーターなしで呼び出されると、すべてのハブ (バージョン 1.x と同様 MapHubs ) がマップされます。個々の PersistentConnection オブジェクトをマップするには、type パラメーターとして接続の種類を指定し、最初の引数として接続の URL 拡張機能を指定します。

メソッドは MapSignalR Owin スタートアップクラスで呼び出されます。 Visual Studio 2013 Owin スタートアップクラスの新しいテンプレートが含まれています。このテンプレートを使用するには、次の操作を行います。

プロジェクトを右クリックします
[ 追加]、[ 新しい項目]の順に選択します。
[ Owin Startup class]$Owin スタートアップクラス$ を選択します。新しいクラスに Startup.cs という名前を付けます。

Web アプリケーションでは、次に示すように、メソッドをMapSignalR含む Owin スタートアップクラスが、Web.Config ファイルのアプリケーション設定ノードのエントリを使用して Owin のスタートアッププロセスに追加されます。

セルフホステッドアプリケーションでは、Startup クラスがメソッドのWebApp.Start型パラメーターとして渡されます。

SignalR 1.x のハブと接続のマッピング (Web アプリケーションのグローバルアプリケーションファイルから):

protected void Application_Start(object sender, EventArgs e) 
{
    // Map all hubs to "/signalr"
    RouteTable.Routes.MapHubs();
    // Map the Echo PersistentConnection to "/echo"
    RouteTable.Routes.MapConnection<myconnection>("echo", "/echo");
}

SignalR 2.0 のハブと接続のマッピング (Owin スタートアップクラスファイルから):

using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Map all hubs to "/signalr"
            app.MapSignalR();
            // Map the Echo PersistentConnection to "/echo"
            app.MapSignalR<echoconnection>("/echo");
        }
    }
}

セルフホステッドアプリケーションでは、次に示すように、Startup クラスがメソッドの型パラメーターWebApp.Startとして渡されます。

string url = "http://localhost:8080";
using (WebApp.Start<startup>(url))
{
    Console.WriteLine("Server running on {0}", url);
    Console.ReadLine();
}

クロスドメインサポート

SignalR 1.x では、クロスドメイン要求は 1 つの EnableCrossDomain フラグによって制御されました。このフラグは、JSONP 要求と CORS 要求の両方を制御しました。柔軟性を高めるために、SignalR のサーバーコンポーネントからすべての CORS サポートが削除され (ブラウザーでサポートされていることが検出された場合でも JavaScript クライアントは CORS を通常どおり使用します)、これらのシナリオをサポートするために新しい OWIN ミドルウェアが使用できるようになりました。

SignalR 2.0 では、クライアントで JSONP が必要な場合 (古いブラウザーでクロスドメイン要求をサポートするため)、次に示すようにオブジェクトtrueを HubConfiguration に設定EnableJSONPして明示的に有効にする必要があります。 JSONP は CORS よりも安全性が低く、既定では無効になっています。

SignalR 2.0 で新しい CORS ミドルウェアを追加するには、次のセクションに示すように、ライブラリをプロジェクトに追加 Microsoft.Owin.Cors し、SignalR ミドルウェアの前にを呼び出 UseCors します。

Microsoft.Owin.Cors をプロジェクトに追加する: このライブラリをインストールするには、パッケージマネージャーコンソールで次のコマンドを実行します。

Install-Package Microsoft.Owin.Cors

このコマンドを実行すると、パッケージの 2.0.0 バージョンがプロジェクトに追加されます。

UseCors の呼び出し

次のコードスニペットは、SignalR 1.x と 2.0 でクロスドメイン接続を実装する方法を示しています。

SignalR 1.x でのクロスドメイン要求の実装 (グローバルアプリケーションファイルから)

protected void Application_Start(object sender, EventArgs e) 
{
    var hubConfiguration = new HubConfiguration();
    hubConfiguration.EnableCrossDomain = true;
    RouteTable.Routes.MapHubs(hubConfiguration);
}

SignalR 2.0 でのクロスドメイン要求の実装 (C# コードファイルから)

次のコードは、SignalR 2.0 プロジェクトで CORS または JSONP を有効にする方法を示しています。このコードサンプルでは、ではなくと RunSignalRMapSignalRを使用Mapして、CORS ミドルウェアが CORS サポートを必要とする SignalR 要求に対してのみ実行されるようにします (で指定されたMapSignalRパスのすべてのトラフィックではなく)。 Map アプリケーション全体ではなく、特定の URL プレフィックスに対して実行する必要がある他のミドルウェアにも使用できます。

using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Cors;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Branch the pipeline here for requests that start with "/signalr"
            app.Map("/signalr", map =>
            {
                // Setup the CORS middleware to run before SignalR.
                // By default this will allow all origins. You can 
                // configure the set of origins and/or http verbs by
                // providing a cors options with a different policy.
                map.UseCors(CorsOptions.AllowAll);
                var hubConfiguration = new HubConfiguration 
                {
                    // You can enable JSONP by uncommenting line below.
                    // JSONP requests are insecure but some older browsers (and some
                    // versions of IE) require JSONP to work cross domain
                    // EnableJSONP = true
                };
                // Run the SignalR pipeline. We're not using MapSignalR
                // since this branch already runs under the "/signalr"
                // path.
                map.RunSignalR(hubConfiguration);
            });
        }
    }
}

MonoTouch と MonoDroid を使用した iOS と Android のサポート

Xamarin ライブラリの MonoTouch および MonoDroid コンポーネントを使用して、iOS および Android クライアントのサポートが追加されました。使用方法の詳細については、「 Xamarin コンポーネントの使用」を参照してください。 SignalR RTW リリースが利用可能になると、これらのコンポーネントは Xamarin ストアで使用できます。

### ポータブル .NET クライアント

クロスプラットフォーム開発を容易にするために、Silverlight、WinRT、Windows Phone クライアントは、次のプラットフォームをサポートする 1 つのポータブル .NET クライアントに置き換えられました。

NET 4.5
Silverlight 5
WinRT (.NET for Windows ストアアプリ)
Windows Phone 8

新しいSelf-Host パッケージ

SignalR Self-Host (Web サーバーでホストされるのではなく、プロセスまたはその他のアプリケーションでホストされる SignalR アプリケーション) の使用を容易にするための NuGet パッケージが追加されました。 SignalR 1.x でビルドされたセルフホストプロジェクトをアップグレードするには、Microsoft.AspNet.SignalR.Owin パッケージを削除し、Microsoft.AspNet.SignalR.SelfHost パッケージを追加します。セルフホストパッケージの概要の詳細については、「チュートリアル: SignalR セルフホスト」を参照してください。

下位互換性のあるサーバーのサポート

以前のバージョンの SignalR では、クライアントとサーバーで使用される SignalR パッケージのバージョンは同じである必要があります。更新が困難なシッククライアントアプリケーションをサポートするために、SignalR 2.0 では、古いクライアントでの新しいサーバーバージョンの使用がサポートされるようになりました。 注: SignalR 2.0 では、新しいクライアントを使用して古いバージョンでビルドされたサーバーはサポートされていません。

.NET 4.0 のサーバーサポートを削除しました

SignalR 2.0 では、.NET 4.0 とのサーバー相互運用性のサポートが削除されました。 .NET 4.5 は SignalR 2.0 サーバーで使用する必要があります。 SignalR 2.0 用の .NET 4.0 クライアントがまだ存在します。

クライアントとグループの一覧にメッセージを送信する

SignalR 2.0 では、クライアント ID とグループ ID の一覧を使用してメッセージを送信できます。次のコードスニペットは、これを行う方法を示しています。

PersistentConnection を使用してクライアントとグループの一覧にメッセージを送信する

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatConnection : PersistentConnection
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string>{"chatGroup", "chatGroup2"};
    protected override System.Threading.Tasks.Task OnReceived(IRequest request, string connectionId, string data)
    {
        Connection.Send(ConnectionIds, data);
        Groups.Send(groups, data);
        return base.OnReceived(request, connectionId, data);
    }
    protected override System.Threading.Tasks.Task OnConnected(IRequest request, string connectionId)
    {
        ConnectionIds.Add(connectionId);
        Groups.Add(connectionId, "chatGroup");
        return base.OnConnected(request, connectionId);
    }
    protected override System.Threading.Tasks.Task OnDisconnected(IRequest request, string connectionId)
    {
        ConnectionIds.Remove(connectionId);
        return base.OnDisconnected(request, connectionId);
    }
}

Hubs を使用してクライアントとグループの一覧にメッセージを送信する

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatHub : Hub
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string> { "chatGroup", "chatGroup2" };
    public void Send(string name, string message)
    {
        // Call the broadcastMessage method to update clients.
        Clients.Clients(ConnectionIds).broadcastMessage(name, message);
        Clients.Groups(groups).broadcastMessage(name, message);
    }
    public override System.Threading.Tasks.Task OnConnected()
    {
        ConnectionIds.Add(Context.ConnectionId);
        Groups.Add(Context.ConnectionId, "chatGroup");
        return base.OnConnected();
    }
    public override System.Threading.Tasks.Task OnDisconnected()
    {
        ConnectionIds.Remove(Context.ConnectionId);
        return base.OnDisconnected();
    }
}

特定のユーザーにメッセージを送信する

この機能を使用すると、ユーザーは新しいインターフェイス IUserIdProvider を使用して、IRequest に基づいて userId を指定できます。

IUserIdProvider インターフェイス

public interface IUserIdProvider
{
    string GetUserId(IRequest request);
}

既定では、ユーザーの IPrincipal.Identity.Name をユーザー名として使用する実装があります。

ハブでは、新しい API を使用してこれらのユーザーにメッセージを送信できます。

Clients.User API の使用

public class MyHub : Hub
{
    public void Send(string userId, string message)
    {
        Clients.User(userId).send(message);
    }
}

エラー処理のサポートの向上

ユーザーは、任意のハブ呼び出しから HubException を スローできるようになりました。 HubException のコンストラクターは、文字列メッセージとオブジェクトの追加エラーデータを受け取ることができます。 SignalR は例外を自動シリアル化し、ハブメソッドの呼び出しを拒否または失敗するために使用されるクライアントに送信します。

詳細 なハブ例外の表示 設定では、 HubException がクライアントに送り返されるかどうかに影響はありません。常に送信されます。

クライアントへの HubException の送信を示すサーバー側コード

public class MyHub : Hub
{
    public void Send(string message)
    {
        if(message.Contains("<script>"))
        {
            throw new HubException("This message will flow to the client", new { user = Context.User.Identity.Name, message = message });
        }

        Clients.All.send(message);
    }
}

サーバーから送信された HubException への応答を示す JavaScript クライアントコード

myHub.server.send("<script>")
            .fail(function (e) {
                if (e.source === 'HubException') {
                    console.log(e.message + ' : ' + e.data.user);
                }
            });

サーバーから送信された HubException への応答を示す .NET クライアントコード

try
{
    await myHub.Invoke("Send", "<script>");
}
catch(HubException ex)
{
    Conosle.WriteLine(ex.Message);
}

ハブの簡単な単体テスト

SignalR 2.0 には、モッククライアント側の呼び出しを簡単に作成できるようにする、Hubs でという IHubCallerConnectionContext インターフェイスが含まれています。次のコードスニペットは、一般的なテストハーネス xUnit.net と moq でこのインターフェイスを使用する方法を示しています。

xUnit.net を使用した SignalR の単体テスト

[Fact]
public void HubsAreMockableViaDynamic()
{
    bool sendCalled = false;
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    hub.Clients = mockClients.Object;
    dynamic all = new ExpandoObject();
    all.send = new Action<string>(message =>
    {
        sendCalled = true;
    });
    mockClients.Setup(m => m.All).Returns((ExpandoObject)all);
    hub.Send("foo");
    Assert.True(sendCalled);
}

moq を使用した SignalR の単体テスト

[Fact]
public interface IClientContract
{
    void send(string message);
}
public void HubsAreMockableViaType()
{
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    var all = new Mock<IClientContract>();
    hub.Clients = mockClients.Object;
    all.Setup(m => m.send(It.IsAny<string>())).Verifiable();
    mockClients.Setup(m => m.All).Returns(all.Object);
    hub.Send("foo");
    all.VerifyAll();

JavaScript エラー処理

SignalR 2.0 では、JavaScript エラー処理コールバックはすべて、生文字列ではなく JavaScript エラーオブジェクトを返します。これにより、SignalR は、より豊富な情報をエラーハンドラーにフローできます。エラーのプロパティから内部例外を source 取得できます。

Start.Fail 例外を処理する JavaScript クライアントコード

connection.start().fail(function(e) {
    console.log('The error is: ' + e.message);
});

ASP.NET Identity

新しい ASP.NET メンバーシップシステム

ASP.NET ID は、ASP.NET アプリケーションの新しいメンバーシップシステムです。 ASP.NET ID を使用すると、ユーザー固有のプロファイルデータをアプリケーションデータと簡単に統合できます。 ASP.NET ID を使用すると、アプリケーション内のユーザープロファイルの永続化モデルを選択することもできます。データは、SQL Server データベースまたは別のデータストア (Azure Storage Tables などの NoSQL データストアを含む) に格納できます。詳細については、「Visual Studio 2013 での ASP.NET Web プロジェクトの作成」の「個々のユーザーアカウント」を参照してください。

クレームベースの認証

ASP.NET はクレームベースの認証をサポートするようになりました。ここで、ユーザーの ID は信頼された発行者からのクレームのセットとして表されます。ユーザーは、アプリケーションデータベースに保持されているユーザー名とパスワードを使用するか、ソーシャル ID プロバイダー (Microsoft アカウント、Facebook、Google、Twitter など) を使用するか、Azure Active Directory または Active Directory フェデレーションサービス (AD FS) (ADFS) を介して組織アカウントを使用して認証できます。

Azure Active Directory とWindows Server Active Directoryとの統合

認証に Azure Active Directory または Windows Server Active Directory (AD) を使用する ASP.NET プロジェクトを作成できるようになりました。詳細については、「Visual Studio 2013での ASP.NET Web プロジェクトの作成」の「組織アカウント」を参照してください。

OWIN 統合

ASP.NET 認証は、OWIN ベースのホストで使用できる OWIN ミドルウェアに基づいています。 OWIN の詳細については、次の「Microsoft OWIN コンポーネント」セクションを参照してください。

Microsoft OWIN コンポーネント

Open Web Interface for .NET (OWIN) は、.NET Web サーバーと Web アプリケーションの間の抽象化を定義します。 OWIN は、Web アプリケーションをサーバーから切り離して、Web アプリケーションをホストに依存しないようにします。たとえば、OWIN ベースの Web アプリケーションを IIS でホストしたり、カスタムプロセスで自己ホストしたりできます。

Microsoft OWIN コンポーネント (Katana プロジェクトとも呼ばれます) で導入された変更には、新しいサーバーおよびホストコンポーネント、新しいヘルパーライブラリとミドルウェア、新しい認証ミドルウェアが含まれます。

OWIN と Katana の詳細については、「 OWIN と Katana の新機能」を参照してください。

注: OWIN アプリケーションは IIS クラシックモードでは実行できません。統合モードで実行する必要があります。

注: OWIN アプリケーションは完全信頼で実行する必要があります。

新しいサーバーとホスト

このリリースでは、セルフホストシナリオを可能にするために新しいコンポーネントが追加されました。これらのコンポーネントには、次の NuGet パッケージが含まれます。

Microsoft.Owin.Host.HttpListener。 HttpListener を使用して HTTP 要求をリッスンし、それらを OWIN パイプラインに送る OWIN サーバーを提供します。
Microsoft.Owin.Hosting コンソールアプリケーションや Windows サービスなどのカスタムプロセスで OWIN パイプラインをセルフホストする開発者向けのライブラリを提供します。
OwinHost。カスタムホストアプリケーションを記述しなくても OWIN パイプラインをラップ Microsoft.Owin.Hosting してセルフホストできるスタンドアロンの実行可能ファイルを提供します。

さらに、このパッケージを使用すると、 Microsoft.Owin.Host.SystemWeb ミドルウェアが SystemWeb サーバーにヒントを提供できるようになり、特定の ASP.NET パイプラインステージ中にミドルウェアを呼び出す必要があることを示します。この機能は、ASP.NET パイプラインの早い段階で実行する必要がある認証ミドルウェアに特に役立ちます。

ヘルパーライブラリとミドルウェア

OWIN 仕様の関数定義と型定義のみを使用して OWIN コンポーネントを記述できますが、新しい Microsoft.Owin パッケージでは、よりわかりやすい抽象化セットが提供されます。このパッケージは、以前のいくつかのパッケージ (たとえば、 Owin.ExtensionsOwin.Typesなど) を 1 つの適切に構造化されたオブジェクトモデルに結合し、他の OWIN コンポーネントで簡単に使用できます。実際、Microsoft OWIN コンポーネントの大部分がこのパッケージを使用するようになりました。

Note

OWIN アプリケーションは IIS クラシックモードでは実行できません。統合モードで実行する必要があります。

注意

OWIN アプリケーションは完全信頼で実行する必要があります。

このリリースには、Microsoft.Owin.Diagnostics パッケージも含まれています。これには、実行中の OWIN アプリケーションを検証するためのミドルウェアと、エラーの調査に役立つエラーページミドルウェアが含まれています。

認証コンポーネント

次の認証コンポーネントを使用できます。

Microsoft.Owin.Security.ActiveDirectory。オンプレミスまたはクラウドベースのディレクトリサービスを使用して認証を有効にします。
Microsoft.Owin.Security.Cookies クッキーを 使用した認証を有効にします。このパッケージは以前にという名前 Microsoft.Owin.Security.Formsでした。
Microsoft.Owin.Security.Facebook Facebook の OAuth ベースのサービスを使用した認証を有効にします。
Microsoft.Owin.Security.Google Google の OpenID ベースのサービスを使用した認証を有効にします。
Microsoft.Owin.Security.Jwt JWT トークンを使用した認証を有効にします。
Microsoft.Owin.Security.MicrosoftAccount Microsoft アカウントを使用した認証を有効にします。
Microsoft.Owin.Security.OAuth。 OAuth 承認サーバーと、ベアラートークンを認証するためのミドルウェアを提供します。
Microsoft.Owin.Security.Twitter Twitter の OAuth ベースのサービスを使用した認証を有効にします。

このリリースには Microsoft.Owin.Cors 、クロスオリジン HTTP 要求を処理するためのミドルウェアを含むパッケージも含まれています。

Note

JWT 署名のサポートは、Visual Studio 2013の最終バージョンで削除されました。

Entity Framework 6

Entity Framework 6 の新機能とその他の変更の一覧については、「 Entity Framework のバージョン履歴」を参照してください。

ASP.NET Razor 3

ASP.NET Razor 3 には、次の新機能が含まれています。

タブ編集のサポート。以前は、Visual Studio の [ ドキュメントの書式設定 ] コマンド、自動インデント、および自動書式設定は、[ タブを保持] オプションを使用すると正しく機能しませんでした。この変更により、タブの書式設定用に Razor コードの Visual Studio の書式設定が修正されます。
リンクを生成するときの URL 書き換えルールのサポート。
セキュリティ透過的属性の削除。

Note

これは破壊的変更であり、Razor 3 は MVC4 以前と互換性がありませんが、Razor 2 は MVC5 または MVC5 に対してコンパイルされたアセンブリと互換性がありません。

=======

ASP.NET アプリの中断

ASP.NET App Suspend は、.NET Framework 4.5.1 のゲームを変える機能であり、1 台のコンピューターで多数の ASP.NET サイトをホストするためのユーザーエクスペリエンスと経済モデルを根本的に変更します。詳細については、「 ASP.NET App Suspend – レスポンシブ共有 .NET Web ホスティング」を参照してください。

既知の問題と重大な変更

このセクションでは、Visual Studio 2013の ASP.NET and Web Toolsの既知の問題と破壊的変更について説明します。

NuGet

SLN ファイルを使用する場合、Mono では新しいパッケージの復元が機能しません。今後のnuget.exeダウンロードと NuGet.CommandLine パッケージの更新で修正される予定です。
新しいパッケージの復元は Wix プロジェクトでは機能しません。今後のnuget.exeダウンロードと NuGet.CommandLine パッケージの更新で修正される予定です。

ASP.NET Web API

ODataQueryOptions<T>.ApplyTo(IQueryable)と $expandのサポートが追加されたので、常に $select が返IQueryable<T>されるわけではありません。

の以前の ODataQueryOptions<T> サンプルでは、常に戻り値をから ApplyTo に IQueryable<T>キャストしました。以前にサポートしたクエリオプション ($filter、) ではクエリの形状が変更されないため、$orderby$skip$topこれは以前に機能しました。がサポート$selectされ、からのApplyTo戻り値が必ずしもであるとはIQueryable<T>限$expandりません。
```
// Sample ODataQueryOptions<T> usage from earlier
public IQueryable<Customer> Get(ODataQueryOptions<Customer> query)
{
    IQueryable<customer> result="query.ApplyTo(_customers)" as iqueryable<customer>; return result;
}
```
前のサンプルコードを使用している場合、クライアントがと $expandを送信$selectしない場合は、引き続き動作します。ただし、サポート $select する必要があり $expand 、そのコードをこれに変更する必要がある場合は。
```
public IHttpActionResult Get(ODataQueryOptions<Customer> query)
{
    IQueryable result = query.ApplyTo(_customers);
    return Ok(result, result.GetType());
}
 
private IHttpActionResult Ok(object content, Type type)
{
    Type resultType = typeof(OkNegotiatedContentResult<>).MakeGenericType(type);
    return Activator.CreateInstance(resultType, content, this) as IHttpActionResult;
}
```
バッチ要求中に Request.Url または RequestContext.Url が null である

バッチ処理シナリオでは、Request.Url または RequestContext.Url からアクセスすると、UrlHelper が null になります。

この問題の回避策は、次の例のように、 UrlHelper の新しいインスタンスを作成することです。

UrlHelper の新しいインスタンスの作成
```
if (RequestContext.Url == null)
{
    RequestContext.Url = new UrlHelper(Request);
}
```

ASP.NET MVC

MVC5 と OrgAuth を使用しているときに、AntiForgerToken 検証を実行するビューがある場合、ビューにデータを投稿するときに次のエラーが発生する可能性があります。

エラー:

Server Error in '/' Application.

指定された ClaimsIdentity に型 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier または https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider が存在しなかったクレーム。クレームベースの認証で偽造防止トークンのサポートを有効にするには、構成されたクレームプロバイダーが、生成する ClaimsIdentity インスタンスでこれらの要求の両方を提供していることを確認してください。構成されたクレームプロバイダーが一意の識別子として別の要求の種類を使用する場合は、静的プロパティ AntiForgeryConfig.UniqueClaimTypeIdentifier を設定して構成できます。

回避策:

Global.asax に次の行を追加して修正します。

AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

これは、次のリリースで修正される予定です。
MVC4 アプリを MVC5 にアップグレードした後、ソリューションをビルドして起動します。次のエラーが表示されます。

[A]System.Web.WebPages.Razor.Configuration.HostSection を [B]System.Web.WebPages.Razor.Configuration.HostSection にキャストすることはできません。型 A は、"System.Web.WebPages.Razor、Version=2.0.0.0、Culture=neutral、PublicKeyToken=31bf3856ad364e35' から発生します。コンテキスト 'Default' の場所 'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll' です。型 B は、'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' をコンテキスト 'Default' の場所 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6d05bbd0\e8b5908e\assembly\dl3\c9cbca63\f8910382_6273ce01\System.Web.WebPages.Razor.dll' に由来します。

上記のエラーを修正するには、プロジェクト 内のすべての Web.config ファイル (Views フォルダー内のものを含む) を開き、次の操作を行います。
1. "System.Web.Mvc" のバージョン "4.0.0.0" のすべての出現箇所を "5.0.0.0" に更新します。
2. "System.Web.Helpers"、"System.Web.WebPages"、"System.Web.WebPages.Razor" のバージョン "2.0.0.0" のすべての出現箇所を "3.0.0.0" に更新します
  
  たとえば、上記の変更を行った後、アセンブリバインドは次のようになります。
```
<dependentAssembly>
  <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
```
  MVC 4 プロジェクトを MVC 5 にアップグレードする方法については、「 ASP.NET MVC 4 と Web API プロジェクトを MVC 5 と Web API 2 ASP.NET にアップグレードする方法」を参照してください。
jQuery Unobtrusive Validation でクライアント側の検証を使用すると、type='number' の HTML 入力要素に対して検証メッセージが正しくない場合があります。有効な数値が必要であることを示す正しいメッセージではなく、無効な数値が入力されると、必須値 ("The Age field is required") の検証エラーが表示されます。

この問題は、通常、Create ビューと Edit ビューの整数プロパティを持つモデルのスキャフォールディングされたコードで見られます。

この問題を回避するには、エディターヘルパーを次のように変更します。

@Html.EditorFor(person => person.Age)

移動先:

@Html.TextBoxFor(person => person.Age)
ASP.NET MVC 5 では部分信頼がサポートされなくなりました。 MVC または WebAPI バイナリにリンクしているプロジェクトでは、 SecurityTransparent 属性と AllowPartiallyTrustedCallers 属性を削除する必要があります。これらの属性を削除すると、次のようなコンパイラエラーが排除されます。

Attempt by security transparent method ‘MyComponent' to access security critical type 'System.Web.Mvc.MvcHtmlString' failed. Assembly 'PagedList.Mvc, Version=4.3.0.0, Culture=neutral, PublicKeyToken=abbb863e9397c5e1' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

この副作用として、同じアプリケーションで 4.0 アセンブリと 5.0 アセンブリを使用できないことに注意してください。それらのすべてを 5.0 に更新する必要があります。

Web サイトがイントラネットゾーンでホストされている間に、Facebook 承認を含む SPA テンプレートが IE で不安定になる可能性がある

SPA テンプレートは、Facebook で外部ログインを提供します。テンプレートで作成されたプロジェクトがローカルで実行されている場合、サインインすると IE がクラッシュする可能性があります。

解決方法:

インターネットゾーンで Web サイトをホストする。または
IE 以外のブラウザーでシナリオをテストします。

Web フォームのスキャフォールディング

Web Formsスキャフォールディングは VS2013 から削除されており、Visual Studio の今後の更新で使用できるようになります。ただし、MVC 依存関係を追加し、MVC のスキャフォールディングを生成することで、Web Forms プロジェクト内でスキャフォールディングを引き続き使用できます。プロジェクトには、Web Formsと MVC の組み合わせが含まれます。

Web Forms プロジェクトに MVC を追加するには、新しいスキャフォールディングされた項目を追加し、[MVC 5 依存関係] を選択します。スクリプトなど、すべてのコンテンツファイルが必要かどうかに応じて、[最小] または [完全] を選択します。次に、MVC のスキャフォールディングされた項目を追加します。これにより、プロジェクトにビューとコントローラーが作成されます。

MVC と Web API スキャフォールディング - HTTP 404、見つかりませんエラー

スキャフォールディングされた項目をプロジェクトに追加するときにエラーが発生した場合、プロジェクトが不整合な状態のままになる可能性があります。スキャフォールディングに加えられた変更の一部はロールバックされますが、インストールされている NuGet パッケージなどの他の変更はロールバックされません。ルーティング構成の変更がロールバックされると、ユーザーはスキャフォールディングされた項目に移動するときに HTTP 404 エラーを受け取ります。

対応策 :

MVC のこのエラーを修正するには、新しいスキャフォールディングされた項目を追加し、MVC 5 依存関係 (最小または完全) を選択します。このプロセスにより、必要なすべての変更がプロジェクトに追加されます。

Web API のこのエラーを修正するには:

WebApiConfig クラスをプロジェクトに追加します。

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }
}

Public Module WebApiConfig
    Public Sub Register(ByVal config As HttpConfiguration)
        config.MapHttpAttributeRoutes()
        config.Routes.MapHttpRoute(
          name:="DefaultApi",
          routeTemplate:="api/{controller}/{id}",
          defaults:=New With {.id = RouteParameter.Optional}
        )
    End Sub
End Module

Global.asax の Application_Start メソッドで WebApiConfig.Register を次のように構成します。

public class WebApiApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        GlobalConfiguration.Configure(WebApiConfig.Register);    
    }
}

Public Class WebApiApplication
     Inherits System.Web.HttpApplication
 
     Sub Application_Start()     
       GlobalConfiguration.Configure(AddressOf WebApiConfig.Register)       
     End Sub
End Class

Visual Studio 2013 の ASP.NET と Web ツールのリリース ノート

内容

Visual Studio 2013の ASP.NET and Web Toolsの新機能

インストールに関する注意事項

ドキュメント

ソフトウェア要件

Visual Studio 2013の ASP.NET and Web Toolsの新機能

1 つの ASP.NET

新しい Web プロジェクト エクスペリエンス

ASP.NET スキャフォールディング

ブラウザー リンク – ブラウザーと Visual Studio の間の SignalR チャネル

Visual Studio Web エディターの機能強化

Visual Studio でのAzure App Service Web Appsサポート

Web 発行の機能強化

NuGet 2.7

ASP.NET Web Forms

1 つの ASP.NET

ASP.NET Identity

ブートストラップ

ASP.NET MVC 5

1 つの ASP.NET

ASP.NET Identity

ブートストラップ

認証フィルター

フィルターのオーバーライド

属性ルーティング

ASP.NET Web API 2

属性ルーティング

OAuth 2.0

OData の機能強化

バッチ処理の要求

ポータブル ASP.NET Web API クライアント

テスト容易性の向上

IHttpActionResult

HttpRequestContext

CORS

認証フィルター

フィルターのオーバーライド

OWIN 統合

ASP.NET SignalR 2.0

OWIN 上に構築

MapHubs と MapConnection が MapSignalR になりました

クロスドメイン サポート

MonoTouch と MonoDroid を使用した iOS と Android のサポート

新しいSelf-Host パッケージ

下位互換性のあるサーバーのサポート

.NET 4.0 のサーバーサポートを削除しました

クライアントとグループの一覧にメッセージを送信する

特定のユーザーにメッセージを送信する

エラー処理のサポートの向上

ハブの簡単な単体テスト

JavaScript エラー処理

ASP.NET Identity

新しい ASP.NET メンバーシップ システム

クレーム ベースの認証

Azure Active Directory とWindows Server Active Directoryとの統合

OWIN 統合

Microsoft OWIN コンポーネント

新しいサーバーとホスト

ヘルパー ライブラリとミドルウェア

認証コンポーネント

Entity Framework 6

ASP.NET Razor 3

ASP.NET アプリの中断

既知の問題と重大な変更

NuGet

ASP.NET Web API

ASP.NET MVC

Web サイトがイントラネット ゾーンでホストされている間に、Facebook 承認を含む SPA テンプレートが IE で不安定になる可能性がある

Web フォームのスキャフォールディング

MVC と Web API スキャフォールディング - HTTP 404、見つかりませんエラー

フィードバック

フィードバック

その他のリソース

Visual Studio 2013 の ASP.NET と Web ツールのリリースノート

新しい Web プロジェクトエクスペリエンス

ブラウザーリンク – ブラウザーと Visual Studio の間の SignalR チャネル

クロスドメインサポート

新しい ASP.NET メンバーシップシステム

クレームベースの認証

ヘルパーライブラリとミドルウェア

Web サイトがイントラネットゾーンでホストされている間に、Facebook 承認を含む SPA テンプレートが IE で不安定になる可能性がある