Visual Studio 2010 .net 3.5 及更低版本在 Windows 7 上出现混乱

发布于 2024-12-11 13:16:57 字数 533 浏览 0 评论 0 原文

在上周的一些故障排除过程中，我卸载了 .net 3.5，以为我可以重新安装，并这样做了（至少尝试过），但现在我似乎无法构建任何针对 3.5 的东西，我尝试重新安装 3.5 但它保留告诉我我必须在 Windows 功能中执行此操作，所以我尝试检查和取消检查它。任何帮助都会很棒。

编辑：我可能应该补充一点，我使用了revo卸载程序并完全抛弃了3.5。在此处输入图像描述

在此输入图像描述在此处输入图像描述

在此处输入图像描述

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

放手` 2024-12-18 13:16:57

您已经破坏了 .NET Framework。恭喜你去过那里，这并不好玩。如果您用 Google 搜索，您肯定已经找到

http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0- on-windows-vista.aspx

其中提到 Vista+ 上的 .Net Framework 是操作系统的一部分，您无法像往常一样重新安装它。提到的调用

sfc.exe /scannow 的

技巧没有帮助，因为它只能修复 MSI 和受信任安装程序控制下的位置中丢失的文件。

在我的文件系统上进行了大量搜索后，我终于在一个意想不到的地方找到了我的程序集。它们都再次安装到 C:\Windows\WinSxS...，通常仅用于非托管并行 dll，如 C-Runtime 或任何其他 dll。我不知道他们是如何安装它的，但安装到 GAC 中的正常 MSI 安装不会再次将托管程序集安装到 WinSxS 文件夹中。

再想一想，这听起来很合理，因为 MSI 和安装程序只关心 WinSxS system32 和其他受特殊保护的文件夹中的文件。 GAC 不受这种方式的保护，这意味着通常的修复机制不起作用。

我摆脱困境的方法是使用 gacutil 将所有内容再次安装到 GAC 中，这些内容可从 WinSxS 程序集安装。使用以下命令我取得了成功：

 1. C:\Windows\winsxs>for /D %i in (*_System.*) do for %j in (%i\*.dll)
    do echo %~fj >> %TEMP%\assemblies.txt 
 2. C:\Windows\winsxs>for /D %i in (*_microsoft.*) do for %j in (%i\*.dll) do echo %~fj >> %TEMP%\assemblies.txt
 3. for /F %i in (%TEMP%\assemblies.txt) do gacutil /i %i

我没有找到任何解释为什么 .NET 程序集第二次安装在 WinSxS 文件夹中。 MSI 确实以几乎相同的方式对待托管和非托管程序集，但使用普通安装程序时我不会出现这种行为。我确实知道 MS 对于 Windows 组件使用了类似于 MSI 的技术，但底层引擎却截然不同。

当您获得操作系统补丁时，它们看起来像普通的 msi 文件，但事实并非如此。如果您尝试重新打包它们，您会发现安装不再有效。获得有关这个黑暗主题的更多信息将是非常有趣的。

You have broken the .NET Framework. Congrats been there this is no fun. If you have Googled you surely have found

http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx

There it is mentioned that the .Net Framework on Vista+ is part of the OS you you cannot reinstall it as usual. The mentioned trick to call

sfc.exe /scannow

does not help since it does only repair missing files in locations under MSI and Trusted Installer control.

After searching a lot on my file system I did finally find my assemblies in an unexpected place. They are all installed a second time into C:\Windows\WinSxS... which is normally only used for unmanaged side by side dlls like the C-Runtimes or any other dll. I do not know how they did install it but normal MSI installations which do install into the GAC do not install the managed assemblies a second time into the WinSxS folder.

On a second thought it sounds reasonable since MSI and the installers do only care about files in the WinSxS system32 and other specially protected folders. The GAC is not protected in this way which means that the usual repair mechanisms do not work.

My way out of this mess was to use gacutil to simply install everything into the GAC again which is intallable from the WinSxS assemblies. With the following commands I had success:

 1. C:\Windows\winsxs>for /D %i in (*_System.*) do for %j in (%i\*.dll)
    do echo %~fj >> %TEMP%\assemblies.txt 
 2. C:\Windows\winsxs>for /D %i in (*_microsoft.*) do for %j in (%i\*.dll) do echo %~fj >> %TEMP%\assemblies.txt
 3. for /F %i in (%TEMP%\assemblies.txt) do gacutil /i %i

I have nowhere found any explanation why the .NET assemblies are installed a second time in the WinSxS folder. MSI does treat managed and unmanaged assemblies nearly the same way but with the normal installers I do not get this behaviour. I do know that MS uses for Windows Components a technology similar to MSI but the underlying engine is quite different.

When you get OS patches they look like regular msi files but they aren´t. If you try to repackage them you will find out that the installation does no longer work. It would be very interesting to get more infos on this dark subject.

回复收藏 0 原文