Sounds like a dumb question I know, but bear with me :-) I'm currently creating a PoSh module which contains a few custom commands. I had already written a PoSh Advanced Module previously to do what I want to do, but I've decided it's time to take the plunge and learn C# !
One of my commands needs to create an instance of a class which is contained in a third party SDK assembly. That assembly is not contained in the GAC. In my PoSh Advanced Function previously, I would query a registry key to confirm that the SDK was installed (and get the path to it), then I would use System.Reflection.Assembly.LoadFile to load the assembly.
In my C# version, my plan was to do something similar. I've managed to query the registry, confirm that the assembly exists etc and even load it. However, because the assembly isn't referenced in Visual Studio, it just throws loads of intellisense errors when I try to instantiate a class from that assembly. I initially suspected I might need to use something from the Activator class to get around this, but I've been through all the methods there and couldn't find anything that might help.
After a bit more pondering, I wondered if perhaps my approach is wrong, and maybe I shouldn't be doing the "manual" loading but instead allow .net handle all that for me, eg by adding a reference to the assembly. In that case however, how do I reference an assembly in VS without knowing where (or even if) it will be installed on the target/invoking machine ?
Or, if my original approach is correct, how do instantiate the class "manually" (or otherwise) without VS being so unhappy. I did consider adding a "temporary" reference to the assembly on my machine, but I think I'd have to remove that again before doing the retail build. And I'd also have to add temporary using directives I guess.
I have googled this quite a bit, but haven't found anything that might help me at all. So I'd really appreciate any guidance anybody can provide. Maybe I should be looking at something else entirely, like App Domains ?
Thanks in advance
After loading assembly use CreateInstance method and store result in dynamic type variable:
dynamic test = assembly.CreateInstance("Full.Type.Name");
You'll not get intellisense, but compiler will assume that this variable supports any operation. Beware, invalid operations will result in errors only at runtime.
Related
I am on a hunt to write a program that will be able to read assembly code from a specified .exe . What i am trying to do is to read the assembly code of a executable, in order to find instructions that i can replace with equivalent instructions, in order to obtain different byte code.
This is generally called a source scrambler / signature scrambler, that modifies assembly code in order to obtain different byte code which results in different signatures.
I was reading about the Assembly class in C# , but did not find anything that could return something like a IEnumerable that contains assembly code from the .exe
Is there anyone that can educate me on this? Is this even possible? Different approaches?
.NET does not really deal with Byte Code. All .NET Programms are turned into somthing called MSIL that is executed by teh .NET Runtime and only then turned into bytecode. The whole process is very similar to how JavaBytecode works.
As a result you get full access to the names of anything. You can even use .NEt Executeables like a .DLL file. But replacing stuff is not easy, outside of inheritance or replacing of the files.
The kind of bitwise manipulation you propably need, requires working with naked pointers. And the .NET Developers went out of their way so you would no ever have to use naked Pointers. You can still use them using Unsface code, but as this sounds like the primary use of your programm you are propably better of starting with something like native C++ instead. Really anything taht uses naked pointers as default, rather then a fallback.
Going over some legacy code, I ran into piece of code that was using reflection for loading some dll's that their source code was available (they were another project in the solution).
I was cracking my skull trying to figure out why it was done this way (naturally the code was not documented...).
My question is, can you think about any good reason for preferring to load an assembly via reflection rather than referencing it?
Yes, if you have a dynamic module system, where different DLLs should be loaded depending on conditions at runtime. We do this where I work; we do a license check for different optional modules that may be loaded into our system, and then only load the DLLs associated with each module if the license checks out. This prevents code that should never be executed from being loaded, which can both improve performance slightly and prevent bugs.
Dynamically loading DLLs may also allow you to drastically change functionality without changing any source code. The main assembly may for instance set in motion a discovery process where it finds all classes that implement some interface, and chooses which one to use depending on some runtime criterion.
These days you'll typically want to use MEF for this kind of task, but that's only been around since .NET 4.0, so there are probably many codebases out there that do it manually. (I don't know much about MEF. Maybe you have to do this part manually there as well.)
But anyway, the answer to your question is that there certainly are good reasons to dynamically load DLLs using reflection. Whether it applies in your case is impossible to say without more details.
Without knowing you specific project, noone here can tell you why it was done that way in your case.
But the general reasons are:
updateability: You can simply recompile and replace the updated libary instead of having to recompile and replace the whole application.
cooperation: if the interface is clear, that way multiple teams can work together. one for the main application and others for the dlls
reusability: sometimes you need the same functionality in multiple projects, so the same dll can be used again and again
extensability: in some cases you want to be able to later extend your program with plugins that where not present at shipment time. This can be realized using dlls.
I hope this helps you understand some of your setup..
Reason for loading an assembly via reflection rather than referencing it?
Let us consider a scenario, where there are three classes with method DoWork() this method returns string, you are accessing it by checking the condition (strong type).
Now you have two more classes in two different DLL's how would you cope up the change?
1)You can add reference of new DLL's , change the conditional check and make it work.
2)You can use reflection , pass on condition and assembly name at run time, this allows you to add any number of functionality at runttime without any change of code in primary appliation.
Here's an example of the code which will be used for the reflection:
var i = typeof(Program).Assembly.CreateInstance("test.Program");
After the software is obfuscated, the code will obviously stop working.
I'm trying to find a way around it by searching for properties of a class, which do not change after obfuscation has been done. I've tried that with type.GUID, but when I run the debug version, I get one GUID, and in the release after the obfuscation is completed, the guid is changed.
I'm using Eazfuscator.NET for obfuscation.
I would like to avoid using attributes to mark class/method if possible.
Any ideas on what would work?
I'm sure there are ways to iterate over all types and find the one you're looking for, but the things that come to mind would all produce the least maintainable code ever.
Some obfuscators (we use DeepSea, I don't know Eazfuscator) allow preventing obfuscation of specific classes, allowing reflection on those. In DeepSea's case, this is indicated by attributes but those won't/shouldn't (I never checked :o) make it to the final assembly.
If you regard reflection as "an outside process looking at your assembly" and obfuscating "preventing outside processes from looking at your assembly" you're really stopping yourself from doing what you want to do.
don't want the obfuscator to defeat the attackers. Just make the job of understanding the code more difficult. And I want this as a part of advanced piracy protection
After obfuscation; zip, encrypt and do whatever you want with your assembly. Then create another wrapper project and add your assembly as a resource into that project. Attach to AppDomain.CurrentDomain.AssemblyResolve event (in your new project) and whenever an unresolved assembly event occurs, read your resource(decrypt,unzip etc.) and return the actual assembly.
You may also try to obfuscate your final wrapper application.
How secure? At least, you can make life more harder for attackers.
I don't have exact answer, but ILSpy's source might help you.
I am not sure the best way to explain this so please leave comments if you do not understand.
Basically, I have a few libraries for various tasks to work with different programs - notification is just one example.
Now, I am building a new program, and I want it to be as lightweight as possible. Whilst I would like to include my notification engine, I do not think many people would actually use its functionality, so, I would rather not include it by default - just as an optional download.
How would I program this?
With unmanaged Dlls and P/Invoke, I can basically wrap the whole lot in a try/catch loop, but I am not sure about the managed version.
So far, the best way I can think of is to check if the DLL file exists upon startup then set a field bool or similar, and every time I would like a notification to be fired, I could do an if/check the bool and fire...
I have seen from the debug window that DLL files are only loaded as they are needed. The program would obviously compile as all components will be visible to the project, but would it run on the end users machine without the DLL?
More importantly, is there a better way of doing this?
I would ideally like to have nothing about notifications in my application and somehow have it so that if the DLL file is downloaded, it adds this functionality externally. It really is not the end of the world to have a few extra bytes calling notification("blabla"); (or similar), but I am thinking a lot further down the line when I have much bigger intentions and just want to know best practices for this sort of thing.
I do not think many people would
actually use its functionality, so, I
would rather not include it by default
- just as an optional download.
Such things are typically described as plugins (or add-ons, or extensions).
Since .NET 4, the standard way to do that is with the Managed Exensibility Framework. It is included in the framework as the System.ComponentModel.Composition assembly and namespace. To get started, it is best to read the MSDN article and the MEF programming guide.
You can use System.Reflection.Assembly and its LoadFile method to dynamically load a DLL. You can then use the methods in Assembly to get Classes, types etc. embedded in the DLL and call them.
If you just check if the .dll exists or load every .dll in a plugin directory you can get what you want.
To your question if the program will run on the user's machine without the dlls already being present - yes , the program would run. As long as you dont do something that needs the runtime to load the classes defined in the dll , it does not matter if the dll is missing from the machine. To the aspect you are looking for regarding loading the dll on demand , I think you are well of using some sort of a configuration and Reflection ( either directly or by some IoC strategy. )
Try to load the plugin at startup.
Instead of checking a boolean all over the place, you can create a delegate field for the notification and initialize it to a no-op function. If loading the plugin succeeds, assign the delegate to the plugin implementation. Then everywhere the event occurs can just call the delegate, without worrying about the fact that the plugin might or might not be available.
Just out of curiosity ... is it possible to programmatically get the MSIL of a delegate? I'm curious because I've been toying with the idea of a distributed computing system where you can simply write programs, and the program itself would be distributed to each disparate node where work would occur. I know you could do it by copying the actual assembly over the network and loading that in an appdomain, but I think it would be really interesting to have a simpler model to work with.
thanks!
How is copying an assembly to another machine and loading it in an appdomain any more complex than the solution you're thinking of?
What about the dependencies of the delegate code -- this might possibly work using CodeDom reflection emit, but if the delegate calls anything outside itself (even framework code), how are you going to ensure it exists on the target machine(s)? Lots of Assembly.Load() code?
By the way: if you build a dynamically changing distributed system along these lines, you ain't gonna get me to maintain or operate it! Imagine doing fault isolation or trying to do anything like comprehensive testing...
You can use either Reflector or ILDASM (MSIL Disassembler) to get the IL of any member in any .NET assembly.