【问题标题】:Windows Form Designer: Could not load file or assemblyWindows 窗体设计器:无法加载文件或程序集
【发布时间】:2008-10-03 13:19:57
【问题描述】:

有没有人遇到过在 Visual Studio .NET 中尝试在 Windows 窗体上“查看设计器”导致错误:“无法加载文件或程序集...”

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

另一条信息是我使用 Resharper 2.5。其他人指出,可能是 Resharper 做了一些影子复制。下次发生这种情况时,我会调查一下。 有没有人了解为什么会首先发生此错误,以及修复它的“正确”方法?

【问题讨论】:

  • 这可能很大程度上取决于 XYZ.dll 实际上是什么...它是 .NET 运行时的一部分吗?它是自定义 DLL 吗?它是您解决方案的其他部分吗?
  • Chen,你的意思是你的项目使用了XYZ.dll中的类但没有引用它?
  • 当问题是由于 64 位 DLL 或项目本身引起的:最后在 VS2022 中这不再是问题(感谢它的 64 位设计)

标签: visual-studio windows-forms-designer


【解决方案1】:

我们有同样的问题。某些 Form/UserControl 类无法在设计器中查看,Visual Studio 会导致各种异常。

有一个典型的原因: 在初始化期间(在构造函数中或在 Load 事件中或之前)中,设计的组件之一引发了未处理的异常。

不仅在这种情况下,您还可以运行另一个 Visual Studio 实例,打开/创建一些独立项目,转到菜单 -> 调试 -> 附加到进程 ... -> 选择有问题的 devenv.exe 进程实例设计师。然后按Ctrl+Alt+E,应显示“例外”窗口。在异常类别中检查“抛出”。

现在使用设计师激活视觉工作室并尝试使用视图设计师。如果将抛出异常,您将看到调用堆栈(可能还有源代码,如果从您的代码中抛出异常)和其他有关抛出异常的典型信息。这些信息可能会很有帮助。

【讨论】:

  • 谢谢!这听起来像是我下次遇到这个问题时肯定会尝试的。我想指出的是,我一直对这种形式持开放态度。这只是最近发生的。
  • 非常有用。谢谢!
  • 一篇旧帖子,但这让我省了很多麻烦!谢谢哥们:)。
  • 这很有帮助!!谢谢!
  • 哇!使用您的解决方案,我可以在引擎盖下的意外项目中找到导致错误的代码的确切行,从没想过它可能是一个问题。
【解决方案2】:

这是一个似乎仍然没有答案的老问题,无论是在这里还是在更广泛的论坛池中,大多数建议与无情清理>重建或关闭>清理文件夹>重新打开或重新启动机器有关。我目前还没有一个可靠的答案,尽管已经对此进行了一些研究,并认为我可以分享。总而言之,在设计控件或表单时,所有设计器文件都复制到一个位置,另一个位置可以存在旧文件,并且描述了一种在设计器生成错误页面之前捕获所有设计器异常的方法。

似乎有两种情况,无法加载或找不到程序集。第一个是由于文件未能复制到设计人员要求的位置,第二个是遗留的过时文件。

如上所述,当项目无法直接引用其引用的引用及其引用所需的所有引用时,文件可能无法复制,递归到框架。这可以通过仔细跟踪所有参考资料及其家属来缓解,确保所有参考资料都得到考虑。

Visual Studio 设计器使用特定位置缓存 dll 以供其在设计器中使用,与项目的源 /bin 文件夹隔离:

Windows XP:

C:\Documents and Settings\[用户名]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies

Windows 7:

C:\Users\[用户名]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

在此位置,已编译的程序集被复制到动态创建的文件夹中,每个程序集一个文件夹。检查此位置的程序集版本日期,它似乎是最新的,在 Visual Studio 退出时被删除。当使用新编译的文件查看设计器时,会复制所有程序集。为每个设计者在此位置制作每个程序集的新副本,因此该位置可以保存每个程序集的多个相同副本。

但还有一个位置可以复制程序集,它是程序集搜索序列的一部分,显然在 ProjectAssemblies 文件夹之前,位于:

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

我不知道程序集如何或何时复制到此位置,但这种情况并不常见,因此到达此处的文件很快就会成为过时引用的来源。当设计器因 “加载文件或程序集失败” 错误而失败时,设计器寻求的版本是仅由该位置的程序集引用的版本。

这是通过在第一个上使用第二个 Visual Studio 实例调试发现的,加载了所有 .net 符号,并且所有已知的异常都在抛出时中断,而不是在未处理时中断。这允许第二个实例拦截已处理的设计器异常并显示该文件位置。这是我使用的设计器错误的结果输出:

=== 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.

【讨论】:

  • 这会更好地作为问题的编辑,而不是作为答案发布。
  • 确实这不是一个答案,尽管它也不是一个真正的问题。也许 stackoverflow 等人需要一个“讨论”部分来讨论贡献者可以共同致力于解决的问题?
  • 谢谢,清除 AppData 下的文件夹为我解决了问题。
【解决方案3】:

删除解决方案中所有项目的所有 bin 和 obj 目录。同时删除 C:\Users\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies 中的文件夹。 VS2008 使用 9.0,VS2010 使用 10.0 等

【讨论】:

    【解决方案4】:

    在这个问题上苦苦挣扎了几个小时。以下是我学到的:检查设计人员尝试加载的 DLL 是否为 64 位 DLL

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

    【讨论】:

    • 上面的答案不起作用,但这个答案做到了。将我的解决方案重新编译为 x86 并能够打开设计器。
    【解决方案5】:

    使用 VS 2005,我遇到了同样的问题。我执行了 Chien 在他原来的问题中列出的步骤,但直到我关闭 VS 并重新打开解决方案之前它仍然没有工作。现在 Designer 视图看起来很好。

    【讨论】:

    • 这也是我的回答。我有一个设计者找不到的直接依赖项(接口项目),但解决方案编译得很好。重启 VS 就成功了。
    【解决方案6】:

    我猜这个问题的发生有不同的原因,但我想我还是会分享我的案例。我希望有人能找到他们项目进展的线索。

    我的问题出现了,因为 Visual Studio(C# 项目)找不到托管的 c++ dll 并将其复制到 J Collins 帖子中提到的位置 => 设计人员找不到该文件。我注意到它没有与其他 DLL:s 一起复制到那里,并发现它有一个不同/非标准的输出目录。将此更改为标准使 Visual Studio 执行复制。

    【讨论】:

      【解决方案7】:

      我在 VS2005 上经常遇到这种情况,特别是在向 winform 添加自定义控件时。通常我只需要重新构建,不需要添加额外的引用,或者关闭并重新打开 VS。

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

      【讨论】:

      • 过去我经常使用 Infragistics Winforms 控件。真烦人,它只发生在我的机器上,即使有 5 个人使用完全相同的代码。
      【解决方案8】:

      我遇到了类似的问题。

      在我的例子中,我有一个基本表单,它引用了混合模式 dll 中的一个类(c++ 托管包装器到非托管库)。 我的派生表单没有正确加载,出现上述相同的错误。

      但是,以下解决了该问题:http://support.microsoft.com/kb/967050

      1. 为 Win32 构建混合模式项目和 ui 项目。由于 VS 是 32 位的,它无法加载 x64 非托管代码:
      2. 清除 ProjectAssemblies 文件夹(需要先关闭 VS)

      当您重新打开 VS 时,设计器会毫无问题地加载。请注意,默认情况下,C# 项目编译为在 Windows x64 上编译为 x64 的任何 CPU。

      希望这对某人有所帮助。

      【讨论】:

        【解决方案9】:

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

        正如其他人所提到的,Windows 窗体设计器显然会在呈现之前实例化您的窗体/用户控件的某个版本。

        如果表单设计器由于某种原因无法实例化该类,它将失败。所以我所做的就是注释掉有问题的 Usercontrol 的构造函数,然后重建我的项目。

        这让我可以再次使用表单设计器。

        当然,您可以使用此方法选择性地注释掉构造函数的某些部分,直到识别出导致表单设计器阻塞的部分,并尽可能修复它。

        【讨论】:

          【解决方案10】:

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

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

          观察:
          如果表单中有继承的组件,设计器可能会停止工作

          观察的伪代码示例:

          ...
          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中继承的组件MyCtrl注释掉,改用基类UserControlVisual Studio 窗体设计器 再次开始工作!

          如何在 C# 中编写一个正确的 Visual Studio 窗体设计器 - 交互、继承的组件类超出了我的能力范围。但是,这个观察结果可能是一个线索,有人可以解决这个问题。

          【讨论】:

            【解决方案11】:

            我同意 Resharper 的评论。我正在运行4.1。我禁用它,重新启动 VS2008,然后再次尝试“转换为 Web 应用程序”,它成功了。

            【讨论】:

              【解决方案12】:

              我在 VS2005 中看到过这种情况,用于 Window Forms、ASP.NET 和 Compact Framework 项目。我正在构建的项目依赖于我的解决方案中的另一个程序集,但抱怨它在尝试生成设计器文件时无法加载它。

              我不确定确切原因,但有时会在我们提高程序集的版本号后发生。出于某种原因,Visual Studio 不会将此程序集视为“新”,并且不会将新版本放入当前项目的 bin/ 文件夹中。但大多数时候确实如此。

              使用设计器错误删除项目的 bin/ 文件夹(以及 obj/ 文件夹),然后重新构建,似乎可以让伤害消失。

              【讨论】:

                【解决方案13】:

                我也遇到过同样的问题。 我从项目中删除了引用并再次添加,一切正常(查看 ptoject 文件,我看到引用定义已更改,例如添加了“SpecificVersion”标签并设置为“false”)。

                【讨论】:

                  【解决方案14】:

                  我发现,对于这样的问题以及许多其他问题,问题往往围绕 .NET 框架安装。很多时候,例如在系统崩溃期间,文件可能会损坏,尤其是。如果您关闭了虚拟内存。当 C:\WINDOWS\Microsoft.NET 文件夹中的文件损坏时,它们不会按应有的方式工作,因为这些文件很多,因此不会总是发生错误。文件的某些部分可能可以正常加载,而其他部分则不能。多年来,我发现将 Microsoft.NET 文件夹的完整备份保存在具有某种类型的损坏保护的存档中对我来说效果很好。您不会相信损坏的 .NET 文件导致出错的事情的数量。 IDE 的几乎每个方面都取决于它的一部分以及许多其他功能。当然,如果你没有备份,你应该卸载所有网络框架安装(不要修复,因为这不能保证文件被重写——文件可能通过校验和和长度检查但仍然损坏)。卸载后重新启动系统,确保整个Microsoft.NET文件夹都被删除,如果没有,自己删除(我不得不这样做,有些文件仍然留下)。完成此操作后,重新安装 NET 框架,具体取决于您的操作系统,您可能无法摆脱整个事情。但是对于 Windows XP,我知道你可以,就测试而言,我还没有在你自己的新操作系统上测试过这个。我首先安装 2.0,然后是 3.5 SP1,依此类推,具体取决于您使用的 Visual Studio。我坚持使用 2008,因为它对我来说是最快的,并且仍然支持一些较新的东西,如 WPF、tr1 等......希望这可以帮助你和其他任何有 .NET 问题的人,错误消息通常会误导但对我来说99% 的时间是 Microsoft.NET 文件损坏。

                  【讨论】:

                    【解决方案15】:

                    对于将来遇到此问题并一直向下滚动搜索的任何人:Delete ComponentModelCache in Appdata/Local/Microsoft/VisualStudio/..

                    【讨论】:

                      【解决方案16】:

                      我已经多次遇到这个问题。大多数时候clean+rebuild 有效(有时与 Visual Studio 的重新启动相结合)。

                      clean+rebuild 失败的两次是:

                      问题 #1

                      在我遇到的一种情况下,它与 C# 和 VB.NET 有关。

                      我的表单中有几个用户控件没有加载到设计器中。用户控件在 C# 中。它们中的大多数都在同一个命名空间下,但其中很少有部分命名空间在字母大小写中不匹配。

                      例如:

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

                      对于 C#,它们是不同的命名空间,因为 C# 区分大小写。但是 VB.NET 不区分大小写。我得到的错误是在尝试加载 myapp.mynamespace.userControl2 时。挣扎了半天,注意到报错信息中的命名空间,在用户控件中更正,使它们都和'myapp.myNamespace1'一样,中提琴设计器在clean+rebuild之后打开。

                      问题 #2

                      我的表单(没有打开),有很多用户控件。其中一个控件具有枚举类型的属性。这个枚举是在一个泛型类中定义的。设计器为此用户控件生成的代码类似于:

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

                      我在打开设计器时遇到的错误是:

                      无法加载类型 somenamespace.SomeGenericClass[System.Date]+SomeEnum

                      我将枚举移到类外,并将设计器代码替换为:

                      myUserControl1.SomeType = somenamespace.SomeEnum
                      

                      然后设计师打开了。 :)

                      我希望这对某人有所帮助。

                      【讨论】:

                        【解决方案17】:

                        我会说这个帖子中的回复对我有所帮助,但并没有准确地确定我的自定义用户控件中发生了什么。

                        在我的特殊情况下,我有许多帮助类库来执行诸如在我的控件上设置样式、后台日志记录之类的事情,以及只是执行我一直在做的例行事情的通用帮助类。

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

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

                        我在我的用户控件的构造函数、加载和属性集方法中执行了此操作...而设计器无法始终构建静态方法调用的路径,因此设计器会失败。

                        我尝试在它周围放置 DesignMode 检查,但问题不在于运行时 - 它是设计时,并且无法构建链接。我唯一的选择是在我的自定义用户控件的以下位置删除对我的静态帮助程序类的所有引用:

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

                        不幸的是,尝试使用辅助 IDE 进行调试并使用 Attach to Process 对我没有工作。

                        【讨论】:

                        【解决方案18】:

                        还要确保您有一个 using 声明,用于在表单或控件中包含控件的库。一旦设计者知道它,它就会在 Form.designer.cs 文件中的对象引用中写入完整的命名空间。

                        【讨论】:

                          【解决方案19】:

                          我尝试了上面有关删除文件、重新构建、重新启动等的许多建议。我的问题是它无法加载解决方案中一些项目使用的实用程序程序集。另一个项目有共同的控制。因此,Form1 引用了 ControlsAssembly1 引用了 UtilityAssembly1。 .resx 文件具有 UtilityAssembly1 中类型的属性。我删除了包含这些类型的资源。尝试再次打开表单(由于缺少资源而出现空引用异常),点击忽略并继续,我的问题得到了解决。

                          【讨论】:

                            【解决方案20】:

                            为了让您的 From 回来。 首先转到 Visual Studio 2008 命令提示符。

                            输入devenv /resetsettings
                            输入devenv /resetSkippkgs

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

                            【讨论】:

                              【解决方案21】:

                              我遇到过这个问题。我做了上面所说的,但没有任何意义。然后我将程序集添加到引用中。重建项目。关闭了 Visual Studio。然后重新打开屏幕,设计器就正常出现了。

                              问候,

                              【讨论】:

                                【解决方案22】:

                                只是为了插话。当我的其他项目打开并引用它时,我构建了我的 UserControl 的新版本。当我回去查看引用用户控件的表单中的设计器时,它说它找不到特定版本的.dll。

                                我试图从工具箱中删除对控件的引用,但没有成功。代码可以编译得很好,但设计器不会显示没有错误。

                                以上方法都试过了,还是不行。

                                表单的 .res 文件有一些 XML:

                                <data name="EventBar1.EventCheckedSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
                                    <value>
                                        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
                                        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
                                        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
                                        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
                                        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
                                        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
                                </value>
                                  </data>
                                  <data name="EventBar1.EventLengthSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
                                    <value>
                                        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
                                        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
                                        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
                                        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
                                        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
                                        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
                                </value>
                                  </data>
                                  <data name="EventBar1.EventLengthTypes" mimetype="application/x-microsoft.net.object.binary.base64">
                                    <value>
                                        AAEAAAD/////AQAAAAAAAAAMAgAAAKABY3RybENhbGVuZGFyU2lkZUJhciwgVmVyc2lvbj0xLjAuNzEy
                                        MS4yMTIzNCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1udWxsXV0sIG1zY29ybGliLCBW
                                        ZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0
                                        ZTA4OQwDAAAAUWN0cmxDYWxlbmRhclNpZGVCYXIsIFZlcnNpb249MS4wLjcxMjEuMjEyMzQsIEN1bHR1
                                        cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAT1N5c3RlbS5Db2xsZWN0aW9ucy5HZW5l
                                        cmljLkxpc3RgMVtbY3RybENhbGVuZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAA
                                        Bl9pdGVtcwVfc2l6ZQhfdmVyc2lvbgQAAC5jdHJsQ2FsZW5kYXJTaWRlQmFyLkV2ZW50QmFyK0V2ZW50
                                        TGVuZ3RoVHlwZVtdAwAAAAgIAgAAAAkEAAAAAAAAAAAAAAAHBAAAAAABAAAAAAAAAAQsY3RybENhbGVu
                                        ZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAACw==
                                </value>
                                  </data>
                                  <data name="EventBar1.EventSettingsSubscriptions" mimetype="application/x-microsoft.net.object.binary.base64">
                                    <value>
                                        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
                                        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
                                        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
                                        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
                                        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
                                        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
                                </value>
                                  </data>
                                

                                我从 .res 文件中删除了它,一切都很好。在我尝试之前,我确实备份了整个文件夹!

                                【讨论】:

                                  猜你喜欢
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 2023-03-12
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 2014-10-22
                                  • 1970-01-01
                                  相关资源
                                  最近更新 更多