We Keep Coding

"Error while trying to run project: Unable to start program". Can run program only once. Then VS needs restart

I'm running my .NET 4.0 (C#) project in debug mode after I start VS2013. It runs just fine.
The second time I start it from VS, I get the Dialog box that says "Error while trying to run project: Unable to start program C:\path\to\file.exe"
The process is still alive in the Taskmanager when I dismiss the dialog box.
From Windows Explorer, I can run the program just fine. And after closing it, the process is gone too from the Task Manager.
A rebuild doesn't help.
Is this a common problem with a known solution?

I had an issue similar to this and I had to clear the component cache instruction can be found Here.
Hope this helps.

For my case, it cause by Platform target, you could force choose it to x86 or x64 which your project is:
Each Project's Properties > Build > Platform target

As I pointed out also here, the only solution that worked for me was to disable the ConEmu integration:
ConEmu → Settings → Integration → Default term → disable Force ConEmu as default terminal for console applications
Some users reported that it was enough for them to disable the Aggressive mode in that same settings tab; that wasn't the case for me though.

The topic is old, but this might help someone else.
So in my case I made a file in Visual Studio with .cp extension (accidentally deleted the last 'p') this made visual studio just "include" the the file and not mark it as a compilation unit, thus not compiling it, I looked the *.vcxproj file in a text editor and found out about this, so if you open the project file in a notepad or something just find your file at the bottom usually and change from <Item .../> to <ClCompile .../>

I was getting similar errors. I just had to restart visual studio. Sometime couple times a day.

I had a similar error and resolved it by cleaning the solution. Right-click the solution name in Solution Explorer and choose Clean Solution.

I found a solution here:
Please check "Use Managed Compatibility Mode" under Tools|->Options->Debugging->General.

I'm Brazilian, I don't speak English very well. I did this translation on google translator.
I know the topic is old, but it can still help someone.
I had this same problem in the following situation, I have a dual boot computer (linux debian 11 and windows 10). Inside debian, on my NTFS D disk, I created a folder to perform programming tests. After accessing that same folder with windows, I created a new project in visual studio inside that same folder that I had created in linux. The creation of the project went without problems, however when I tried to run the project (F5), I received the same error from this topic. I tried all the solutions I found on the internet, and nothing worked. I gave all permissions to my admin user and it still didn't work. Then I realized that even going straight to the folder where the application's executable was and clicking directly on it, I still received the access denied error message. So, I took the project out of the folder I had created in linux, and it worked. So, what I could conclude, is that because the folder where my project was was created in linux, for some reason, my windows didn't trust this folder, so it didn't allow running executables from inside that folder, even this one executable having been created by visual studio from within windows.

Just simply create a folder name as "projects" in c drive and copy paste the newly created project in it. Run the project by doing clean & Build or Rebuild method . It will work

open the folder which contains the solution in visual studio.
again, open your *.sln file by double clicking it inside the solution explore once opened try running the solution or rebuild the solution. once rebuild gets completed, it will open without error from next time.

My way of solving the error : error while trying to load project : Unable to start program and c:\Path\to\file.exe was simply by
First restart Visual Studio
Click the build icon
Select the rebuild option
Run the Program or Debug the Program

This was a weird one. Going to put what happened to me here because it might happen to someone else. Everything was fine with the app until suddenly after some fairly insignificant code changes I suddenly started getting this error. Visual Studio was compiling the executable just fine. But, the moment I tried to run it (either from Visual Studio or directly) the executable file would be automatically deleted right out of the Debug folder. Super odd--never seen anything like it. I began to get suspicious that perhaps an anti-virus or the OS was somehow identifying a checksum or some signature in the executable as "dangerous". Or perhaps some obscure compilation bug was corrupting the executable. So on a hunch I made another innocuous change (added a couple of lines of code to color code some text in a rich text box) and the problem went away.

VS Crashing after 'Set As StartUp Project'

I have a solution in VS 2012,
I try to change the startup project to specific project but the vs crashing immediately (with the other projects - no problem)
with the familiar message "Visual Studion Stop Working.."
I try also to define the startup project manualy in the .suo file
(See details in Why is "Set as Startup" option stored in the suo file and not the sln file?)
But when i reopen the VS, it crashes during the assemblies loading.
Any idea what can be the cause?
Edit:
Additional Details:
Its solution contains also WCF project, run in front of local IIS, This project run perfectly, with the same code, in other team computers.
As result of the facts, It seems an environment problem, IIS setting, Permissions and etc.
Note that i already reset VS setting, and also repair the installation and the problem not resolved.
Maybe someone knows what the logical action of 'Set as startup project', what the VS perform during the action except for the start point definition? i think that the root of the problem hides there...

I had this problem too, but on VS 2015. You should logoff from your MS account from VS, set your project as startup and then login back if you want ...

It is hard to guess what the problem could be, but because it works on other team members' machine, it might have something to do with your Visual Studio state.
Try clearing or moving out all files from:
C:\Users\<Username>\AppData\Local\Microsoft\VisualStudio (if starting as admin)
C:\Users\<Username>\AppData\Roaming\Microsoft\VisualStudio (if not starting as admin)
You might need to restart your machine if the files are in use before you can delete/move them. These folders contain some VS settings, cached files and logs.

In addition to what AVS said, you can try deleting your Visual Studio .suo file.

The Web Application Project [...] is configured to use IIS. The Web server [...] could not be found.

I have a web project in my solution file that is "unavailable" when I open the solution. When I right-click on the web project and reload the project, I get the following error:
The Web Application Project mycompany.myapp.mywebproject is configured to use IIS. The Web Server 'http://localhost/MyWebApp could not be found.
I have not manually set up virtual directories for this web application.
Per colleagues, Visual Studio should prompt me to create virtual directories but I am not getting prompted.
I installed VS2010 before installing IIS on my dev machine.
Here is my development machine setup:
Windows 7 Enterprise
Service Pack 1
64 bit OS
Visual Studio 2010 Enterprise Service pack 1
IIS version 7.5

Since the accepted answer requires IIS Manager, and IIS Express doesn't have IIS Manager or any UI, here's the solution for you IIS Express users (and should work for everyone else too):
When you open Visual Studio and get the error message, right-click the project Solution Explorer and choose "Edit {ProjectName}.csproj"
In the project file, change the following line:
<UseIIS>True</UseIIS>
to
<UseIIS>False</UseIIS>
Save the file.
Now reload your project.
Done.
You'll then be able to open your project. If at this point, you want to use IIS, simply go to your project properties, click the "Web" tab, and select the option to use IIS. There's the button there to "Create Virtual Directory". It may tell you that you need to run Visual Studio as an administrator to create that directory, so do that if needed.

Open the project folder and delete {Project}.csproj.user, then reload the project on Visual Studio.

When this happens the easiest solution is to make the virtual directory manually.
First of all, you need to make sure you have the right version of ASP.Net installed and that you have installed the IIS extensions.
To do this, go to the relevant .net version's folder in C:\(Windows)\Microsoft.NET\Framework\(dotnetver)\
(substituting the bracketed folders for the right folders on your PC) and run this command
aspnet_regiis.exe -i
Next once that's run and finished, sometimes running
iisreset
from the command line helps, sometimes you don't need to.
Next, go to your IIS Manager and find you localhost website and choose add a folder.
Browse to the folder in your project that contains the actual ASP.Net project and add that.
Finally, right click on the folder you added and you should have an option that says 'convert to application' or 'create virtual directory' or something similar.
!!Make sure the Virtual directory has the name 'MyWebApp'!!
Reload your solution and it should work.
Please be wary; this isn't a programming question (and shouldn't really be posted here) but I've posted this guidance as it's a common problem, but the advice I've posted is generic; the commands I've listed are correct but the steps you need to do in IIS may vary, it depends on your version and your account privileges.
Good luck!

This solution worked for me: Right click the Project and select edit and find the following code as shown below in the picture.
change the <UseIIS>True</UseIIS> to <UseIIS>False</UseIIS>
OR
change the <IISUrl>http://example.com/</IISUrl> to <IISUrl>http://localhost/</IISUrl>

For my project, I had to delete these two lines from .csproj file
<ProjectGuid>{3AA499DF-4A65-43B7-8965-D08A4C811834}</ProjectGuid>
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
I tried deleting only the first one, but it wasn't enough.
EDIT: As many users have pointed out, this can change your project type or mess with your source control program. I can't investigate these issues as it was a school project I do not have anymore.
Please be careful when trying this. At least make a copy of what you delete.

Edit the .csproj or vbproj file. Find and replace these entries
<UseIIS>true</UseIIS> by <UseIIS>false</UseIIS>
<UseIISExpress>true</UseIISExpress> by <UseIISExpress>false</UseIISExpress>

In my case, this problem was caused by broken IIS bindings. Specifically, my 'http' binding had been deleted. Recreating it fixed the problem.

Cause: The IISURL inside project.csproj is not correctly reflected in the project setting, and the virtual directory was not created.
Solution: Change the Project URL to correct PORT and create the Virtual Directory to make the missing PORT available.
Follow Below Steps:
Step 1: Right click on the project file to Edit the project.csproj file.
Step 2: Search IIS and modify from <UseIIS>True</UseIIS> to <UseIIS>False</UseIIS>
Step 3: Right Click Project to Reload the Project. After Reload successfully, right click Project and select Properties.
Step 4: Locate Project URL option under Properties => Web
Step 5: Change the Project URL to IIS URL indicated both on the Error Message and on the <IISURL>http://localhost:8086 </IISURL> from project.csproj file. Then Click Create Virtual Directory. Save All
Step 6: Redo Step 2 so it doesn't impact the remote codebase and the server deployment settings.

This worked for me:-
Make all your IIS websites point to localhost(All Unassigned) only

Try opening Visual Studio with Administrator privileges. In my case, it gave access to the IIS site and made this error go away. I was then able to switch the project to use IIS Express which doesn't seem to need administrator privileges.

If you are connected via TFS, open your project.csproj.user file and check for
<UseIISExpress>false</UseIISExpress>
and change it to true.
<UseIISExpress>true</UseIISExpress>

You will not believe that, start visual studio as Administrator
as obvious from the message
The Web Server 'http://localhost/MyWebApp' could not be found.
could not be found because may it has no privileges to see it
so Just restart visual studio as Administrator

You can load the project without setting the value of attribute UseIIS to true.
Simply follow the below steps:
In the mywebproject.csproj file--
Delete the tag < IISUrl>http://localhost/MyWebApp/< /IISUrl> and save the file.
The application will automatically assign the default port to it.

In my case I wanted to switch from http to https, so I had deleted http from IIS. In my .csproj.user file found that I still had:
<IISUrl>http://localhost/</IISUrl>
So I changed it to:
<IISUrl>https://localhost/</IISUrl>

In my case I was able to open the solution in offline mode just running the command:
iisreset

For you Win8 users out there, if you follow the steps in the accepted answer, console spits out a message at you saying "thou shalt not use the command-line to execute this command" (paraphrasing). Instead, access the Programs & Features via Control Panel (or Windows + R > appwiz.cpl), click 'Turn Windows features on or off', and make sure you have the following installed:
Internet Information Services
> World Wide Web Services
> Application Development Features
> ASP.NET 4.5
This will check a bunch of other options as well. As soon as I installed these features, and ran VS2012 with elevated permissions, I was able to launch my app successfully.

This happens with me when I tried to open a project from the .csproj file, but I get over it by opening the project from VS:
File> Open> Web Site
and select the directory which include my project.

I had this error, too. I thought everything was setup correctly, but I found out that one thing was missing: The host name I used for my project was not (yet) resolvable.
Since my app determines the current client's name from the host name I used a host name like clientname.mysuperapp.local for development. When I added the development host name to my hosts file, the project was loadable again. Obviously, I had to this anyway, but I haven't thought that VS checks the host name before loading the project.

Check if IIS Express is installed. If IIS Express is missing, Visual Studio might discard the setting <UseIISExpress>false</UseIISExpress> and still look for the express.

in my case, make sure you have a "Default" website

In my case, the "Default Web Site" in IIS didn't have a binding for localhost on port 80.
You should have a binding for whatever your value in the .csproj file is.

I fixed this simply by reinstalling IIS Express after downloading from below link:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=48264

Turns out my IIS was working on localhost:8181.Had to configure the {Project}.csproj file.
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">
<WebProjectProperties>
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>7386</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>**http://localhost:8181/ProjectName**</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>
<CustomServerUrl>
</CustomServerUrl>
<SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile><EnableWcfTestClientForSVCDefaultValue>True</EnableWcfTestClientForSVCDefaultValue>
</WebProjectProperties>
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>

In my case, the url referenced in the csproj file was incorrect.
It needed to be prefixed with www.
I made the changes, saved the file and the project loaded fine.

I ran into this issue when the <ProjectTypeGuids> element in the .csproj file contained the unit test project GUID: {3AC096D0-A1C2-E12C-1390-A8335801FDAB}.
Removing it made the project load without problems.

For DNN users my issue was I needed a binding for dnndev.me at port 80. I have multiple installs that run on different ports and VS requires that that particular Url to exist on port 80 (not 86 like mine was).

Follow this completed solution step by step. it's works for me in VS 2017.
Open Command prompt in administrator mode
Open File explorer and got to .NET Framework folder
Eg:C:\Windows\Microsoft.NET\Framework\v4.0.30319
v4.0.30319 this is my .NET folder. you want to select your relevant folder.
in CMD - Go to .NET folder path
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
Execute below command in CMD
aspnet_regiis.exe -i
You can see this message finally - Finished installing ASP.NET (4.0.30319.0)
iisreset
You can see this message finally - Internet services successfully restarted
Open IIS in your computer (if not config Follow this)
Go to Site and right click
Add WebSite
Fill - Site name and select physical path
Then type port number (you can find port number in .csproj file and port number must equal with (IISUrl)
EG : <IISUrl>http://localhost:15724/</IISUrl> my port is 15724
Note : you cannot create port 80 number. because it used default IIS page
Click Ok
Open visual studio with administrator permission
Then right click and reload your project
Your Problem may be solved.

This may help some people in 2020. The main issue is that the IIS settings in the CSPROJ file don't match with the configuration for the machine. For example, if you had the Web Application Project pointing to localhost:12345, and a virtual directory isn't set up on the machine on that port, you'll get this error.
Using VS2019, I had this same issue, and the IIS settings in the CSProj file were being ignored. The reason for this is a new property in the CSProj file called "SaveServerSettingsInUserFile":
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">
<WebProjectProperties>
<SaveServerSettingsInUserFile>True</SaveServerSettingsInUserFile>
</WebProjectProperties>
</FlavorProperties>
<UserProperties UseAjaxifiedTemplates="True" UseJQuerySupport="True" />
</VisualStudio>
</ProjectExtensions>
When this is set to TRUE, the IIS/Web server properties are in the
.CSPROJ.User file of the same project name.
This allows individual users of a project to have their own IIS settings, provided this file is not checked into source control.
You can control where the settings are stored using Visual Studio GUI in the properties for the project under "Web", "Apply server settings to all users"
When this is on, the IIS settings are stored in CSPROJ, when off, they are stored in CSPROJ.User

Build error: "The process cannot access the file because it is being used by another process"

I've got a C# webforms app, that until today had been working just swimmingly.
Now today, all of a sudden, every time I try run the app, I get a file locking error:
Unable to copy file "obj\Debug\MyProject.exe" to "bin\Debug\MyProject.exe". The process cannot access the file "bin\Debug\MyProject.exe" because it is being used by another process.
Googling the error doesn't come up with anything beyond the obvious, i.e. VS thinks the file is locked. And it is definitely Visual Studio itself that locks the file, because when I close VS and reopen it, the project executes fine - the first time. When I try to run it a second time, I get the file locking error.
Closing VS and reopening every time I want to run the app is not a viable workaround! How do I find out what's locking the file, and stop it from getting locked?
EDIT: Another interesting discovery: I don't even have to run the app. Just compiling it once causes the file locking; I cannot compile twice in a row!
This problem is specific to one project in my solution. All other projects work fine and can be executed as many times as I like. It's only this one project that gets itself locked up.

I have found a simple solution which works for me. It goes like this:
When the problem occurs, just change the building configuration at the top (if in “Release” to “Debug” and vice versa), build and then change back to previous configuration and build again.
I suppose that changing the configuration releases the vcshost and devenv.

Well, I solved the problem myself - though I still have no clue why. I decided to isolate the problem by removing all files from the project, then re-adding them and determining that way which file was the source of my trouble. So, one by one I reintroduced files to the project, compiled & cleaned each step of the way... until... I added the last one...
... and everything still worked fine.
I did a compare to the source control of my original .csproj; no real differences. And even when I tried reverting to the previous version of the .csproj, it still worked.
Black magic. If it works, sometimes it's better not to ask why - just accept it and move on...
EDIT: The problem is a recurring one, and I believe I've isolated it to when I have the form designer open of an abstract/generic form at compile time.
Lesson learned: Make sure the Form Designer of any abstract or generic forms or controls is closed before you compile! If not, you have to close VS and reopen!

What we have discovered here, is the following:
In the project properties page, Debug tab, uncheck the "Enable visual studio hosting process".
I am unsure what this property is for, but it does the work once unchecked.

Solved by closing all instances of MSBuild.exe in the windows task manager

Actually you should want "Enable the Visual Studio hosting process" checked. At least for VS2010 anyway. And I also have:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
in the pre-build options. This problem has dogged me for a very long time and it wasn't until John W. mentioned this check box that I even took notice that it existed and low and behold it was already unchecked.
Also notice that -app-vshost.exe runs in the background even when not debugging. Which is what makes it successfully build and run every time I guess. It wasn't running before. And I also tried cleaning out the debug and release folders and changing the target type constantly and nothing worked except as described above. My solution before was to just wait 5 minutes between builds, which got super annoying and time-consuming to get anything done. I haven't seen any change in behavior where it mattered what tabs where open or XNA vs windows form or designers being opened. This issue occurred in 32-bit or 64-bit builds and didn't matter if I killed an app with ALT-F4 or killing it with task manager, which would, in theory, not allow the app to close or release resources. At first I thought it was a garbage collection issue.

I have overcome this problem by renaming the locked file (using Windows Explorer). I was not allowed to delete the file, but renaming the locked file works!

Little late to answer, but I solved this by going to the properties of the project > tab "Debug" > unchecked "Enable the Visual Studio hosting process" option.

I solved this by deleting the folder bin\Debug and, possibly, restarting VS

Run this command from the Run box:
net stop iisadmin /y
and then
iisreset
worked for me.
vs 2003

For me, it was a Windows Service that was installed and running. Once I stopped it, the build was successful.

I had a similar error but during the deployment of the UWP application. Finally, I found out the process that used a file that caused this error and stopped it. Credits to this link. Copy-pasted version is below.
How to Solve the Issue?
One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.
Identify what program is using a file
Using Process Explorer there is a simple way to find the program:
Open Process Explorer (running as administrator).
On the toolbar, find the gunsight icon on the right.
Drag the icon and drop it on the open file or folder that is locked.
The executable that is using the file will be highlighted in the Process Explorer main display list.
Identify which handle or DLL is using a file
Open Process Explorer (running as administrator).
Enter the keyboard shortcut Ctrl+F.
Alternatively, click the “Find” menu and select “Find a Handle or DLL”.
A search dialog box will open.
Type in the name of the locked file or other file of interest.
Partial names are usually sufficient.
Click the button “Search”.
A list will be generated.
There may be a number of entries.
And then kill this process.

Unfortunately none of the answers worked for me. This is what solved it:
Win Key + R and run resmon.exe. There you'll find the EXE process that VS claims to be using the file. Right click and end the process. Although you might get an Access Denied error message, it will be suspended and you'll be able to build again.

Recently ran into this problem when attempting to build a solution I am working on (not just a winforms proj).
In addition to build failure, I noticed that cleaning projects would quietly fail (checking the bin folder showed that the files had not actually been erased) and closing the Visual Studio did not end the devenv process - rather, it caused it to crash. Windows recovery process would then restart the Visual Studio.
After some trial and error, I found the problems only happened to me when I opened the solution from the "Recent" menu on starting up VS.
Opening the solution from File >> Open >> Project/Solution found it working as per usually.
Currently no idea why - will keep looking into this but for now, at least I can work!

Just check the references and remove the self-reference to the project.
Explanation: My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
I literally removed the whole source code regarding the custom control and the problem still remained, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!

I had the same issue on my Xamarin application in visual studio and it was resolved by unplugging my test mobile device. The application was closed and the debugger was stopped but the error was still happening when trying to build or rebuild the solution. It only stopped after i unplugged the device because i had to receive a call.

Just to throw in my 2 cents. My issue was solved by opening Task Manager and killing the application. It was running in the background without any indication that it was running at all (no item in the task bar, no ui, nothing), but I am not sure why this happened. Obviously the debugger was not running and I only had a single instance of VS opened at the time. It amazes me that this is still happening in this VS 2017.
Perhaps I can add a build step that looks for the application running the background and kills it before starting the new one.

I had the same issue and could not rectify by using any of the methods mentioned in previous answers. I resolved the issue by killing all instances of "SSIS Debug Hist (32 bit)" in task manager and now working as normal.

I had this issue (and its an issue I have seen in other places not just VS).
It's caused by Dropbox (in my case). After editing some code and hitting run, sometimes dropbox immediately locks the file (so it can process it).
Solution 1.
Just hit run again
Solution 2.
Pause dropbox. (not good if your using dropbox as your cloud backup)
Solution 3.
Remove the build folder from dropboxes sync list.

Deleting Obj, retail and debug folder of the .NET project and re-building again worked for me.

This got me stuck for over two days, had to reclone the project and save the project folder in a different name, but today I found the solution from a microsoft dev forum.
solution:
Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This code will copy the file to a different name, and allows the build to continue successfully.

How is your web app configured? Does it run under Cassini (the tray web server) or IIS?
This shouldn't happen normally though. I think ProcessExplorer can tell you what files a process has locked. If not process explorer one of the other sysinternals tools.
One thing to try before even downloading one of the SI tools is to stop the Cassini web server, and seeing if that frees up the file.

What worked for me was restarting IIS

i had this same problem as well. changing the debug/release config didn't do the trick. at least not without building in between.
in my solution (winform) it was solved by opening the mainform of the winform in the designer. switching to code (F7). Then closing the code, closing the designer of the winform and rebuild all (ctrl-shift-B). This worked for me.
seems like some kind of handle from within the winform app (which runs a backgroundworker) still had a file handle on some of the other libraries used.

I had two instances of Visual Studio opened the same solution.

In my case there were some vstest processes running (with various names but all containing the string vstest). I had to terminate them in taskmgr.

Same error, solved by updating Google Nuget support packages

When I ended the process .Net Core Host, everything built fine. I didn't have to close Visual Studio or do change anything else.

For those who are developing in VS with Docker, restart the docker for windows service and the problem will be solved immediately.
Before restarting docker I tried all the mentioned answers, didn't find a msbuild.exe process running, also tried restarting VS without avail, only restarting docker worked.

One more solution: when the files get locked, blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)") with it's id in parentheses.
To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".

I recently ran into the issue when deploying to Service Fabric. The error is implying a 'file' is in use, however, I found that the port was being used by another IDE. By stopping a running service which was already hosting on the port, I was able to stop this exception from occurring.

Visual Studio 'Publish' command fails

I'm working on a moderately sized WebForms project. Due to the peculiarities of management here, I have to upload the site to a remote server in order to test (no localhost testing). I'm using the 'Publish' command in Visual Studio 2008. Sometimes, it even works. Most of the time, I inexplicably get a "publish failed" in the bottom left corner, with no further details.
The few googled articles/forum posts I read suggested making the target local folder for the publish operation readable/writable for everyone. Doesn't help.
Is there are way to get further details as to WHY a publish fails in VS2008, and if not, is there a better way of doing these deployments? I'm spending more time building/pushing to the web server than actually debugging.

It's worth checking the output window. I've just had a publish fail because I had deleted an image outside of VS so VS was complaining that the image couldn't be found, but this information was only displayed in the output window.
See this link for more information:
http://ericfickes.com/2009/08/find-out-why-visual-studios-publish-fails/

It happens to us when there is an error in markup (!). Bad thing is that VS will just swallow the error and just tell you Failed.
What I suggest is to run your publish from command line using MSBuild. It's not that straightforward but it works (once you get into it).

I've since discovered that the reason for these particular publish failures was due the "Delete Existing Files" option being checked. Using Visual Studio 2008 under a non-administrative account on Windows Vista could cause a permissions error while attempting to delete the existing files. The publish would fail silently after encountering a file that Visual Studio had insufficient access to delete. Once the files were deleted manually outside of Vidual Studio, the publish functioned normally.
I have not had this issue with Windows 7; I assume the UAC changes in Windows 7 fixed the problem.

I mostly work with Web Forms, and I encounter this problem daily.
It seems to me that publish fails when it fails to delete a file it is trying to replace. Even if I don't have any files open, it still fails sometimes. Not sure why.
Not only VS publish fails very often, it is painfully slow as well.
I just publish to empty local directory and use separate FTP client to upload files. It's more work, but works.

This is probably not the case for you, but I've seen this happen when I'm publishing a web site. If the app_offline.htm file is not excluded from your project (if you use this file), the publish will fail.

Same happened to me.. what I did was include images files that was not included in the project and delete images that were not used.

After struggling with a similar issue for about 30 mins with no clue as to what was causing it closed down VS and reopened my project. Started working fine. No idea why but it worked.

You should always stop the IIS instance running on the machine your are publishing to. Google the word "iisreset". Other hosting providers like DiscountAsp and Arvixe offer you tools to "Stop" and "Start" your app pool on their IIS remotely. This is very necessary because IIS may have locked some files as "in use", so your publish fails when it tries to write over them. When your publish is complete, then just restart IIS (or press "Start" from a web tool if you're using a 3rd party hosting provider).
When all else fails, check your "Output" window (the tab to the right of your "Error List" at the bottom of Visual Studio). Scroll through all of it after a failed publish and look for anything that says "Unable to add". If you keep seeing the same "Unable to add" errors on the same publish, then ftp into the folder, delete the the problematic files manually, and try publishing again.

I got this when my ProjectName.Publish.xml file was read-only. Once I checked the file out of source control, I no longer got the error and could publish.

Just to add to this thread, I found that, for some bizarre reason, only the Mercurial files were being published to the server, everything else just wasn't being copied across.
Another strange thing was that only the Debug configuration was available; Release was nowhere to be seen.
After reading other threads around S.O., I found that there were many for VS 2010 and 2012, but not much to cover the same problem with 2008.
The fix, I found, was to delete the [solution].suo file and then attempt a publish. That seemed to do the job, though it took a long time to complete.

What I found and work in my case. It is to use a different version of VS.
I recently had the problem, the solution works perfectly in VS2015 build, compile and tested.
However, when I try to publish was failing silently.
So, I closed the solution and open it with VS2017 that use the same file structure for the projects/solutions. Then rebuild it and publish without any problems.
I believe it could be VS related and it is complicated to debug.
This is a workaround if you work with multiple Vs instances in your local machine.