Is there and easy way to decompile a C# DLL (like ILSpy does, for example), but instead of method bodies, have the methods return default values (or throw runtime exceptions for that matter)?
Why do I need this? I am trying to replace some classes in a .dll library. I can't decompile the entire library, since it contains many lambda function and iterators that cause problems when decompiled.
I had, however, success doing this: Copy the decompiled source of the class I want to change, paste it into a new project and include the original .dll as a library. Then, change the class to my liking (change methods implementation for now), and then compile the project and inject the compiled IL code into the original .dll via a disassembler.
This has worked out so far with a success, however now I have run into a problem. The class (let's say A) that I'm trying to change now, passes this as an argument to other classes (let's say B), and it's generating a compile error (since the original B class expects the original A class, and not the "fake" A class that I'm editing).
This, of course, would not be a problem if I had the complete source code to the .dll library, but I don't. Fortunately, I don't have to. If I had a "structure-only" source code (declarations of classes, fields, methods, interfaces and what not, but no method implemetations), I could copy-paste the source of class A into this sructure-only sorce code, make the changes I need, compile, and then inject the IL code as before.
So, can I easily get the sructure-only sorce code (again, method implementation can be eighter returning default value, or throwing runtime exception), or is there a better to replace a class in a .dll library like that?
Related
I have some DLL from third party that I need to license. It has some method that I must call from my own DLL. My DLL is referenced in couple of projects and I don't want to make changes to every hoster. Is there any method that I can use within my DLL which will call some method in my DLL? Like add some static class or constructor but without explicit call to that class from hosters? I am not sure if I am explaining it clearly. Please ask questions if needed.
ThirdPartyType license = new ThirdPartyType();
license.Load("license.xml");
This is a piece of licensing code that I want to place in my DLL and call it within the same DLL.
At the low level, the runtime supports "module initializers". However, C# does not provide any way of implementing them, so the closest you can manage is a static constructor ("type initializer") or just a regular constructor.
However, it is probably a bad idea to hook your licencing into either a module initializer or a type initializer, as you don't know when they will run, and it could impact code that wasn't going to access your lib. It is somewhat frowned upon to take someone's app down because your licensing code decided it was unhappy - especially if your library wasn't actively being invoked at the time.
As such: I suggest the most appropriate place to do this is in either a constructor, or a post-construction Initialize(...) method (with the tool refusing to work unless supplied with valid details).
High-level question here:
I have spent a lot of time today educating myself on basic high-level concepts such as APIs, static and dynamic libraries, DLLs and marshaling in C#. Gaining all of this knowledge led me to what seems like a pretty basic question, and probably demonstrates a hole in my understanding of these concepts:
What I know:
DLLs may contain classes which in turn contains various class-members such as methods and fields, several of which I might want to utilize in my program
In C# we use the keyword "using" at the top of the code, to define a namespace we
want to include in our program
What I do not get:
I was under the impression that the actual methods were defined in the DLLs. How does my program find the actual functions that are defined in the DLLs, when all i give them is a namespace? It seems more intuitive to me to have "using XYZ.dll" at top, rather than "using XYZ_namespace".
Thanks a lot for helping me fill in the gaps here.
EDIT: Modified post to be specific to C#.
EDIT 2: For other people that wonder how their C# application actually gets a hold of the types made available through "using namespaceX", this is a good resource (in addition to the helpful posts below): http://broadcast.oreilly.com/2010/07/understanding-c-namespaces-and.html.
Basically the type you would like to use resides in libraries and you have to set Visual Studio to reference these libraries in order to make it possible to "use" its namespace in your code.
DLLs contain many routines / methods we might want to use in our
programs
Partially correct. .Net DLLs contain Classes, and these classes contain Members (Fields, Constants, Methods, Properties, Events, Operators, Indexers).
.Net is strictly OOP, and it does not allow code "floating in limbo". Everything is defined inside classes.
Classes are organized in Namespaces just to keep a naming separation and organization. Think of namespaces as "folders" that contain one or more classes, and that might be defined in one or more assemblies (DLLs).
For example, Classes inside the System namespace are defined in 2 assemblies (DLLs): mscorlib.dll and System.dll.
At the same time, these 2 assemblies contain many different namespaces, so you can think the Assembly to Namespace relation as a Many-to-Many.
When you put a using directive at the beginning of a C# code file, you're telling the compiler "I want to use classes defined in this Namespace, no matter what assembly they come from". You will be able to use all classes defined in such namespace, inside all assemblies Referenced from within the current project.
In C#, DLLs (aka assemblies) contain classes (and other types). These types typically have long full names, like System.Collections.Generic.List<T>. These types can contain methods.
In your References area, you have references to assemblies (this is part of your .csproj file). In a .cs file, you don't need to include any using to reference this DLL, because it's already referenced in your .csproj file.
If you include a line like using System.Collections.Generic;, that tells the C# compiler to look for System.Collections.Generic.List<T> when you type List<T>. You don't need to do it that way, however: you can simply type System.Collections.Generic.List<T>.
I was under the impression that the actual methods were defined in the
DLLs. How does my program find the actual functions that are defined
in the DLLs, when all i give them is a namespace?
The process of finding the correct code occurs through static or dynamic binding and also assembly binding. When you compile the code static binding will tell you if you wrote bad code or forgot to add a reference:
ClassInADifferentAssembly.M(); //Generally this will static bind and
cause a compiler error if you forgot to include a reference to
DifferentAssembly
Unless you are dealing with dynamic or reflection then you have static binding. Assembly binding is a different process. The overall process is complex, but basically assemblies are discovered in the the GAC, current location or you can even handle an event yourself, AppDomain.AssemblyLoad.
So when you add a using statement then static binding can successfully find the correct code in the context. However, you can still receive a runtime error if later the assembly fails to bind at runtime.
DLL is short for dynamic link library. And can be a class library containing classes, methods etc that can all be put under different namespaces.
So first you have to add a reference to the DLL into your project. When that is done, you then use a keyword such as "using" to basically shorten the path to reach the methods/classes in that particular namespace.
Example namespaces
Namespace.Something.SomethingMore.Finally.Just.One.More
Namespace.Something.SomethingMore.Finally.Just.One.More2
To reach classes under those namespaces you can do either of the following
using Namespace.Something.SomethingMore.Finally.Just.One.More;
using Namespace.Something.SomethingMore.Finally.Just.One.More2;
// Now you can access classes under those namespaces without typing the whole namespace
// Like in the row below
Class.GetData();
If you did not have the usings, you would still be able to access those classes. But would then have to type
Namespace.Something.SomethingMore.Finally.Just.One.More.Class.GetData();
Namespace.Something.SomethingMore.Finally.Just.One.More2.AnotherClass.GetData();
DLLs have a collection of functions.
You can calls these functions by one of 2 ways:
link with the DLLs export library (a lib file) or do the link in runtime:
Call LoadLibrary()
Call GetProcAddress and provide the name of the function you want. You'll need to cast it to the actual type (function pointer).
Call the function via the new function pointer.
Pretty simple stuff, just read it on MSDN.
C++ namespaces are just a part of the function name.
You can view what functions are exported from a DLL by using a tool called Dependency Walker.
I am not even sure if this is possible so apologies if not. I have googled quite extensively and not found what I am looking for.
Basically we have an application produced by a third party, which, to be perfectly blunt is rubbish. We have a particular issue and have managed to trace the problem using ILSpy to a method within a DLL. Obviously we don't have (nor are able to get) the source code and the company in question is unwilling to fix the problem in any reasonable timescales.
So, we've investigated various avenues of investigation and come up with nothing. I've been looking into seeing whether this can be done using reflection and this is pretty much the last hope we have of getting this to work. In a nutshell, what I would like to do is the following:
Create a simple class library with the same name as the existing DLL
Use reflection to import the methods from the existing DLL
Somehow override the method in question with my own, correct code
Rebuild the code, so I have a new DLL, containing 99% of the functionality of the existing DLL but with my override code providing the correct functionality.
I have found, during my investigations TypeBuilder.DefineMethodOverride and also a page from StackOverflow, which seems similar but not quite what I am looking for.
http://msdn.microsoft.com/en-us/library/system.reflection.emit.typebuilder.definemethodoverride.aspx
Is there a way to "override" a method with reflection?
Any advice appreciated!
Andrew
Edit
The other possible idea I has was to produce a partial class containing the override function, but that didn't seem feasible either.
You can override the method only if it is virtual, and it doesn't matter whether you do it through reflection or statically. I would suggest using a decompiler (there are a lot of free ones available) and fixing the code in MSIL. Then you can generate a new assembly from the MSIL.
I think your first idea is good.
If the third party class isn't sealed, you can derive from it, and add your own method, with a different name, to correct the behavior that is wrong.
If you need it to be in 1 dll, you can use IlMerge.
If your third party class is sealed you can just have an instance of this third party class in your new class and call the methods when needed.
But you'll have to check that the method you want to "override" isn't called inside that library, because if it is this solution won't work...
It's not very clean, but it can be a temporary solution during the time the company that edits the library fixes the problem.
And when it's fixed you'd just have to rename the method you use, so it won't be time consuming.
From what you have described I would recommend modifying the original assembly. The process is essentially
Decompile the assembly into MSIL, C# or whatever language you so choose
Modify the decompiled assembly to include your changes
Recompile the assembly using the modified source
From what I can see Reflexil allows you to do just that, although it may require that you buy Resharper (I've not tried it myself)
Alternatively you can use ILDasm to decompile the entire assembly to a single file, modify the file and then recompile it using ILAsm
I know I'm coming in a bit late on this, but I'd agree with Charleh; if you've got a class that's not behaving well and isn't conducive to substitution, but at least declares its methods as virtual, then you're in luck. The following uses references to Castle.Core and Patterns:
var interceptor = new DelegateInterceptor(proceed: call =>
{
if(ShouldCallProceed(call)) call.Proceed();
else AlternativeLogic();
});
var generator = new ProxyGenerator();
var proxy = generator.CreateClassProxy<UncooperativeType>(interceptor);
proxy.RubbishMethod();
I've also taken the liberty of providing a running sample of this in LinqPad. It shows the difference between methods that allow interception (virtual ones) and ones that don't. It also shows a useful way of trapping exceptions without all the code using Try.Do from Patterns.
I'm working with some, unfortunately largely undocumented, existing code and I'm having trouble understanding how it calls upon the methods of the plugins it loads.
My aim at the moment is simply to step into one of the methods loaded via the plugin manager, as it's causing an exception. However I had to rebuild the pluginManager from the source to get debug symbols and when I reference this new DLL version the compiler throws up arms.
The code appears to load the plugin into plug.Instance and then access the specific methods like so plug.Instance.ReturnLeaNumber();
This compiler error makes sense, because it doesn't know the details of the plugins. What confuses me is how the compiler ever knew these where valid before run time, when no plugins are initialized. I can step through the code that doesn't work now with the older DLL!
This is an example of where the program loads up a plugin.
plug = GenericServicePlugins.AvailablePlugins.Find(Application.StartupPath + "\\Dlls\\SchoolInterface.dll");
// Compiler doesn't like this next line anymore though
plug.Instance.Initialize(null, null);
If there are any differences between my rebuilt library and the previously working one, I can't tell how as the versions match up with the ones in our source control. Would appreciate some advice on where to start looking!
public interface IGenericPluginMasterInterface
{
String returnName();
void Initialize(ExceptionStringResources.Translate ExceptionStrings);
Object ExecuteFunction(String macAddress, bool log, String functionName, LoginCredentials logonCredentials, WebConfiguration webConfig,
Int64 dataLinkId, DataLinkParam[] dataLinkParams, String dataName,
DataParam[] dataParams, Object[] additionalParams);
}
Rest of Manager code on PasteBin
How does the compiler know about these plug.Instance.Method() methods before runtime?
Edit:
I've not quite worked this out yet, but there was a "PluginsService" file I missed which partly mirrors the "GenericPluginServices".
I think this error could have been caused when I removed parts of this class that related to an now defunct plugin, which I am looking into. However I figured posting this other code snippet would help the question.
PluginService.cs code
GenericPluginService code
Find returns AvailablePlugin, so .Instance is of type IGenericPluginMasterInterface; if so, indeed; that .Instance.ReturnLeaNumber() can't possibly work...
The only way that could work (without introducing some generics etc) is if .Instance actually returned dynamic. With dynamic the name/method resolution is happening at runtime. The compiler treats dynamic very deliberately such as to defer all resolution to runtime, based on either reflection (for simple cases) or IDynamicMetaObjectProvider (for more sohpisticated cases).
However, if the code you have doesn't match what was compiled, then: we can't tell you what it was. IMO, the best option is to get hold of the working dll, and look at it in reflector to see what it is actually doing, and how it is different to the source code that you have.
Actually, strictly speaking it could still do that with the code you've pasted, but only if plug is typed as dynamic, i.e. dynamic plug = ...
I remember with InterSystems Cache code, you can use indirection to take a string and turn that into real executable code by preceding the string variable with "#". Can this be done in C#.NET or VB.NET code? So I'd like to have a method that would take an arguments array of strings (with one or multiple lines of code), and run that code, assuming it doesn't throw an exception of course. Where am I going with this? I'm trying to write a compiler within .NET code.
SET x="set a=3" XECUTE x ; sets the public variable a to 3
OR
SET x="tag1" d #x ; do/call the public subroutine tag1
OR
Set Y = "B",#Y = 6 ; sets public variable B = 6
I assume that you want to compile during runtime.
System.CodeDom and System.CodeDom.Complier namespaces contain interfaces that are relevant to runtime compilation.
For your own language you need to implement your derived class from a derived class of CodeDomProvider.
For .NET you can either programmatically build up code using System.CodeDom which is basically a wrapper over the Intermediate Language, or you can use System.CodeDom.Compiler to get an object that compiles a string (or file) into an executable or DLL using a C# or VB.NET compiler.
Compiling the string is more like the Intersystems Cache way of doing it, but it's still more work, because you must provide all the information the compiler needs. If you look at the CompilerParameters class you will see the added complexity. The compiled code will be in it's own assembly. An assembly can't be unloaded unless it's in it's own App Domain, and when dynamically compiling it is difficult enough that most people don't bother if they can avoid it.
Various approaches to your problem are proposed on this very site.
Some source code for one solution to what you've described can be found here if the link stays alive.