Interesting view on building a "File watch" process. I have built similar solutions but I tend not to use VB to control the delay as I recall the CPU usage shoots up.

Instead, I use the VB purely to check for the file and return true or false back to the package/ populate a variable.

I also use this inside a "for loop container" and include a SQL task to process the delay (does not hit the CPU).

The properties on the "for loop container" are then configured to increment up to a given point,

i.e. n times the delay in the SQL Task

and include checks on the EvalExpresion to drop out when the file is found (previously populated variable =true) or when the total delay has been exceeded.

The work flows continuing from the container can then also check the previously populated variable and act accordingly.

Simple modifications to the VB to use a variable to hold the file to watch, this package can be called from a parent package, and collecting parent variables, allows the same child package to be called multiple times, e.g. waiting for n number of files to be available.

I am sure there are another dozen ways to achieve the same goal.