I get the error described above invoking this:

[System.web.httputility]::HtmlEncode($tm.uri)

And I wasn't able to solve it. Although it doesn't block the script, any help would be useful anyway.

Indeed you will see that message when you use the ProjectAutomationAPI but that is just a warning message that has no impact on the actual project creation. Studio as an application uses a logging framework which is named log4net and this framework is looking for some initialization settings in the application config. Now in this case since the ProjectAutomationAPI doesn't run in Studio context the logging framework is not initialized and thus the warning you see. This is not specific to powershell you can get this message even if you create a .net console application that uses the ProjectAutomationAPI.

Hi Evzen,

I discussed this at length with Romulus this afternoon. The problem you are encountering here would require a fix in the core product to resolve so that you didn't see this error when only using scripting. So we will log this with development, but we don't anticipate this will get a very high priority so won't be fixed in the short term. Would rather be up front with you now.

So the only options you have are these we think:

1. We (SDL Dev) fix Studio so it doesn’t show this error in the first place, or
2. you just use .NET and deliver a small UI to manage this.

We know you won't like the second option, and in reality if you used .NET to write the UI over powershell, which is possible, then you might as well do the whole thing with .NET and then at least you could suppress the error message. But given your views here this isn't going to wash!

So until the SDL Dev team resolve this problem we hope this won't be a real problem as it's probably only IT admins working via a command prompt and they will have enough knowledge to understand it's just a warning they can ignore... at least this is what we assume?

Anyway, that's where we are. Avoidable with .NET, but not using powershell until we fix this problem.

Regards

Paul

Unknown said:

According to the API documentation, method used by PowerShell Toolkit for creation of new project "creates a new project based on the default project template set up in SDL Trados Studio."

But... while Studio 2015 recognizes a *.mqxliff file - apparently because it's included by default, no need to Install File Type from OpenExchange - and produces correct analysis stats, Studio 2014 does not and spits out only zeroes... and I don't understand why, since my Studio 2014 default project template DOES include MemoQ XLIFF file type!

Quoting myself since this problem was not solved the first time and I'm seeing it again, this time with Studio 2015 SR2 and Excel file.

My default template (and also the setting in Studio Options) is changed to NOT translate Excel worksheet names (in Excel 2007-2013 file type definition).

Still, project created using API (using the Powershell Toolkit) ignores completely this setting and DOES include worksheet names...
In other words, it looks like the project was created using some 'hardcoded default' settings (those which Studio uses when it's run the very first time and creates the default template) instead of using the default template settings.

Why?! And how do I make it work as expected, i.e. as documented?!

Hahaha, found the reason... apparently it does NOT work as documented :(... or the documentation is incorrect :(

The project is not based on "default project template set up in SDL Trados Studio", but it's based on "Default.sdltpl" present in "<Documents>\Studio 2015\Project Templates" directory.
If that file is not present, project creation via API fails big time :( ... at least using the Powershell Toolkit.

New-Object : Exception calling ".ctor" with "1" argument(s): "Could not find the default project template. Run SDL Trados Studio to initialize the default project template."At D:\Documents\WindowsPowerShell\ Modules\ProjectHelper\ProjectHelper.psm1:107 char:22
+     $FileBasedProject = New-Object Sdl.ProjectAutomation.FileBased.FileBasedProject ...
+                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [New-Object], MethodInvocationException
    + FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand

The referred PS line says:

$FileBasedProject = New-Object Sdl.ProjectAutomation.FileBased.FileBasedProject $ProjectInfo

The point is that "default project template set up in SDL Trados Studio" is NOT stored in "Default.sdltpl" file, but e.g. in "SDL Trados.sdltpl", depending on which option user used during the Studio first run setup.

Looking forward to some official SDL statement...

EDIT:
Before someone starts asking - all settings in my user profile, etc. are correct and point to the "SDL Trados.sdltpl" template file...
Isn't this again about "not providing the needed context" like in the case of the annoying log4net message?

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?