Develop Reference

How can I decompiling IL code of .net framework

I want to investigate IL code of most .net framework library classes. Is it possible? I am trying to decompiling some dll (e.g.: System.Treading), and I only see signature of the functions. Then I go to mscorlib.dll and see only manifest. There is a way to see the real code?

You can use .NET Reflector (commercial but very good):
https://www.red-gate.com/products/dotnet-development/reflector/
You can open a .net assembly with it (.exe or .dll).
So you can also directly browse .NET Framework assemblies by selecting the framework version.
Select view IL or other language such as C# or VB code and it is done.
There is also for example this free tool (slow, very slow):
https://www.jetbrains.com/decompiler/

If you want to study the implementation of .Net classes. I suggest you use the reference code provided by Microsoft.
The main advantage of using the reference code, is that you can see the comments and other elements that will not be added to IL (like #define).
Reference Source
To study the effect of certain C# constructs on the generated IL, I would suggest using SharpLib.
SharpLib

Personnaly to decompile IL code i use ILspy , it's lightweight tool and easy to use .
you can found it in the link below :
https://sourceforge.net/projects/ilspyportable/
Best Regards .

How to link statically C++ dll to .NET library (build in c++ dll to net wrapper dll to get one dll)

I have C++ dll. Than I wrote .NET Wrapper to this C++ dll, and I can attach .NET wrapper to my project and use C++ library in it. But now I have two files: c++.dll and wrapper.dll. The problem is with c++.dll, someone can replace c++.dll and inject its code to my application through wrapper.dll. How can I embed c++.dll to .net wrapper to get one .net wrapper dll?
Thanks

Simple: Don't.
You could bundle the C++ DLL into the .NET Assembly as a resource - but then these malicious users could just use ILDASM or Reflector or whatever to pull resources out of your .NET assembly - or decompile your .NET wrapper and recompile it with whatever code they want.
Bottom line is, you're really barking up a tree you can't climb (you can do things to dissuade people, but you're not going to stop them from messing with your app if they really want to) - and somehow merging your DLLs into one file really isn't going to give you any meaningful benefit.

You could try merging them (with ILmerge, for instance), though I'm not sure how useful that would be. Then again, if you merge as many files as possible into one single file, that could help your security at least a bit. This might help: http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx
Hopefully that helps.

dotnet dll decompile and change the code

I need to change the code of the .NET DLL. I am able to see the code by compilable the DLL with .NET reflector, but I am not able to change the code of the DLL. With .NET Reflector, I decompile the code and saved in to my hard disk, but when i am able to recompile the code its giving errors.
Few code is decompiled in binary format few code is decompiled with c#. Is there any tool to change and recompile the DLL?
Here are the tools I used for trying to decompile the DLL:
ILSpy
DisSharp
Reflector7.1 With the Reflexil plugin
Spices.Net.Suite.5.8
Deploy .NET 1.0.0
devextras.codereflect
dotPeek-1.0.0.2545
intellilock
JustDecompile_BETA_2011.1.728.1
Unfortunately, none of the tools giving perfect source code to recompile the DLL code.

The following code is working:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ildasm.exe" original.dll /out=code.asm
echo Here changes to code.asm should be done.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe /dll code.asm
So if the change in code is to be small, it's doable by making the changes in assembly code directly. One can compile and disassemble simple methods to see how the assembly code should look like. Putting additional methods inside the assembly file should not be too hard too.
Of course code analyzis should be done using ilspy-like tools, displaying the source code rather than assembly code.
Tools employed here come from Windows SDK (ildasm) and from .net framework (ilasm).

I've had limited success in recompiling DLLs. A better way of going about it is to using Reflector and the Reflexil plugin. You need to have a bit better knowledge of the IL code that makes up .NET assemblies but Reflexil does a great job of describing the OP codes. I have a little walk through on my blog about how I used to modify the PowerShell Cmdlet Help Editor: http://csharpening.net/?p=348

How would i use a C++/CLI dll that wraps native code with multiple dependent libraries in C#?

I am wondering how I would go about correctly setting up a C++/CLI library that wraps native c++ code that has several dependencies. I have tried both statically and dynamically linking the native library to its dependent libraries with no luck.
The Managed C++/CLI dll builds just fine and can be added as a reference to a C# project. However when I attempt to use any of the defined classes i receive either a BadImageFormatException or FileNotFoundException depending how i linked. I believe I need to specify the dependent libraries in the CLI library so it is loaded in the manifest but I am unsure of the process. Also because i know it will come up, I have verified that all of the libraries involved are built on the x86 architecture.

I figured out the problem and everything is working correctly now. It was a combination of several incorrect things all happening together.
If anyone has the same issue, I resolved it by setting up the following:
1) The Boost libraries that were referenced (specifically boost_thread) needed to be compiled with BOOST_THREAD_USE_DLL preprocessor (other boost libraries may need BOOST_ALL_DYN_LINK to just dynamically link everything). This is apparently a common issue.
2) I verified that all dependencies were in system Path (like R Ubben reiterated)
3) I used the DependencyWalker (depends.exe from sourceforge) to analyze my compiled managed DLL. It turned out that the libpq.lib library being used actually referenced additional DLLs that were not included in the lib folder but in the bin folder. So that need to be added to the Path.
4) Part of my wrapper was using the #include header for lists. This forced my library to link against 2.0 framework dependent libraries. This was not compatible with my 4.0 client targeted C# application. This was only made known by parsing through the Warnings from compiling (previously hidden due to C++ generating too many..foolish i know). However this was resulting in a System.BadImageFormateException being thrown despite everything targeting the same x86 architecture.
Hope that helps anyone else who has the same problem. The BadImageFormateException and FileNotFoundException were entirly too vague and unhelpful.

You should make the C++ dll in release mode and use extern "C" for public static things.

I have gotten that error when the dependent libraries were not in the path. The wrapper library is found because of the reference, but the reference does not also take care of the dependent libraries. Try placing them explicitly where the program is executing.

The .NET equivalent of static libraries?

I'm building a tool in managed code (mostly C++/CLI) in two versions, a 'normal user' version and a 'pro' version.
The fact that the core code is identical between the two versions has caused me a little trouble as I want to package the resulting tool as a single assembly (DLL) and I don't want to have to include the .cpp files for the common code in the projects of the two versions of the tools. I'd rather have a project for the common code and a project for each version of the tool and have each version of the tools project depend on the common code and link it in as desired.
In unmanaged C++ I'd do this by placing the common code in a static library and linking both versions of the tool to it. I don't seem to be able to get this to work in C++/CLI. It seems that I'm forced to build the common code into a DLL assembly and that results in more DLL's than I'd like.
So, in summary, I can't work out how to build the common code in one project and link it with each of the final product projects to produce two single DLL assemblies that both include the common code.
I'm probably doing something wrong but I tried to work out how to do this using netmodules and whatever and I just couldn't get it to work. In the end the only way I got it working was to tell the linker to link the build products of the common code assembly rather than the results which works but is a bit of a hack IMHO.
Anyway, does anyone have any suggestions for how I SHOULD be solving this problem?
Edited: I guess I should have mentioned the fact that the assemblies generated are not 100% managed code, they contain a mix of managed and unmanaged code as is, probably, quite common with assemblies produced with C++/CLI...

If you are annoyed at all the DLLs, download ILMerge. I use this to bundle together multiple DLL's into an easy-to-use .EXE for my clients.

If I'm understanding this correctly, you have a solution which contains two projects. One project for the "normal" user and one project for the "pro" user. Visual Studio allows you to add a "link" to another file source from another project. If your "pro" version has the real core code file, and in your "normal" version you add existing -> find the file in the "pro" project, and click the down arrow by the Add button and select "Add as Link". Now you have single file that is literally the same between two projects.

As said, ILmerge is one way. Personally, if you're bundling some exe with a lot of DLLs, I favor Netz.

You could use modules. You can link them into an assembly using the assembly linker, al.exe.

That's the downside of the .Net compilation process, you can't have things like static libraries and the header files that hold them together, everything is held in one big dll file and the only way to share information is to either build a common dll and reference it from other assemblies or to duplicate the code in each dll (possibly by copying/linking .cs files between projects).
Note that the 2nd way will declare different types, even though they have the same name. This will bite you on the ass with stuff like remoting (or anything that requires casting to specific shared interfaces between processes).

Remotesoft Salamander will hook you up. It's basically a native compiler and linker.

When using mono (or cygwin is an option) mkbundle may also be a valid choice.