Visual Studio 2022未生成“生成”
我昨天试图调试AWS SystemsManager源代码,以试图跟踪它在冷启动我的ASP.NET Core 6应用程序时造成的漫长延迟。我没有到任何地方,但是在此期间,它会引发有关生成的编辑配置的错误。
我导航到了错误,它打开了看起来像项目文件的东西。我以为是源的项目文件,并评论了该代码行,现在构建很高兴。最后,我未参考源项目副本并恢复了Nuget软件包,并关闭了一天。
今天,我无法使用Visual Studio 2022构建任何解决方案。我尝试过的所有错误,即从每个项目的obj
文件夹中丢失了agentsbuildeditorConfig.editorConfig
在解决方案中。
我想我最终从一个Visual Studio配置文件中评论了一些内容,但我并不了解该文件名是什么或它的位置,因此我可以解决错误。
有人有建议在我可能找到这个特殊文件的地方吗?我想在更糟糕的情况下,我可以修复VS,但我不想尝试并发现它破裂了。
我的VS2019仍然可以正常工作,因此将其隔离到VS2022安装。
I was trying to debug the AWS SystemsManager source code yesterday to try and track down the long delay it causes in cold booting my ASP.NET Core 6 apps. I didn't get anywhere, but during that time it was throwing errors about generated editor configs.
I navigated to the error and it opened something that looked like a project file. I assumed it was the project file for the source and commented out that line of code and the build was now happy. In the end I un-referenced the source project copy and restored the NuGet package and closed down for the day.
Today, I can't build any solution using Visual Studio 2022. All that I have attempted throw an error that a GeneratedMSBuildEditorConfig.editorconfig
is missing from the obj
folder of each project in a solution.
I guess I ended up commenting out something from a Visual Studio configuration file and I haven't the slightest clue what the file name is or where it is located so I can fix my mistake.
Does anyone have suggestions where I may find this special file? I suppose in a worse case scenario I could repair VS, but I don't want to try that and find it broke something else.
My VS2019 still works correctly, so it's isolated to VS2022 install.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我之所以发生这种情况,是因为文件路径太长。 Windows的提醒最大字符的路径可能是260。我的是267。
I had this happen because the file path was too long. Reminder for Windows the max characters a path can have is 260. Mine was 267.
确保
设置
为1
编辑
向下滚动窗户,然后返回。
In
ensure
is set to 1
EDIT
Roll your Windows down, then back up.
我决定自己只进行VS2022维修,并发现今天实际上有一个更新的17.2.4,所以给了它。一切都恢复正常,所以我猜更新更换了我弄乱并解决问题的配置文件。
I decided to just have VS2022 repair itself and saw that there was actually an updated available today, 17.2.4, so gave it a shot. Everything is working as normal again, so I'm guessing the update replaced the configuration file I messed up and resolved the issue.
总而言之,要启用长路径,两种方式:
确保将长路径索取设置为1:
[hkey_local_machine \ system \ currentcontrolset \ control \ filesystem]
“ LongPathSeNabled” = DWord:00000001
我更喜欢此选项2:在powershell(as admin)中,只需运行以下行:
new -itemproperty -path“ hklm:\ system \ currentcontrolset \ control \ filesystem” - 名称“ longpathseNabled” -value 1 -propertytype dword -force
不幸的是,将不得不重新启动您的计算机。
参考(以及进一步的说明):Microsoft文档在这里。
In summary, to enable long paths, two ways:
Ensure LongPathsEnabled is set to 1:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
I prefer this option 2: In PowerShell (as admin) just run this line:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
Unfortunately, you will have to reboot your computer.
Reference (and further explanation): Microsoft documentation here.