Some of the scripts in the modules folder are pointing to: 'C:\Program Files' - you will need to amend these to: 'C:\Program Files (x86)' if you are running Studio on a 64-bit machine.

Is it possible to provide an example of this using server based rather than file based TMs?

Cheers

Hugh

Unknown said:

I want to have new project-TMs created upon package creation, hence I set:

$packageOptions.ProjectTranslationMemoryOptions = [Sdl.ProjectAutomation.Core.ProjectTranslationMemoryPackageOptions]::CreateNew;

However, as soon as this option is enabled, I don't get any project-translation-memories at all.

The parameter itself is valid and should work, since setting it to "UseExisting" results in attached project-TMs (most of the time), so it's got to be some hidden magic?

If somebody could shed some light on this issue, I'd be very grateful.

Has this ever been clarified/solved? I'm now having exactly the same problem...

I got the new project TMs being created only if I also set the "IncludeReports" option (newly introduced in Studio 2015 CU7) to True.

It seems to me like if this option doesn't control only including reports, but rather works as a global "DO include / DON'T include stuff" switch... which would point to either incorrectly documented API, or incorrectly working API.

Anyone can comment on this?

Paul, it is obvious that most (if not all) of the issues recently reported by me have nothing to do with PowerShell itself. PowerShell is just the way to use the API. Moreover, I have commented in quite a few threads where the same issues were reported by people NOT using PowerShell.
Show me working C# code which does NOT show the buggy behavior to prove that the problem is PowerShell...

Regarding your previous offer - perhaps I did not post the answer after all, since it was quite pointless... because you obviously failed to get the point of the discussion :-\.
So, in short - I need to be able to automate EVERY basic engineering operation (creating project, running tasks, creating packages, importing packages, creatingTMs, updating TMs, etc.) from commandline.

And in fact I'm already very close to have it already done using the PowerShell Toolkit... but the terrible bugs in either API or Studio itself are preventing me from getting it finished - memory hogs causing OutOfMemory exceptions, options not working as documented, etc.

So you should better invest the effort in fixing the bugs instead of developing some funny single-purpose application which would be full of new bugs anyway...

Unknown said:

The reason I asked again is because fixing this is something that will require core development, so finding a workaround is going to be the best approach if we want something quickly.

Well, but you have to fix it anyway as most (if not all) of my recent discoveries look like quite serious core BUGS...

I have probably mentioned already somewhere that I have already implemented a workaround for the default project template:

1. Get default project template GUID from the user settings (UserSettings.xml) file
2. Get the location of local projects storage from ProjectApi configuration (SDL.ProjectApi.xml) file
3. Get the default project template path from local project storage (projects.xml) file

switch ($StudioVersion) {
    "Studio2" {$StudioVersionAppData = "10.0.0.0"}
    "Studio3" {$StudioVersionAppData = "11.0.0.0"}
    "Studio4" {$StudioVersionAppData = "12.0.0.0"}
}
$DefaultProjectTemplateGuid = Select-Xml -Path "${Env:AppData}\SDL\SDL Trados Studio\$StudioVersionAppData\UserSettings.xml" -XPath "//Setting[@Id='DefaultProjectTemplateGuid']" | ForEach {$_.node.InnerXml}
$LocalDataFolder = Select-Xml -Path "${Env:AppData}\SDL\ProjectApi\$StudioVersionAppData\SDL.ProjectApi.xml" -XPath "//LocalProjectServerInfo/@LocalDataFolder" | ForEach {$_.node.Value}
$DefaultProjectTemplate = Select-Xml -Path "$LocalDataFolder\projects.xml" -XPath "//ProjectTemplateListItem[@Guid='$DefaultProjectTemplateGuid']/@ProjectTemplateFilePath" | ForEach {$_.node.Value}

At the moment I am not quite sure how realiable it will be in the real world - the users across the company have really VERY variable environments, so the result is unpredictable.

Unknown said:

If I look at your default project template issue. Why can't you use a named project template for example? If you do that then the API performs correctly and using your example will honour the excel settings to ignore worksheet names. If you make that your default it still works. So is this a major problem for you to work around this problem in this way?

This is not acceptable. We are not talking about situation you seem to be typically used to - a SINGLE user (typically a freelancer translator). We are talking about solution for DOZENS of individual users across the company with various environments, various needs, various habits, etc., which MUST be respected. I am not in a position to push them to workarounds... especially if these weird workarounds would be connected with the automation... that would show the automation in VERY BAD light.
So I really need a solution which "creates new project based on default template configured in Studio", just as the Studio does when the project is created from Studio GUI.

Unknown said:

We are not talking about situation you seem to be typically used to - a SINGLE user (typically a freelancer translator). We are talking about solution for DOZENS of individual users across the company with various environments, various needs, various habits, etc., which MUST be respected.

Evzen,

I wish you would tone down your language when you respond to me.  I'm trying very hard to help you.  I do work for a company that has a fairly large LSP and I reckon I also deal with many more companies than you do who are trying to find solutions for these problems.  Truth is I have no idea who you are Evzen or what problems you are trying to solve from a business perspective.  You could just as easily be a hobby scriptor rather than someone providing solutions for a major enterprise supporting thousands of users.  You have an aversion to using the APIs without powershell (whether they work or not) so it's very hard to tell.

For this reason I asked you this:

Unknown said:

So is this a major problem for you to work around this problem in this way?

A simple explanation would be just fine without the barbed responses.

Unknown said:

So I really need a solution which "creates new project based on default template configured in Studio", just as the Studio does when the project is created from Studio GUI.

ok.  So we will look at this to see whether there is a way to workaround the problem in the product for you and also see what we need to do in order to address the product.  I did have a quick play with InSource which offers a simple example of how to use the API for project automation and there we also do not use the default template.  So custom templates are always used.  Could be we did this because of the scenario you have described.  However, we will look at this and let you know the outcome one way or the other.

Regards

Paul

Hi Paul,

I'm just judging from your replies in other forums, where the solutions usually concern one particular person in one particular situation. That's all, nothing else.

Regarding the default template problem - if someone can confirm that my current workaround could be the right direction (is this perhaps the same way Studio itself determines which is the default configured template?) or what should be better workaround, that will be enough for now for me.
(Still, this bug should be fixed in the API rather earlier than later, IMO)

What's much more serious are the other reported showstoppers:

• "Invalid number of analysis bands" exception when Analysis task is called using overload with status event handler
• (Presumably) memory leaks causing Out Of Memory exceptions (and/or other failures) when "Create New Project TM" option is used when creating packages
• Similar (same?) memory issues during Analysis causing the analysis to fail
• Json.NET component version issue which started happening after update to CU7 (and disappeared after downgrading back to CU6)

The memory issues and the Json.NET problem concern rather Studio as such than only the API.

Regarding the memory issues - it looks like it can be related to work with rather huge TMs. I can see it happening when project includes one or more TMs which are several hundreds of megabytes, up to even ~1GB *.sdltm file.
On the other hand, from the memory consumption graphs I posted recently it doesn't seem that the TM size itself is the problem; it looks rather like some unfreed memory issue.