I am trying out the Managed Extensibility Framework for the first time in Visual Studio 2010 beta 2 using the System.ComponentModel.Composition from .net-4.0.
I have been unable to get the CompositionContainer to find my implementation assemblies using the two alternative routines below.
First attempt (this worked in an older codeplex release of MEF):
var composition = new CompositionBatch();
composition.AddPart(this);
var container = new CompositionContainer(new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory));
container.Compose(composition);
Second attempt (this worked in beta 1, I think):
var aggregateCatalog = new AggregateCatalog(
new AssemblyCatalog(Assembly.GetExecutingAssembly()),
new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory));
var compositionContainer = new CompositionContainer(aggregateCatalog);
compositionContainer.ComposeParts(this);
Is there a new way to do this in beta 2?
EDIT: It turned out to be nothing to do with the composition. I had a static property representing my imported implementation:
[Import] public static ILog Log { get; set; }
which should have been:
[Import] public ILog Log { get; set; }
I marked Daniel's answer as accepted because the sage advice of debugging in a more thorough fashion solved the problem.
What is failing? Is there an import you expect to be satisfied which is not being satisfied? Are you calling GetExports() and it is failing?
You can break in the debugger after the catalog has been created, and mouse over the aggregateCatalog variable to inspect it and see what parts are in it. My guess is that the parts are probably in the catalog, and the problem is somewhere else in your code. A likely cause is that you have a collection import which is using the [Import] attribute instead of [ImportMany], and/or that your parts are being rejected because they have imports that can't be satisfied.
I you take a look at the Compose method in the SoapBox Core Host, you can see it using a DirectoryCatalog to find all parts in the directory. However, this isn't compiled against .NET 4, just against the preview release of MEF:
private bool Compose()
{
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog("."));
_container = new CompositionContainer(catalog);
try
{
_container.ComposeParts(this);
}
catch (CompositionException compositionException)
{
MessageBox.Show(compositionException.ToString());
return false;
}
return true;
}
Related
I used to have some code which scanned the bin directory of my application for assemblies which weren't loaded in the AppDomain yet and loaded them. It basically looked like:
foreach (var assemblyPath in Directory.GetFiles("path\to\bin", "*.dll"))
{
var inspected = Assembly.ReflectionOnlyLoadFrom(assemblyPath);
Assembly.Load(inspected.GetName());
}
I skipped the try/catch clauses, etc for brevity.
This allowed me to drop assemblies in the bin folder at run-time with implementations for certain interfaces and let the IoC container pick them up automatically. Now with the new Roslyn magic, there are no physical DLL's anymore when debugging. Is there any way to retrieve assembly names, project names or dependency names (in project.json) dynamically.
I guess I have to implement something like this example in the Entropy repo, but I don't know how to implement it for my scenario.
You can use the IAssemblyLoadContextAccessor interface to load ASP.NET 5 class library (.xproj) projects dynamically. The following example code works with Beta 4:
public class Startup
{
public void Configure(IApplicationBuilder app)
{
var assemblyLoadContextAccessor = app.ApplicationServices.GetService<IAssemblyLoadContextAccessor>();
var loadContext = assemblyLoadContextAccessor.Default;
var loadedAssembly = loadContext.Load("NameOfYourLibrary");
}
}
What you are looking for is ILibraryManager implementation which provides access to the complete graph of dependencies for the application. This is already flowed through the ASP.NET 5 DI system. So, you can reach out to it from there.
Sample usage can be found inside RoslynCompilationService.
I solved this issue partly using the ILibraryManager as suggested by #tugberk. I changed the approach a bit which dropped the need of scanning the bin folder for new assemblies. I just want all the loaded assemblies in the current AppDomain.
I injected an instance of the ILibraryManager interface in my type finder class and used the GetReferencingLibraries() method with the name of the core assembly, which is referenced by all the other assemblies in the application.
A sample implementation can be found here, where this is the important part:
public IEnumerable<Assembly> GetLoadedAssemblies()
{
return _libraryManager.GetReferencingLibraries(_coreAssemblyName.Name)
.SelectMany(info => info.Assemblies)
.Select(info => Assembly.Load(new AssemblyName(info.Name)));
}
For .net core users, here is my code for loading assemblies from a specific path. I had to use directives, as it's slightly different for .Net Framework and .Net Core.
In your class header you'll need to declare the using something similar to:
#if NET46
#else
using System.Runtime.Loader;
#endif
And in your function something similar to the following:
string assemblyPath = "c:\temp\assmebly.dll";
#if NET46
Assembly assembly = Assembly.LoadFrom(assemblyPath);
#else
AssemblyLoadContext context = AssemblyLoadContext.Default;
Assembly assembly = context.LoadFromAssemblyPath(assemblyPath);
#endif
Its not ASP.NET but it can be converted easily to asp.net.
bellow if function for loading an assembly, and invoke a method inside a class on that assembly.
private static FormCustomized loadLayout(global::System.String layoutFilename, global::System.String layoutNameSpace)
{
FormCustomized mainForm = default;
Type typeMainLayout = default;
FileInfo layoutFile;
layoutFile = new FileInfo(layoutFilename);
layoutFile.Refresh();
if (!layoutFile.Exists)
{
MessageBox.Show("Layout file not found. You need to reinstall the program");
return default;
}
try
{
Assembly assemblyRaw = Assembly.LoadFrom(layoutFilename);
AssemblyLoadContext context = AssemblyLoadContext.Default;
Assembly assembly = context.LoadFromAssemblyPath(layoutFilename);
Type typeMainLayoutIni = assembly.GetType(layoutNameSpace + ".initializeLayoutClass");
Object iniClass = Activator.CreateInstance(typeMainLayoutIni, true);
MethodInfo methodInfo = typeMainLayoutIni.GetMethod("AssembliesToLoadAtStart");
enVars.assemblies = (Dictionary<string, Environment.environmentAssembliesClass>)methodInfo.Invoke(iniClass, default);
typeMainLayout = assembly.GetType(layoutNameSpace + ".mainAppLayoutForm");
mainForm = Activator.CreateInstance(typeMainLayout, enVars) as FormCustomized;
}
catch (Exception ex)
{
return default;
}
return default;
}
I have a console application project with NUnit tests in the same project.
I have been trying to apply this solution.
At run-time the solution worked OK. But when I ran the tests by Resharper test runner or NUnit GUI runner, GetExecutingAssembly().Location returned a path like this: d:\Temp\f4ctjcmr.ofr\nojeuppd.fmf\R2Nbs\assembly\dl3\9766f38e\b9496fb3_43cccf01\.
Disabling shadow-copying fixed the problem in both test runners, but new problems appeared (VS is not able to build the project until NUnit Gui is closed). Is there a better solution than disabling shadow-copying?
Update: Environment.GetCommandLineArgs()[0] returned C:\Program Files (x86)\NUnit 2.6.3\bin\ in the tests running in NUnit Gui with shadow-copying enabled.
Alright, this goes into fun territory.
You should be mocking out this dependency.
Example code:
public interface IApplicationRootService {
Uri GetApplicationRoot();
}
public class ApplicationRootService : IApplicationRootService {
public Uri GetApplicationRoot() {
//etc
}
}
Now, apply liberally to your code where you're calling getexecutingassembly and whatnot. Inject the IApplicationRootService as a constructor dependency.
Ex:
public class DoWork {
private IApplicationRootService _applicationRootService;
public DoWork(IApplicationRootService applicationRootService) {
_applicationRootService = applicationRootService;
}
public void DoSomething() {
var appRoot = _applicationRooService.GetApplicationRoot();
//do your stuff
}
}
Now when you're testing, use a mocking service and mock out the return value of application root to the appropriate folder for nunit to go sniffin'.
Ex code, using nunit and moq:
[Test]
public static void test_do_something() {
var applicationRootService = new Mock<IApplicationRootService>();
applicationRootService.Setup(service => service.GetApplicationRoot()).Returns(new Uri("MyRoot", UriKind.Relative);
var myClass = new DoWork(applicationRootService.Object);
//continue testing!
}
The following solution worked for me. Please vote to its author if it helps you.
As explained in the MSDN forums post, How to convert URI path to normal filepath?, I used the following:
// Get normal filepath of this assembly's permanent directory
var path = new Uri(
System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().CodeBase)
).LocalPath;
I have a huge application where one project of my solution makes reports.
I want to add new report (update report) without building my project, just add .dll files. I read about Assembly and
AppDomain, but I don't know is it really good way to add new dll for new report and how to update old report in runtime?
Here's my example, it takes my first dll, but second time it doesn't. First dll - sum, second - deducted.
static void Main(string[] args)
{
try
{
//first domain
AppDomain domain = AppDomain.CreateDomain("MyDomain");
AssemblyDll asb1 = new AssemblyDll();
Console.WriteLine(asb1.AssemblyMethod(1));
AppDomain.Unload(domain);
Console.ReadKey();
//second domain
AppDomain newDomain = AppDomain.CreateDomain("myNewDomain");
AssemblyDll asb2 = new AssemblyDll();
Console.WriteLine(asb2.AssemblyMethod(2));
AppDomain.Unload(newDomain);
Console.ReadKey();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
public class AssemblyDll
{
public string AssemblyMethod(int version)
{
//loading .dll
Assembly assembly = Assembly.LoadFrom(#"../../../../Assembly/DynamicDLL" + version + ".dll");
Type type = assembly.GetType("DynamicDLL.Dynamic");
object instance = Activator.CreateInstance(type);
MethodInfo[] methods = type.GetMethods();
//invoke method
object result = methods[0].Invoke(instance, new object[] { 5, 3 });
return result.ToString();
}
}
My .dll file comes from:
namespace DynamicDLL
{
public class Dynamic
{
public int DynamicMethod(int a, int b)
{
return a + b;
//return a - b;
}
}
}
If you want to write something like plugins and like the plugin approach, you should take a look at MEF http://msdn.microsoft.com/en/library/vstudio/dd460648.aspx
MEF allows you to use any assembly dynamically and even drop dlls into a folder and build a MEF catalog out of it.
Actually Visual Studio and uses MEF internally for extensiblility (Plugins...)
Assemblies are generally loaded into an AppDomain once and you cannot unload them once loaded.
You can create a new AppDomain and load your assemblies into this and when you release this the assemblies will be unloaded. However the caveat here is you cannot directly communicate between two AppDomain you have to marshal between the two using some other method like remoting.
There's been much wrote on this in terms of plugins and making plugins unloadable, a quick Google search presented these:
http://www.brad-smith.info/blog/archives/500
http://adrianvintu.com/blogengine/post/Unloadable-plugins.aspx
Hopefully these will aid you.
I am working a WPF application that uses MEF. But even when I run the below code(As a test code snippet some where in the code), the catalog is always empty. All the sample codes have done the same thing, those are working fine. but mine is not working. I am missing something important that I can not figure out on my own. So,I want some help on this.
var catalog = new AggregateCatalog();
var x = Assembly.GetExecutingAssembly().Location;
catalog.Catalogs.Add(
new DirectoryCatalog(
Path.GetDirectoryName(
Assembly.GetExecutingAssembly().Location)));
CompositionContainer container = new CompositionContainer(catalog);
This is the actual scenario code. there are 3 projects in the same solution.
W PF Project.
Extension Project.
Contract Project.
Extension project contains the Exports. and the contract project contains the interfaces shared by the W PF project and the Extension project.
[Export("LoginManager", typeof(IEmployeeLoginManager))]
public class LoginManager : IEmployeeLoginManager
{
public EmployeeLoginModel LoginEmployee(String userName, string password)
{
DEmployeeLoginManager employeeLoginManager = new DEmployeeLoginManager();
return employeeLoginManager.LoginEmployee(userName, password);
}
}
this Export is used in the WPF project as belows,
public partial class LoginWindow
{
public EmployeeLoginModel LoggedInEmployee;
[Import("LoginManager",AllowDefault = true)]
private IEmployeeLoginManager LoginManager;
public LoginWindow()
{
InitializeComponent();
}
private void RadWindow_Closed_1(object sender, Telerik.Windows.Controls.WindowClosedEventArgs e)
{
Application.Current.Shutdown();
Environment.Exit(0);
return;
}
private void RadButton_Click_1(object sender, RoutedEventArgs e)
{
string passWord = PasswordText.Password;
LoggedInEmployee.Password = passWord;
var container = MEFLoader.GetMEFContainer();
container.ComposeParts(this);
EmployeeLoginModel employee= LoginManager.LoginEmployee(LoggedInEmployee.UserName, passWord);
if (employee.LoginStatus == true)
{
this.Close();
}
}
PS: This is the MEFLoader Class:
public static class MEFLoader
{
public static CompositionContainer GetMEFContainer()
{
var catalog = new AggregateCatalog(new DirectoryCatalog("."), new AssemblyCatalog(Assembly.GetExecutingAssembly()));
var container = new CompositionContainer(catalog);
return container as CompositionContainer;
}
}
I am new to MEF and I appreciate any improvement point as well in my code.
thanks in advance.
First I thought parts in other projects that are in the same solutions are identified automatically by code snippet shown below.
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(
new DirectoryCatalog(
Path.GetDirectoryName(
Assembly.GetExecutingAssembly().Location)));
CompositionContainer container = new CompositionContainer(catalog);
but it is not like that, we have to manually place the dll in the executing projects bin/debug(since this is running in the debug mode)
or what you have to do is, you have to change the project properties=> build events => post built event command line to
copy $(TargetPath) $(SolutionDir)\[Your running application folder]\bin\Debug
this will automatically copy the necessary dlls to the executing bin.
OR you can change it in the project properties=> build => output path, you can set the output path to the Debug folder of the executing project.
I'm trying to create a sandboxed AppDomain for loading extensions/plugins. I have a MarshalByRefObject that in instantiate inside the appdomain to load the dll. I'm getting SecurityExceptions when trying to load the dll and I can't figure out how to get around them while still limiting what the third party code can do. All my projects are .net 4.
The InDomainLoader class is in a fully trusted domain, the method is marked SecuritySafeCritical. From everything I've read, I think this should work.
Here is my Loader class that creates the AppDomain and jumps into it:
public class Loader
{
public void Load(string dll, string typeName)
{
Log.PrintSecurity();
// Create new AppDomain
var setup = AppDomain.CurrentDomain.SetupInformation;
var permissions = new PermissionSet(null);
permissions.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
var strongname = typeof(InDomainLoader).Assembly.Evidence.GetHostEvidence<StrongName>();
var strongname2 = typeof(IPlugin).Assembly.Evidence.GetHostEvidence<StrongName>();
AppDomain domain = AppDomain.CreateDomain("plugin", null, setup, permissions, strongname, strongname2);
// Create instance
var loader = (InDomainLoader)domain.CreateInstanceAndUnwrap(
typeof (InDomainLoader).Assembly.FullName, typeof (InDomainLoader).FullName);
// Jump into domain
loader.Load(dll, typeName);
}
}
And here's the bootstrap loader that runs in the domain:
public class InDomainLoader : MarshalByRefObject
{
[SecuritySafeCritical]
public void Load(string dll, string typeName)
{
Log.PrintSecurity();
var assembly = Assembly.LoadFrom(dll); // <!-- SecurityException!
var pluginType = assembly.GetType(typeName);
var demoRepository = new DemoRepository();
var plugin = (IPlugin)Activator.CreateInstance(pluginType, demoRepository);
Console.WriteLine(plugin.Run());
}
}
Some logging statements tell me that the assembly's IsFullyTrusted is true and the method has both IsSecurityCritical and IsSecuritySafeCritical set to true, IsSecurityTransparent is false.
I zipped up the whole project to http://davidhogue.com/files/PluginLoader.zip in case that makes this easier.
If anyone has any ideas, I'd be very grateful. I seem to be stuck at a dead end here.
Well for a start you probably shouldn't be marking the function as SecuritySafeCritical as that implies untrusted callers can call you, which you probably don't really want (not that it should be a major issue).
As for your problem the issue is that by default you still don't run with any special permissions, the normal easy way to do the assembly loading is you create your own AppDomainSetup and point it's ApplicationBase at a Plugin directory of some kind (which isn't a bad idea in general), you can then use the normal Assembly.Load("AssemblyName") to load out of the base. However if you must load an arbitrary file then you need to assert FileIOPermission for the plugin dll (full path), i.e.
private Assembly LoadAssemblyFromFile(string file)
{
FileIOPermission perm = new FileIOPermission(FileIOPermissionAccess.AllAccess, file);
perm.Assert();
return Assembly.LoadFile(file);
}