In releaseProgramWhen some debug DLL files and some release DLL files are mixed and released, the entire production environment is paralyzed (the memory and CPU usage are very high, and there is no response for Website access ). I still don't know why, maybeCodeSome of them use unstable things, or maybe the DOTNET framework is mixed with debug and release. However, from the perspective of solving the problem, the fastest way is to separate the DLL files after the hybrid piles, and then re-release a uniform version of DLL.
Isdebug:
At http://www.sliver.com/dotnet/isdebug/the author has a program isdebugused for this detection. This program can tell whether the EXE and DLL files are debug or release. However, this program is not very accurate, and some DLL cannot be truly distinguished, and it is only applicable to DOTNET programs. PS: the author of this program is the author of reflector.
I am also talking about determining whether a program is debug or release.ArticleFind another method to determine whether the program is debug. This method is directly judged by reading the mark in the program file. Therefore, this method is suitable for various execution files and class libraries. The results are also more accurate than isdebug, and many isdebug errors can be identified accurately.
The core code is as follows:
Code
1 String szname = Filepath;
2 Filestream FS = Null ;
3 Binaryreader R = Null ;
4 Bool Bdebug = False ;
5
6 Try
7 {
8 FS = New Filestream (szname, filemode. Open, fileaccess. Read );
9 R = New Binaryreader (FS );
10
11 FS. Seek ( 0x3c , Seekorigin. Begin ); // PE heaher offset
12 Int I = R. readint32 ();
13
14 FS. Seek (I + 0x18 , Seekorigin. Begin ); // Magic number offset
15 Int Imagicnumber = R. readint16 ();
16 If (Imagicnumber = 0x010b )
17 {
18 // Pe32
19 FS. Seek (I + 0xa8 , Seekorigin. Begin ); // Debug Data Directories info offset
20 }
21 Else If (Imagicnumber = 0x020b )
22 {
23 // Pe32 +
24 FS. Seek (I + 0xb8 , Seekorigin. Begin ); // Debug Data Directories info offset
25 }
26
27 Else
28 {
29Throw NewSystemexception ("Impossible! Nnd, it is not a PE file! FK u");
30}
31
32 Bdebug = R. readint32 () ! = 0 ;
33 }
34 Catch (Systemexception E)
35 {
36Console. writeline (E. Message );
37}
38 Finally
39 {
40 If (FS ! = Null )
41 {
42FS. Close ();
43}
44
45 If (R ! = Null )
46 {
47R. Close ();
48}
49 }
Therefore, I used this method to create a program similar to isdebug. Download
This program has two main problems:
1. I always think this is inappropriate when only the suffix is used to judge executable files and class libraries;
2. There is no way to determine whether the Managed execution file is not managed.
Finally, let's talk about the system paralysis mentioned above. The mix of debug and release is not the root of this problem, but is generally just the fuse.