I'm having some...challenges...with assembly paths in M4A. Let me describe
what I'm doing, and what I'm seeing. Some of the behavior I understand, some I
don't.
I have three distinctly different scenarios where I'm having a problem, but
they are all rooted in the same behavior - dynamically loading local
configuration files and then dynamically loading compiled assemblies. Think of
them as configuration and then plug ins, where we derive from a known
interface, but the actual implementation could be in an assembly we know
absolutely nothing about during compile time (i.e. no project reference).
For example, the OpenNETCF IoC library has the ability to load assemblies based
on an XML configuration document. Basically the config document is put into
the same folder as the application and it describes modules to load (a la
SCSF), something along these lines:
<SolutionProfile>
<Modules>
<ModuleInfo AssemblyFile="ICM.Hosting.Module.dll" />
<ModuleInfo AssemblyFile="ICM.Infrastructure.Supervisor.dll" />
<ModuleInfo AssemblyFile="ICM.Simulation.Module.dll"/>
<ModuleInfo AssemblyFile="ICM.DataCollector.Module.dll" />
</Modules>
</SolutionProfile>
The AssemblyFile attributes name assemblies that are typically deployed with
the app, and since no pathing is given with the assembly, it is assumed to be
"in the same folder as the executing application". Each of these assemblies is
loaded via Reflection and some interface methods are called to initialize the
Module.
The pain point right now is finding the "folder from which we are executing".
A call to Assembly.GetExecutingAssembly().GetName().CodeBase returns different
things whether we're in Debug or Release, and the Release version looks to be a
hard-coded path on the machine that actually built the Mono runtime. Another
one of our devs did some chatting with Jon Pryor (thanks again Jon!) and we now
understand that the answer there is "Don't do that!". However, we still need
this functional behavior.
If I include the XML file in my project, how do I "find" it and load it? I
can't use an Asset, because the IoC library actually knows nothing about its
caller, except what it can divine through Reflection or Environment calls plus
I really want to keep the code base platform-agnostic. This is what I have so
far, but as you can see, the Android stuff is just a placeholder.
private bool LoadConfigFromFile()
{
string configPath;
if (Environment.OSVersion.Platform == PlatformID.Unix)
{
// what goes here???
}
else
{
configPath =
Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase);
if (configPath.StartsWith("file:\\")) configPath =
configPath.Substring(6);
}
configPath = Path.Combine(configPath, "ProfileCatalog.xml");
if (!File.Exists(configPath)) return false;
return false;
}
Is the solution, at this point anyway, to "force" the developer to use some
magic path (something like /root/IoC)? I'd love to allow them to set that path
via a Configuration file, but that's a Catch-22. I'm also thinking of adding a
"SetLoaderPath" to the RootWorkItem in IoC, but if a user doesn't make that
call, I'd like to have some sort of default.
I've got more questions regarding actual assembly loading, but I'll hold on
those until I figure this part out.
As a separate, but probably equally import part of this is where on earth are
my app files when I install an APK anyway? I get the feeling they remain in
the APK and are squirreled away somewhere on the device. Is there any
documentation online about the actual application and assembly startup/load
process?
-----------------
Chris Tacke
President
OpenNETCF Consulting, LLC
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
