Just installed Visualcron on a Win2k8r2 server VPS after struggling with the windows TaskScheduler for, well, far too long.

I really only have 2 things I need it to do and it seems to have failed on the first one - the application (which is self written) runs on the server box OK, and I can coax TaskScheduler into running it using syswows because it is 32bit in 64 bit environment.

However, VisualCron complains that it is not a valid 32 bit application. So that seems to mean it is finding the program and attempting to start it OK - but has the same issue as TaskScheduler in that natively running 32bit (which it is) on 64bit platform is a problem.

So. I can't believe it would fail so easily. Which means I missed something or did something wrong. Suggestions?

Is it an application we can test from here?

---

Not easy - it has embedded login information to a financial site and the server isn't really set up for remote access. I'll look into it, but I can run the thing natively with a click, or inside visual studio without problem. It is being locally compiled on the VPS. First off, I will see if I can target the build to 64 bit - but since it runs OK with a simple click in the file explorer window, I didn't really expect it to show similar copatibility issues to going over Scheduler.

Tried to embed a screen-shot but didn't manage. The window dialogue says

"Message from server - <my prog name>
Unhandled error ocurred when trying to start job. Error: specified executable is not a valid Win32 application.

Which at the very least, is wrong.

Which language is the application written in? Seems like we would like to try the "shell" only with no content.

---

OK. It is C#

I ran it as a hidden window. It didn't complete, but also didn't completely crash!
I ran it as a shell execute with no conditions, and it ran to completion, producing credible output.

That is fair enough, and I am happy that it runs. And at the end of the day, that is all I really care about. But - and I am no expert here - that makes your error message look a bit toooooo much like it is failing for the same reason as Task Scheduler in running 32 bit images in a 64 bit environment.

Would be interesting if you unchecked "Use shell execute" and change the select box to "Run managed" instead of "Run with API code".

---

Can you attach a screenshot of your execute settings? It might have something to do with how you write the command and argument.

---

Can't do a screen shot right now .- but I unclicked 'shell execute' and the 'run with API code' remains greyed out - I have no chance to select something here. Nothing else is changed in the window except the path to the command (C:\Users\Public\CorrectScores\get_BF_Events.application) and the working directory (C:\Users\Public\CorrectScores).

Uncheck it and Credential (the user that you are logged in as). First, please try with "Run with API code" and then "Run managed".

This is a click once application?

---

OK I did that - added the user crdential for me running as admninistrator. Edited the job to run both as API code and managed. The job starts and appears to run (indicated in 'Result' as running), but it appearns not to be going to completion in a reasonable time - the hour glass icon is still there several minutes later. If I run the program by double clicking in the file explorer, it runs to completion within 2 seconds.

Yes, it is a 'click once' application.

Thank you for your testing.

We did some tests ourselves and have so far come to the conclusion that something special is happening with .application (click once files). We are able to execute them in two scenarios:

1. using "Use shell execute"
2. use path to cmd.exe and /c path to application in argument

1 and 2 are basically the same. The reason why .application works is because we use the default "opener" for .application files. When using "normal execute" it seems to be confused of how to open .application. I guess there is some kind of application that launches these files.

Using "Use shell execute" is really not a problem. Only disadvantage is that we cannot capture output but I guess this is irrelevant in most cases. Most important is that we have find a execution method that works.

---

That sounds very like the scenario I had with TaskScheduler. I run the .application with syswows\cmd.exe /C successfully where it is basically being run in a protected (emulated) 32 bit environment. This is necessary because scheduler expects a 64 bit application. There is some very limited documentation on it spread around various forums, and it may relate to some way in your 'default opener' situation.

(Edit: Here is some of the 'deeper' discussion behind the problem to which I am referring. It may not be what lies behind this issue - though it sounds similar, but at least if you know where to start looking to check it out, it will save some time - http://blog.zachsaw.com/...dcontext-may-return.html )

Running the .application natively with a double click from a system folder is no problem.

My main issues with MSTaskScheduler are its inability to *update* the 'time' of an event; and the syntactic horror of creating an event of the type I need from within C# given the awful state of the API (unless I have missed something) and the need to run it with the cmd.exe /C syntax.

I can run as a shell exec for now - that isn't an issue, and seems to work - so I will move on to trying to create the event using the VisualCron API and see if I run into issues there. As long as I can create or update an event, and it runs - even as a shell exec, then I get what I need - but I guess you need to look into the .application thing because it won't be just me.

(Edit2); I pulled the .EXE file and ran that instead (hadn't realised it was also produced!). That seems to run in VisualCron and produces the expected output - except that having finished its job, the executable is still in the process list and VisualCron still identifies it as running - did some of the changes to the exec screen prevent a clean exit here? So I recreated the job from scratch and after selecting to run in a hidden window I have what appears to be success!

Thanks for the update. Yes, an exe is produced. Just be aware of that the path to exe might change when a new update comes.

---