获取“types或命名空间名称找不到”，但一切似乎没问题？
我得到一个：
types或命名空间名称找不到
VS2010中的C＃WPF应用程序错误。 这段代码编译正常，但突然间我得到这个错误。 我已经尝试删除项目引用和using声明，closuresVS2010和重新启动，但我仍然有这个问题。
任何想法，为什么这可能会发生，似乎我正在做的事情参考和using声明？
我还注意到在VS2010中，该命名空间的intellisense工作正常，所以它似乎像VS2010一方面有项目引用和看到命名空间，但在编译期间看不到它？
这可能是两个项目之间.Net框架版本不兼容的结果。
它可以以两种方式发生：
- 一个引用完整框架项目的客户档案项目; 要么
- 一个针对较新的框架版本的较旧的框架版本
例如，当应用程序被设置为定位.Net 4客户端configuration文件框架，并且它所引用的项目的目标是完整的.Net 4框架时，就会发生这种情况。
所以要更清楚一点：
- 项目A定位客户端configuration文件框架
- 项目A参考项目B
- 项目B的目标是完整的框架
在这种情况下，解决scheme是升级应用程序的框架目标（项目A），或降级引用程序集（项目B）的目标。 完整的框架应用程序引用/使用客户端configuration文件框架程序集是可以的，但反过来（客户端configuration文件不能引用完整的框架目标程序集）。
请注意，当您在VS2012或VS2013（使用.Net 4.5作为默认框架）中创build新项目时，也可能会出现此错误，并且：
-
引用项目使用.Net 4.0（当你从VS2010迁移到VS2012或VS2013，然后你添加一个新的项目时，这是很常见的）
-
被引用的项目使用更大的版本，即4.5.1或4.5.3（您已经将您的现有项目重新定位到最新版本，但VS仍然创build了针对v4.5的新项目，然后引用新项目）
当构build解决scheme时，我得到了同样的错误（types或命名空间“无法find）。 在它下面，我看到一个警告，说明引用无法parsing，并确保程序集存在磁盘上。
我感到非常困惑，因为我的DLL非常清楚地在参考指向的位置。 VS似乎没有突出任何错误，直到我试图build立解决scheme。
我终于意识到了这个问题（至less我怀疑是什么问题）。 我在同一个解决scheme中构build库文件。 所以即使它存在于磁盘上，它也正在被重build（不知何故，在图书馆重build我的另一个项目的过程中 – 在相同的解决scheme – 引用图书馆必须已经决定，图书馆不存在）
当我右键单击这个项目，并且只是build立这个项目，而不是整个解决scheme，我没有得到这个错误。
为了解决这个问题，我添加了库作为依赖到正在使用它的项目。
为此，我在解决scheme资源pipe理器中右键单击我的解决scheme并select“属性”，然后在“通用属性”中select“项目相关性”。 然后在Projects下拉菜单中，我select了依赖于该库的项目，并将box net复选到“Depended”
这确保了图书馆项目得到build设。
它可能会closures并重新启动Visual Studio。 它有时似乎得到“卡住”
重新安装nuget软件包对我来说是个诀窍。 在将.NET Framework版本更改为所有项目同步之后，仍然为以前的版本安装了一些nuget软件包（特别是entity framework）。 Packages Manager Console中的这个命令为整个解决scheme重新安装软件包：
Update-Package –reinstall
我不知道为什么这个工作，但我删除了VS2015告诉我无法find的项目参考，并再次添加。 解决了这个问题。 我试了清洗，build设和重新启动VS无济于事。
首先我会validation你的项目生成的信息没有损坏。 做一个干净的和重build你的解决scheme。
如果这样做没有帮助的话，我曾经在devise师问题上见过的一件事就是打开一个windows窗体项目，然后再closures它。 虽然这是一个小鸡，但是，不要屏住呼吸。
这个为我工作。 在你的class级里定义了class级名称，例如：公共class级ABC，删除一个人物然后等一下。 你错误列表会增加，因为你已经改变了名字。 现在放回你input的字符。 这工作对我来说，希望它也能为你工作。 祝你好运！！！
我遇到的一个棘手的情况是：项目一针对安装了Microsoft.Bcl.Async软件包的4.0完整框架。 项目二以4.0完整框架为目标，但在引用一个项目一个类时不会编译。
一旦我在第二个项目上安装了Async NuGet包，它编译得很好。
从VS2008升级到VS2012时，我遇到了这个问题。 我发现两个项目（我创build的唯一两个）针对不同的.Net框架（3.5和4.0）。 我在项目的“应用程序”选项卡上解决了这个问题，确保两个项目在“目标框架”框中都有“.NET Framework 4”。
我有一个类似的问题：编译器无法检测到同一个项目中的一个文件夹 ，所以使用指令链接到该文件夹产生了一个错误。 在我的情况下， 问题来自重命名该文件夹 。 即使我更新了该文件夹内所有类的名称空间，项目信息无法更新。 我尝试了一切：删除.suo文件和bin和obj文件夹，清理解决scheme，重新加载项目 – 没有任何帮助。 我通过删除里面的文件夹和类，解决了这个问题，创build一个新的文件夹，并在新的文件夹中创build新的类 （简单地移动新文件夹内的类没有帮助）。
PS：在我的情况下，我正在研究一个Web应用程序，但是这个问题可能发生在不同types的项目中。
你也可以尝试消除你认为你有问题的代码，看看它是否编译没有引用该代码。 如果不是的话，修复一些东西，直到它再次编译，然后再把你怀疑的问题代码写回来。有时候，当编译器不喜欢别的东西的时候，我会得到关于类或者方法的奇怪的错误。 一旦我解决了这个问题，那么这些“幻影”错误就会消失。
我们有一个奇怪的例子，我刚刚解决了一个问题。 主项目中的“using”语句前面有一个隐藏/空白字符。 该项目将build立罚款和网站工作正常，但引用它的unit testing项目不能build立。
[Facepalm]我的问题是我用C ++的方式添加了依赖项。
转到不能构build的项目，在解决scheme资源pipe理器中打开“参考”文件夹，然后查看是否列出了您的依赖项。
如果没有，您可以“添加引用”，然后在“项目”选项卡上select依赖项。
热潮尚卡尔。
在我的情况下，问题是，更改后名称空间完全相同，在另一个项目中（有意），程序集的名称也改变了VS，所以有两个程序集同名，一个覆盖另一个
我知道这是踢死马，但我有这个错误和框架罚款。 我的问题基本上是说，无法find一个接口，但它构build和访问得很好。 所以我不得不这样想：“为什么只有这个界面在别人工作的很好？
最后，我实际上正在使用WCF访问一个使用实体版本6的端点接口的服务，而其余的项目使用的是版本5.我没有使用NuGet，而是简单地将nuget包复制到本地存储库以供重用，列出他们不同。
例如EntityFramework6.dll与EntityFramework.dll 。
然后我添加了对客户端项目和poof的引用，我的错误消失了。 我意识到这是一个边缘案例，因为大多数人不会混合entity framework的版本。
在我的情况下，我发现在VisualStudio中的参考有一个三angular形，感叹号作为这个图像，
然后，我右键单击删除它，并再次正确添加DLL引用，问题解决了。
检查你是否引用了dll。 Dll位于解决scheme目录的bin文件夹中。
它发生在Visual Studio 2017中。
- 重新启动Visual Studio
- 清理无法build立的项目。
- 重build项目。
在我的情况下，我有一个由外部依赖（xsd2code）构build的文件，不知何故它的designer.cs文件没有正确处理VS。 在Visual Studio中创build一个新文件并粘贴代码，对我来说是个诀窍。
join我的解决scheme，因为它有点不同，花了我一段时间才弄清楚。
在我的情况下，我添加了一个新的类到一个项目，但因为我的版本控制绑定没有设置我需要使文件可以在Visual Studio以外（通过VC）。 我已经取消了在Visual Studio中的保存，但是当我在VS之外创build文件之后，我再次在VS中点击Save All。 这无意中导致新的类文件不被保存在项目中..但是，尽pipe当我尝试重新编译文件没有find并获得了，但是在参考项目中仍然显示为蓝色和有效键入找不到的错误。 closures和打开Visual Studio仍然显示了这个问题（但如果我注意到类文件重新打开时丢失）。
一旦我意识到这一点，修复很简单：将项目文件设置为可写，将丢失的文件读取到项目中。 现在一切正常。
对于任何在尝试将自己的网站发布到Azure时出现此错误的人，上述有前途的解决scheme都无法帮助我。 我在同一条船上 – 我自己的解决scheme很好。 我结束了不得不
- 删除我的解决scheme中的所有nuget包。
- closures并重新打开我的解决scheme。
- 重新添加所有nuget包。
有点痛苦，但是我可以让我的网站发布到Azure的唯一途径。
我遇到过同样的问题。 有一天晚上我的项目会在第二天早上编译错误！
我最终发现，视觉工作室决定“调整”我的一些参考资料，并在其他地方指出。 例如：
System.ComponentModel.ISupportInitialize莫名其妙地成了“blahblah.System.ComponentModel.ISupportInitialize”
如果你和我一样，那么这对你来说是件很粗鲁的事情
有相同的错误，我的故事如下：在糟糕的合并后（通过git）我的一个.csproj文件有重复的compile条目，如：
<Compile Include="Clients\Tree.cs" /> <Compile Include="Clients\Car.cs" /> <Compile Include="Clients\Tree.cs" /> //it's a duplicate
如果在错误窗口中有一个大的解决scheme和超过300条消息，很难检测到这个问题。 所以我通过记事本打开损坏的.csproj文件，并删除重复的条目。 在我的情况下工作。
我得到了这个错误，试图使用作为代理在本地机器上运行的Visual Studio Team Services构build进行构build。
它在我的常规工作区中工作得很好，我可以在本地代理文件夹内打开SLN文件，并且编译好的所有代码都可以正常工作。
问题的DLL被存储在项目中作为Lib/MyDLL.DLL并在csproj文件中引用此：
<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa"> <SpecificVersion>False</SpecificVersion> <HintPath>Lib\MYDLL.dll</HintPath> </Reference>
事实certificate，尽pipe有提示path，但实际上并没有find该文件。 我想也许msbuild相对于SLN文件，而不是项目文件。
在任何情况下，如果您收到的消息是Could not resolve this reference. Could not locate the assembly Could not resolve this reference. Could not locate the assembly然后确保该DLL在msbuild的可访问位置。
我有点欺骗，发现一个消息说Considered "Reference\bin\xxx.dll" ，只是复制到那里的DLL。
我的情况是相同的讨论在这里，但没有解决它，直到我从参考列表中删除System.Core引用（一切工作正常，没有它）
希望能帮助别人，因为这个问题相当令人沮丧
您的解决schemepipe理是由Nugets引用吗？
做使用VPN来恢复你的nuget引用？
尝试连接到该VPN，删除引用，再次添加并尝试编译。
这对我的情况有效。
在我的情况下，我进入解决scheme属性，并确保“构build”在两个项目的configuration中检查。 我的主要项目没有检查。
从GAC中删除程序集（C：\ WINDOWS \ assembly文件夹 – select您的安装并右键单击并卸载）。 因为解决scheme使用GUID保持参考，如果GUID在GAC中，它将继续采用GAC版本进行编译。
