现在假设你有两个程序集,他们分别是A,B
其中 A 是一个类库
public class A
{
public const string ConstValue = "A1";
}
而 B 是一个 console app,或者asp.net,或者无论什么可执行的程序,然后它依赖了B。
class B
{
static void Main(string[] args)
{
Console.WriteLine(A.ConstValue);
Console.ReadKey();
}
}
这个程序非常简单,以致于刚入门的新手都能轻易看懂,正如你想的那样,它输出了 A1。
然而,当你想把A1改成A2的时候,问题出现了。
你以为它会输出 A2,但事实是它还是会输出A1,惊不惊喜,意不意外?
同样的,枚举也类似。
这是因为 编译器对待常量的方式是提取,它会A程序集的常量的值,编译到自身的程序集里。也就是说,再编译后, A1这个字符串位于程序集B,而不是程序集A。
除非你修改一下程序集B,然后触发B的重新编译。
因此习惯性思维如同一座大山,任凭你如何努力,你也休想改变B的输出结果,你会以为是别的地方的问题,于是你会疯狂找bug,一直找,一直找,从白天到黑夜,从黑夜到凌晨。
你猜我是怎么发现的。
现在假设你有两个程序集,他们分别是A,B
其中 A 是一个类库
而 B 是一个
console app,或者asp.net,或者无论什么可执行的程序,然后它依赖了B。这个程序非常简单,以致于刚入门的新手都能轻易看懂,正如你想的那样,它输出了
A1。然而,当你想把
A1改成A2的时候,问题出现了。你以为它会输出
A2,但事实是它还是会输出A1,惊不惊喜,意不意外?同样的,枚举也类似。
这是因为 编译器对待常量的方式是提取,它会A程序集的常量的值,编译到自身的程序集里。也就是说,再编译后,
A1这个字符串位于程序集B,而不是程序集A。除非你修改一下程序集B,然后触发B的重新编译。
因此习惯性思维如同一座大山,任凭你如何努力,你也休想改变B的输出结果,你会以为是别的地方的问题,于是你会疯狂找bug,一直找,一直找,从白天到黑夜,从黑夜到凌晨。
你猜我是怎么发现的。