問題タブ [assemblies]

今日、 hostingEnvironmentタグのshadowCopyBinAssembliesオプションに出くわしました。

どうやらこの属性は、Bin ディレクトリ内のアプリケーションのアセンブリがアプリケーションの ASP.NET 一時ファイル ディレクトリにシャドウ コピーされるかどうかを示す、 web.config (system.web) 構成のブール オプションです。

同僚がこの設定を有効にする必要があったのは、彼の開発マシンで (のみ) Web ブラウザーで ASP.NET エラーが頻繁に発生したためです。

Visual Studio 2008 で特定の Web プロジェクトをコンパイルし、ページを開きます。

それでは私の質問: この設定を本番環境で保持できますか、それともパフォーマンスに悪影響を及ぼしたり、他の問題を引き起こす可能性がありますか?

ありがとう！

GAC で同じアセンブリを使用する複数の Web サイトを含むフォルダーがあります。各 Web サイトには、共通アセンブリを参照する独自の「カスタム」アセンブリもいくつか含まれています。

このフォルダーには web.config があり、<system.web>/<compilation>/<assemblies>要素に読み込むアセンブリなど、サイトの共通設定を定義しています。

私ができるようにしたいのは、<runtime>/<assemblyBinding>要求を古い「カスタム」アセンブリから GAC にインストールされた新しいものにリダイレクトするセクションを追加することです。(残念ながら、他のサイトに影響するため、machine.config または GAC リダイレクト ポリシーの使用はオプションではありません。)

<assemblyBinding>Web サイト自体の web.config または machine.config にない限り、このセクションは無視されるようです。

私はすでに<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">問題に遭遇したので、そうではないことを知っています。

これが起こるべきことなのか、それとも私が何かを見逃しているのか、誰かが知っていますか?

型 'x' は、参照されていないアセンブリで定義されています。アセンブリ 'abc123' への参照を追加する必要があります。

アセンブリ 'abc123' を参照する .NET 2.0 Web アプリケーションがあります。アセンブリは GAC に存在し、それが正しい (同じ) バージョンであることを確認しました。アプリケーションの残りの部分には、1 つの .aspx ページを除いて問題はありません。問題のページには、ユーザー コントロールを「フィールド」の 1 つとして表示するリピーターがあります。タイプ y のリストをリピーターにバインドすると、次に示すように、タイプ x (y のプロパティ) のリストをユーザー コントロールに渡します。

ユーザー コントロールのプロパティ セットで、タイプ x のリストをユーザー コントロールのグリッドビューにバインドします。

注意すべき奇妙な点の 1 つは、このレポートは開発用 PC では正常に機能しますが、展開するとどのサーバーでも機能しないことです。私のPCはWindows XP、IIS6、VS2005です。サーバーは Windows Server 2003、IIS6 です。

十分に説明したことを願っています。あなたが提供できる洞察を前もって感謝します。

タイトルが示すように、vbscript を使用して GAC アセンブリ ファイルを削除するにはどうすればよいですか?

私たちの処理ソフトウェアでは、外部アセンブリのあるバージョンから新しいバージョンに移行しています。アセンブリが実行する全体的なタスクは同じですが、API は根本的に異なり、下位互換性は維持されていません。API は、一致する新しい API または古い API で実行されている外部ステーションからデータを抽出する役割を果たします (後方互換性もありません)。外部アセンブリまたは外部ステーションのソフトウェアを制御することはできません。外部アセンブリは強力に署名されておらず、アセンブリ内のモジュールは両方のバージョンで同じ名前になっています。

処理ソフトウェアの 2 つのバージョンを維持する代わりに、それを動的に進化させ、接続する外部ステーションに応じて、外部アセンブリの古いバージョンまたは新しいバージョンのいずれかを使用するようにします。外部ステーションが新しいバージョンをサポートしているかどうかを判断できるため、「バージョン」の選択は多かれ少なかれ明確になる可能性があります。

したがって、2 つのバージョンの外部アセンブリ ComLib.dll がセットアップされます。同じアセンブリ/プロジェクトから 2 つのバージョンを参照できますか?また、タイプなどを決定するときに 2 つのアセンブリをどのように区別できますか?

上記が単一のアセンブリ/プロジェクト内から実行できないと仮定すると、外部アセンブリの各バージョンに 1 つずつ、バージョン固有の「アダプター」アセンブリを実装できます (これには十分なインターフェイスと抽象化が既に用意されていると思います)。実行時のタイプ/バージョンの混乱 (アセンブリの解決/読み込みなど) を避けるために、注意すべき注意事項や特定の設定はありますか? このセットアップの .NET ランタイムには十分な「サイド バイ サイド」サポートがありますか?

更新: 物事をより面白くするために、この質問にさらにひねりが加えられています。外部アセンブリが追加のアセンブリを読み込み、外部構成ファイルを使用しているようです。異なるバージョンには異なる構成ファイルと異なる追加アセンブリが必要なため、各バージョンは、バージョンに一致する追加アセンブリを何らかの方法でロードする必要があります。

私たちが望むのは、各バージョンのアセンブリを、構成ファイルと追加のアセンブリを含む別のフォルダーに「ルート」でロードすることです。これは、標準のアセンブリ リゾルバー/ローダーでも可能ですか?それとも、「ルート」フォルダーを強制するために、何らかの魔法をかけてアセンブリを手動で (別の AppDomains で?) ロードする必要がありますか?

.NET Windows サービスをインストールする VS2008 インストーラー プロジェクトがあります。サービスの依存関係の 1 つは、サテライト アセンブリの形式でローカライズされたリソースを持つ .NET アセンブリです。何らかの理由で、インストーラーがサテライト アセンブリをパッケージ化またはインストールしていないため、サービスが開始されません。何か案は？

外部 DLL を参照する Web アプリケーションがあります (これを productA.dll と呼びましょう)

GAC、web.config、および参照を更新し、バージョンを確認しましたが、すべてが一貫しているように見えます。

しかし、アプリケーションを実行すると、使用するメソッドをproductA.dll呼び出すことができず、the specified module cannot be foundエラーが発生します。

Windowsアプリケーションを作成してみましたが、問題なく使用できますproductA.dll。

Web アプリケーションの実行時に出力ウィンドウを観察すると、productA.dllシンボルが読み込まれていないことに気付きました。それがモジュールが見つからない理由だと思います。

問題は、シンボルがロードされないのはなぜですか?

解決策または診断技術に関するヒントをいただければ幸いです。

2つの違いは何ですか？

.NET では、AssemblyInfo を変更してアセンブリを再構築することなく、アセンブリのマニフェストを変更できるツールまたはその他の方法はありますか?

GACを介してプロジェクト ソリューションから他のアセンブリを参照しているプロジェクトからアセンブリを参照しているサードパーティのワークフロー ソフトウェア (Captaris Teamplate) があります。

アプリケーションが実行されると、Captaris Teamplate メソッドを呼び出してワークフロー プロセスを作成し、GAC のプロジェクト アセンブリを使用してデータをデータベースに保存します。

問題は、プロジェクトをコンパイルし、GAC からアセンブリを削除してそれらを新しいバージョンに置き換えるときですが、プロジェクト全体を実行すると、Captaris Teamplate がエラーをスローします。

例外の種類: System.IO.FileNotFoundException
メッセージ: ファイルまたはアセンブリ名 VBAssembly、またはその依存関係の 1 つが見つかりませんでした。
FileName: VBAssembly
FusionLog: === Pre-bind state information ===
LOG: DisplayName = VBAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

つまり、アセンブリ DLL ファイルの名前はわかりません。探しているバージョンも見つけようとしています。このような問題のトラブルシューティングは、暗闇での撮影のようなもので、ASP.NET 一時ファイル フォルダー、プロジェクト フォルダー、および Web サイト フォルダー (inetpub) に保持されている古いアセンブリの削除、再起動など、エラーのテスト、エラーの取得、他の古いアセンブリの検索など。

だから私の質問は：

1. アセンブリの名前や欠落しているバージョンなど、この例外に関する詳細情報を抽出できる手法はありますか?
2. コンパイル時にシステムから古いアセンブリ バージョンをすべてクリーンアップする簡単な方法はありますか?
3. このDLL Hellおよび/または Captaris Teamplateに対処するための他の提案はありますか?

Captaris Workflow 5.0 を搭載した Visual Studio 2003 で ASP.NET バージョン 1.1 を使用しています。