如何使用AppDomains并向其添加搜索路径？ [英] How do I use AppDomains and add search paths to it?
问题描述
我有一个应用程序，我正在添加对插件的支持，我正在寻找
以获得最佳处理方式的帮助。我的问题与
AppDomains以及使用它们的最佳方式有关。
我有这样的目录结构：
MyApp
\AddIns
\AddIn1
\AddIn2
我的部分问题是AddIn1使用了一些与MyApp一起安装的组件，我不想在
AddIn1或2中复制这些组件目录。我不想把它们放在GAC中，所以请不要
建议。
为了支持我现在正在使用这个方法：
AppDomain.CurrentDomain.AppendPrivatePath（< AddInPath）;
问题在于这个方法被认为是过时的我ñ
真的很想做到这一点。我已经读过我应该把加载项分别作为
单独的AppDomain，但我想知道每个AddIn是否应该在它自己的
AppDomain中，如果是的话，那是什么？ AppDomain的内存开销。这些是非常小的加载项，而且我不想杀死计算机这是
正在运行。
我也想知道我的目录结构是否可行。我/ b $ b真的不太了解创建AppDomain或需要什么。我希望
希望AppDomain指向MyApp\AddIns\AddIn1中的DLL
我还可以将MyApp目录添加到其搜索路径中，以便它可以使用
与主应用程序相同的程序集。
可以添加一个高于主应用程序的搜索路径
动态加载AppDomain和动态加载的DLL？任何帮助都会对此感激不尽。
谢谢，
Eric Renken
您好Eric，
您能告诉我您对插件型号的特殊要求吗？ br />
通常，我们为
插件程序集创建一个新的AppDomain有2个要求：
1.需要卸载插件支持-in组件
2.需要一个单独的沙盒安全环境来托管插件
组件
如果你不这样做有这两个要求，我认为你不需要创建单独的AppDomain
a。您可以使用Assembly.Load（）方法在默认的AppDomain中动态加载
插件程序集。
是的，AppDomain.AppendPrivatePath（）方法已过时但是，你可以通过< probing>
元素在app.config文件中设置探测路径.Net2.0，
。有关详细信息，请参阅以下链接：
http://msdn2.microsoft.com/en-us/library/823z9h8w.aspx
下面的链接记录了Assembly.Load方法的正式搜索路径：
运行时如何找到程序集
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx
插件程序集加载到单独的AppDomain中以确保安全和卸载
benifit，我推荐以下由CLR开发人员撰写的好文章
Shawn Farkas，它提供了一个完整的步骤和采用这个模型的b / b
的源代码。
发现安全托管不受信任的加载项的技术。 NET
Framew ork 2.0"
http： //msdn.microsoft.com/msdnmag/is...s/default.aspx
在这种情况下，您无法使用私有探测路径来指定
" MyApp"新AppDomain的目录，因为私有探测路径必须
是应用程序基目录的子文件夹。但是，您可以将
新AppDomain的ApplicationBase设置为与主要的
AppDomain相同的文件夹（MyApp），以便新的AppDomain（插件） -in assemblies）可以在这个文件夹中找到
程序集。
最后，使用多个AppDomain并不是一个很大的开销。 Asp.net使用相同型号的
：如果您在Asp.net网站上创建多个Web应用程序
网站，它将为每个Web应用程序创建一个单独的AppDomain
处理请求。
希望这会有所帮助。
祝你好运，
Jeffrey Tan
Microsoft在线社区支持
============================ ======================
通过电子邮件收到我的帖子通知？请参阅
http://msdn.microsoft .com / subscripti ... ult.aspx＃notif
ications。
注意：MSDN托管新闻组支持服务是针对非紧急问题
如果社区或微软支持人员在1个工作日内做出初步回复是可以接受的。请注意，每个跟随
的响应可能需要大约2个工作日作为支持
专业人士与您合作可能需要进一步调查才能达到
最有效的分辨率。该产品不适用于需要紧急，实时或基于电话的交互或复杂的b $ b项目分析和转储分析问题的情况。这种性质的问题最好通过联系
Microsoft客户支持服务（CSS）处理
href =http://msdn.microsoft.com/subscriptions/support/default.aspx\"target =_ blank> http://msdn.microsoft.com/subscripti...t/default.aspx 。
======================================== ==========
此帖子按原样提供。没有保证，也没有授予任何权利。
我在线阅读，大多数人建议单独运行它们
AppDomain 。我不介意只使用AssemblyLoad运行它们，但是我遇到的问题是我不知道AddIn的确切路径
直到我的应用程序运行，所以我不能把这些信息放在
app.config文件中。
真正的问题是AddIn可能有自己的依赖DLL，
与它一起安装在它的目录中，当它试图加载它的
依赖的DLL时，AddIn就无法搜索它自己的目录。 br />
我可能看起来至少为AddIns创建一个AppDomain而我
正在考虑你所说的并设置
ApplicationBase到MyApp然后我相信有一种方法可以设置搜索
到新AppDomain的路径。我没有在Shawn Farkas中看到过这种情况。文献。你有没有很好的参考资料？
Eric Renken
"" Jeffrey Tan [MSFT]"" < je *** @ online.microsoft.com写信息
新闻：gU ************** @ TK2MSFTNGHUB02.phx.gbl ...
嗨Eric，
您能告诉我您对插件型号的特殊要求吗？
通常，我们有2个要求为
插件组件创建一个新的AppDomain：
1.需要卸载支持插件组件
2.需要一个单独的沙箱安全环境来托管插件
组件
如果你没有这两个要求，我认为你不需要创建单独的AppDomain
a。您可以使用Assembly.Load（）方法在默认的AppDomain中动态加载
插件程序集。
是的，AppDomain.AppendPrivatePath（）方法已过时但是，你可以通过< probing>
元素在app.config文件中设置探测路径.Net2.0，
。有关详细信息，请参阅以下链接：
http://msdn2.microsoft.com/en-us/library/823z9h8w.aspx
下面的链接记录了Assembly.Load方法的正式搜索路径：
运行时如何找到程序集
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx
插件程序集加载到单独的AppDomain中以确保安全和卸载
benifit，我推荐以下由CLR开发人员撰写的好文章
Shawn Farkas，它提供了一个完整的步骤和采用这个模型的b / b
的源代码。
发现安全托管不受信任的加载项的技术。 NET
Framewor k 2.0"
http： //msdn.microsoft.com/msdnmag/is...s/default.aspx
在这种情况下，您无法使用私有探测路径来指定
" MyApp"新AppDomain的目录，因为私有探测路径必须
是应用程序基目录的子文件夹。但是，您可以将
新的AppDomain的ApplicationBase设置为与主要的
AppDomain相同的文件夹（MyApp） ，以便新的AppDomain（插件程序集）可以在此文件夹中找到
程序集。
最后，使用多个AppDomain并不是一个很大的开销。 Asp.net
利用
相同型号：如果您在Asp.net网站上创建多个Web应用程序
网站，它将创建一个为每个Web应用程序单独分配AppDomain
处理请求。
希望这会有所帮助。
祝你好运，
Jeffrey Tan
Microsoft在线社区支持
==================== ==============================
通过电子邮件收到我的帖子通知？请参阅
http://msdn.microsoft .com / subscripti ... ult.aspx＃notif
ications。
注意：MSDN托管新闻组支持服务是针对非紧急问题
如果社区或微软支持人员在1个工作日内做出初步回复是可以接受的。请注意，每个跟随
的响应可能需要大约2个工作日作为支持
专业人士与您合作可能需要进一步调查才能达到
最有效的分辨率。该产品不适用于需要紧急，实时或基于电话的交互或复杂的b $ b项目分析和转储分析问题的情况。这种性质的问题最好通过联系
Microsoft客户支持服务（CSS）处理
href =http://msdn.microsoft.com/subscriptions/support/default.aspx\"target =_ blank> http://msdn.microsoft.com/subscripti...t/default.aspx 。
======================================== ==========
此帖子按原样提供。没有保证，也没有赋予
权利。
嗨Eric，
感谢您的反馈！
＃1，>我遇到的问题是我不知道确切的路径
AddIn直到我的应用程序运行
是的，我看到了你的担忧。但是，Assembly.Load（）方法不需要Addin的
绝对路径，你需要通过< probingin app设置Addin
的相对路径.config文件（我假设你知道Addin的相对
目录结构）。只有Assembly.LoadFrom（）方法需要Addin的
绝对路径。请参阅以下链接了解更多
信息：
http://blogs.msdn.com/suzcook/archiv.../29/57143.aspx
＃2，>真正的问题是AddIn可能有自己的依赖DLL
>与它一起安装在其目录中，当它试图加载其依赖的DLL时，AddIn无法搜索自己的目录。
对不起，你的意思是在使用新的AppDomain或使用单个AppDomain吗？
我假设你正在谈论单个AppDomain的上下文。在这个
场景中，一旦你设置了< probingto" AddIns \ AddIn1"相对
路径，整个AppDomain CLR代码将探测AddIns \AddIn1"文件夹
以备将来使用。所以这不是问题。为了实现这一点，我创建了
3个示例项目：
1. ClassLibrary1（类库），代码如下：
namespace ClassLibrary1
{
公共类Class1
{
public static int Add（int a，int b）
{
返回+ b + ClassLibrary2.Class1.Multiply（a，b）;
}
}
}
2. ClassLibrary2（类库）代码如下
namespace ClassLibrary2
{
公共类Class1
{
public static int Multiply（int a，int b）
{
返回a * b;
}
}
}
3. ProbingDllTest （Winform App）
private void button1_Click（object sender，EventArgs e）
{
MessageBox.Show（ClassLibrary1.Class1.Add（5） ，6）.ToString（））;
}
现在，我在ProbingDllTest winform项目中添加了一个App.Config
设置相对pr obing path：
<？xml version =" 1.0"编码= QUOT; UTF-8英寸？>
< configuration>
< runtime>
< assemblyBinding xmlns =" urn：schemas-microsoft-com： asm.v1">
< probing privatePath =" AddIns\AddIn1" />
< / assemblyBinding>
< / runtime>
< / configuration>
最后，在构建这3个项目之后，我进入了
" ; ProbingDllTest\bin\Debug"然后我将ClassLibrary1.dll和
ClassLibrary2.dll移动到ProbingDllTest\bin\Debug \AddIns \ Add1In中（是的，我创建了
）与您相似的目录结构）。当我点击
ProbingDllTest.exe时，一切都可以正常工作。这意味着ProbingDllTest.exe可以找到ClassLibrary1.dll。没有任何问题，和ClassLibrary1.dll可以
找到ClassLibrary2.dll没有任何问题。如果我有误b / b $ b误解了你的观点，请随时告诉我，谢谢。
＃3，>>设置
< blockquote class =post_quotes>
>> ApplicationBase到MyApp然后我相信有一种方法可以设置搜索到新AppDomain的路径。
我假设你的意思是你已经创建了一个新的AppDomain并将
AppDomainSetup.ApplicationBase设置为MyApp。基本目录，你想知道
如何告诉新的AppDomain搜索Addin子目录。如果我有误b / b
误解了你，请随时告诉我。
因为你已经将AppDomainSetup.ApplicationBase设置为MyApp基础
目录，CLR将始终探测MyApp。基本目录程序集
没有任何问题。要设置为另一个子目录（Addin），您可以使用
AppDomainSetup.PrivateBinPath属性。此属性具有相同的效果
as< probingelement in app.config
如果您还有任何不清楚的地方，请随时告诉我，谢谢。
祝你好运，
Jeffrey Tan
微软在线社区支持
===== =============================================
通过电子邮件收到我的帖子通知？请参阅
http://msdn.microsoft .com / subscripti ... ult.aspx＃notif
ications。
注意：MSDN托管新闻组支持服务是针对非紧急问题
如果社区或微软支持人员在1个工作日内做出初步回复是可以接受的。请注意，每个跟随
的响应可能需要大约2个工作日作为支持
专业人士与您合作可能需要进一步调查才能达到
最有效的分辨率。该产品不适用于需要紧急，实时或基于电话的交互或复杂的b $ b项目分析和转储分析问题的情况。这种性质的问题最好通过联系
Microsoft客户支持服务（CSS）处理
href =http://msdn.microsoft.com/subscriptions/support/default.aspx\"target =_ blank> http://msdn.microsoft.com/subscripti...t/default.aspx 。
======================================== ==========
此帖子按原样提供。没有保证，也没有授予任何权利。
I have an application that I am adding support for plug-ins and I am looking
for some help on the best way to handle this. My question has to do with
AppDomains and the best way to use them.
I have a directory structure like this:
MyApp
\AddIns
\AddIn1
\AddIn2
Part of my problem is that AddIn1 uses some of the assemblies that are
installed with MyApp and I don''t want to duplicate those assemblies in the
AddIn1 or 2 directory. I don''t want to put them in the GAC, so please don''t
suggest that.
To support that now I am currently using this method:
AppDomain.CurrentDomain.AppendPrivatePath( <AddInPath);
The problem with that is that this method is considered obsolete and I
really want to do this right. I have read that I should put the add-in a
separate AppDomain, but I am wondering if each AddIn should be in its own
AppDomain and if so what is the memory overhead of the AppDomain. These are
mostly very small add-ins and I don''t want to kill the computer this is
running on.
I am also wondering if this is possible with my directory structure. I
really don''t know much about creating AppDomains or what would be needed. I
hoping that with the AppDomain pointing to a DLL in MyApp\AddIns\AddIn1 that
I can also add the directory MyApp to its search path so that it can use the
same assemblies as the main application.
Can a search path be added that is higher than the main application for a
dynamically loaded AppDomain and a dynamically loaded DLL? Any Help would
be greatly appreciated on this.
Thanks,
Eric Renken
Hi Eric,
Can you show me your special requirement regarding the plug-in model?
Normally, there are 2 requirements for us to create a new AppDomain for the
plug-in assemblies:
1. Needs unloading support of plug-in assemblies
2. Needs a separate sandbox security environment to host the plug-in
assemblies
If you do not have these 2 requirements, I do not think you need to create
a separate AppDomain. You may just use Assembly.Load() method to load your
plug-in assemblies dynamically in your default AppDomain.
Yes, AppDomain.AppendPrivatePath() method is obsolete in .Net2.0, however,
you may set the probing path in the app.config file through <probing>
element. Please refer to the link below for more details:
http://msdn2.microsoft.com/en-us/library/823z9h8w.aspx
The link below documents the offical search paths of Assembly.Load method:
"How the Runtime Locates Assemblies"
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx
If you really wanted to leverage the new AppDomain model to load the
plug-in assemblies into the separate AppDomain for security and unloading
benifit, I recommend the following good article written by CLR developer
"Shawn Farkas", it provided a complete steps and source code of adopting
this model.
"Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET
Framework 2.0"
http://msdn.microsoft.com/msdnmag/is...s/default.aspx
In this scenario, you can not use the private probing path to specify the
"MyApp" directory for the new AppDomain, because private probing path must
be a sub-folder of the application base directory. However, you may set the
new AppDomain''s ApplicationBase to the same folder("MyApp") as the main
AppDomain, so that the new AppDomain(plug-in assemblies) can locate the
assemblies in this folder.
Finally, using multiple AppDomains is not a big overhead. Asp.net leverages
the same model: if you create multiple web applications on a Asp.net web
site, it will create a separate AppDomain for each web application to
handle the request.
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
I was reading online and most people recommended running them in a separate
AppDomain. I don''t mind running them with just the AssemblyLoad, but the
problem I have with that is that I don''t know the exact path of the AddIn
until my application is running, so I can''t put this information in the
app.config file.
The real problem is that the AddIn might have its own dependent DLLs that
are installed with it in its directory and when it tries to load its
dependent DLLs the AddIn can''t search its own directory.
I will probably look at least creating one AppDomain for the AddIns and I
was thinking along the lines of what you said and setting the
ApplicationBase to MyApp and then I believe there is a way to set search
paths to a new AppDomain. I didn''t see that in "Shawn Farkas" document. Do
you have a good reference on how to do that?
Eric Renken
""Jeffrey Tan[MSFT]"" <je***@online.microsoft.comwrote in message
news:gU**************@TK2MSFTNGHUB02.phx.gbl...Hi Eric,
Can you show me your special requirement regarding the plug-in model?
Normally, there are 2 requirements for us to create a new AppDomain for
the
plug-in assemblies:
1. Needs unloading support of plug-in assemblies
2. Needs a separate sandbox security environment to host the plug-in
assemblies
If you do not have these 2 requirements, I do not think you need to create
a separate AppDomain. You may just use Assembly.Load() method to load your
plug-in assemblies dynamically in your default AppDomain.
Yes, AppDomain.AppendPrivatePath() method is obsolete in .Net2.0, however,
you may set the probing path in the app.config file through <probing>
element. Please refer to the link below for more details:
http://msdn2.microsoft.com/en-us/library/823z9h8w.aspx
The link below documents the offical search paths of Assembly.Load method:
"How the Runtime Locates Assemblies"
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx
If you really wanted to leverage the new AppDomain model to load the
plug-in assemblies into the separate AppDomain for security and unloading
benifit, I recommend the following good article written by CLR developer
"Shawn Farkas", it provided a complete steps and source code of adopting
this model.
"Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET
Framework 2.0"
http://msdn.microsoft.com/msdnmag/is...s/default.aspx
In this scenario, you can not use the private probing path to specify the
"MyApp" directory for the new AppDomain, because private probing path must
be a sub-folder of the application base directory. However, you may set
the
new AppDomain''s ApplicationBase to the same folder("MyApp") as the main
AppDomain, so that the new AppDomain(plug-in assemblies) can locate the
assemblies in this folder.
Finally, using multiple AppDomains is not a big overhead. Asp.net
leverages
the same model: if you create multiple web applications on a Asp.net web
site, it will create a separate AppDomain for each web application to
handle the request.
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
Hi Eric,
Thanks for your feedback!
#1, >the problem I have with that is that I don''t know the exact path of
the AddIn until my application is running
Yes, I see your concern. However, Assembly.Load() method does not need the
absolute path of the Addin, you need to set the relative path to the Addin
through <probingin the app.config file(I assume you know of the relative
directory structures of Addin). Only Assembly.LoadFrom() method needs the
absolute path of the Addin. Please refer to the link below for more
information:
http://blogs.msdn.com/suzcook/archiv.../29/57143.aspx
#2, >The real problem is that the AddIn might have its own dependent DLLs
that>are installed with it in its directory and when it tries to load its
dependent DLLs the AddIn can''t search its own directory.
Sorry, do you mean this when using new AppDomain or using single AppDomain?
I assume you are talking under the context of single AppDomain. In this
scenario, once you have set the <probingto the "AddIns\AddIn1" relative
path, the entire AppDomain CLR code will probe the "AddIns\AddIn1" folder
for future using. So this is not a problem. To provide this, I have created
3 sample projects:
1. ClassLibrary1 (Class Library) with code below:
namespace ClassLibrary1
{
public class Class1
{
public static int Add(int a, int b)
{
return a + b + ClassLibrary2.Class1.Multiply(a, b);
}
}
}
2. ClassLibrary2 (Class Library) with code below
namespace ClassLibrary2
{
public class Class1
{
public static int Multiply(int a, int b)
{
return a * b;
}
}
}
3. ProbingDllTest (Winform App)
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(ClassLibrary1.Class1.Add(5, 6).ToString());
}
Now, I added an App.Config to the ProbingDllTest winform project with
setting the relative probing path:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="AddIns\AddIn1"/>
</assemblyBinding>
</runtime>
</configuration>
Finally, after building these 3 projects, I go into
"ProbingDllTest\bin\Debug" and I moved the ClassLibrary1.dll and
ClassLibrary2.dll into the "ProbingDllTest\bin\Debug\AddIns\AddIn1"(yes, I
created the similar directory structure as you). When I click
"ProbingDllTest.exe", all can work well. This means ProbingDllTest.exe can
find "ClassLibrary1.dll" without any problem, and "ClassLibrary1.dll" can
find "ClassLibrary2.dll" without any problem either. If I have
misunderstood your point, please feel free to tell me, thanks.
#3, >>setting the>>ApplicationBase to MyApp and then I believe there is a way to set search
paths to a new AppDomain.
I assume you mean you have created a new AppDomain and set the
AppDomainSetup.ApplicationBase to "MyApp" base directory, you want to know
how to tell the new AppDomain to search the Addin sub-directory. If I have
misunderstood you, please feel free to tell me.
Since you have set AppDomainSetup.ApplicationBase to "MyApp" base
directory, CLR will always probing "MyApp" base directory assemblies
without any problem. To set to another sub-directory(Addin), you may use
AppDomainSetup.PrivateBinPath property. This property has the same effect
as <probingelement in app.config
If you still have anything unclear, please feel free to tell me, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
这篇关于如何使用AppDomains并向其添加搜索路径？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
