Why does my emulator deployment fail with "The process cannot access the file because it is being used by another process"?

2

I am in the process of porting a Windows CE solution from .NET 1.1 to 3.5

I was able to "deploy" it -- once -- (to the Pocket PC 2003 SE Emulator), and run the .exe, upon which it failed with an error message.

After closing the emulator, I put a breakpoint in the Visual Studio 2008 IDE within the constructor causing the problem, and deployed again, hoping to step through the code and see where the problem is.

Instead of this coder's nirvana, though, I was stung instead by this communique from the compiler:

"Deployment and/or registration failed with error: 0x8973190e. Error writing file '%CSIDL_PROGRAM_FILES%\ABC\ABC.exe'. Error 0x80070020: The process cannot access the file because it is being used by another process. Device Connectivity Component"

Thinking maybe the emulator's process was hanging around like a pimply lout outside a southern sorority, I shut down Visual Studio and restarted. I mashed F5 again, filled with the hope that springs eternal in the human breast, only to be accosted once more by the very same message.

What need I do to get my emulator back?

As an <aside>, I find it odd that I cannot take a screen shot of the emulator - both PrtScn and Alt+PrtScn fail to fill the clipboard with pixels thereof.

UPDATE

I subsequently deployed to "USA Windows Mobile 5.0 Pocket PC R2 Emulator", on which "device" my app runs, but when I attempt to put the app through its paces, I get: "Exception: File or assembly name 'System.Core,Version=3.5.0.0 ..., or one of its dependencies, was not found"

I see that File Explorer has a ".NET CF 2.0" folder, but nothing for ".NET CF 3.5" - yet the app, which uses 3.5, was deployed to the device (at least partially)...am I correct in assuming there would be such a folder? If not, where should System.Core version 3.5 be located?

UPDATE 2

Next, I tried "Windows Mobile 5.0 Smartphone Device R2", and get the error: "Deployment and/or registration failed with error: 0x8973190e. Error writing file '\Windows\NETCFv35.wm.ARMV4I.cab'. Error 0x80070070: There is not enough space on the disk. Device Connectivity Component"

Pennsylvania Hip-Hop! (Key-rap!)

...Oh, oops - I actually wanted to use an emulator again, not deploy it to the actual device.

UPDATE 3

I'm getting this err msg again, deploying straight to the device. I ran it several times today, and the last couple of times it failed with what was probably a bad REST call (wrong verbiage on the client). Now I see this "There is not enough space on the disk" jazz again.

I tried JP2Code's suggestion, but I see no running apps at all, nor the tab wherein there names are ostensibly stored:

enter image description here

As to adding this.Close() to the Exit code, what already exists is this:

DialogResult userResponse =
    MessageBox.Show("Are you sure you want to exit Duckbill?", Platypus.GetFormTitle("", "", ""),
        MessageBoxButtons.YesNo,
        MessageBoxIcon.Question, MessageBoxDefaultButton.Button2);

if (userResponse == DialogResult.Yes)
{
    Dispose(false);
}

I don't know why the original coder did it this way, but I assume this fancy-pants code obviates a call to this.Close() - or not?

The rather odd and scary custom "Dispose" method is (comments mine):

protected override void Dispose(bool disposing)
{
    dbconn.DBClose();
    base.Dispose(disposing);
    Application.Exit(); // Why?
    // I would add to that "Why?" comment above with a reference to this:
    // http://codereview.stackexchange.com/questions/23133/is-there-a-valid-answer-to-this-why-comment
    // This makes me think twice about removing it, though:
    // http://social.msdn.microsoft.com/Forums/en-US/clr/thread/15efa70b-0065-44ef-ab09-7088fefd52b0
    // If it becomes a problem/there are complaints about it crashing when closing, revisit...
    // Could this have been the cause of the NRE that I ended up "eating"? See frmEntry.saveDSD()'s 
    // catch block
}
visual-studio-2008
compact-framework
emulation
windows-ce
visual-studio-debugging
asked on Stack Overflow Oct 3, 2013 by B. Clay Shannon • edited Nov 28, 2013 by B. Clay Shannon

2 Answers

3

The old app process on the emulator is still running. Restart the emulator or, better yet, use Remote Process Viewer to find and kill it.

EDIT

The initial error you're having is most certainly due to the process being still running on the target device. Bear in mind that each project has a setting for the target device, so it's quite possible that you have the EXE pointing at one device (an emulator is a device) and a DLL pointing at a different device. Visual Studio will then deploy these assemblies to different locations, so it's possible your DLL went to the emulator but the EX went to a physical device attached to the PC and that you simply didn't realize where it was running. In this case resetting the emulator wouldn't stop the process. Yes, it can get confusing.

The error in your first Update indicates that CF 3.5 isn't installed. The project should deploy it if necessary (you can turn that off in the project properties). You can verify if it is installed by running cgacutil.exe (it should be in the \Windows folder). There won't be any installed folder as the CF should go right into the \Windows directory. Also, verify that you don't have CF 2.0 and 3.5 installed - that can cause headaches. A lot of headaches.

As for Update 2, Studio is trying to push the CF CAB file to your target device to install it, but it's running out of space.

answered on Stack Overflow Oct 3, 2013 by ctacke • edited Oct 4, 2013 by ctacke
3

Click Start > Settings then tap the System tab.

System Tab

Tap Memory and then tap the Running Programs tab.

Running Programs

Find your application, and click ...er, I mean tap Stop.

Now, close out of your application.

To prevent this in the future, open your Project's main form, look at the Properties of that form, and set ControlBox to False.

This should make the application exit when the form closes.

ControlBox

It has been a long time since I coded that part, though, so I could be a tad off there.

One thing that will close it for certain is by writing in a Close() command like I did for my Exit Menu Item:

private void mi_Exit_Clicked(object sender, EventArgs e) {
  this.Close();
}

That should be enough to exit the application.

Now, how to make the device re-activate the the application that is running in memory would be a nice trick to learn. I'm guessing Visual Studio would not be friendly with that, though, as the executable build would typically be different.

answered on Stack Overflow Oct 4, 2013 by jp2code

User contributions licensed under CC BY-SA 3.0