Windows窗体devise器:无法加载文件或程序集

有没有人有试图在Visual Studio .NET中的Windows窗体上“视图devise器”的问题导致错误: “无法加载文件或程序集…”

在这种情况下,有问题的程序集是XYZ.dll 。 我设法通过添加XYZ.dll及其所有对我的项目引用的引用(即使我的项目不直接依赖于它们)并重build整个解决scheme来解决此问题。 然而,之后,我从我的项目中删除了所有这些引用,重build,它仍然工作。

另一个信息是我使用Resharper 2.5 。 有人指出,这可能是Resharper做一些阴影复制。 我会在下次发生这种情况。 有没有人有理解为什么这个错误首先发生,可能是“正确的”方法来解决它?

我们有同样的问题。 某些Form / UserControl类不能在devise器中查看,并且Visual Studio会导致各种exception。

有一个典型的原因:devise组件之一在初始化期间(在构造函数或Load事件或之前)抛出未处理的exception。

不仅对于这种情况下,你可以运行另一个Visual Studio的实例,打开/创build一些独立的项目,进入菜单 – >debugging – >附加到进程… – >select与有问题的devise师的devenv.exe进程的实例。 然后按Ctrl + Alt + E ,应显示“例外”窗口。 在exception类别中检查“Thrown”。

现在与devise师一起活动视觉工作室并尝试视图devise师。 如果抛出exception,你会看到callstack(也可能是源代码,如果exception是从代码中抛出的)和其他关于抛出exception的典型信息。 这些信息可能非常有帮助。

这是一个老问题,看起来还没有答案,无论是在这里还是在更广泛的论坛池中,大多数build议涉及到无情的清理>重build或closures>清理文件夹>重新打开或重新启动机器。 目前我没有一个确切的答案,虽然已经做了一些研究,并认为我可以分享。 总而言之,当控件或表单被devise时,有一个位置可以将所有devise器文件复制到一个位置,旧文件可以存在的另一个位置以及一个方法被描述为在devise器生成错误页面之前捕获所有devise器exception。

似乎有两种情况下,无论是集装箱不能被加载或无法find。 第一个是文件无法复制到devise者所需的位置,第二个是过时的文件被留下。

如上所述,当项目无法直接引用引用的引用及其引用所需的所有引用时,文件可能无法复制,而是recursion地引用到框架。 这可以通过仔细跟踪所有参考文献和他们的家属来减轻,确保所有参考文献都被logging下来。

Visual Studiodevise器使用特定位置来cachingdll以在devise器中使用,与项目的source / bin文件夹隔离:

Windows XP:

C:\ Documents and Settings \ [user_name] \ Local Settings \ Application Data \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

Windows 7的:

C:\用户\ [USER_NAME] \应用程序数据\本地\微软\ VisualStudio的\ 10.0 \ ProjectAssemblies

在这个位置,编译的程序集被复制到dynamic创build的文件夹,每个程序集一个文件夹。 检查这个位置上的程序集版本date,它似乎是相当新的,当Visual Studio退出时被删除。 使用新编译的文件查看devise器时,所有程序集都将被复制。 为每个devise人员将每个assembly的新副本制作到该位置,因此该位置可以保存每个assembly的多个相同的副本。

然而,另外一个位置存在,其中可能会复制程序集,并且是程序集search序列的一部分,明显位于ProjectAssemblies文件夹的前面,位于:

C:\ Program Files \ Microsoft Visual Studio 10.0 \ Common7 \ IDE

我不知道如何或什么时候将程序集拷贝到这个位置,但是通常不会那么快到达这里的文件成为过时引用的来源。 当devise器由于“无法加载文件或程序集”错误而失败时,devise人员所寻求的版本是仅在此位置由程序集引用的版本。

这是通过使用第二个Visual Studio实例第一次debugging,加载了所有的.net符号,以及所有已知的exception抛出而不是未处理时发现的。 这允许第二个实例拦截已处理的devise器exception并显示文件位置。 这是我使用的devise器错误的结果输出:

 === Pre-bind state information === LOG: User = ************** LOG: DisplayName = ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null (Fully-specified) LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/ LOG: Initial PrivatePath = NULL Calling assembly : ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null. === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: The same bind was seen before, and was failed with hr = 0x80070002. 

什么帮助我删除解决scheme中的所有项目的所有bin和obj目录。 如前所述,还要删除C:\ Users \\ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies中的文件夹。 VS2008使用9.0,VS2010使用10.0

使用VS 2005,我遇到了同样的问题。 我执行了Chien在他原来的问题中列出的步骤,但是直到我closuresVS并重新打开解决scheme之后,它依然没有奏效。 现在devise师视图看起来很好。

我想这个问题是出于不同的原因,但我想我会分享我的情况。 我希望有人会发现他们的项目正在发生什么。

我的问题发生在Visual Studio(C#项目)找不到托pipec + + dll并将其复制到J Collins post =>中提到的位置devise器无法find该文件。 我注意到它没有与其他DLL复制在一起,发现它有一个不同的/非标准的输出目录。 将其更改为标准,使Visual Studio执行复制。

在VS2005中,我经常遇到这种情况,特别是在向winform添加自定义控件时。 通常我只需要重build,而不需要添加额外的引用,或closures并重新打开VS.

没有明显的原因,只是VS的错误。

我有一个类似的问题。

在我的情况下,我有一个基本的forms,其中引用混合模式DLL(C托pipe库的C托pipe包装)的类。 我的派生forms没有正确加载,给出了上述相同的错误。

但是,下面的问题解决了这个问题: http : //support.microsoft.com/kb/967050

  1. 为Win32构build混合模式项目和ui项目。 由于VS是32位,所以无法加载x64非托pipe代码:
  2. 清除ProjectAssemblies文件夹(需要先closuresVS)

当你重新打开VS时,devise者加载没有问题。 请注意,默认情况下,C#项目被编译为在Windows x64上编译为x64的任何CPU。

希望这有助于某人。

在这个问题上挣扎了几个小时。 以下是我所学到的: 检查devise者是否正在尝试加载的DLL是64位DLL

结果,对我来说很明显,VS是一个32位的应用程序,所以VSdevise师 – 惊喜! 惊喜! 也是一个32位的应用程序,所以如果你有一个用户控件或其他WinForms控件有一个64位DLL的引用 – 这是一个很大的否,这将导致你的表单不在VSdevise器中呈现,并生产无法加载文件或程序集错误 。 所以你应该做的第一件事是确保devise者所抱怨的DLL 不是一个64位的DLL。

我在一个c ++ / cli项目中遇到了这个问题。

正如其他人已经提到的,显然Windows窗体devise器在呈现之前实例化您的Form / UserControl的一些版本。

如果表单devise者不能以任何理由实例化类,它将失败。 所以我所做的就是评论出有问题的Usercontrol的构造函数,然后重build我的项目。

这使我再次使用表单devise器。

当然,你可以使用这个方法来有select地注释构造函数的部分,直到识别出造成表单devise器窒息的部分,并且如果可能的话修复它。

我同意Resharper的评论。 我正在运行4.1。 我禁用它,重新启动VS2008,并再次尝试“转换到Web应用程序”,它的工作。

我已经看到在VS2005中发生这种情况的窗体,ASP.NET和Compact Framework项目。 我正在构build的项目对我的解决scheme中的另一个程序集有依赖性,但是抱怨在尝试生成devise器文件时无法加载它。

我不知道确切的原因,但有时会遇到大会的版本号。 出于某种原因,Visual Studio将不会将此程序集看作“新的”,并且不会将新版本删除到当前项目的bin /文件夹中。 大部分时间它虽然。

用devise器错误删除项目的bin /文件夹(以及obj /文件夹),然后重build,似乎使伤害消失。

我面临同样的问题。 我从项目中删除了引用,并再次添加,所有工作正常(看在ptoject文件中,我看到参考定义已更改,例如“SpecificVersion”标记已添加并设置为“false”)。

我发现,像这样的问题和其他问题,这个问题往往围绕.NET框架安装。 很多时候,比如在系统崩溃时,文件可能会被损坏。 如果你有虚拟内存closures。 当C:\ WINDOWS \ Microsoft.NET文件夹中的文件被损坏时,它们不会按照他们应该的方式工作,因为这些文件很多,错误总是不会发生。 文件的某些部分可能是正常的,加载,然后其他人不。 多年来,我发现保留一个完整的Microsoft.NET文件夹备份在一个档案中有一些types的腐败保护对我来说很好。 你不会相信那些损坏.NET文件的东西的数量会导致错误。 IDE的每个方面都取决于其中的一部分以及许多其他function。 当然,如果你没有备份你应该卸载所有的NET FRAMEWORK INSTALLATIONS(不要修复,因为这不保证文件被重写 – 文件可能通过校验和长度检查,但仍然是腐败)。 卸载后,重新启动系统,确保整个Microsoft.NET文件夹被删除,如果没有,自己删除它(我必须这样做,一些文件仍然留下)。 一旦完成,重新安装NET框架,根据您的操作系统,您可能无法摆脱整个事情。 但与Windows XP中,我知道你可以,我还没有testing过这个新的操作系统是你自己的testing。 我开始安装2.0,然后3.5 SP1,依此类推,取决于你正在使用的Visual Studio。 我坚持2008年,因为它对我来说是最快的,并仍然支持一些像WPF,TR1等新的东西…希望这可以帮助你与任何人与.NET的困境,错误信息往往是误导,但对我来说99%的时间是Microsoft.NET文件损坏。

对于将来有这个问题的人,一直向下滚动search:在Appdata / Local / Microsoft / VisualStudio /中删除ComponentModelCache。

我多次面对这个问题。 大多数时候clean+rebuild工程(有时与Visual Studio的重新启动相结合)。

两次,当clean+rebuild没有工作,这是:

问题#1

在我面对的其中一个案例中,它与C#和VB.NET有关。

我的表单中有几个用户控件没有在devise器中加载。 用户控件在C#中。 他们中的大多数都在同一个命名空间下,但是其中很less有一部分名字空间在字母表中不匹配。

例如:

 userContorl1 was in myapp.mynamespace1, and userControl2 was in myapp.myNamespace1 

对于C#,它们是不同的名称空间,因为C#区分大小写。 但VB.NET不区分大小写。 我得到的错误是当试图加载myapp.mynamespace.userControl2。 经过长时间的努力,我注意到了错误信息中的命名空间,并在用户控件中进行了更正,使得它们与“myapp.myNamespace1”相同,并且在clean+rebuild之后打开了violadevise器。

问题#2

我的表单(这是不开放),有许多用户控制。 其中一个控件是具有枚举types的属性。 这个枚举是在generics类中定义的。 devise者生成这个用户控件的代码是这样的:

 myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum 

我打开devise师时得到的错误是:

无法加载typessomenamespace.SomeGenericClass [System.Date] + SomeEnum

我将类枚举移出了该枚举,并将devise器代码replace为:

 myUserControl1.SomeType = somenamespace.SomeEnum 

devise师打开。 🙂

我希望这有助于某人。

我会说在这个线程中的反应有点帮助我,但没有确切地指出我的自定义用户控件中发生了什么。

在我的情况下,我有许多助手类库,执行诸如我的控件的样式,后台日志logging,以及执行例行工作的generics助手类。

我正在使用其他一些库静态方法来执行错误情况下的日志logging。 这是一个例子:

try { _InitializeStuff(); } catch (Exception ex) { Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage); }

我在我的用户控件的构造函数,加载和属性集方法中这样做…并且devise者不能总是build立到静态方法调用的path,所以devise者会失败。

我试着将DesignMode放在它的周围,但问题不在于运行时 – 这是devise时,链接无法build立。 我唯一的select是在我的自定义用户控件的下列位置删除对我的静态帮助器类的所有引用:

  • 构造函数
  • 加载
  • 属性访问器

尝试使用辅助IDE进行debugging,并且使用“附加到进程”对我不起作用。

还要确保你有一个使用声明的图书馆与控制在你的forms或控制。 一旦devise人员知道它,它会在Form.designer.cs文件中的对象引用中写入完整的命名空间。

我正在使用VS2005和VS2013,看到了同样的问题。 一些Visual Studio表单devise师在我的项目工作中,其他人不会在devise模式下打开。 有些开启尝试甚至会在错误页面出现之前崩溃Visual Studio,并说:

为了在加载devise器之前防止可能的数据丢失,必须解决以下错误:

一个观察:
如果表单中有inheritance组件,devise者可能会停止工作

观察的伪代码示例:

 ... using System.Windows.Forms; // UserControl namespace MyNamespace { public class MyForm : Form { public MyForm() { InitializeComponent(); ... } private void InitializeComponent() { //this.ctrl = new MyNamespace.MyCtrl(); // Inherited class this.ctrl = new System.Windows.Forms.UserControl(); ... } //private MyNamespace.MyCtrl myCtrl; // Inherited class private UserControl ctrl; } public class MyCtrl : UserControl { ... } } 

在非伪代码实现中,我注释了MyForm的inheritance组件MyCtrl ,而是使用了基类UserControlVisual Studio窗体devise器再次开始工作!

如何编写一个正确的Visual Studio表单devise器 –在C#中的交互,inheritance组件类超越了我。 但是,这个观察可能是某个人的线索,他们可以解决这个问题。

我尝试了许多以上关于删除文件,rebuliding,重新启动等等的build议。我的问题是,它无法加载在解决scheme中的一些项目使用的实用程序集合。 另一个项目有共同的控制。 所以,Form1引用了ControlsAssembly1引用的UtilityAssembly1。 .resx文件具有UtilityAssembly1中的types的属性。 我删除了包含这些types的资源。 试图再次打开表单(由于缺less资源得到空引用exception),点击忽略并继续,我的问题已修复。

为了让你的回来。 首先去Visual Studio 2008命令提示符。

键入devenv /resetsettings
键入devenv /resetSkippkgs

  1. 在解决scheme资源pipe理器中单击“显示所有文件
  2. 现在双击打开Form1.vb,然后单击+将其展开。
  3. 打开Form1.Designer.vb
  4. 您可以在编辑器窗口(IDE)中看到两个选项卡。
  5. 现在右键单击选项卡“Form1.vb”并保存
  6. 同样右键单击选项卡Form1.vb [Design]并保存
  7. 重新构build你的项目。
  8. 重新启动Visual Studio。