I have a DLL written in C# for which I don't have the sources. I have tried different C# decompiler to modify the DLL, but they all give me errors in my attempts to recompile with the modifications, I suppose due to IL decompilation limitations. Is it possible to add a .cs file to the root of the DLL in order or inject a method to add a functionality ?
PS: This is not intended to hack a software but to create a mod of a game which requires DLL modification.
Your best approach may be to just create a wrapper project around the dll to add the functionality that you want. Your code could them reference the project instead of the dll. As long as the classes aren't sealed you should be able to inherit from them.
Modifying code you don't have access to probably isn't a good idea to begin with. Especially if the dll could be updated in the future.
You can also create a new DLL with the same namespace. This might make things look as if they're in the same location, but it's not the best practice and it could be confusing since namespaces are expected to match the project/dll name.
Benjamin's solution with the wrapper seems reasonable.
The Reflexil plugin for .NET Reflector could inject a method or a class in a DLL as illustrate in a video by its creator.
It prevents decompilation-compilation errors as it just injects IL code in the assembly.
To install this plugin follow these steps.
Related
Here is my problem. There is a game engine with a core library core2.dll which has a class C in it.
It is a windows class with a c# wrapper.
I want to use mainly all the classes from core2.dll except for one class which I want to use the class from the previous version of the library core1.dll
If you try to call the class from core2.dll it has a 'deprecated error message'.
I think the class is pretty self contained. (Lets say it is some math functions for example) So my thoughts are to include both core2.dll and core1.dll in my project but somehow make the class C only from core1.dll.
Any thoughts on how (if at all ) to achieve this?
If you need to replace part of the code inside core2.dll then you can decompile both using ildasm, change required pieces inside core2.dll and compile it back again.
Run x64_x86 Cross Tools Command Prompt for VS 2017 and execute
ildasm core1.dll /OUT=core1.il
ildasm core2.dll /OUT=core2.il
REM open il files with text editor, find classes in core1.il and replace them in core2.il
REM note, that there might be no core2.res
ilasm core2.il /RESOURCE=core2.res /DLL
This will work absolutely fine if dll is not signed. Even better - you assemble to code so ilasm will ensure your code will work in the runtime. Runtime incompatibility is a pretty annoying issue with binding redirects...
Make sure you don't violate any licenses and copyrights.
you need to use external alias for both dll
here is an example:
https://www.learningsomethingnew.com/how-to-use-two-versions-of-the-same-dll-in-the-same-project
What is the best way to prevent C# programmer from using particular library class?
Class is from external assembly so it is impossible to use [Obsolete] attribute on it. I tried to use Resharper custom patterns but it seems not to support generics types.
Patch the library method/class (there are several plugins for Reflector) - add DeprecatedAttribute, or modify its code to throw an exception, for example.
You can also make a special unit test which runs at CI server and fails if a particular deprecated item usage indicated.
You can disassemble the library with ildasm, add [Obsolete(true)] attributes and reassemble with ilasm.
You might be able to find some assembly edit tool, like Reflexil together with a trial of Reflector.
Note that if you edit an assembly you loose all signing and stuff.
I am trying to implement a COM interface in my C# dll for others to consume. I have defined an interface in foo.idl.
I've run foo.idl through tlbimp to produce foo.dll, a .Net assembly. Now to implement my interface, I can reference foo.dll in my dll to implement the interface.
This works perfectly as it stands with one exception: I now have to distribute two dlls instead of one. This actually goes against the requirements of the project I'm working on: deliver one DLL.
Is there a way to merge the tlbimp dll into mine, or any other way to do this (implement a COM interface in C# without the second dll)?
A good disassembler gets the job done, like Reflector. You can simply disassemble the interop assembly and copy the generated C# interface declarations into your source code. Of course you should only do this if the interface declarations and IIDs are stable.
And definitely consider upgrading to VS2010. Its "embed interop types" feature allows you to ship your assembly without the interop assembly.
You could probably cheat by using a .tlb instead of the 'glue' dll.
I'd suggest you create a mixed-mode assembly using MSVC++/CLR
http://msdn.microsoft.com/en-us/library/k8d11d4s(v=vs.100).aspx
Interop (How Do I in Visual C++)
This might have the drawback that you can't use C# in the same assembly. Should you want to add C# code to the mix, you might be able to squeeze out of your tough situation using
IlMerge
For other, possibly interesting, thoughts see my earlier answer:
Is it possible to compile a console application into a single .dll file?
In C++, you can create usable code modules by creating a class, and giving out header and implementation files to the developers who want to use your class.
I want to do this in C# but I have little experience with the C# language. Basically I need to create a class that can be reused by another C# programmer in Visual Studio 2010. I know that referencing DLLs is one way to use other peoples' classes. Do I need to create a DLL to achieve what I want to accomplish? Or are there other, better ways?
For example, let's say I create a Cow class that can "moo". In C++, someone who uses my class would just include Cow.h, instantiate a Cow object myCow, and then call myCow.moo(). How can I achieve this simple task in C#?
Thanks for your time and patience.
Yes, just create Class Library project and share the resulted dll's.
Other developers will just need to add a reference to your dll and after that they're free to use any public objects from your library.
It is the standard to create a dll to distribute reusable code.
You could look into old school COM objects, but I would steer clear of them and just use a well organized class library.
Of course you can always share your source files, but the recommended .Net way of distributing reusable code is though dlls. This allows developers using any .Net language to use your code (they don't have to use the same language as your project).
It also makes it easier to maintain the project. If you share source code then it will likely be more difficult to distribute updates than if you just needed to update a single dll. If you have multiple projects referencing the same dll, they can all reference it from the same location and whenever the dll is updated, all the projects that use it will automatically use the updated dll the next time they compile the project. You can also update the dll without having to recompile the projects that use it (though you can't change the names/signatures of anything that is being used by the project).
I'm working on a module for a CMS. This module is distributed as a class library DLL.
I have several utility libraries I'd like to use in this module. Is there anyway I can link these libraries statically so I won't have to distribute several DLL's (thereby distributing my utility libraries separately)?
I would like to have only one DLL.
You can merge your many DLLs with ILMERGE:
http://research.microsoft.com/~mbarnett/ILMerge.aspx
Haven't tried it myself. Hope it helps.
Download here:
http://www.microsoft.com/downloads/details.aspx?familyid=22914587-B4AD-4EAE-87CF-B14AE6A939B0&displaylang=en
Brief Description (from download-page)
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
If you don't want to use ILMerge, see this page:
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
editor's note: Jeffrey Richter advices to put your dlls into exe file as resources (For each DLL file you add, display its properties and change its “Build Action” to “Embedded Resource.”). Then a custom class loader is needed to make the executable work (At runtime, the CLR won’t be able to find the dependent DLL assemblies, which is a problem. To fix this, when your application initializes, register a callback method with the AppDomain’s ResolveAssembly event).
Be sure to change the resourceName string to point to your actual resources. (e.g. change AssemblyLoadingAndReflection to your project name.)
The short answer for this is no!
You can not link in a dll during compilation.
I don't know if there is some subtle way to do this, but you would probably have to distribute the dlls along with your cms.
The best way to do this is to make some kind of re-distributable.