编译是有很多警告，帮看看什么问题

搞了一个小程序，编译没有错误，但是有很多警告，烦请大家看看都是啥问题，是c#菜鸟见笑了，
谢谢！
1>– 已启动全部重新生成: 项目: WindowsFormsApplication1, 配置: Release Any CPU —
1>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1635,5): warning MSB3267: 未能在当前目标框架中解析主引用:

Quote: 引用:
你不测试吗？
假如进行真正的测试，那么这些警告可以暂时不看。

测试啊，编译通过了，原因是以前不用c#开发，不太懂这些警告啥意思，怕这些警告在别的环境或别的人用的时候出错而用不了，

你可以针对警告而设计测试用例。你还是没有揣摩一点本人说的“测试”真正的意思。

引用:

Quote: 引用:
首先你得搞清楚Error和Warning的区别，Error是指编译无法通过的错误，Warning是指不影响编译，但可能会影响程序正确性的问题，而你的那些提示里面，哪些是不影响的，哪些是可能影响的很容易看出来吧，提示都这么明确了……

提示是很明确，中文本人全都看得懂，但是不清楚内在含义，warning CA1401: Microsoft.Interoperability : 更改 P/Invoke “NativeMethods.SetWindowsHookEx(int, NativeMethods.HookProc, IntPtr, int)” 的可访问性，使它在本人的程序集外部不再是可见的啥意思，不是很明白，

编译器多管闲事呗。让你别让程序集外部的dll、exe也可以访问到它。你可以从本人的立场出发来判断。本人说“编译期多管闲事”也是从动手的角度，从“假如让本人写一个测试用例”的角度出发来判断这样做到底有没有什么 bug。本人不认为有什么“天规”或“洁癖”，我们完全接受编译器的提示，但是我们动手测试一下，结果就算是从外部可以访问它而现在也没能发现bug。这就是结论。

针对警告，你可以编写测试用例！这就是本人的建议。
实际上就算是测试，今天不报bug，未1个月后也不报bug。未必现在有10个测试时不报bug，而有20个测试时也不报bug。所以就是是测试，也是与时俱进的。
总之，不要“含沙射影”地夸大那些警告。而具体对待它们，自然处理就好了。

引用:

测试啊，编译通过了，原因是以前不用c#开发，不太懂这些警告啥意思，怕这些警告在别的环境或别的人用的时候出错而用不了，

假如你针对那些提示而设计测试用例，最多写上5个，基本上就心里有数了。
本人动手写测试的人根本不可能“怕”什么东西。

警告没关系。
不过你可以跟着警告看看能否严重。这个本人主观也能判断一下的