ConfigurationExamplePlugin example code assembly code could not be found
nshCore opened this issue · 5 comments
Hi I am trying your example code for configuration plugins
https://github.com/autofac/Examples/tree/master/src/ConfigurationExample
When trying to run the example solution I face this error
Unhandled Exception: System.InvalidOperationException: The type 'ConfigurationExamplePlugin.ExternalPlugin, ConfigurationExamplePlugin' could not be found. It may require assembly qualification, e.g. "MyType, MyAssembly".
at Autofac.Configuration.Core.ConfigurationExtensions.GetType(IConfiguration configuration, String key, Assembly defaultAssembly) in C:\projects\autofac-configuration\src\Autofac.Configuration\Core\ConfigurationExtensions.cs:line 221
Stating the assembly can not be found.
If I reference the external plugin in the ConfigurationExample.csproj then the plugin loads fine. but this defeats the point of loading it from a configuration.json also it is not logical that the IoC should be aware of external code like this.
I did bump the version of dotnetSDK in the global.json to match my installed version of 2.2.103. But I can not imagine this is the issue. Am I missing something? I am trying to run on an ubuntu platform.
Did you build the whole solution or just the one project? The project isn't standalone and while the plugin assembly ConfigurationExamplePlugin is copied to the ConfigurationExample application as a post-build event of ConfigurationExample, no copy will happen if ConfigurationExamplePlugin isn't built first.
I built the following three solutions
ConfigurationExample
ConfigurationExampleInterface
ConfigurationExamplePlugin
Which I would assume is what is needed.
Trying to build the entire project throws errors to do with MultitenantExample.WcfService/MultitenantExample.WcfService.csproj(126,3)
To further add to my initial comment the DLL is copied over during these steps, but will not work unless reference the plugin project in the csprto of the configuration example project
It will be a bit before I can get to this. It sounds like the assembly resolution event may not be behaving properly. If the plugin assembly is there, then try setting a breakpoint on the assembly resolve event handler and see if it's returning the right path to the assembly. It may be that in newer frameworks Directory.GetCurrentDirectory() isn't returning what it used to be; or maybe there's something else happening in your runtime environment that isn't accounted for.
Thanks will investigate this a bit more ourselves,
In the AssemblyLoadContext in program a quick Console log
Console.WriteLine(Directory.GetCurrentDirectory());
Console.WriteLine($"{assembly.Name}.dll");
Console.WriteLine(System.IO.Path.GetDirectoryName(typeof(Program).GetTypeInfo().Assembly.Location))
Shows the right path and, and find the default assembly, just not the external plugin dll
/srv/dev/Examples/src/ConfigurationExample
ConfigurationExamplePlugin.dll
/srv/dev/Examples/src/ConfigurationExample/bin/Debug/netcoreapp2.1
Hello, we found that the issue is actually quite simple. Environment.CurrentDirectory doesn't point to the bin/Debug/netcore2.1 sub folder when trying to run the .csproj directly from its folder using the dotnet CLI command
dotnet run ./ConfigurationExample.csproj
I have prepared a suggestion for a fix in this PR: #14