为何Linq方法出现相同命名空间错误？重构后ObservableCollection编译异常

哈哈，这种“只有某类操作报错，加个无关命名空间就好”的问题我之前也踩过类似的坑，结合你的描述，咱们来捋捋可能的原因和解决方向：

1. 命名空间缺失导致的类型解析歧义 #

你说给ObservableCollection相关类加个随便什么命名空间就搞定了，这大概率是根源在这：

• 当你的自定义类没加命名空间时，它和.NET自带的System.Collections.ObjectModel.ObservableCollection都在全局命名空间里混着。Linq的扩展方法（比如Where、Select）是靠命名空间导入来让编译器找到的，这时候编译器搞不清你用的是哪个ObservableCollection，自然就没法正确绑定Linq方法了。
• 加了自定义命名空间后，编译器能清晰区分你的类和框架原生类，扩展方法的绑定逻辑一下就正常了，错误也就消失了。

2. Visual Studio的编译缓存确实可能搞鬼 #

你怀疑是VS bug真的很合理，这类莫名其妙的编译错误十有八九和缓存脱不了干系，就算暂时用命名空间解决了，也可以试试这些操作彻底排查：

• 先清项目：点「生成」→「清理解决方案」，再手动删掉项目目录下的bin和obj文件夹
• 重置VS缓存：关掉VS，去%LOCALAPPDATA%\Microsoft\VisualStudio\<你的VS版本号>\ComponentModelCache把里面的文件全删了
• 重启VS再重新生成整个解决方案

3. 确认你的自定义ObservableCollection类写法 #

检查下你的自定义类是不是正确继承了框架的原生类，最好写全命名空间避免混淆：

// 比如这样写，明确指定继承框架的ObservableCollection
namespace MyProject.Collections
{
    public class MyCustomObservableCollection<T> : System.Collections.ObjectModel.ObservableCollection<T>
    {
        // 你的自定义代码
    }
}

要是继承的时候没写完整命名空间，在全局命名空间下很容易和框架类“撞脸”，编译器懵了就会报Linq的错。

4. 检查WinForm里的命名空间导入 #

确保你的WinForm代码顶部加了这两个命名空间：

using System.Linq;
using System.Collections.ObjectModel;

虽然其他对象没问题，但ObservableCollection的Linq方法对这俩命名空间的依赖更敏感，一旦编译器有点歧义，就会先在这上面出问题。

内容的提问来源于stack exchange，提问作者Valamas