.NETアセンブリ読み取り専用プロパティを変更する方法?

アプリケーションの実行時にAssembly.Locationプロパティを変更したい。リソースから.NETアセンブリをロードしています。ロードされたアセンブリ(メモリからロードされた)には、このフィールドが空になっており、アプリケーションの機能が分かりません。

私はソースコードを制御できません。私は自分のコードでこのバグを回避する方法を知っていますが、そうではありません。 Assembly.Locationを使用して空の文字列を取得すると、問題が発生します。

http://msdn.microsoft.com/en-us/ /library/system.reflection.assembly.location.aspx

それは読んだだけです。それを行うための低レベルの方法はありますか?何か案は?

私のアプリケーションは、リソースに埋め込まれたアプリケーションのローダーなので、それに依存しません。任意のアセンブリをメモリから読み込み、それらの読み込まれたアセンブリのAssembly.Locationフィールドを確認してください、空白になります。彼らはメモリからロードされているので、場所を持っていませんが、.NET内部の変更やその他の方法のいずれかで変更したいと思います。

圧縮されたアセンブリをディスクに解凍することはできません。あなたがそれを達成する方法を知っていれば、大きな問題の危険は気にしません。

2
私の更新された答えを見てください。
追加された 著者 Equality In Tech,
私の更新された答えを見てください。
追加された 著者 Equality In Tech,
私の更新された答えを見てください。
追加された 著者 Equality In Tech,
私は近い投票に同意しない。この質問はあまりローカライズされていません...現在のところ、一般的な文脈であり、十分に文書化されていない図書館開発者の本当の懸念に対処しています。この質問にはメリットがあると私は信じている。
追加された 著者 Equality In Tech,
私は近い投票に同意しない。この質問はあまりローカライズされていません...現在のところ、一般的な文脈であり、十分に文書化されていない図書館開発者の本当の懸念に対処しています。この質問にはメリットがあると私は信じている。
追加された 著者 Equality In Tech,
私は近い投票に同意しない。この質問はあまりローカライズされていません...現在のところ、一般的な文脈であり、十分に文書化されていない図書館開発者の本当の懸念に対処しています。この質問にはメリットがあると私は信じている。
追加された 著者 Equality In Tech,
@tcaswell - 私はこのブログの投稿のどこにでもこの質問へのリンクを見つけることができません。
追加された 著者 Equality In Tech,
@tcaswell - 私はこのブログの投稿のどこにでもこの質問へのリンクを見つけることができません。
追加された 著者 Equality In Tech,
@tcaswell - 私はこのブログの投稿のどこにでもこの質問へのリンクを見つけることができません。
追加された 著者 Equality In Tech,
まあ、機能が壊れますか?これらのアセンブリはあなたがコントロールしていますか?そうであれば、このプロパティに依存しないように修正できるかどうかを調べる必要があります。
追加された 著者 Jon Skeet,
まあ、機能が壊れますか?これらのアセンブリはあなたがコントロールしていますか?そうであれば、このプロパティに依存しないように修正できるかどうかを調べる必要があります。
追加された 著者 Jon Skeet,
なぜこれをしようとしていますか?より多くの文脈を与えてください - より良いアプローチかもしれません。
追加された 著者 Jon Skeet,
このすべてはあなたの質問にあったはずの文脈です。
追加された 著者 Jon Skeet,
このすべてはあなたの質問にあったはずの文脈です。
追加された 著者 Jon Skeet,
このすべてはあなたの質問にあったはずの文脈です。
追加された 著者 Jon Skeet,
@BartoszWójcik再び質問が懇願する - なぜ?ディレクトリをアセンブリにマッピングするだけでよいのであれば、アプリケーション内から管理するのはなぜですか?アセンブリ名/パスのマッピングを維持することができます。
追加された 著者 James,
@BartoszWójcik再び質問が懇願する - なぜ?ディレクトリをアセンブリにマッピングするだけでよいのであれば、アプリケーション内から管理するのはなぜですか?アセンブリ名/パスのマッピングを維持することができます。
追加された 著者 James,
@BartoszWójcikアセンブリ自体に依存するものではありませんが、アセンブリの配置場所の場所に依存します。なぜなら、ロケーション。たぶん私はあなたの質問を誤解しているかもしれませんが、あなたがしていることの背後にある理由を十分に理解していません。
追加された 著者 James,
@BartoszWójcikアセンブリ自体に依存するものではありませんが、アセンブリの配置場所の場所に依存します。なぜなら、ロケーション。たぶん私はあなたの質問を誤解しているかもしれませんが、あなたがしていることの背後にある理由を十分に理解していません。
追加された 著者 James,
@BartoszWójcikアセンブリ自体に依存するものではありませんが、アセンブリの配置場所の場所に依存します。なぜなら、ロケーション。たぶん私はあなたの質問を誤解しているかもしれませんが、あなたがしていることの背後にある理由を十分に理解していません。
追加された 著者 James,
質問は本当に意味をなさないが、アプリケーションはアセンブリの場所に依存しますが、アセンブリは埋め込まれているため、ディスク上の場所はありません。
追加された 著者 James,
質問は本当に意味をなさないが、アプリケーションはアセンブリの場所に依存しますが、アセンブリは埋め込まれているため、ディスク上の場所はありません。
追加された 著者 James,
質問は本当に意味をなさないが、アプリケーションはアセンブリの場所に依存しますが、アセンブリは埋め込まれているため、ディスク上の場所はありません。
追加された 著者 James,
これは「閉鎖戦争」のブログ記事からリンクされており、本質的に同じことを求めている+11の質問へのリンクがあることを考えると、「性格によるダウンボート」の様相ここに。
追加された 著者 tacaswell,
これは「閉鎖戦争」のブログ記事からリンクされており、本質的に同じことを求めている+11の質問へのリンクがあることを考えると、「性格によるダウンボート」の様相ここに。
追加された 著者 tacaswell,
これは「閉鎖戦争」のブログ記事からリンクされており、本質的に同じことを求めている+11の質問へのリンクがあることを考えると、「性格によるダウンボート」の様相ここに。
追加された 著者 tacaswell,
私はリソースからロードされた圧縮されたアセンブリに精通していないので、このアイデアは非スターターである可能性があります:おそらくアセンブリをILDASMにフィードし、中間テキストを変更した後にILASMでラウンドトリップできるでしょうか?私はこれがはるかに聞こえると知っていますが、これは実際にアセンブリの厳密な名前署名を変更するための推奨される方法の1つです。
追加された 著者 RenniePet,
私はリソースからロードされた圧縮されたアセンブリに精通していないので、このアイデアは非スターターである可能性があります:おそらくアセンブリをILDASMにフィードし、中間テキストを変更した後にILASMでラウンドトリップできるでしょうか?私はこれがはるかに聞こえると知っていますが、これは実際にアセンブリの厳密な名前署名を変更するための推奨される方法の1つです。
追加された 著者 RenniePet,
私はリソースからロードされた圧縮されたアセンブリに精通していないので、このアイデアは非スターターである可能性があります:おそらくアセンブリをILDASMにフィードし、中間テキストを変更した後にILASMでラウンドトリップできるでしょうか?私はこれがはるかに聞こえると知っていますが、これは実際にアセンブリの厳密な名前署名を変更するための推奨される方法の1つです。
追加された 著者 RenniePet,
私がそれを望んでいるから、あなたが解決策を知らないなら、私にそれをしないように納得させてください。あなたが難しい問題を解決できない場合、プログラマーになることのポイントは何ですか?
追加された 著者 Bartosz Wójcik,
@Jamesはい、彼らはメモリからロードされているので、彼らはまだ、私はそれを変更したいので、場所を持っていない.NETの内部の変更や他の方法。
追加された 著者 Bartosz Wójcik,
私のアプリケーションは、リソースに埋め込まれたアプリケーションのためのローダーなので、依存しません。メモリから任意のアセンブリを読み込み、読み込まれたアセンブリのAssembly.Locationフィールドを確認すると、空白になります。
追加された 著者 Bartosz Wójcik,
私のアプリケーションは、リソースに埋め込まれたアプリケーションのためのローダーなので、依存しません。メモリから任意のアセンブリを読み込み、読み込まれたアセンブリのAssembly.Locationフィールドを確認すると、空白になります。
追加された 著者 Bartosz Wójcik,
私のアプリケーションは、リソースに埋め込まれたアプリケーションのためのローダーなので、依存しません。メモリから任意のアセンブリを読み込み、読み込まれたアセンブリのAssembly.Locationフィールドを確認すると、空白になります。
追加された 著者 Bartosz Wójcik,
私はソースコードを制御できません、それは問題です!私は自分のコードでこのバグを回避する方法を知っていますが、そうではありません。 Assembly.Locationを使用して空の文字列を取得すると問題が発生します;)
追加された 著者 Bartosz Wójcik,
私はソースコードを制御できません、それは問題です!私は自分のコードでこのバグを回避する方法を知っていますが、そうではありません。 Assembly.Locationを使用して空の文字列を取得すると問題が発生します;)
追加された 著者 Bartosz Wójcik,
リソースから.NETアセンブリをロードしています。ロードされたアセンブリ(メモリからロードされた)には、このフィールドが空になっており、アプリケーションの機能が分かりません。
追加された 著者 Bartosz Wójcik,
@Jamesはい、彼らはメモリからロードされているので、彼らはまだ、私はそれを変更したいので、場所を持っていない.NETの内部の変更や他の方法。
追加された 著者 Bartosz Wójcik,
正しい答えがない同じ質問
追加された 著者 Bartosz Wójcik,
正しい答えがない同じ質問
追加された 著者 Bartosz Wójcik,
正しい答えがない同じ質問
追加された 著者 Bartosz Wójcik,
私はここで危険な道を取っていることを知っているが、他のマネージドアセンブリ内のAssembly.Locationへのアクセスですか?もしそうなら、あなたはクライアントコードを書き直し、あなたの実装に呼び出しを乗り越えることを考えることができます。実現可能なアプローチかもしれませんか?
追加された 著者 Lorenzo Dematté,
私はここで危険な道を取っていることを知っているが、他のマネージドアセンブリ内のAssembly.Locationへのアクセスですか?もしそうなら、あなたはクライアントコードを書き直し、あなたの実装に呼び出しを乗り越えることを考えることができます。実現可能なアプローチかもしれませんか?
追加された 著者 Lorenzo Dematté,
私はここで危険な道を取っていることを知っているが、他のマネージドアセンブリ内のAssembly.Locationへのアクセスですか?もしそうなら、あなたはクライアントコードを書き直し、あなたの実装に呼び出しを乗り越えることを考えることができます。実現可能なアプローチかもしれませんか?
追加された 著者 Lorenzo Dematté,
私はそれを行うべきではないと言っているのですが、それは方法かもしれませんか? (ああ、私は@ RenniePetが多かれ少なかれ同じ考えを示唆しているのを見ている...私はメモリ内のアプローチの多くを考えていたが、まだ...)
追加された 著者 Lorenzo Dematté,
私はそれを行うべきではないと言っているのですが、それは方法かもしれませんか? (ああ、私は@ RenniePetが多かれ少なかれ同じ考えを示唆しているのを見ている...私はメモリ内のアプローチの多くを考えていたが、まだ...)
追加された 著者 Lorenzo Dematté,
私はそれを行うべきではないと言っているのですが、それは方法かもしれませんか? (ああ、私は@ RenniePetが多かれ少なかれ同じ考えを示唆しているのを見ている...私はメモリ内のアプローチの多くを考えていたが、まだ...)
追加された 著者 Lorenzo Dematté,

6 答え

目的のアセンブリリソースをそのコンテナアセンブリからコンテナアセンブリのディレクトリまたはサブディレクトリにコピーします。次に、コピーしたアセンブリをアプリケーションにロードします。これは、プライベートフィールド(または関数呼び出しの結果)を変更しようとするとかなり簡単になります

Assemblyクラスは公開インタフェースを公開しています。つまり、使用されるはずです。クラスの内部作業を変更しようとすると、それが可能であると仮定して大きな問題が発生する可能性があります。将来のバージョンや定期的な更新だけでも、クラスの内部動作が変更され、コードが破損する可能性があります。また、クラスの他のどの部分がそのフィールドに依存しているかを予測することもできません。その値を変更すると、意図しない結果がさらに発生する可能性があります。定義された振る舞いからクラスを変更することを提案しています。これにより、他のアセンブリやプログラマが道路の混乱や不満をさらに深刻化させる可能性があります。このため、このフィールドは読み取り専用として実装されています。そのため、.NETでは読み取り専用の値を簡単に変更できません。


更新

Locationプロパティのソースコードは次のとおりです。

[System.Security.SecurityCritical] //auto-generated
[ResourceExposure(ResourceScope.Machine)] 
[DllImport(JitHelpers.QCall, CharSet = CharSet.Unicode)]
[SuppressUnmanagedCodeSecurity] 
private static extern void GetLocation(RuntimeAssembly assembly,
    StringHandleOnStack retString); 

public override String Location 
{
    [System.Security.SecuritySafeCritical] //auto-generated
    [ResourceExposure(ResourceScope.Machine)]
    [ResourceConsumption(ResourceScope.Machine)] 
    get {
        String location = null; 

        GetLocation(GetNativeHandle(), 
                    JitHelpers.GetStringHandleOnStack(ref location));

        if (location != null)
            new FileIOPermission( FileIOPermissionAccess.PathDiscovery, location ).Demand();

        return location; 
    }
} 

Note that this code is actually located inside an undocumented class named RuntimeAssembly which is defined as internal within the Assembly class. You can see the full source code here:
http://www.dotnetframework.org/default.aspx/[email protected]/[email protected]/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/clr/src/BCL/System/Reflection/[email protected]/1305376/[email protected]

ご覧のとおり、修正するバッキングフィールドはありません。必要に応じてLocationプロパティをオーバーライドする方法はありません(Windows OSの一部を書き換えない)。

AND... just in case you get a hankerin' for rewriting that GetLocation function, you may be interested in this Q/A:
What is [DllImport("QCall")]?
(It probably goes without saying that, at this point, you are on your own.)

8
追加された
@RenniePet:ソースコードは公開されています: referencesource.microsoft.com/netframework.aspx
追加された 著者 jgauffin,
圧縮について初めて説明しました。私は、あなたが何をしているのか、なぜそれをやっているのかを説明できるなら、それが助けになると思います。あなたは、 "難しい問題を解決できない場合は、プログラマーになるのは何ですか?" と述べました。現在の方法ではどこに行きたいのかわからないときに仕事の一部が別の方法を見つけるです。 質問する方法を参照してください:あなたの質問に対する答えは、あなたが望むものとは限りませんそれが間違っているということではありません」。
追加された 著者 Equality In Tech,
(ところで、 Jon Skeet はC#の最前線の専門家の一人です。彼のアドバイスにかなりの注意を払うことが賢明でしょう。)
追加された 著者 Equality In Tech,
@Bartosz - これは netshrink と関係がありますか?あなたの質問は、その核心で、良いものでした。私はあなたが物事をよりよく説明していれば、実際には良い関心と確かな答えを得ていると思います。おそらくあなたがそれを見直す気になれば、それは再び開くことができます。
追加された 著者 Equality In Tech,
@ RenniePet - 私はBartoszのプロフィールからnetshrinkリンクを得ました。マイクロソフトは、参照ライセンスのもとで.netフレームワークのソースコードを公開しました。ウェブサイトはあまり良くありませんが、完全なソースコードをダウンロードしてインストールするよりも簡単です。
追加された 著者 Equality In Tech,
@ Cyborgx37この問題を近づけるためのフェアプレー。残念ながら、OPは非常に頑固で、彼がやろうとしていることは、標準/許容可能なアプローチ(もしあれば)を使って達成できないということを受け入れない。間違ったアプローチをしているとき、なぜ理解しているのか、代替手段を探している時を知っているのは、良い開発者であるということです。OPはそうしたくないようです。 。
追加された 著者 James,
+1あなたの研究のために。あなたがdotnetframework.orgに提供しているリンクは、FirefoxやIE 10ではうまくいきません。そのソースコードはどこから入手できましたか?マイクロソフトではこれを公開しましたか? netshrinkについてのあなたの推測に関しては、BartoszのSOプロフィールには、そのWebサイトへのリンクが含まれているので、おそらくそれはすべてについてです。
追加された 著者 RenniePet,
申し訳ありませんが、圧縮されたアセンブリをディスクに圧縮解除することはできません。あなたがそれを達成する方法を知っていれば、私は大きな問題がほしいと思っています。
追加された 著者 Bartosz Wójcik,
彼が専門家であれば気にしない。私は仕事をやりたいだけです。あなたができないのであれば、できないというわけではありません。それはメモリにロードされた単なるコードなので、実行できます。私は2日間でこれについて賞金を稼ぐつもりです。
追加された 著者 Bartosz Wójcik,
私はReflectorでGetLocationの実装を見てきました。これはCLR.dllのネイティブコードにつながります。私はこのlibにネイティブフックを置くことを考えています。
追加された 著者 Bartosz Wójcik,

簡単に言えば、プロパティを変更することはできません。この場合、そのアセンブリがディスクからロードされた場所が通知されます。代わりにアセンブリを移動し、アプリケーションが新しい場所からアセンブリをロードするようにする必要があります。

4
追加された
@BartoszWójcik:あなたはReflectionを使ってフィールドを修正したいと思うかもしれませんが、それは後でラインを痛める原因になります。回避策を回避策に積み重ね始めます。代わりに最初の問題を修正してみましょう
追加された 著者 Ian,
@BartoszWójcik:もう一度やるのは間違っています。内部的に保存された変数がないため、Reflectionでフィールドを設定することさえできません。代わりに、Windows APIを呼び出す内部関数の結果を変更する必要があります。
追加された 著者 Ian,
@BartoszWójcik:いいえ、それは本当に答えです。達成できない値であるAssembly.Locationに依存するアセンブリを使用している場合、それらのアセンブリは、使用している目的に適合しません。
追加された 著者 Jon Skeet,
私の友人がこのブログエントリを表示します。 blogs.msdn.com /b/thottams/archive/2006/04/26/583722.aspx と言って、Assembly.Locationのgetterメソッドを変更して、必要なものを返すことができ、このメソッドを試す必要があるかもしれないと教えてください。
追加された 著者 Bartosz Wójcik,
私はあなたがexe-compressionについて知っているか分からないように見えますが、それは問題であり解決する必要があります。あなたはそれが気に入らないかもしれませんが、すべての問題が素敵で簡単に修正できるわけではありません。あなたはそれで論争するかもしれませんが、それは私の顧客のための本当の問題であり、私はそれに対処しなければなりません。あなたはその解決策について私に教えてくれましたが、コードを表示していませんでした、私はここの唯一の悪いプログラマーではないと思います...
追加された 著者 Bartosz Wójcik,
それは答えではない、私はちょうど反射、ランタイムバイトコードの変更または必要な他の手段のいずれかでこのプロパティを変更したい。
追加された 著者 Bartosz Wójcik,
それでも有効な答えはありません。 .NETはフレームワークであり、内部変数を変更してフィールドのみを読み取る方法でなければなりません。ドキュメント化された方法を探しているわけではありません。
追加された 著者 Bartosz Wójcik,
しかし、それは最初の問題です。 2つのアセンブリは、同じディスクパスの下で一緒にバインドされます。それらのうちの1つがメモリから読み込まれ、格納されている実行可能ファイルを参照するように場所フィールドを設定したいと思います。解決策がわからない場合は、他の人のコメントを許可してください。
追加された 著者 Bartosz Wójcik,
@イアン私にコードを表示してください、それは全体のポイントです:)
追加された 著者 Bartosz Wójcik,

簡単に言えば、プロパティを変更することはできません。この場合、そのアセンブリがディスクからロードされた場所が通知されます。代わりにアセンブリを移動し、アプリケーションが新しい場所からアセンブリをロードするようにする必要があります。

4
追加された
@BartoszWójcik:あなたはReflectionを使ってフィールドを修正したいと思うかもしれませんが、それは後でラインを痛める原因になります。回避策を回避策に積み重ね始めます。代わりに最初の問題を修正してみましょう
追加された 著者 Ian,
@BartoszWójcik:もう一度やるのは間違っています。内部的に保存された変数がないため、Reflectionでフィールドを設定することさえできません。代わりに、Windows APIを呼び出す内部関数の結果を変更する必要があります。
追加された 著者 Ian,
@BartoszWójcik:いいえ、それは本当に答えです。達成できない値であるAssembly.Locationに依存するアセンブリを使用している場合、それらのアセンブリは、使用している目的に適合しません。
追加された 著者 Jon Skeet,
私はあなたがexe-compressionについて知っているか分からないように見えますが、それは問題であり解決する必要があります。あなたはそれが気に入らないかもしれませんが、すべての問題が素敵で簡単に修正できるわけではありません。あなたはそれで論争するかもしれませんが、それは私の顧客のための本当の問題であり、私はそれに対処しなければなりません。あなたはその解決策について私に教えてくれましたが、コードを表示していませんでした、私はここの唯一の悪いプログラマーではないと思います...
追加された 著者 Bartosz Wójcik,
@イアン私にコードを表示してください、それは全体のポイントです:)
追加された 著者 Bartosz Wójcik,
私の友人がこのブログエントリを表示します。 blogs.msdn.com /b/thottams/archive/2006/04/26/583722.aspx と言って、Assembly.Locationのgetterメソッドを変更して、必要なものを返すことができ、このメソッドを試す必要があるかもしれないと教えてください。
追加された 著者 Bartosz Wójcik,
それは答えではない、私はちょうど反射、ランタイムバイトコードの変更または必要な他の手段のいずれかでこのプロパティを変更したい。
追加された 著者 Bartosz Wójcik,
それでも有効な答えはありません。 .NETはフレームワークであり、内部変数を変更してフィールドのみを読み取る方法でなければなりません。ドキュメント化された方法を探しているわけではありません。
追加された 著者 Bartosz Wójcik,
しかし、それは最初の問題です。 2つのアセンブリは、同じディスクパスの下で一緒にバインドされます。それらのうちの1つがメモリから読み込まれ、格納されている実行可能ファイルを参照するように場所フィールドを設定したいと思います。解決策がわからない場合は、他の人のコメントを許可してください。
追加された 著者 Bartosz Wójcik,

簡単に言えば、プロパティを変更することはできません。この場合、そのアセンブリがディスクからロードされた場所が通知されます。代わりにアセンブリを移動し、アプリケーションが新しい場所からアセンブリをロードするようにする必要があります。

4
追加された
@BartoszWójcik:あなたはReflectionを使ってフィールドを修正したいと思うかもしれませんが、それは後でラインを痛める原因になります。回避策を回避策に積み重ね始めます。代わりに最初の問題を修正してみましょう
追加された 著者 Ian,
@BartoszWójcik:もう一度やるのは間違っています。内部的に保存された変数がないため、Reflectionでフィールドを設定することさえできません。代わりに、Windows APIを呼び出す内部関数の結果を変更する必要があります。
追加された 著者 Ian,
@BartoszWójcik:いいえ、それは本当に答えです。達成できない値であるAssembly.Locationに依存するアセンブリを使用している場合、それらのアセンブリは、使用している目的に適合しません。
追加された 著者 Jon Skeet,
@イアン私にコードを表示してください、それは全体のポイントです:)
追加された 著者 Bartosz Wójcik,
私の友人がこのブログエントリを表示します。 blogs.msdn.com /b/thottams/archive/2006/04/26/583722.aspx と言って、Assembly.Locationのgetterメソッドを変更して、必要なものを返すことができ、このメソッドを試す必要があるかもしれないと教えてください。
追加された 著者 Bartosz Wójcik,
私はあなたがexe-compressionについて知っているか分からないように見えますが、それは問題であり解決する必要があります。あなたはそれが気に入らないかもしれませんが、すべての問題が素敵で簡単に修正できるわけではありません。あなたはそれで論争するかもしれませんが、それは私の顧客のための本当の問題であり、私はそれに対処しなければなりません。あなたはその解決策について私に教えてくれましたが、コードを表示していませんでした、私はここの唯一の悪いプログラマーではないと思います...
追加された 著者 Bartosz Wójcik,
それは答えではない、私はちょうど反射、ランタイムバイトコードの変更または必要な他の手段のいずれかでこのプロパティを変更したい。
追加された 著者 Bartosz Wójcik,
それでも有効な答えはありません。 .NETはフレームワークであり、内部変数を変更してフィールドのみを読み取る方法でなければなりません。ドキュメント化された方法を探しているわけではありません。
追加された 著者 Bartosz Wójcik,
しかし、それは最初の問題です。 2つのアセンブリは、同じディスクパスの下で一緒にバインドされます。それらのうちの1つがメモリから読み込まれ、格納されている実行可能ファイルを参照するように場所フィールドを設定したいと思います。解決策がわからない場合は、他の人のコメントを許可してください。
追加された 著者 Bartosz Wójcik,

@ Cyborgx37は正しいですが、既存のアセンブリの場所を変更することはできませんが、この問題に近づく別の方法があります。

すでにロードされているアセンブリの場所を設定するのではなく、 Mono.Cecil のようなライブラリを使用して、このプロパティを使用してアセンブリを書き換えます。

それがコア.NETフレームワークアセンブリの1つではないと仮定すると、すべての Assembly.Location アクセスを、注入できる静的プロパティで置き換えるのはかなり簡単です。

私は暗号化されたアセンブリローダーを書くときにそういったことをしなければならず、かなり成功しました。

編集

これを行うには本当に死んでいる場合は、これらの2つの記事は、実行時にexisingメソッドを書き換える方法を開始する必要があります。しかし、複数の注意点があります:これはNGENやGACではまったく動作しません。解決しなければならないasync/await/enumerable/exception hそしてlingにはいくつかの問題があります。自己責任。

MSIL注入:実行時に非動的メソッドを書き直す

CLRインジェクション:ランタイムメソッドリプレイサ

私は強くアドバイスをしています。それらの解決策は製造者コードで使用するにはあまりにも脆いので、著者が言及しました。

意図していない方法でCLRメモリを直接操作していることに注意する必要があります。このコードは、.NET Frameworkの新しいバージョンでは機能しない可能性があります。これはVista x86上の.NET 3.5でテストされており、マシン上で動作しない可能性があります。

そして

マイクロソフトはこのハックなものをサポートしていません。可能であれば、目標を達成するための別の手段を検討する必要があります。

4
追加された
カッコいい!それはOPの目標に合っているようだ。私はこの答えを受け入れるだろう。
追加された 著者 Equality In Tech,

やや長めの答え。

Location ゲッターで返された値は、次のようなバッキングフィールドに格納されていないということは難しいでしょう(私はあなたがすでに疑っていると確信しています)。

  private readonly string location;

代わりに、アセンブリのネイティブハンドルを使用してフェッチされます(または実際にはそのクラスは抽象クラスであるため、メモリから読み込むときに取得するサブクラスの RuntimeAssembly 外部の dll 呼び出しを使用してその場所を読み込みます。

このように見える(簡略化された)。

[DllImport(JitHelpers.QCall, CharSet = CharSet.Unicode)]
private static extern void GetLocation(RuntimeAssembly assembly, StringHandleOnStack retString);

public override String Location {
  get {
    String location = null;
    GetLocation(GetNativeHandle(), JitHelpers.GetStringHandleOnStack(ref location));

    return location;
  }
}

これを必要とするコードを、値を注入するよりも空でなければ簡単に変更できます。

- L Lawliet -

1
追加された
++ 1 upvoteこれに....
追加された 著者 james raygan,