I am using Azure DevOps Server 2019 (ADOS for short, installed on-premises) to run end to end tests based on Selenium in C#.
Every now and then a build ends badly without properly stopping the chromedriver.exe process used by my Selenium tests. As a result, the subsequent build fails at the Initialize Job step with an error that looks like this:
One or more errors occurred. (Access to path 'C:...\chromedriver.exe' is denied.)
What I understand from this is that because chromedriver.exe is still running ADOS cannot delete its .exe file when it tries to clean the working folder at the start of the build run.
I've tried disabling the Clean feature of the Get sources step definition but that only shifted the error a bit forward to the Checkout step.
To resolve the problem I am forced to manually RDP into my agent machine, taskkill /IM chromedriver.exe /F and re-run the failed build.
My question is - How can I prevent the access denied error? I've thought of these approaches but I'm not sure which is practical:
Get ADOS to run taskkill automatically before the Get sources step. How?
Make the agent have higher privileges so it can delete chromedriver.exe even when its process is still running. Again, how?
If your assumption is correct:
What I understand from this is that because chromedriver.exe is still running ADOS cannot delete its .exe file when it tries to clean the working folder at the start of the build run.
Make sure you are using the driver.close() as well as the driver.quit() methods at the end of every test.
Use teardown to make sure it will always happen.
EDIT:
As OP commented:
when I cancel the ADOS build, the test step is terminated abruptly and the teardown step is not executed.
My recommendation is to an atexit method.
For C# Use ProcessExit Event (credit to #Fredrik Mörk's answer)
For Python use atexit
I've come up with a solution based on ADOS Pipelines' functionality. After my Visual Studio Test task I've added a Command Line task and configured it like so:
The script is 'taskkill/IM chromedriver.exe /F'.
Under Control Options I've set:
Run this task to 'Custom conditions'
Custom condition to 'canceled()'
Continue on error checked.
This way, whenever my build is cancelled manually, all instances of the chromedriver.exe process are terminated, clearing the way for subsequent builds to run.
c#
namespace MyTestProject
{
[TestClass]
public class MyTesterClass
{
[TestMethod]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("$(SolutionDir)\\MyWebProject", "/MyWebProject")]
[UrlToTest("http://localhost:29633/")] // FIXUP for your port
public void MyTestMethod()
{
Console.Out.WriteLine("BEFORE");
Assert.IsTrue(System.Diagnostics.Debugger.IsAttached); // always fails
System.Diagnostics.Debugger.Break();
Console.Out.WriteLine("AFTER");
}
}
`
IDE: VS2015 update 1 (on Win10), no extra 3rd party addons installed
Target: .net 4.5
Using IISExpress to test as a non-Administrator user (which is 32bit even on 64bit system for me)
Have 2 binds setup in IISExpress the "localhost:29633" and one to IP "192.168.0.2:29633" to allow across network testing and usage. This is all working just fine. This is setup in .vs\config\applicationhost.config with 2 entires bindingInformation=":29633:*" and bindingInformation=":29633:192.168.0.2"
I can get my unit tests to pass successfully, but I can not get execution to stop at any breakpoint that is setup, either in code Break() or the IDE breakpoint window.
So I provide a target test class to get working in your IDE to prove it should work for someone else as-is.
You'll need to create a dummy/empty ASP.NET project called "MyWebProject" and have this test case in its own project.
Things I have tried:
Resetting all settings
Ensuring both projects (MyTestProject and MyWebProject are rebuild and setup for Debug build types)
Ensuring the ASP.NET debugging is enabled on that project.
Modifying Test menu -> Test Settings -> Default Process Architecture from 32bit to 64bit.
Modifying Test menu -> Test Settings -> Keep Test Execution Running
Settings for debug symbols, disabling Just My Code,
Settings for Common Properties -> Startup Project -> Multiple startup projects
Tried this (but all my code in project is rebuilt, I do not need to debug any DLLs): Use Managed Compatibility Mode
Lots of other things tried that I have simply forgotten now. Have "Reset all settings" since.
If I try to attach to process (existing IISExpress.exe that runs in background between tests), then I can not start my tests at all, option "Run/Debug All Tests" greyed out.
If I try to start any other app, like running ASP.NET webapp on its own, again I can not start the tests the options are greyed out.
So it has to work from "Test [menu] -> Debug -> All Tests" and letting VS2015 start up all processes as needed, with debugger attached (ideally to both IISExpress.exe and TE.processhost.managed.exe).
What I find painful is that if something went wrong during the setup why didn't the unit test fail on the basis that VS2015 could not attach to process and then confirm correct setup of process so it was executing the expected copy of the project, etc.. Surly it should ALWAYS suspend execution at the start to allow VS to setup and communicate to inferior process being debugger, then execution resumed. It should just fail unit test run and not even start the testing if the environment if not all setup as expected.
I notice what looks like 2 te.processhost.managed.exe (one is persistent across tests and one spawns during the current test run). The breakpoint dialog indicates this process is the location of the test case breakpoints (but not ASP.NET ones)
But of course the ASP.NET runs in iisexpress.exe which is another process.
So is debugger attaching to both ok? How can I see this while it should be the case? How can I stop debugger cleaning up on termination, as this resets UI to many options in Debug -> Window -> ... are not available (if you are not quick enough).
If I set an ASP.NET breakpoint in code for example in Application_BeginRequest() from Global.asax/aspx execution does not stop in here either.
I am after a working project ZIP file and settings of the simplest test case project that proves the debugger is attached from VS so I can run-step though the code.
I have just recently upgraded from VS2010 to VS2012 Ultimate. I have been running Web Performance tests and Load tests on this setup on 2010, but the biggest problem in 2012 is that they seemed to have removed any way to run all my Webtests at the same time. Since I no longer can use the test list editor, or even the test explorer, the only options I have been able to come up with are:
Put all web tests into a load test, and run it just long enough for every test to be run once
Use mstest in cmd
Use the run all tests, stop the run, uncheck all load tests or other webtests I do not want to run, and then run the rest
However, the only method that has worked so far is the last one (though its a pain).
The 1st option could work, it just requires adding more virtual users and/or more time than I have had. The flaw with it is just inefficiency since I only want to run each one only once and then stop.
As for the cmd line solution, I am not sure why this is not working. For some reason they always error when trying to load the assembly that contains my custom plugins (Error: "Could not load file or assembly.."). The command I use (in solution dir): 'mstest /testcontainer:"LoadTest\Workstation\NormalOrder\Order1.webtest" /testsettings:Main.testsettings'
I am just looking for any solution to this problem that would work the best. Ideally the webtests would show in the Test Explorer, but until that happens, I will continue to run with my 3rd option.
EDIT:
Followup to answer below.
You still can run multiple web tests in the same time ; it's just different in VS2012.
First, select desired web tests in the solution explorer and then, from the LOAD TEST menu, choose Run or Debug and then chose either Selected Test.
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.
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.