1 person found this helpful
@Linden - Have not heard of this side effect from anyone as of yet, but good to know. Sounds like the file lock is coming from the Flash Player and causing the spawning process (rundll32.exe) to hang around as well. The FlexUnit team runs on Hudson using the FlexUnit Ant task, but we don't seem to encounter the same issue. What's the longest interval you've tried to use with the sleep task? Does the FP ever release its handle to the test SWF on your development machines?
Not sure this is a problem with the FlexUnit Ant task, but in 4.2 we could try to explicitly kill the rundll32 process since we'll have the PID when the task launches it. Head on over to JIRA and file a feature request for us and I'll see what I can do in the new year. In the short term though, maybe try upgrading your version of the stand alone debug flash player to see if that helps. Has anyone else seen this issue? Could you possible just move the clean target to be called before the xci-test target is run? Just some suggestions.
Brian, thanks for the quick response!
I just tried 60 seconds, and it still had a lock on the file. From what I can see, as soon as the ant process stops, the process stops, but not until then. We have the latest (10.1) standalone player from adobe's site ( we just set this up last week ). I'll put a feature request in at Jira, and possibly we can switch the clean task to before each build instead of after.