問題タブ [assembly-resolution]

NUnit を使用して 2 つのアセンブリでテストを実行する MSBuild スクリプトがあります。これらは .NET Framework 3.5 上にあり、長い間完全に機能していました。

コマンドラインは次のとおりです：（実際のパスと名前は簡略化されています）

VS2010 にアップグレードし、2 つのテスト アセンブリのターゲットを .NET 4.0 にしました。また、NUnit 2.5.4 にアップグレードしました。

次のようにして、単一のアセンブリを単体テストできます。

tests1.dll または tests2.dll で問題なく動作します。

以前のように両方を指定しようとすると、失敗するようになりました。

エラーは次のとおりです。

fuslogvw を調べたところ、tests1\bin\debug および nunit-console フォルダーで tests2 が検索されていることがわかります。コマンドラインで指定されていても、tests2\bin\debug は検索されません。

どうしたの？

32 ビット DLL である Microsoft.TeamFoundation.VersionControl.Client.dll を参照するツールを作成しました。

ツールを 64 ビット Windows でビルドするときは、Visual Studio を X86 をターゲットにするように設定して、強制的に 32 ビット ビルドにします。

All-CPU の代わりに X86 をターゲットにすると、ツールを直接呼び出す限り (たとえば、コマンド ラインで「myTool.exe」と入力する) 、BadImageFormatException が発生しなくなります。ただし、ツールを呼び出すバッチ ファイルを実行すると、依然として例外が発生します。これは、バッチ ファイルが 32 ビット コマンド プロンプト (%WINDIR%\SysWOW64\cmd.exe) で実行されている場合でも発生します。

この作業を行うために他に何ができますか?

MVC フレームワーク内のインデクサーを使用して ID を生成する際に問題があるようです (詳細はこちらhttp://aspnet.codeplex.com/WorkItem/View.aspx?WorkItemId=5495 )。

これを修正するために、ソースをダウンロードして修正し、使用してみましたが、ソースのダウンロードにサインインするための snk ファイルがないため、何を試しても地獄を参照することになります。

ソースを再コンパイルせずにこの問題を修正したり、変更したコピーを機能させる方法はありますか?

ありがとう！

特定のバージョンのベンダー DLL に依存しない .NET コンポーネントを開発した場合、.NET アセンブリである My3rdPartyComponent.dll で動作したとしますが、どのバージョンでもかまいません。

このコンポーネントで見つかったクラスのいくつかのインスタンスは、私のコンポーネントに渡す必要があります。開発者は私のコンポーネント dll を参照しますが、ソース コードにはアクセスできません。

基本的に、ユーザーが 3rdPartyComponent.MyClass のインスタンスをコンポーネント関数に渡すように要求できるようにしたいのですが、それがサードパーティの dll のバージョン 1.1、2.2、2.23.980 などであるかどうかは気にしません。

コンポーネントに渡したいパラメータを入力しながらこれを行う方法はありますか? オブジェクトを参照として使用したくありません。

私のコンポーネント プロジェクトでは、アセンブリ参照で SpecificVersion=True を指定できました。これで私の問題は解決しますか?それとも、私が見ていない他の「dll 地獄」の問題に対処する必要がありますか?

私の Web アプリケーションではNHibernate.dllを使用しています。これは、次のアセンブリに依存します。

「Antlr3.Runtime、バージョン = 3.1.0.39271、文化 = ニュートラル、PublicKeyToken = 3a9cab8f8d22bfb7」

同じプロジェクトで、別の要件のためにAntlr3.StringTemplate.dllを導入する必要があります。上記のアセンブリの別のバージョンに依存しています。

NHibernateを満たすAntlr3.Runtime.dllのバージョンを使用すると、Antlr3.StringTemplateが不平を言い始め、逆もまた同様です。

このような状況を解決するにはどうすればよいですか？

継続的インテグレーションのために現在のシステムと統合するには、NUnit を使用して (UI 以外の) Silverlight コードをテストします。これを行うことは、ビジュアル要素や DependencyObject などの Silverlight 固有のクラスを実際に使用しない限り、通常は正常に動作する完全な .NET フレームワークのランタイムを使用して Silverlight コードを実行することを意味します。ただし、Silverlight の Reactive Extensions などの一部の汎用ライブラリも、Silverlight ランタイム (agcore) に依存しているようです。

ランタイムをだまして、Silverlight ランタイムの依存関係をそれらのモック バージョンにリダイレクトさせる方法はありますか? または、Reactive Extensions などのアセンブリ参照を実行時にまとめてリダイレクトし (単体テストのみを実行する場合)、代わりに完全な .NET フレームワークの対応する対応物をロードすることは可能ですか?

AppDomainとそのAssemblyResolveイベントをクラス内にラップして、アセンブリ解決プロセスをカスタマイズしようとしています。私の簡略化されたバージョンClassLoaderは以下のとおりです。私が抱えている問題は、イベントが発生したときに、以前に作成したものではなく、AssemblyResolveの新しいインスタンスを取得したように見えることです。ClassLoader

このコードを実行すると、Domain_AssemblyResolve イベント ハンドラーで FooProperty が初期化されず、ClassLoader インスタンスのハッシュ コードが "c" とは異なります。

何が起こっているのですか？またはいくつかの回避策？

ありがとう！

現在、アセンブリを 1 つのアプリケーション ファイルに埋め込む 2 つの方法を知っています。ILMerge と ResolveAssembly イベントの使用です。

誰かが他のものよりも成功したかどうか知りたい.

これらのいずれか (パフォーマンス、セキュリティなど) を使用することによる欠点はありますか?

私の観点からは、すべての「プライベート」アセンブリを常にアプリケーションにマージする必要があるように見えます。これは、アプリケーションを全体として考えると、この方法の方がクリーンであるためです。

何かご意見は？

次のシナリオは、IIS を使用して ASP.NET アプリケーションを操作する Windows サービスと Web の両方で発生します。デプロイ後に動作を変更したいアプリケーションがあります。そのために、アプリケーション プロセス (iis ワーカー プロセス) を強制終了するか、Windows サービスを停止します。1 つ以上の dll の名前を変更して、拡張子oldを付けます。次に、元の dll を置き換えたい dll を配置します。アプリケーションを起動すると、新しい dll ではなく元の dll が使用されます (拡張子がoldの dll )。誰かがこのなぞなぞを解いてくれたら嬉しいです。成功するためにクリアしなければならないキャッシュはありますか？

それがあなたを助けるなら、私は.Net Framework 2.0を使用しています。

MEFが、アプリケーションフレームワークがとるべき適切な方向であるかどうかを判断しようとしています。MEFを読んだところ、私たちのフレームワークは「正確に」適合していないようですが、専門家が私を導いてくれるかどうかを確認します。

私たちのフレームワークでは、1つのコアWebサイトと依存アセンブリを1つの場所にデプロイでき（修正または機能はすべてのクライアントに伝達されます）、コアWebサイトに「マージ」して必要に応じて拡張するクライアントWebサイトがあります。

現在IISでは、各クライアントサイトは、独自のAppDomainで実行される独自のアプリケーションです。ただし、すべてのアプリケーションには、「コアWebサイト」を指す同じ物理パスがあります。

したがって、ファイル構造は...

• / CoreSite
  • / bin（コアサイトと依存関係のdllを含む）
  • / [コアサイトフォルダ]（例：モデル、ビュー、コントローラ、コンテンツなど）
  • /クライアント
    • / _Assemblies（すべてのクライアントアセンブリを含む-数百のクライアント）
    • / Client1
      • / [クライアントサイトフォルダー]（モデル、ビュー、コントローラーなど）
    • / Client2
      • / [クライアントサイトフォルダー]（モデル、ビュー、コントローラーなど）
    • / ClientN

ご想像のとおり、アセンブリのロードが問題です。いくつかの理由から、すべてのクライアントアセンブリをルート/binフォルダーに配置したくありませんでした。まず、各クライアントサイトに他のすべてのクライアントアセンブリをロードさせたくありませんでした。次に、別のクライアントのアセンブリが/ binフォルダーで更新されたという理由だけで、すべてのサイトのAppDomainがリサイクルされることを望んでいませんでした。

これをasp.net1.1で機能させるために、http： //www.hanselman.com/blog/MovingTheCodeBehindAssembliesDLLsToADifferentFolderThanBINWithASPNET11.aspxに従い、web.configに<probing privatePath = "bin; Clients /_Assemblies"/>要素を追加しました。クライアントサイトの各ビューに<％@ Assembly Name = "ClientN"％>ディレクティブを使用します。克服しなければならなかった他の唯一の問題はクライアントアセンブリの更新でしたが、asp.net1.1は/Clients/_Assembliesディレクトリ内のアセンブリをロックしていました。単に追加しました：

そしてビオラ、すべてが魅力のように機能しているように見えました。残念ながら、asp.net 4.0では、AppDomain.CurrentDomain.SetShadowCopyPath（）は非推奨になりました。そのため、バイト配列からアセンブリを自分でロードしようとしたり、AssemblyResolveイベントを使用したり、[アセンブリ：PreApplicationStartMethod（typeof（MvcApplication）、 "PreApplicationStart"）]をいじったり、Systemを使用したりしました。 Replication.BuildManager.AddReferencedAssemblyは役に立ちません。

次のいずれかを取得します。-アセンブリがロードされていない-アセンブリが多すぎる、または-アセンブリがロードされているが、ビューがレンダリングされているときに、名前空間が<％@ Assembly Name="ClientN"から配置されているはずの<Import/>ディレクティブに遭遇した場合％>は単に失敗します。

だから私は、MEFが進むべき道であるかどうかについてのメカニズムやアドバイスを使った提案を求めています。私の1000フィートの見方では、MEFは、複数のコンポーネントがプラグインされている1つのアプリケーション（またはWebサイト）を対象としています。私たちの状況では、アプリケーション/アプリドメインごとに一度に1つのコンポーネントしかプラグインできないため、メジャーコードリファクタリングを開始することを躊躇しています（そう思われます）。また、必要以上のことを実行しているようです（アセンブリをロードして、asp.netに認識させるだけで、すべてのコードが機能します）。

アドバイスをいただければ幸いです。