• State Suggested Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 4148 views
  • Users 0 members are here
Options

ProjectServer.OpenProject fails in Taskscheduler

Markus Wiedenmaier

Hi,

while running my Trados app by double click, app works as expected. 

But as soon as I put this task to Windows Task-Scheduler, ProjectServer.OpenProject raises an Exception:

Code:

var tradosProjectServer = new Sdl.ProjectAutomation.FileBased.ProjectServer(this.Host, false, this.UserName, this.Password);
string projectId = myProjectId;
var project = tradosProjectServer.OpenProject(new Guid(projectId), workFolder);

Exception:

There was an error opening the server project
   at Sdl.ProjectAutomation.FileBased.ProjectServer.OpenProject(Guid projectId, String localProjectFolder)

While any other things like working with local projects work as expected, here app fails.

Is there an issue with this function, when process is running without UI?

 

Credentials: checked

 

Thoughts? Thanks

Markus
Rate translation
×
Suggest better translation
×
  • 0

    Hi  

    I have not been able to reproduce the issue that you signalled above.  Please confirm that the steps I followed correspond to yours, to rule out that I missed something, as follows:

    Steps

    1. Open your console solution in Visual Studio as Administrator
      Note: the solution is simply a connection to the project server + open a project
      Example:
      • var server = new Sdl.ProjectAutomation.FileBased.ProjectServer(host, false, user, password);
      • var project = server.OpenProject(new Guid(projectId), workFolder);
    2. Set the output path of the solution to the Studio5 installation directory
    3. Compile + close the solution.
    4. Create a new Task from the windows Task Scheduler
      • Security: I used my windows user credentials (already logged in)
      • From the actions tab, select the new executable file that was built in the studio installation directory.
      • From the triggers, indicate the conditions that will trigger the task. I simply chose to run once at a specific time.
      • All other settings are default
    5. Click 'OK' to save the Task.

     I wonder is the issue related to security; possibly select the option 'Run with hightes privileges'?
  • 0 in reply to Patrick Andrew Hartnett
    Hi Patrick,
    many thanks for your investigations and your time.
    Indeed there seems to be an issue with rights or my account. Created another user with "same" rights and process seems to work now. No idea why…
    Markus
  • 0 in reply to Patrick Andrew Hartnett

    Hi Patrick,

    now I found out, what's the real problem, as after a while I got same issue with the newly created user.

    This issue happens, when %temp% is filled up with 65536 files. As soon as %temp% reaches this amount of temp files this exception is thrown.

    Cleaning up %temp% solved the issue.

    Just need to check why there are so many files in %temp%, but I think it's not a Trados issue.

    Thanks again and hope this info is useful for others

    Markus
  • 0 in reply to Markus Wiedenmaier
    Short update...
    It seems Trados 2017 produces this temp-files. As our process is more complex I can't tell you, in which steps.
    But it seems Trados or its API calls Path.GetTempFileName on certains points. temp-files often have a size of 0kb. Any time one call Path.GetTempFileName this functions creates this file directly, so after every call this file has to be deleted again.
    I also noticed this effect when creating a project in Trados by hand, but not with so much files.
    Perhaps you can double check your Code. Meanwhile I'll create an other scheduled Task which cleans up %temp% Directory once a day.
    Markus
  • 0 in reply to Markus Wiedenmaier

    Hi Markus,

    Just a quick response now to thank you for the excellent research with this; I'll follow up with the team and shed some light on the temp file usage, especially if this is causing the process to crash.
  • 0 in reply to Patrick Andrew Hartnett
    Some more information:
    I found out, that same problem occurs with Studio 2011 also , where we didn't use GroupShare and GroupShareAPI. At the moment both processes (Studio 2011 and Studio 2017) are running, so %temp% fills faster of course.

    I was not right, when I said "anything else is running well" at the beginning of this thread. OpenProject in Studio 2017 is only one effect. Also AutomaticTasks don't run properly anymore if %temp% is "full".
    I found two lines in my code where I used Path.GetTempFileName and where I didn't delete this temp file after this call. But in my case it was one file per project.

    In my case this happend when calling Path.GetTempFileName and I need another file extension. Something like that:

    var tempFile = Path.GetTempFileName() ; //creates tmpAAAA.tmp
    tempFile = tempFile + ".html";
    //create html file again
    File.Delete(tempFile)
    tmpAAAA.tmp is not deleted in this case.

    Perhaps this helps
  • 0 in reply to Markus Wiedenmaier
    Just adding a reference to a discussions about basically the same thing:
    community.sdl.com/.../67904