1

Basically, I'm running into trouble "working around" an API I have no control over which is locking a file when it shouldn't be.

The method from the API looks like this:

public static bool Upload(string fileName) { ... } // I have no ability to look inside this

It behaves like it's reading the file directly off the disk, and not placing the file into memory before hand.

This is a problem because it's written so poorly that whenever it fails at uploading, it fails to release the file lock. This means I have to start my application over again in order to release the file - which is a huge pain in production!

The only work-around I could think of was making an individual copy of the file (~ few MB at most) for each firmware upload instance. This could get it working, but then leaves me with the problem of deleting each file manually afterwards (since the file lock would be open as long as the app is, I couldn't do it in code)

Is there any workaround I can do that wouldn't create a ton of issues? My only thought is creating a separate C# class to hold the static upload function, then find some way to dispose the class and resources after it runs. Any ideas?

EDIT: It's a 3rd party API that uses proprietary code to talk to a microcontroller - so unless I want to bit-spy and re-create all the back and forth packets, it looks like rewriting the original function is a no-go.

au42
  • 111
  • 9
  • 2
    `This is a problem because it's written so poorly` Question can you refactor the code that's written so poorly..? – MethodMan Nov 04 '14 at 17:58
  • 2
    Or even use the better code? Or write the code yourself? – AgentFire Nov 04 '14 at 17:59
  • 2
    Uploads in general are easy. .NET classes like TcpClient or WebClient make it even easier. So unless there's something proprietary about this library, I agree with AgentFire that you should just stop using it. If you have to use it, you _might_ be able to force the API to release the file by executing the upload in a new AppDomain which you can then unload if the API fails. – Peter Duniho Nov 04 '14 at 18:03
  • @PeterDuniho Thanks for the suggestions. I updated the question with more info - basically rewriting or subbing out the function is out of my scope because it's proprietary to a microcontroller. – au42 Nov 04 '14 at 18:23
  • How about checking if its locked after method finished and then clearing the lock if so. WinAPI could help with unlocking file: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365715(v=vs.85).aspx – Panu Oksala Nov 04 '14 at 19:27
  • 1
    Maybe overkill, but would it be feasible to isolate the part that may leave a file locked into a self-contained program and then launch it as a separate process each time it's needed. When a process terminates Windows is usually able to clean up any resources that haven't been freed, incl. unlocking files that have been locked. – RenniePet Nov 04 '14 at 19:40
  • @RenniePet That's something I hadn't thought of, thanks! That seems like a feasible "last-resort" I can use if I can't manage to find a cleaner way. – au42 Nov 05 '14 at 16:00

0 Answers0