What's the point of dynamically loading an assembly? Isn't it just way simpler to just reference it in your solution/project, saving you all the calls to Assembly.*Load* functions?
Update: Is it useful outside of plugins? What about exclusively in web development, what uses would I find there for dynamically loading an assembly?
Dynamically loading an assembly is useful for anything requiring execution of external code that might not even exist when the hosting program is developed.
For instance, any plug-in system will have to use that feature.
What if you want to make it possible to write plugins for your application, which get loaded at runtime and you don't have that project at compiletime?
You may not have that assembly when you compile your code, think of plugins for instance. You can't compile with a reference to them. Other reason is generating and compiling code and then loadin that Advanced stuff but real use.
GJ
Related
I'm trying to change a method in a compiled C#-asp.Net web application. is it possible to somehow override a method inside a compiled dll ?!
I did reflect the dll, but it has tons of references and has been referenced tons of times, so I do not think, even if it is possible because of the hundreds of errors in Visual Studio, recompile the dll would be a good soloution.
Basically what I need to do is to change a FormatDateTime method inside a core dll to add support for an unsupported calendar (date format).
and of course I have access to the server of the application, and I can do what ever I want in Administrator level.
can someone guide me in a direction ?!
You can override the method only if it is virtual, and it doesn't matter whether you do it through reflection or statically.
It think that the best thing you can do is use a decompiler and fixe the code in MSIL. Then you can generate a new assembly from the MSIL.
For a decompiler, you can use the Telerik JustDecompile is simply awesome: http://www.telerik.com/products/decompiler.aspxI
Our team works on Modules that have dependencies to different assemblies. E.g. We have a EmailClient Module that uses one set to assemblies for one particular build and another set of completely different assemblies for another build. That's because depending on the customer we integrated to different backends.
We want to keep one source tree for the EmailClient and make sure the "Latest" version always works for all customers. Our challenge here, is to not distribute unnecessary assemblies to one set of customers. As they get picky and ask what all these other files are for.
This is causing the following error and is very difficult to catch in one place:
System.IO.FileNotFoundException: Could not load file or assembly.
Does .Net provide such a feature where we can add reference to all sorts of assemblies, but not distribute some of them?
You should look at a plugin architecture like Managed Extensibility Framework (MEF) http://msdn.microsoft.com/en-us/library/dd460648.aspx
This way you can expand your current application without creating dependencies to assemblies.
Even if you're not planning to implement MEF. It will gives ideas and new ways to think, about how to implement it your own.
How can I correctly reference a C# DLL that I don't have physical access to? (I actually have the DLL, just not all it's dependencies.)
Background:
On the target computer, there is a program and many interdependent dll files installed in C:\FancyProgram.
I need to write a simple application that will be deployed on the target computer to C:\SimpleProgram.
This simple program will need to make some calls into one of the dll files under C:\FancyProgram. It is a .net managed DLL
On my development machine, I do not have a copy of FancyProgram. I do have that one DLL file, but I do not have any of it's many dependencies. I also can not bundle that DLL into SimpleProgram.
What is the correct method to use and reference this DLL in my Visual Studio project such that my SimpleProgram will correctly compile but load the DLL at runtime from the correct location?
Thank you
My recommendation is to create a Facades for the functionality you want to use from that dll. And don't use (reference) it directly - resolve and load it dynamically:
C# - Correct Way to Load Assembly, Find Class and Call Run() Method
Load Assembly at runtime and create class instance
.Net will do late binding anyway. As long as you don't reference the .dll in any way until you actually mean to load it this will work.
Simply encapsulate all references (fields, properties, methods, instances) into a spearate class or project and make an instance only when you have to. You can then try-catch the load error.
See Visual Studio Output window when your app is run, it will tell you when its is attempting to load what .dll.
You may also want to look at these events to make your app handle errors gracefully:
AppDomain.CurrentDomain.AssemblyLoad += ...;
AppDomain.CurrentDomain.AssemblyResolve += ...;
AppDomain.CurrentDomain.UnhandledException += ...;
AppDomain.CurrentDomain.FirstChanceException += ...;
You may also want to take the MEF approach. It is a framework for doing late loading/binding.
You might want to look at the details of LoadLibrary, GetProcAddress and Marshal.GetDelegateForFunctionPointer.
I would also build dll for testing locally, with the same interface as your external dll. How much functionality yo put in there depends on the complexity of the interface and your SimpleProgram.
There were some excellent answers to my old question about importing external dlls.
Uhhhh, what are you going to do about testing it? Assuming you've figured that out you need to make sure that either the .dll is in the GAC and reference it that way (ideally) or the .dll needs to be in the same place on all computers. Add the .dll in your references and mark it as Copy Local: false, so you don't deploy it. Good luck.
What are the implications and suggested scenarios to use either?
Assembly.Load is a dynamic reference since you're dynamically loading an external DLL at run-time. You would consider a static reference more like when you're adding a reference to a .NET project and building the project with that reference in place.
EDIT:
From the MSDN Doc:
The compiler records static references
in the assembly manifest's metadata at
build time.
Hmmm, not sure about this one myself. I'll keep my answer here for now, in the hope of getting more correction comments or seeing better answers.
In reference to:
What are the implications and
suggested scenarios to use either?
Usually, if I use Assembly.Load(), it is because I am developing a pluggable system. Dynamic references facilitate inclusion of assemblies that are not necessarily part of my build.
Instantiating types from a dynamically loaded assembly requires at least some reflection. The amount of reflection necessary can be mitigated by ensuring that dynamically-loaded types implement some known interface or base class (from a statically-loaded assembly).
In short, it's a lot of work to use dynamically loaded assemblies; however, doing so can make an application more flexible by allowing users to develop plug-ins. Just weigh the trade-offs of the anticipated flexibility of dynamic references (which may not be a requirement), and design-time support from Visual Studio for static references.
A practice worth consideration if building a plug-in architecture is to load assemblies in their own AppDomains. Doing so permits you to have finer-grained control over the security permissions of assemblies you may not entirely trust, and provides the added benefit that the assemblies can be unloaded at run-time. Personally, I found working with AppDomains to be labor-intensive; however, if the benefits are required, it's good to know that AppDomains are there.
A dyanamic reference as stated in the MSDN(http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx) references dynamic referencing as loading a reference with only enough information that the runtime has to search for the assembly being loaded. With static references, the location of assemblies(GAC, application direcotry, etc) are known and can be still accomplished using Assembly.load.
I am running on Windows CE and using the Compact Framework. I need to get a list of all reference assemblies that my application has loaded. It would be nice to be able to get to the AssemblyName (object) of these assemblies.
An example is like getting my running assembly by doing: Assembly.GetExecutingAssembly(); except I need to get the reference to all the other loaded assemblies (3rd party Dlls).
The full framework has the Assembly.GetExecutingAssembly().GetReferencedAssemblies() method but it's not available on the Compact Framework. Any help would be appreciated.
Based on this it would appear that managed dll's are not truly 'loaded' in the sense that they are in the conventional framework. Instead the IL is memory mapped and the JIT just grabs what it needs as it goes along (saving having to maintain a load of memory for code that has executed but is no longer used)
This would explain why the CF provides no way to iterate over the loaded dll's. As to why it doesn't allow iterating over the referenced dlls which are an entirely complie time construct...
As a possible work around:
Use GetExecutingAssembly to get the active code. Ensure that this happens in your executable so it gets the root assembly.
Write some code capable of parsing the dll for the manifest indicating which assemblies are referenced (this need not be managed code - the unmanaged introspection API microsoft provides may even do this for you and the dll format specification is both public and unlikely to radically change in the near future). I suggest black listing dll's loaded from the GAC (though this may be unnecessary).
I guess if there is no API to do this you can try this out ...
Remember, this is not a good way to do this ...
Look for PInvoke calls in Windows CE and call those to figure out what dlls are loaded by the process.
Then iterate through the dlls to check if they have a CLI header. Or you can just try to load the dll as assembly, if it loads then it is a .NET assembly loaded by the application.
I know its not a right way to do this, but this might work.