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.LoadFr om() 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\Add In1" relative
path, the entire AppDomain CLR code will probe the "AddIns\Add In1" 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.C lass1.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(o bject 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" ?>
<configuratio n>
<runtime>
<assemblyBindin g xmlns="urn:sche mas-microsoft-com:asm.v1">
<probing privatePath="Ad dIns\AddIn1"/>
</assemblyBinding >
</runtime>
</configuration>
Finally, after building these 3 projects, I go into
"ProbingDllTest \bin\Debug" and I moved the ClassLibrary1.d ll and
ClassLibrary2.d ll into the "ProbingDllTest \bin\Debug\AddI ns\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
>>ApplicationBa se 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 <probingeleme nt 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.
