AppDomain.CurrentDomain.AppendPrivatePath Depreciated?

[Benny Raymond]

What should I do instead of this:
AppDomain.CurrentDomain.AppendPrivatePath(Path.GetDirectoryName(System.Windows.Forms.Application.ExecutablePath)
+ @"\plugins");


now that AppDomain.CurrentDomain.AppendPrivatePath is depreciated?

 

[David Levine]

You need to configure the private paths before the appdomain has been
created. You can do it by adding entries to the app.config file (for the
entire app or for each appdomain that is created by the app), or by adding
entries to the appdomain setup information that is used to construct
secondary appdomains. You can also subscribe to the
AppDomain.AssemblyResolve event and manually load assemblies using LoadFrom
(or one of its variants)....the disadvantage is assemblies loaded using
Loadxxx are in a different fusion load context then assemblies that the
runtime resolves automatically.

I've lobbied (unsuccessfully) for this API to remain as I use it in v1.1.

 

[Benny Raymond]

Since loading my plugins in a seperate domain wasn't sufficent for what
my app required, here's what I ended up doing. Please let me know if
i'm going about anything wrong. - Also, I can't figure out how to make
my plugins automatically compile into the plugins directory instead of
the main output one - please let me know if you know how to do this
(right now i'm using the post compile event)

I changed my main form so that it loads up as a stub executable, so my
exe ends up being really small and just consists of this:

namespace APPNAME
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
setup.PrivateBinPath = @"\,\Plugins";
setup.ApplicationName = "APPNAME";
AppDomain appDom =
AppDomain.CreateDomain("APPNAME",null,setup);
appDom.CreateInstanceFromAndUnwrap("APPNAME.Container.dll",
"APPNAME.Container.Program");
}

}
}

then, I start buliding my app as normal within the APPNAME.Container dll
- instead of your normal program.cs file it ends up looking something
like this:

namespace APPNAME.Container
{
[Serializable]
class Program
{
public Program()
{
Application.Run(new Form1());
}
}
}

 

[Benny Raymond]

How do you configure private paths in the app.config file? Do those
paths have to be absolute? (i hope not)

~Benny

 

[David Levine]

This links to the docs on the schema required for the app.config files.

http://msdn.microsoft.com/library/d.../cpgenref/html/gngrfruntimesettingsschema.asp

The <probing> element adds subdirectories to the search path.

Your .config file will have a section that looks like this...

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>

where each path component is a subdirectory under the application base
directory; delimit each relative path with a semi-colon. The paths are all
relative to the base directory.

This has a similar effect to adding these subdirectories using the
AppendPrivateBinPath API.

 

[David Levine]

The line of code:

setup.PrivateBinPath = @"\,\Plugins";

does not appear correct. Each separate relative path should be delimited
with a semi-colon, not a comma, and the relative path "\" does nothing so
far as I can tell. Also, you do not need to pre-pend a leading backslash. I
think you could replace that LOC with this...

setup.PrivateBinPath = @"Plugins";

Also, if the only thing your loader does is specify a relative search path
you could more easily add a <probing> element (see my other reply) to you
app.config file and not need the loader at all.