.vhost.exe是一个调试器进程，因此正在调试的进程似乎没有正确关闭。有可能你有一个错误，使它仍然存在，并且没有正确地停止调试进程——当你单击“停止调试”而不是实际杀死调试器时，有一些选项可以从进程中分离出来，所以也许你有这样的设置。

但这就是问题所在——你试图复制的文件被操作系统锁定(即仍在使用)，所以它阻止了复制。确保该文件是免费的，您将能够复制。

我在Windows 8上的VS 2012 Version 11.0.60610.01 Update 3上遇到了同样的问题

没有打开设计器窗口，项目是一个简单的控制台应用程序。

删除访问该文件的vshost进程在大多数情况下都不起作用，因为该进程没有访问该文件。

最简单的工作方法是将项目从解决方案中删除，在解决方案中构建另一个项目，然后将原始项目添加回来。

这是一种刺激和浪费时间，但这是我所知道的所有其他选择中最便宜的。

希望这对你有所帮助……

我在Visual Studio 2013中遇到过类似的错误消息。

大多数情况下，我发现这种情况发生在调试进程因为异常而停止时。

当clean+build不能为我解决这个问题时，我通过以下方法取得了成功:

关闭Visual Studio 删除bin和obj文件夹 重新开放Visual Studio。

此“bug”自Visual Studio 2003以来一直存在。

最后，我还发现我通常可以通过简单地重命名可执行文件然后删除它来克服这个问题。

我通过在任务管理器中杀死IISExpress解决了这个问题

Use

Debug.Flush();
Debug.Close();

如果发生异常，则在catch或finally中阻塞。

编辑: 我个人遇到过这个问题，我通常会做一个小技巧，效果很好。 我将构建类型从“调试”更改为“发布”(如果已经存在，则将“发布”更改为“调试”)。

我不能给出一个解决方案来防止这种情况发生，但你至少可以重命名锁定文件(windows资源管理器，或经典命令窗口)，然后编译/构建。不需要重启VS201x。如果有一些经验，你可以添加一个预构建脚本来删除旧文件或重命名，以防出现锁。

看看另一个答案。基本上，你可以让MSBuild.exe进程在后台运行，消耗资源文件。如果你有任何构建前或构建后的任务，导致MSBuild通过命令行启动，尝试添加"/nr:false"标志到这个命令。但是，关于更具体的细节，请参见前面的回答。

如果我使用VS2012在WP8上编辑Xaml页面，每次部署都会遇到这个问题。

我需要要么不打开Xaml页面，要么使用进程资源管理器杀死进程XDesProc.exe。

如果您得到这个错误，那么我建议使用进程资源管理器来查看发生了什么(即使这是一个不同的问题)。只要找到进程“WeinGartner.WeinCad.exe”，它应该显示进程和处理访问文件(好吧，至少当杀死vhost文件不解决问题)。

我终于怎么修了。为什么我们不能在第一次调试后继续调试，因为第一次调试exe仍在运行。这样，在第一次调试之后，您需要进入任务管理器->进程选项卡->[您的项目名称exe]结束exe进程。

这对我很有用:)

问题是调试器/构建器创建的可执行文件或库被反病毒程序识别为威胁，因此在可以执行之前立即删除。

最好你应该调整你的反病毒软件，不分析你的项目文件夹。

按照从好到坏的顺序，有以下几种方法:

将项目文件夹从防病毒程序中排除 不包括pdb文件(不是100%保证修复) 关闭实时保护(不推荐)

这个问题是查找以下错误时的第一个结果:

无法复制文件“…”，因为没有找到该文件。

在Visual Studio 2013(更新3)中构建时。

解决方案:卸载Visual Studio 2013中的“生产力工具”。

https://connect.microsoft.com/VisualStudio/feedback/details/533411

在Visual Studio Premium 2013 (Update 3)中，我用一个预构建的一行程序解决了这个问题:

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

这将优雅地删除任何旧的PDB文件(如果可以的话)，然后重命名任何带有.old的文件。pdb的扩展。一个很好的副作用是，如果旧的PDB仍然是锁定的，它只是在文件名中添加另一个.old块，并且在下次重新启动Visual Studio并进行构建时，它们都将被清除。

例如，构建/调试会话1离开MyProject。pdb锁定。 下次构建时: MyProject的。MyProject.old.pdb

然后，构建/调试会话2启动，并且MyProject。pdb和MyProject.old.pdb仍然锁定: MyProject.old.pdb—> MyProject.old.old.pdb MyProject的。MyProject.old.pdb

最后，重新启动Visual Studio并进行一个新的构建将摆脱这两个问题，并像往常一样继续这个过程。

这是因为你已经关闭了你的应用程序，但它仍然在后台运行。

临时解决方案:

进入任务管理器(Ctrl + Shift + Esc)。 进入进程选项卡，找到“YourProjectName.exe”。 如果找不到自己的进程，请勾选“显示来自所有用户的进程”。 结束处理

永久解决方案:必须通过编码关闭应用程序。这是代码…

System.Windows.Forms.Application.Exit();

您必须以所有形式将此代码放入表单的关闭事件中。例子:

private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)
{
    System.Windows.Forms.Application.Exit();
}

在任务管理器中检查任何运行.exe .exe的进程

进入“工具>>选项>>数据库工具>>常规” 检查脚本/查询执行情况

在我的情况下，它是Resharper单元测试运行器(加上NUnit测试，从来没有这样的问题与MsTests)。在杀死进程后，可以重建进程，而无需重新启动OS或VS2013。

其他测试运行程序，比如xUnit，也会导致同样的问题。

有帮助的方法是检查是否可以添加Dispose模式，例如，如果您正在添加DbFixture，而数据库联系人没有正确地处理。这将导致即使测试完成，程序集文件也被锁定。

请注意，您可以将IDisposable接口添加到DbFixture中，并让IntelliSense添加Dispose模式。然后，处理相关的包含属性，并显式地将它们赋值为null。

这将有助于以一种干净的方式结束测试，并在测试结束后立即解锁相关的锁定文件。

示例(DBFixture由xUnit测试使用):

public class DbFixture: IDisposable
{
    private bool disposedValue;
    public ServiceProvider ServiceProvider { get; private set; }
    
    public DbFixture()
    {
        // initializes ServiceProvider
    }
    
    
    protected virtual void Dispose(bool disposing)
    {
        if (!disposedValue)
        {
            if (disposing)
            {
                // dispose managed state (managed objects)
                ServiceProvider.Dispose();
                ServiceProvider = null;
            }

            // TODO: free unmanaged resources (unmanaged objects) and override finalizer
            // TODO: set large fields to null
            disposedValue = true;
        }
    }

    // // TODO: override finalizer only if 'Dispose(bool disposing)' has code to free unmanaged resources
    // ~DbFixture()
    // {
    //     // Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method
    //     Dispose(disposing: false);
    // }

    public void Dispose()
    {
        // Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }
}

测试类本身也需要相同的模式——它需要自己的Dispose方法(如上面的DbFixture类所示):

   public SQL_Tests(ITestOutputHelper output)
    {
        this.Output = output;
        var fixture = new DbFixture(); // NOTE: MS Dependency injection framework didn't initialize when the fixture was a constructor param, hence it is here
        _serviceProvider = fixture.ServiceProvider;
    } // method

因此，它需要在自己的dispose方法中处置其本地属性_serviceProvider，因为测试类构造函数SQL_Tests实例化了它。

我没有意识到我仍然连接着调试器，并试图在同一个Visual Studio实例中构建。一旦我停止调试器，我就能够构建。

另一个拼凑，额，但它很容易，为我在VS 2013工作。单击项目。在属性面板中应该有一个名为Project File的条目，该条目带有一个值

(你的项目名).vbproj

更改项目名称—例如在末尾添加-01。被锁定的原始.zip文件仍然在那里，但不再被引用…这样你的工作才能继续。下次计算机重新启动时，锁将消失，您可以删除错误文件。

删除Bin文件夹中的Debug或Release文件夹下的所有.cache文件。

对我来说，杀死vste .executionengine.exe进程(es)在90%的情况下解决了这个问题。如果这不起作用，那么也杀死QTAgent32.exe，然后删除项目的/bin和/obj文件夹。

这是我工作中最烦人的部分。：）

@Geoff (https://stackoverflow.com/a/25251766/3739540)的回答很好，但在重新编译时抛出错误代码1。

下面是对我有用的(2>nul 1>nul在结束+退出0):

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul
(if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul
exit 0

我想我解决了这个问题，当一个进程在调试选项中中断时，我删除了中断所有进程的复选标记(op的第一个截图->第二个选项)。 自从我未检查它以来，它已经运行了一段时间。 我在我的项目中使用MySql NET连接器和DevExpress控件。可能其中一个没有很好地处理连接、绑定等，因为这个标志被激活了。

编辑:绝对有效!没有更多的“无法复制文件”，没有更多的表单设计器错误。

对我来说，它是Avast反病毒，不让visual studio写入/读取/执行文件。所以我不得不将Visual studio 2010/2012文件夹添加到防病毒排除列表中。就在那之后……它的工作原理。

我在VS 2015中遇到了这个问题。我的环境的原因是使用StyleCop项目设置StyleCopAdditionalAddinPaths Include="…"来指定额外的StyleCop Addin路径。我使用的变通方法是从.csproj文件中删除这个项目设置，取而代之的是手动复制StyleCop AddIn中的StyleCop. csharp . rules .dll。不是一个优雅的解决方案，但我发现解决方案从来没有锁定dll之后，这样做。

请确保关闭所有wcfSvcHost实例，然后重试。 这对我很管用!

我能够修复这个问题(VS 2010)通过提供以下预构建操作;

if exist "$(TargetPath).locked" del "$(TargetPath).locked"

if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

I ran into this as well. It turns out that I had been testing with a service which I had built myself and which was running out the of the ..\bin\release directory of one of the projects in my solution. I had got the service running, but I forget to stop/uninstall it before returning to testing. As a result, it was holding on to one of the dlls that I reference and which needed to be moved (automatically as a dependency) from one project's bin/release subfolders to another. Stopping the service solved the problem.

关闭进程w3wp.exe (IIS)通常可以解决这个问题。通常，您可以通过导航到bin文件夹并尝试删除它来了解对该文件具有锁的进程。如果另一个进程正在使用它，将弹出的错误消息将包含需要被杀死的进程的名称。

使用Blazor和Fluent UI Web组件，我在发布时得到了以下错误:

https://learn.microsoft.com/en-us/fluent-ui/web-components/integrations/blazor

C:\Program Files\dotnet\sdk\6.0.402\Sdks\Microsoft.NET.Sdk.Razor\targets\Microsoft.NET.Sdk.Razor.StaticWebAssets.targets(615,5): Warning MSB3026: Could not copy "C:\Users\oscar.nuget\packages\microsoft.fast.components.fluentui\1.5.3\staticwebassets\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_24_regular.svg" to "C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_24_regular.svg". Beginning retry 10 in 1000ms. Could not find a part of the path 'C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_24_regular.svg'. C:\Program Files\dotnet\sdk\6.0.402\Sdks\Microsoft.NET.Sdk.Razor\targets\Microsoft.NET.Sdk.Razor.StaticWebAssets.targets(615,5): Warning MSB3026: Could not copy "C:\Users\oscar.nuget\packages\microsoft.fast.components.fluentui\1.5.3\staticwebassets\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_20_regular.svg" to "C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_20_regular.svg". Beginning retry 10 in 1000ms. Could not find a part of the path 'C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionRotate270Right\en\text_direction_rotate_270_right_20_regular.svg'. C:\Program Files\dotnet\sdk\6.0.402\Sdks\Microsoft.NET.Sdk.Razor\targets\Microsoft.NET.Sdk.Razor.StaticWebAssets.targets(615,5): Error MSB3027: Could not copy "C:\Users\oscar.nuget\packages\microsoft.fast.components.fluentui\1.5.3\staticwebassets\icons\TextDirectionHorizontalRight\ko\text_direction_horizontal_right_24_regular.svg" to "C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionHorizontalRight\ko\text_direction_horizontal_right_24_regular.svg". Exceeded retry count of 10. Failed.

看着

C:\Users\oscar\source\repos\MyVeryLongProjectName12345678\MyVeryLongProjectName12345678\Server\obj\Release\net6.0\PubTmp\Out\wwwroot\_content\Microsoft.Fast.Components.FluentUI\icons\TextDirectionHorizontalRight\ko\text_direction_horizontal_right_24_regular.svg

长度为261个字符。

然后我尝试启用长路径并重新启动我的计算机。

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

这没有工作，我得到了同样的错误。然后，我将项目移动到C:\MyVeryLongProjectName12345678\，而不是C:\ users \奥斯卡\source\ rep\ MyVeryLongProjectName12345678\。这样做之后，一切都解决了。

我注意到一些答案可以解决我的问题，但是，以防有人有和我一样的问题。

如果你正在运行一个控制台应用程序:在你做任何其他事情之前。

确保您已经关闭了从以前的版本中打开的任何控制台窗口。例如，我只是在一个控制台应用程序中测试一些代码，我没有意识到以前运行程序时的控制台窗口是打开的。在我调试的过程中，窗口被推到后面，我看不到它。只是说，这可能是你的问题，所以检查确保这不是问题。

似乎通过更改项目的程序集名称就可以解决这个问题。

所以不是这样

我把它变成这个

注意，我只是把它从Increment and Recall改成了Increment_Recall，我只是去掉了空格。它现在对我来说工作得很好。

在你的主项目taskkill /f /fi "pid gt 0" /im "YourProcess.vshost.exe"中添加预构建事件

在我的情况下(Windows 10, Visual Studio 2015):

任务管理器->用户-> EndTask=>vshost.exe

(它会立即重新启动，你可以重新构建)

最快的方法是更改Build配置类型并再次返回到以前的配置。

这发生在我使用IL支持插件时。

当您的项目中没有任何IL文件时(例如，因为您删除了最后一个文件)，构建将失败，如问题中所述。

删除对IL的支持解决了这个问题

如果您正在调试T4模板，那么这种情况经常发生。我的解决方案(在MS修复这个问题之前)将只是杀死这个进程:

任务管理器—> User—> T4VSHostProcess.exe

此过程仅在调试T4模板时出现，而不会在运行T4模板时出现。

我的10美分贡献。

我在VS 2015更新2时偶尔还会遇到这个问题。

我发现切换编译目标可以解决这个问题。

试试这个: 如果你在调试切换到释放和构建，然后回到调试。问题已经解决了。

斯特凡诺

下面是一个脚本，绝对可以摆脱这个问题:

REM   This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM   The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM   This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM   delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM   assembly file (.exe / .dll) - .pdb file and eventually .xml file (documentation) are concerned
REM   use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

REM PreBuildEvent code
REM   $(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

REM References:
REM   http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
REM   http://stackoverflow.com/a/2738456/27194
REM   http://stackoverflow.com/a/35800302/27194

脚本需要从每个VS项目预构建事件中调用。

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

重置IIS，停止使用您的DLL的服务(可能是控制台应用程序或windows服务托管应用程序或IIS)，然后尝试。

这对我很管用。

I experienced the error-messages when attempting to build the primary WinForms (XAF) project. I could only execute the application one time then needed to shutdown the VS2015 IDE and restart before a rebuild could be performed. After some digging in the project's property pages - in the "debug" property page, a check box was selected - Enable the Visual Studio Hosting Process. I unchecked and restarted the IDE, the application is now building without - "unable to copy the {project}.exe" messages.

Visual Studio托管过程的目的是什么?

异常

在某些情况下，在Visual Studio当你(Build || Rebuild)在上面 运行IISExpress时，你会遇到这个异常:

无法复制文件"obj\Debug\YourProjectName.dll"到bin\YourProjectName.dll"。进程无法访问该文件 'bin\YourProjectName.dll'，因为它正在被其他人使用 过程

解决方案

右键单击需要构建的web项目。 单击属性。 在左侧选择Build Events选项卡。 在Pre-build events命令行中粘贴这两行:

tasklist /fi “imagename eq iisexpress.exe” |find “：” > NUL 如果错误级别 1 任务杀死 /f /im “iisexpress.exe”

你很好!

在Visual Studio 2010中，我也会定期遇到这个问题。关闭Visual Studio，删除bin和obj目录，并重新启动将修复一个构建。然后问题又回来了。我已经尝试了这个帖子上的所有其他答案，但没有一个对我有效。对我来说，唯一能永久解决这个问题的方法就是打开项目设置，关闭“启用Visual Studio托管进程”，构建，再打开，然后再次构建。

引用:

一个解决方法是把它放在>项目的预构建事件命令行属性中(在构建事件选项卡中):

代码片段

if exist "$(TargetPath).locked" del "$(TargetPath).locked"

if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

打开项目属性[菜单>项目>属性] 选择“调试”选项卡 取消勾选“启用visual studio托管进程” 启动调试[F5] 你会收到安全警告，只是“ok”。让应用程序运行 停止调试。 检查选项“启用visual studio托管进程”，在调试选项卡下， 现在，尝试开始调试，您将不会再次看到错误

[为我工作]

在我的案例中，Visual Studio 2105远程调试器是问题所在。当我在任务管理器中杀死这个任务时，我能够成功地在Visual Studio中重建我的应用程序。

我也遇到过同样的问题，我尝试了这里提到的很多不同的方法，但没有一个对我有效，唯一对我有效的解决方案是:

从解决方案的DEBUG文件夹中删除READ ONLY属性 将此添加到构建事件:如果存在“$(TargetPath)”。$(TargetPath).locked" $(TargetPath)。锁定" if exists "$(TargetPath)" move "$(TargetPath)"“$(定位路径).locked”

用款。我通过编辑MSBuild.Community.Tasks.Targets文件并更改bin路径解决了这个问题:

<MSBuildDnnBinPath Condition="'$(MSBuildDnnBinPath)' == ''">$(MSBuildProjectDirectory)\bin</MSBuildDnnBinPath>

我发疯了，试图找到为什么系统进程在我正在工作的EXE上保持一个打开的句柄，在它被终止后的另一分钟，我得到了与OP相同的错误。

原因是之前的开发人员在使用(){}时没有包装IDisposable对象。一旦IDisposable对象正确地销毁自己，错误不再发生，我能够立即重建。

将此添加到预构建:

(if exist "$(TargetDir)*old.exe" del "$(TargetDir)*old.exe") & (if exist "$(TargetDir)*.exe" ren "$(TargetDir)*.exe" *.old.exe)

我意识到这只是为这个问题增加了一个已经非常多的答案，但我认为值得一提的是，尽管不完美，但@Stefano， @MichaelRibbons和@IvanFerrerVilla给出的答案的组合已经提供了一些不错的成功，因为他们各自都不太成功。

花了几个小时试图解决这个问题，然后发现我正在处理一个服务-记住停止任何服务作为解决方案的一部分!

在我的例子中，VS不能复制的文件是. task项目的文件，所以问题是我有一些本地运行的计划任务。一旦我停止并禁用它们，复制问题就消失了。

遵循以下步骤

打开任务管理器(Ctrl + Alt + Delete) 在Performance选项卡下选择<ProjectNameOfYours.exe>。 单击End Process。 现在构建解决方案。

以上步骤永久地解决了错误。

我找到了一个完整的解决方案!

大多数答案告诉你杀死进程，然而与进程黑客，我找不到任何。

我找到了一个相对简单的解决方案。

在窗体设计器中选择您的主窗体。 单击属性菜单上的事件选项卡。 双击事件FormClosing。这将自动生成事件系统和函数:

private void[你的表单名]_FormClosing(对象发送器，FormClosingEventArgs e)

在这个函数中，添加Application。退出

像这样:

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
    Application.Exit();
}

有用的图像

我希望这能有所帮助!这道题真糟糕!

修复2

打开一项名为“应用体验”的服务。

如果没有一个答案是正确的，试试这个简单的检查。 找到任何MSbuild.exe运行和持有您的项目EXE。杀死MSBuild.exe，你应该很好。

对我来说，这是一个许可问题。我必须以管理员的身份运行Visual Studio。

有时它不能清除DEBUG文件夹。我所做和工作的是重命名不能删除的文件。因此，删除所有不能删除的文件夹和文件，重命名为，例如，“_old”。

我正在研究一个微服务项目解决方案，我需要同时运行两个项目，冲突发生在lunchsettings.json applicationurl: {portNo}部分用于两个正在运行的项目是相同的端口

lunchsettings。第一个项目的Json

...
"Project#1": {
  ...
  "applicationUrl": "http://localhost:5001",
  ...
}

lunchsettings。第二个项目的Json

...
"Project#2": {
  ...
  "applicationUrl": "http://localhost:5001",
  ...
}

来修复它

lunchsettings。第一个项目的Json

...
"Project#1": {
  ...
  "applicationUrl": "http://localhost:5001",
  ...
}

lunchsettings。Json for secondproject

...
"Project#2": {
  ...
  "applicationUrl": "http://localhost:5002",
  ...
}

我以管理员的身份运行Visual Studio，设法解决了这个问题。

@Gerard的答案是正确的。

当clean+build不能为我解决这个问题时，我通过以下方法取得了成功:

Closing Visual Studio
Deleting the bin and obj folders, and
Reopening Visual Studio.

但我需要在主机上做一些额外的工作:

> Add-Migration Initial
> Update-Database

然后我开始调试，它起作用了。

我已经添加了不同次相同的问题，从这个治疗没有一个答案可以帮助，或者如果他们这样做了，使用一个讨厌的工作。 我认为这个问题总是有一个很好的原因发生(不是微软的bug!)-好吧，不过VS在标记方面可以做得更好:-))。

主要原因可能只是你的项目依赖关系搞砸了! 作为一个简单的例子():

在同一个解决方案中有多个项目 你清理+构建所有，并假设一切都很顺利，因为你没有看到错误 您开始运行其中一个项目—到目前为止一切正常! 然后开始运行第二个项目，但这个项目也有前一个项目使用的依赖项，并尝试重新构建它们 然后挂一段时间 它无法在第一个项目已经运行时进行构建，并且不允许您覆盖正在进行的流程

现在，您可以想到所有可能触发此类错误的场景:

Error Could not copy "obj\Debug\ProjectX.exe" to "..\bin\Debug\ProjectX.exe". Exceeded retry count of 10. Failed. The file is locked by: "ProjectX (17132)" ProjectX

修复这个问题通常是一个乏味的过程，因为您必须完全理解系统中的所有依赖项

必须在关闭后终止进程。 我用;

Process.GetCurrentProcess().Kill();

将此代码添加到您用于关闭的关闭事件或方法。

如果你使用Visual Studio Code (vsCode)遇到这个问题，或者你坚持使用终端命令，clean命令将删除构建文件，并通常修复描述的问题:

dotnet clean

然后，您可以返回运行:

dotnet build

or

dotnet run

您可以通过脚本终止应用程序。

如果你的应用程序名为myapp.exe，在终端中运行下一个脚本:

taskkill /IM myapp.exe /F

参数为:

/IM   application name (imagename)

 /F                     Specifies to forcefully terminate the process(es).

在我的例子中，我在发布到它无法访问的文件夹时遇到了麻烦。您可以通过尝试发布到您的c驱动器中的一个文件夹来排除这种情况，您应该不会有访问问题。

使用Ms进程资源管理器查看是否需要在Windows 7中打开“应用程序体验”

在我的情况下，所有其他建议都不起作用(Windows 7, VS2019)

编译后，生成的. exe文件被重新锁定约一分钟。另一个奇怪的观察:当删除。exe文件时，它像往常一样消失在文件资源管理器中，但在刷新时(F5)重新出现。

您可以使用MS进程资源管理器来查找是否有任何进程持有生成的. exe文件的句柄。为此，查看进程资源管理器的“下窗格”，选择查看句柄而不是dll，并使用“查找”来搜索您的. exe文件。

这告诉我，这是Windows 7的“系统”进程，得到了一个句柄。exe。

一些研究显示，我必须打开Windows的“应用程序体验”服务(“自动启动”)才能永久摆脱这种奇怪的行为。

以下是更多信息: 在什么情况下，系统进程(PID 4)保留一个打开的文件句柄?

此问题通常在运行测试时发生。如果这是你的情况，只需转到任务管理器并杀死testHost

按Cntrl+alt+Delete，然后进入资源监视器，在CPU选项卡下选择您的exe名称，右键单击并杀死该进程。

第一个消息错误解决方案:

在我的例子中，问题在于路径长度。

解决方案是减少/更改问题文件路径。如果问题出在项目中的文件上，你应该减少/更改存储库路径。

C:\Users\userTest\folder1\folder2\folder3\...\folderX\myProject\...\file.exe

如。

C:\Users\userTest\folder1\myProject\...\file.exe

换句话说，默认情况下路径长度不能超过260个字符。

原线程答案 (https://stackoverflow.com/a/73686473/12678101)