私は組織内でJQueryを宣伝することにかなり成功しています。それ自体に小さな偉業はありません。ただし、アプリの一部にするためにここで蹴られているアイデアの1つは、ASP.netサーバー側のコントロールを作成することです。（当面の間、WebFormsを使い続ける予定です。）
いくつかのスクリプトタグがその仕事をするとき、それはやり過ぎのように見えるので、私はこのアプローチについてあまりワイルドではありません。Webで記事を見つけましたが、関連するコードの量は実際には正当化されていないようです。ただし、サーバーコントロールで発生するスクリプトのキャッシュまたは生成にはいくつかの利点があると聞いています。
私の質問：
Microsoftは（Nokiaと共に）jQueryを「主流化」しており、将来のバージョンのVisualStudioと統合する予定です。彼らが公式にそれをどのように使用するかを調べて、今すぐセットアップを調整し、将来的には「公式のMSjQuery」への移行を容易にすることができます。
仰るとおりです。JQueryスクリプトの場所を追加するためのコントロールを作成し、オーバーヘッドをかけて作成する価値はありません。
より良い解決策は、ページにロードするために必要なすべてのリンクを含む1つの.jsファイルを用意することです。それがチームの問題である場合、それは.jsリンクの割り当てを排除する可能性があります。
JavaScriptをリンクするだけのカスタムコントロールを作成することを許すのは、何らかの理由でJavaScriptをサーバーにコピーせず、.dllに埋め込みたい場合だけです。ただし、ファイルを.dllに埋め込む場合は、完全なスクリプトファイルとしてヘッダーに登録する必要があるため、ページにJavaScriptが表示されるのを防ぐことはできません。
JavaScript参照を挿入するためにサーバーコントロールを使用する理由の1つは、どのJavaScriptファイルをページに追加するかを制御する方が簡単だからです。jQueryコアに加えて、jQueryUIと他のいくつかのプラグインを使用するシナリオを想像してみてください。このコントロールのコーディング方法に応じて、開発者は、必要な特定のスクリプトを気にすることなく、特定のページに必要な機能を簡単に選択できます。このアプローチにより、アプリケーションをセグメント化するための多くの柔軟性が得られます。たとえば、サーバーコントロールは、マスターページ、子ページ、ユーザーコントロール、または別のサーバーコントロールによって使用される場合があります。マスターページが1つのjQueryライブラリの要件を登録しているが、子ページまたはユーザーコントロールの1つが追加のライブラリを必要とする場合、統合APIを使用するとこれが簡単になります。個人的には、
肝心なのは、各開発者が車輪の再発明を行うか、アプリ全体で統一性を強制する一般的で使いやすいAPIを使用することをどれだけ望んでいるかです。
ASP.net AJAX + JQuery を使用するサンプル アプリを含むScott Hanselman のブログ投稿を見つけました。シンプルなアプリですが、script タグ付きのすべての JavaScript が含まれています。サーバーコントロールを使用してスクリプトを提供するというアドバイスはありません。