• 0

C# Better & more efficient way to load DLL dynamically & get interf


Question

Hi,

Been using the code below to load a dll dynamically and get an instance of certain interface. This was done way back in .NET 2 days. What is a better & more efficient way to do this using .NET 4 functionality?


// Usage
ICountryHandler pCountryHandler = GetInstanceFromModule<ICountryHandler>("Company.Product.Country.Australia.dll");

public static TInterface GetInstanceFromModule<TInterface>(string AModuleName)
where TInterface : class
{
Assembly pAssembly;
ConstructorInfo pConstructor;
TInterface pInstance;
Type pInterface;
pAssembly = null;
if (AModuleName.Contains(Path.DirectorySeparatorChar.ToString()) || AModuleName.Contains(Path.AltDirectorySeparatorChar.ToString()) || AModuleName.Contains(Path.PathSeparator.ToString()) || AModuleName.Contains(Path.VolumeSeparatorChar.ToString()))
{
pAssembly = Assembly.LoadFrom(AModuleName);
}
else
{
pAssembly = Assembly.LoadFrom(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), AModuleName));
}
if (pAssembly != null)
{
foreach (Type pType in pAssembly.GetExportedTypes())
{
pInterface = pType.GetInterface(typeof(TInterface).ToString());
if (pInterface != null)
{
pConstructor = pType.GetConstructor(new Type[] { });
pInstance = pConstructor.Invoke(null) as TInterface;
if (pInstance != null)
{
return pInstance;
}
}
}
}
return null;
}
[/CODE]

TA :)

10 answers to this question

Recommended Posts

  • 0


pInterface = pType.GetInterface(typeof(TInterface).ToString());
if (pInterface != null)[/CODE]

I take it this tests if pType implements TInterface? I'd do:

[CODE]if (typeof(TInterface).IsAssignableFrom(pType))[/CODE]

Also rather than getting the default constructor and invoking explicitely, you could use Activator for that:

[CODE]
pConstructor = pType.GetConstructor(new Type[] { });
pInstance = pConstructor.Invoke(null) as TInterface;

// instead do
pInstance = (TInterface)Activator.CreateInstance(pType);[/CODE]

No need to use [font=courier new,courier,monospace]as[/font] and check for null since you just checked that pType implements TInterface: the cast must necessarily succeed.

None of this is .NET 4-specific but might allow you to cut down the number of lines a bit.

  • 0

You should divide that method into smaller methods - one to get the assembly from a string, one to get all types implementing an interface, and one to create an instance of all these types.

Your check for absolute path can be replaced with Path.IsPathRooted().

Also, stop using Hungarian notation...especially if you're not actually using the prefix but just using "p" at the beginning of everything. It's both ugly and useless. ( see http://msdn.microsoft.com/en-us/library/vstudio/ms229045.aspx - "Do not use Hungarian notation").

  • 0

Actually the biggest efficiency gains here would be by caching the results. Iterating all the types in an assembly can take a long time and you're doing it every time the method is called. Of course, measure your gains - how much time this method currently takes and how much you're saving (or wasting!) by doing things differently. You might find out this method takes an insignificant amount of time and you're just worrying for nothing.

  • Like 1
  • 0

Iterating all the types in an assembly can take a long time and you're doing it every time the method is called.

(Y)

Unless it's a once-off thing - then it's probably not worth overcomplicating it.

And just for fun, here's a LINQ version:

(PS: If you often need to test code snippets (not necessarily LINQ-related), LINQPad is invaluable)


public static TInterface GetInstanceFromModule<TInterface>() where TInterface : class
{
// Change this to load assembly from file
var pAssembly = Assembly.GetAssembly(typeof(TInterface));

// Magic!
if (pAssembly != null)
return pAssembly.GetExportedTypes()
.Where(t => t.IsClass)
.Where(t => typeof(TInterface).IsAssignableFrom(t))
.Select(t => (TInterface)Activator.CreateInstance(t))
.FirstOrDefault();

return null;
}
[/CODE]

Edit: It doesn't really increase efficiency, but does make it a lot easier on the eyes. And [i]slightly[/i] harder to debug :p

Edited by GreenMartian
  • 0

Thanks guys.

I am using hungarian notations as that is the coding practices where I work and I gotta follow their guidelines. I am going to implement few of these suggestions and see how things go. I am only calling this once for each DLL that I want to load and once they are loaded that is it.

I read somewhere to use newly introduced dynamic key word and use managed extensibility framework but I am stuck there... Any advice on that would be useful too.

Cheers :)

  • 0

Ah, didn't realise MEF is now built into .NET 4.

From your example, it looks like you're looking more into Dependency Injection (DI). From what I remember, MEF does it to some extent, but is more geared towards supporting extensions (I haven't actually used it, but did some reading on it a couple years ago, so feel free to correct me).

There are multiple frameworks that provide DI Containers. Personally, I've only used Castle Windsor. There's also Unity, and a few others.

Setup properly, DI containers make it ridiculously easy to inject interface implementations to other classes.

In a nutshell, you basically tell it once, at the start of your app, to load a config from an xml file like so:

container.Install(Configuration.FromXmlFile("settings.xml")

With the xml file looking something like

&lt;configuration&gt;
&lt;components&gt;
  &lt;component service="Namespace.ICountryHandler, AssemblyNameOfInterface"
	type="Namespace.AustralianHandler, AssemblyNameOfImplementor" /&gt;
&lt;/components&gt;
&lt;/configuration&gt;

And everywhere else in the code when you have a property of type ICountryHandler, you'll get the Australian handler.

PS: Thanks for mentioning MEF. I might revisit it and see what MS have been up to. There goes my weekend!

This topic is now closed to further replies.
  • Posts

    • "Of course the easiest solution is to switch to uBlock Origin Lite if you want to remain on Chrome, as it is MV3-based, but from our experience, uBO Lite does not seem to be as good as the original non-Lite version" In my experience uBlock Origin Lite does the job for normal everday home users. When they kill that we get to watch Firefox and Brave get a boost in user market share.
    • Block by DNS ad blocker! I dare you! I will even layer unlock Origin, on top of my internal DNS, if I need to and I don’t even block ads today (I really should but this type of behavior makes me angry). I suppose I could also just be lazy, and add the flags myself, back to each release (it wouldn’t be that difficult).
    • Wonder what MPs have ties to these privacy/verification/data harvesting companies that are going to step in this time. Last time under the Tories half the cabinet had fingers in the pies, heck even the PM and his wife at the time was working for silicon valley, probably made a fortune.
    • Google Chrome is killing all uBlock Origin bypasses, Microsoft Edge, Opera to follow by Sayan Sen For a while now the transition away from Manifest V2 (MV2) to MV3 has been on-going and it looks like it is entering its final phase of deprecation, at least, in the case of Google Chrome. A recent discussion thread in the w3c WebExtensions Community Group GitHub repo has highlighted how the latest and upcoming versions of the most popular browser are expected to be its final releases with support for MV2 extensions. Chromium contributor Andrey Bershanskiy shared details about recent Chromium changes and according to comments from Google engineer Devlin Cronin, Chrome has now started removing the flags that previously controlled MV2 availability. kExtensionManifestV2Disabled, the Chromium feature flag that allowed controlled disabling of MV2 add-ons, is now completely removed, which means you will likely no longer find uBlock Origin in your browser extensions list. He wrote: "The kExtensionManifestV2Disabled feature has been default-enabled for over a year. Remove the feature and the effectively-dead code. ... Any tests that relied on being in the "warning" phase (i.e., with the kExtensionManifestV2Disabled) for their sole behavior testing are removed, since this stage is no longer reachable." Cronin further explained why MV2 extensions are no longer allowed in supported Chrome versions as maintaining the associated functionality indefinitely is no longer possible. He cited growing technical difficulties and implementation complexities as well as security concerns. He wrote: "MV2 extensions are no longer allowed in any supported version of Chrome, and we are removing support for them and the associated functionality. We won't be able to provide / maintain this functionality indefinitely due to the complexity and tech debt, as well as the security risks it entails (we've actually found a number of bugs that are specific to MV2 lately). Of course, other browsers can continue supporting these if they so desire. Unfortunately, we won't be putting code behind a compilation flag ... We won't be removing all the MV2 code wholesale right away, so many of these things will continue working for awhile (but they will go away eventually, and some may go away sooner than others)." What this essentially means is that the tricks and bypasses that were used to keep MV2 extensions like uBlock Origin and others alive will not work any more on Chrome, or at least not for very long. For example the Windows Registry mod that could extend MV2 availability will cease to function after Chromium version 151. Here is a rundown of the changes coming in the final such releases of Chromium releases: Chromium 150 lost ExtensionManifestV2Disabled option Chromium 151 will loose ExtensionManifestV2Unsupported option Chromium 151 will loose ExtensionManifestV2Availability option Chromium 151 will likely loose AllowLegacyMV2Extensions option Other Chromium-based browsers like Opera and Microsoft Edge could soon follow suit too. Although it is not specified, Edge began disabling uBlock Origin back in February, and Opera could also stop the functioning of MV2 add-ons, even though it had committed to support MV2 for longer in October 2024. uBlock Origin developer Raymond Hill (gorhill) apparently stated the following: "For Opera I did submit 1.70.0 rather late, but this was weeks ago. A while ago I received an email from Opera that they plan to abandon MV2-based extension so maybe they are no longer allocating resources for reviewing such extensions." The email which developers like Gorhill mentions was received from Opera last year. Here is what it seemingly said: Hence for now the only Chromium browser that seems to be on-board fully with MV2 support is Brave, and perhaps Vivaldi as well. Meanwhile if you want to ditch Chromium browsers entirely then Mozilla Firefox is an excellent alternative as MV3 and MV2 are both supported. Of course the easiest solution is to switch to uBlock Origin Lite if you want to remain on Chrome, as it is MV3-based, but from our experience, uBO Lite does not seem to be as good as the original non-Lite version. Source: w3C (GitHub repo) As an online publication, Neowin too relies on ads for operating costs and, if you use an ad blocker, we'd appreciate being whitelisted. In addition, we have an ad-free subscription for $28 a year, which is another way to show support!
    • Write to your MP 😄 Like believing in Santa. Total surveillance IS the goal. Wake up.
  • Recent Achievements

    • One Month Later
      mobmobiles earned a badge
      One Month Later
    • Very Popular
      Captain_Eric earned a badge
      Very Popular
    • One Month Later
      amusc earned a badge
      One Month Later
    • One Month Later
      DJC50PLUS earned a badge
      One Month Later
    • Week One Done
      DJC50PLUS earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      510
    2. 2
      PsYcHoKiLLa
      219
    3. 3
      ATLien_0
      92
    4. 4
      +Edouard
      90
    5. 5
      Steven P.
      82
  • Tell a friend

    Love Neowin? Tell a friend!