Hi all,

I tried to investigate this issue by running project automation API with Studio 2011 professional license (both the case to use license server or independent) and I could not reproduce any license problem reported in this thread if I follow a certain rules. Here is the steps I tried:

1) Prepare a folder to store the reference files and the output of Visual Studio build. In my case I use the folder d:\dev\bin\debug. And I run the following batch file to make the folder and copy all the possible required files (Here I am using Windows 7 and Studio is installed to the default folder. Basically this is to create a new folder, and copy everything from Studio installation folder):

::::::: the batch file content :::::::::::::::::::::

@echo off

:: setup the folders

SET DEV_FOLDER=D:\dev

SET STUDIO_FOLDER="C:\Program Files (x86)\SDL\SDL Trados Studio\Studio2"

SET DEV_BIN=%DEV_FOLDER%\bin\debug

:: copy all studio files to dev folder so that project reference and output will go to this folder

IF EXIST %DEV_BIN% GOTO copy_file

mkdir %DEV_BIN%

:copy_file

xcopy /s %STUDIO_FOLDER% %DEV_BIN%

2) Create a project in Visual Studio. Make sure all the project reference files are from the folder in the first step -- that is d:\dev\bin\debug for my case. And also make sure the project output path is set to the same folder, just as shown in the following screenshot:

3) Now I wrote the code with project automation api, then I run either from debug or outside Visual Studio, everything works fine.

4) To further investigate this issue I also created a unit test project. In the first test I forgot setting project output path as I did in step 2, therefore my test failed with "Invalid filechck" error. I then start fussion log tool (FUSLOGVW.exe -- from Microsoft SDK) to check all the DLL loading. I saw it is the DLL loading issue. Therefore I changed the project output path to the same folder as in Step 2, now it works fine again.

5) With the setting in step 2 for all the projects, all my coded DLLs and Exes are in the folder d:\dev\bin\Debug. After finishing my work, I just copy my own DLLs and Exes to SDL Studio installation folder for production usage.

Could you all try the same steps as I did to see if you still have problem? If you still problems, you might post your detailed steps and I will look further the issue.

Thanks,

Xingzeng

How can this be different than just building in the C:\Program Files (x86)\SDL\SDL Trados Studio\Studio2 folder when I build with references to this folder?

I now get it working on my own pc using a normal license key or a server license key. But if I try it on another pc it doesn't work anymore.

Edit: I can now get it working on other pc's too if I follow your steps. Thank you.

Kind regards,

Piet

Hi Piet,

If you already copied everything from Studio installation to the output path, references to the output path instead of PF folder can avoid any further reference checking/copying for Visual Studio building. The steps I posted are to ensure we have all the necessary required DLLs/resources etc in place to run SDK apps, also ensure we do not have security related problems. If you follow the steps I posted and it does not work, please post your fusion log.

Thanks,

Xingzeng

Hi Piet,

If you already copied everything from Studio installation to the output path, references to the output path instead of PF folder can avoid any further reference checking/copying for Visual Studio building. The steps I posted are to ensure we have all the necessary required DLLs/resources etc in place to run SDK apps, also ensure we do not have security related problems. If you follow the steps I posted and it does not work, please post your fusion log.

Thanks,

Xingzeng

Hello Xingzeng,

It's working now. Thank you!

Piet

Hello Xingzeng

Unfortunately, the error persists in my case.

I created an empty folder, as you suggested: "C:\tmp\build"

Both my main project's and my test project's output now go to that directory. My main project is a WPF program which has references to several Studio DLLs. I removed these references and replaced them by direct references to the "C:\tmp\build\XXX.dll".

I adapted your script to fit the situation:

@echo off

:: setup the folders

SET DEV_FOLDER="C:"

SET STUDIO_FOLDER="C:\Program Files\SDL\SDL Trados Studio\Studio2"

SET DEV_BIN=%DEV_FOLDER%\tmp\build

:: copy all studio files to dev folder so that project reference and output will go to this folder

IF EXIST %DEV_BIN% GOTO copy_file

mkdir %DEV_BIN%

:copy_file

xcopy /s %STUDIO_FOLDER% %DEV_BIN%

Nevertheless, running my unit tests causes the exception all the same. Again, I would like to repeat that at the end of this all, there is no "filechck.dll" in my "C:\tmp\build" directory. This simply due to the fact that there is no "filechck.dll" in my "Studio2" folder, either.

 Is there any step I missed out on? Should a "filechck.dll" be present? Is my Studio installation corrupted?

 Thanks for your feedback and best regards

Pascal 

Hi Pascal,

Could you please try to look at your DLL loading from the fusion log? Normally this helps to understand where the DLLs are looking for files to load. For example in my configuration, the fusion log for Sdl.Core.FileCheck is:

=== Pre-bind state information ===

LOG: User = GLOBAL\xliu

LOG: DisplayName = Sdl.Core.FileCheck, Version=1.8.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888

(Fully-specified)

LOG: Appbase = file:///D:/Dev/bin/Debug

LOG: Initial PrivatePath = NULL

LOG: Dynamic Base = NULL

LOG: Cache Base = NULL

LOG: AppName = QTAgent32.exe

Calling assembly : Sdl.ProjectApi.Licensing, Version=10.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888.

----------------------------------------------

So I know it is from the right place I explected (actually this was not the case when I have fileckck missing problem).

Thanks,

Xingzeng

Hi Xingzeng

I've uploaded the full Fusion output to the following temporary storage: http://temp-share.com/show/3YgF7qwJx

All the relevant DLLs seem to load successfully from my C:\tmp\build folder.

Thanks,

Pascal

Hi Pascal,

Yes, your DLLs are all loaded OK from the right location. But your fusion log shows that you are running from Studio. I assume this is from debugging. Do you have problem to debug your code?

This thread initially was for unit test. Think for unit test the app should run from qtagent just as my fusion log shows. Could you describe more of your error details? If you only have problem in unit test just like the initial bug report, could you please check the fusion log for unit test?

Thanks,

Xingzeng

Hi Xingzeng

No, debugging works fine, though I'm not debugging it currently. I am merely running the unit tests directly from Visual Studio. I wasn't even aware that one could run them outside of VS, to be honest. Should I try to run QtAgent with my unit tests manually? What command line would I have to use in order to do that?

Thanks

Pascal

Hi Pascal,

QTAgent32 is the test runner for Visual Studio. When I run unit test from Visual Studio 2010, in the fussion log it reports the application as QTAgent32. So I guess the fussion log you sent is not for unit test (actually your fussion looks fine, therefore I expect your debug should be OK).

Thanks,

Xingzeng

Hi Xingzeng

Please find the fusion log for QTAgent32.exe here:

temp-share.com/.../664060501d959ed5a4ffcfb18af83c72

Still, I find myself incredibly stuck here. Can you gather something from the fusion logs there or could I send you my test program for you to test in your environment? This showstopper is killing the whole project by now.

Thanks, Pascal

Sorry, wrong link: temp-share.com/.../HKdPlTi5A

Hi Pascal,

I wonder if you correctly set your unit test project output path. For example I copied all my Studio DLLs to folder D:\Dev\bin\Debug and my project output is set to the same folder. Therefore each DLL is loaded from that folder (see the following screenshot).

However from your log file, I see the DLLs are loaded from C:/Users/pkesseli/Software/C#/project-creator/TestResults/pkesseli_BCLN03 2012-10-30 10_29_37/Out (see the following screenshot). Think you do not expect to load DLLs from there. Certainly it fails to check the license.

 Thanks,

Xingzeng