Question about reference generation [reprinted]

Reprinted: http://hi.baidu.com/remind_them/blog/item/1916966688991523aa184ce6.html

 

Today, I found a lot of problems that I didn't notice before. In order to solve the inconsistency between the dll version shared with others (you overwrite me, I overwrite you, and always cause errors on the other side), it is a little troublesome to unify the dll version, and it involves a large number of people. So I am lazy and want to find a way to get lazy.

1. What I initially thought was to put the dll I needed under a specific directory and use the assembly Method to dynamically call the dll. The results were continuously incorrect. Originally: I want to call. dll, while. dll calls a bunch of dll (using B. dll. dll + B. dll is put into Directory d and dynamic call. dll, But B is always not found. dll. It turns out that even if a calls B, it does not look for B in the same directory as a, but calls the exe OF a to look for B in the same directory. Alas... I'm an idiot!

2. Project a calls Project B, Project B calls Project c, and c references a d. dll, that is, a-> B-> c-> d. When c is generated, there will be d. dll in the bin directory of c, which is beyond doubt. When B is generated, there should be d. dll in the bin directory of B, and there is no problem. When generating a, d should still exist in the bin directory of. dll, but the question is: no, do not question my operations. I really don't have one. Why Can someone tell me?

3. project B of the same 2. In debug mode, the bin directory contains d. dll, but in the release mode, d is not generated. dll, why again, who can tell me?

4. method 1 is invalid, so with the help of a colleague, I decided to adopt. dll and B. dll into a c. dll, so that it will not cause duplication with others, and it looks much refreshed. I found a tool called ILmerge. I am too lazy to write a post.

[Convert] C # to import the dll into the exe, and add the shell

In the past few days, I am working on a small program. Because of the three-tier architecture, there are many dll files in the running directory, I plan to merge all dll files into the exe file. ILmerge, a free software released by Microsoft, can do this. After studying it, its usage is as follows: 1. Merge file1.dll and file2.dll to destination. dll. ILmerge /ndebug /target:dll /out:C:\destination.dll /log C:\file1.dll C:\file2.dll However, the command format for this version is: ILmerge/out: C: \ destination. dll C: \ file1.dll C: \ file2.dll... In addition, he does not support ILmerge/out: C: \ destination. dll directory1 or ILmerge/out: C: \ destination. dll dire \ *. dll I pasted it for a long time. I don't know if it's my idiot. 2. Merge file1.dll1_file2.dllwith myapp.exeto newapp.exe ILmerge /ndebug /target:winexe /out:C:\newApp.exe /log C:\myapp.exe C:\file1.dll C:\file2.dll Note: When merge is exe, myapp.exe must be written before file1.dll and file2.dll. After that, you will get an exe file. If you want to do something evil, you can merge some dll of the cracking software into your exe. The premise is that all the dll files are hosted. If you try to merge the dll files written in C ++, it will fail. A tool called mergebin.exe can be used to merge hosted and unmanaged dll files. I haven't studied the usage yet, and it seems quite difficult. This tool is ADO. NET 2.0 Data Provider for SQLite written by the author, he published the System. data. SQLite. dll can be referenced by the dotNet program or directly called by the C/C ++ program. This dll is a hosted and unmanaged hybrid dll, which is really awesome! Mergebin.exe is in its source code package. If you are interested, you can study it. This is its official website:Http://sqlite.phxsoftware.com Continue to the evil topic. If your exe is merged with cracked dll files, you may not want to let others know, or you do not want others to decompile your exe files. Obfuscation Software charges fees, and the method after obfuscation is still visible, but the name has no rules, no way, no use. We have to find a very powerful shell software. We recommend a software called Sixxpack, which is dedicated to shelling the dotNet program. The latest version is Sixxpack22, and requires that the machine be installed with A. netframework2.0 or later version. In addition to shelling, Sixxpack also uses compression technology with a maximum compression ratio of 80%. Sixxpack is a free software. its official website is:Http://www.reversers.net/ After Sixxpack shelling, use Reflector to open the exe file. Haha, it will always be a actmp. dll information, which contains four 7zip namespaces and one Sixxpack namespace. It is useless to decompile these things. It turns out that the compression ratio is 7 zip. It's no wonder that the compression ratio is so high. One problem is that after the Sixxpack is used for processing the assembly, the version information is 0.0.0.0, and other information is incorrect. It doesn't matter. Use Resource Hacker to modify it! Resource Hacker is also a free software. its official website is:Http://angusj.com/resourcehacker/ I used some evil things in this small project to beautify the interface. The final exe file is about 5 MB. After Sixxpack is used, the volume is reduced to 2 MB, and there is almost no performance loss during running. The most important thing is that it is difficult to decompile and can be used by others.