Application cannot find injected assembly, which is mentioned in App.config

Aug 8, 2014 at 8:42 AM
I am using scenario 1 (inject all dlls) for a Microsoft Prism WPF application. When the libz'ed application starts, I get an error, that 'Microsoft.Prcatices.Prism.Composition can not be found'.
This assembly and all required assemblies are already injected and this assembly is mentioned in the App.config in a '<configsections><section name=".." type="...">...' entry.
Now my question: Can libz handle this scenario ? When 'YES', how can this be done ?

Thank you.
Aug 8, 2014 at 11:01 AM
There is nothing I could think of.
You skipped the important part. Include App.config.
Do you use partial names? As documentation for scenario says: "NOTE: injecting dll (skipping the container part, see below) injects very simple assembly resolver. It is actually that simple that it cannot resolve assemblies by partial names."

NOTE: I'm going for holiday (off-the-grid) for two weeks, so unfortunately if you don't hurry you won't get another answer soon.
Aug 8, 2014 at 11:11 AM

thank you for the fast response !!!!
I try to add modules to a module catalog using the App.config.

<?xml version="1.0" encoding="utf-8"?>
<section name="modules" type="Microsoft.Practices.Prism.Modularity.ModulesConfigurationSection, Microsoft.Practices.Prism.Composition" />

Thanks. Otherwise nice holidays!
Aug 8, 2014 at 11:35 AM
Edited Aug 8, 2014 at 11:36 AM
As I thought. You DO use partial names: "Microsoft.Practices.Prism.Composition" is a partial name!

Partial name: MyCompany.AssemblyName
Full qualified name: MyCompany.AssemblyName, Version=, Culture=neutral, PublicKeyToken=b17a5c561934e089

So, scenario 1, as mentioned in documentation, DOES NOT work with partial names. Use other approaches or use fully qualified names.
Aug 8, 2014 at 11:37 AM
I will check this.
Thank you!
Aug 8, 2014 at 12:20 PM
Edited Aug 8, 2014 at 12:20 PM
It worked !!! All assemblies must have full qualified names. :-)
Dec 5, 2014 at 2:14 PM
Edited Dec 5, 2014 at 2:47 PM
I ran into the same issue. Using strong names in the config can be a pain (hard to read, may require updates if version changes etc.)
My work around was to add an AssemblyResolve handler in my main() that checks for types used in the config file and resolves their assemblies.
    static void Main(string[] args)
      AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

    static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
      if (args.Name.StartsWith("NLog"))
        return typeof(NLog.LogManager).Assembly;
      else if (...)
        return null;
This works like a charm. But it remains a work-around since it is not so stable. What if one references a new type in the config without adapting the AssemblyResolve?
I had a quick look into the zlib-modified assembly. There does not seem to be a way for reverse-lookup of which assemblies with which strong names are included. If one would want to support such a lookup also in loaded libz archives this would probably be even more complex.

BTW: There is already the issue 9 requesting this feature.
Dec 5, 2014 at 2:45 PM
I'm still recommending Scenario 4 though. It solves this problem.
Dec 8, 2014 at 9:31 AM
I wasn't aware that Scenario 4 would solve the issue but after reading your remark and then the note of Scenario 1 it became clear to me. This is indeed the better solution. Still, it would be nice to have partial names also in Scenario 1 one day.