タグ付けされた質問 「appdomain」

AppDomain複雑な参照ツリーを持つ新しいいくつかのアセンブリにロードしたい（MyDll.dll-> Microsoft.Office.Interop.Excel.dll-> Microsoft.Vbe.Interop.dll-> Office.dll-> stdole.dll） 私が理解している限り、アセンブリがに読み込まれているときAppDomain、その参照は自動的に読み込まれず、手動で読み込む必要があります。だから私がするとき： string dir = @"SomePath"; // different from AppDomain.CurrentDomain.BaseDirectory string path = System.IO.Path.Combine(dir, "MyDll.dll"); AppDomainSetup setup = AppDomain.CurrentDomain.SetupInformation; setup.ApplicationBase = dir; AppDomain domain = AppDomain.CreateDomain("SomeAppDomain", null, setup); domain.Load(AssemblyName.GetAssemblyName(path)); そして得たFileNotFoundException： ファイルまたはアセンブリ 'MyDll、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null'またはその依存関係の1つを読み込めませんでした。システムは、指定されたファイルを見つけることができません。 重要な部分は依存関係の1つだと思います。 はい、前に行います domain.Load(AssemblyName.GetAssemblyName(path)); foreach (AssemblyName refAsmName in Assembly.ReflectionOnlyLoadFrom(path).GetReferencedAssemblies()) …

113 c#  .net  reflection  assemblies  appdomain 

私はemacsでC＃の補完（インテリセンス）機能に取り組んでいます。 ユーザーがフラグメントを入力し、特定のキーストロークの組み合わせを介して補完を要求すると、補完機能は.NETリフレクションを使用して可能な補完を決定するという考え方です。 これを行うには、完成するものの種類を知っている必要があります。文字列の場合、考えられるメソッドとプロパティの既知のセットがあります。それがInt32の場合は、別個のセットがあります。 emacsで利用可能なコードレクサー/パーサーパッケージのセマンティックを使用して、変数宣言とその型を見つけることができます。そのため、リフレクションを使用して型のメソッドとプロパティを取得し、オプションのリストをユーザーに提示するのは簡単です。（OK、emacs 内で実行するのは簡単ではありませんが、 emacs 内でpowershellプロセスを実行する機能を使用すると、はるかに簡単になります。リフレクションを実行するためのカスタム.NETアセンブリを記述し、それをpowershellにロードしてから、elisp内で実行しますemacsはコマンドをpowershellに送信し、comintを介して応答を読み取ることができます。その結果、emacsはリフレクションの結果をすばやく取得できます。） 問題varは、完了したものの宣言でコードが使用するときに発生します。つまり、タイプが明示的に指定されておらず、補完が機能しません。 変数がvarキーワードで宣言されている場合、実際に使用されているタイプを確実に判断するにはどうすればよいですか？明確にするために、実行時にそれを決定する必要はありません。「設計時」に決定したい。 これまでのところ、私はこれらのアイデアを持っています： コンパイルして呼び出す： 宣言ステートメントを抽出します。例： `var foo =" a string value ";` ステートメント `foo.GetType（）;`を連結します 結果のC＃フラグメントを動的にコンパイルして新しいアセンブリに アセンブリを新しいAppDomainに読み込み、フレームを実行して戻り値の型を取得します。 アセンブリをアンロードして破棄する 私はこれをすべて行う方法を知っています。しかし、エディターでの完了要求ごとに、それはひどく重いように聞こえます。 私は毎回新しいAppDomainを必要としないと思います。単一のAppDomainを複数の一時的なアセンブリに再利用し、複数の完了リクエストにまたがって、それを設定および破棄するコストを償却できます。これは、基本的な考え方の微調整です。 ILのコンパイルと検査 宣言をモジュールにコンパイルし、ILを検査して、コンパイラーによって推論された実際のタイプを判別します。これはどのようにして可能でしょうか？ILの検査には何を使用しますか？ そこにもっと良いアイデアはありますか？コメント？提案？ 編集 -これについてさらに考えると、コンパイルと呼び出しは受け入れられません。呼び出しには副作用がある可能性があるためです。したがって、最初のオプションは除外する必要があります。 また、.NET 4.0の存在は想定できません。 更新 -正解は、上記には言及されていませんが、エリックリッパートによって穏やかに指摘されていますが、完全な忠実度の型推論システムを実装することです。これは、設計時に変数のタイプを確実に決定する唯一の方法です。しかし、それも簡単ではありません。私はそのようなものを構築したいという幻想に苦しんでいないので、オプション2のショートカットをとりました-関連する宣言コードを抽出してコンパイルし、結果のILを検査します。 これは、完了シナリオのかなりのサブセットに対して実際に機能します。 たとえば、次のコードフラグメントで、？ユーザーが完了を要求する位置です。これは機能します： var x = "hello there"; x.? 補完により、xは文字列であることがわかり、適切なオプションが提供されます。これは、次のソースコードを生成してコンパイルすることによって行われます。 namespace N1 { static class dmriiann5he …

109 c#  reflection  appdomain  type-inference 

背景：Noda Timeには、シリアライズ可能な構造体が多数含まれています。バイナリシリアライゼーションは嫌いですが、1.xタイムラインに戻って、それをサポートするための多くのリクエストを受け取りました。ISerializableインターフェースを実装することでサポートします。 Noda Time 2.x が.NET Fiddle内で失敗するという最近の問題レポートを受け取りました。Noda Time 1.xを使用する同じコードは正常に動作します。スローされる例外はこれです： メンバーの上書き中に継承セキュリティルールに違反しました： 'NodaTime.Duration.System.Runtime.Serialization.ISerializable.GetObjectData（System.Runtime.Serialization.SerializationInfo、System.Runtime.Serialization.StreamingContext）'。オーバーライドするメソッドのセキュリティアクセシビリティは、オーバーライドされるメソッドのセキュリティアクセシビリティと一致する必要があります。 これを対象のフレームワークに絞り込みました。1.xは.NET 3.5（クライアントプロファイル）を対象としています。2.xは.NET 4.5をターゲットにします。サポートPCLと.NET Coreの違い、およびプロジェクトファイルの構造には大きな違いがありますが、これは重要ではないようです。 私はなんとかローカルプロジェクトでこれを再現しましたが、解決策を見つけていません。 VS2017で再現する手順： 新しいソリューションを作成する .NET 4.5.1をターゲットとする新しいクラシックWindowsコンソールアプリケーションを作成します。私はそれを「CodeRunner」と呼んだ。 プロジェクトプロパティで、[署名]に移動し、新しいキーでアセンブリに署名します。パスワード要件のチェックを外し、任意のキーファイル名を使用します。 次のコードを貼り付けて置き換えProgram.csます。これは、このMicrosoftサンプルのコードの省略バージョンです。すべてのパスを同じにしたので、完全なコードに戻りたい場合は、他に何も変更する必要はありません。 コード： using System; using System.Security; using System.Security.Permissions; class Sandboxer : MarshalByRefObject { static void Main() { var adSetup = new AppDomainSetup(); adSetup.ApplicationBase = System.IO.Path.GetFullPath(@"..\..\..\UntrustedCode\bin\Debug"); var permSet = new …

109 c#  .net  serialization  appdomain  code-access-security 

Microsoftが.NETCoreでAppDomainsをサポートしないことを選択した強い理由はありますか？ AppDomainsは、サーバーをシャットダウンせずに、サーバーによってロードされたアセンブリを適切な方法で更新したい場合に、長時間実行されるサーバーアプリを構築するときに特に役立ちます。 AppDomainsがない場合、長時間実行されるサーバープロセスでアセンブリをどのように置き換えるのでしょうか。 AppDomainsは、サーバーコードのさまざまな部分を分離する方法も提供します。同様に、カスタムWebSocketサーバーはプライマリappdomainにソケットコードを持つことができますが、サービスはセカンダリappdomainで実行されます。 AppDomainがないと、上記のシナリオは不可能です。 アセンブリの変更を処理するためにクラウドのVMの概念を使用し、AppDomainのオーバーヘッドを発生させる必要がないことについて話し合う可能性のある議論を見ることができます。しかし、これはマイクロソフトが考えていること、または言っていることですか？または、上記のシナリオに特定の理由と代替案がありますか？

86 .net  clr  appdomain  .net-core 

特に、2つの異なるアプリケーションドメインでコードを実行することの意味は何ですか？ データは通常、アプリケーションドメインの境界を越えてどのように渡されますか？プロセスの境界を越えてデータを渡すことと同じですか？この抽象化とそれが何に役立つのかについてもっと知りたいです。 編集：私はアプリケーションドメインを理解していませんが、一般的にAppDomainクラスの既存のカバレッジは良好です

83 .net  appdomain 

私のプロジェクトは次のように設定されています。 プロジェクト「定義」 プロジェクト「実施」 プロジェクト「消費者」 プロジェクト「Consumer」は「Definition」と「Implementation」の両方を参照しますが、「Implementation」のタイプを静的に参照しません。 アプリケーションが起動すると、プロジェクト「Consumer」は「Definition」の静的メソッドを呼び出します。このメソッドは「Implementation」でタイプを見つける必要があります。 パスや名前を知らなくても、できれば本格的なIOCフレームワークを使用せずに、参照されているアセンブリを強制的にApp Domainにロードする方法はありますか？

83 c#  assemblies  appdomain 

.NETには、このアプリケーションドメインの概念があり、私が理解していることから、アセンブリをメモリにロードするために使用できます。私はアプリケーションドメインについていくつかの調査を行ったほか、この主題に関する追加の知識を得るために地元の書店に行きましたが、それは非常に少ないようです。 アプリケーションドメインでできることは、アセンブリをメモリにロードすることだけで、必要なときにアンロードできます。 私がアプリケーションドメインについて言及した他の機能は何ですか？スレッドはアプリケーションドメインの境界を尊重しますか？通信のパフォーマンスを超えて、メインのアプリケーションドメイン以外の異なるアプリケーションドメインにアセンブリをロードすることによる欠点はありますか？ アプリケーションドメインについて説明しているリソースへのリンクもいいでしょう。私はすでにMSDNをチェックアウトしましたが、MSDNについてはそれほど多くの情報がありません。

80 .net  appdomain