• State Suggested Answer
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 391 subscribers
  • Views 9128 views
  • Users 0 members are here
Options

Debug & Logging of Plug-In

Memi Lavi

Hi,

Is there any way to debug Plug-In execution?

I tried to attach to the process of the Trados, but nothing happened.

In addition - what is the best practice for logging in the Plug-In? Is there any unified log storage I should write to, or should I write my logs to a regular file?

Thanks,

Memi
Rate translation
×
Suggest better translation
×
  • 0
    Hi Memi,

    I think that Romulus will answer this better but from my experience -> debugging is out of scope in the sense that you are expecting it here. Instead, I simply streamed out everything to log files, as you are probably doing already.

    What type of problems are you experiencing with the plugin development?

    Patrick.
  • 0

    Debugging

    I use 2 ways to debug studio plugins:

    1. Attach to process from Visual Studio. This is my preferred way of debugging but for this to work you need to be careful that Studio loads the assembly that corresponds to your source code. For my plugins I always set the output directly to this path c:\Users\{user}\AppData\Roaming\SDL\SDL Trados Studio\12\Plugins\Packages\ and then I make sure that the files from c:\Users\{user}\AppData\Roaming\SDL\SDL Trados Studio\12\Plugins\Unpacked\{plugin name folder} are deleted.

    2. I use this in situation where I need to debug the intialization code or something like that and I don't physically time to attach the VS debugger. This requires to add the following line of code where you want your application to stop for debugging System.Diagnostics.Debugger.Launch()

    In any cases I recommend to compile your plugin with Debug configuration.

    Logging

    Studio uses log4net for logging errors. The drawback of this is that you will not be able to log any other information from your plugin except when the plugin crashes and Studio will catch that exception and write it on the centralized logging file. Based on your needs you can separate logging for your plugin. Studio API doesn't provide anything towards that so you can use whatever you like. I recommend log4net or NLog. Recently I tend to use more NLog but log4net can do the trick just fine. If you want to see how I internalized NLog for one the plugins have a look here. 

    Hope this helps.

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

  • 0 in reply to Romulus Crisan (former member)
    Hi,

    Unfortunately, I can't make it work...
    I cannot delete the folder from the Unpacked folder, I keep getting a message the files are open in another app (which is logical - Studio is using those files...)
    When I try to attach the process, the breakpoints never hit, even after I allow the source code to be different.

    What am I missing?
  • 0 in reply to Memi Lavi
    You need to close Studio in order to be able to delete the files from the Unpacked folder.

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

  • 0 in reply to Romulus Crisan (former member)
    But when I re-open it, it loads the files to this folder again...
  • 0 in reply to Memi Lavi

    Yes that's correct. The workflow should be something like this:

    1. Stop SDL Studio
    2. Make changes in the plugin source code
    3. Compile the plugin with output in the packages folder
    4. Remove the dll's from the unpacked folder
    5. Start SDL Studio 
    6. When the unsigned message appears attach the VS debugger

    After this steps you should have the correct version in the unpacked folder and you should be able to attach and debug the plugin.

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

  • 0 in reply to Romulus Crisan (former member)
    OK, thanks. That worked.

    It turns out the problem is that the Plug-In cannot access the app.config file of the Plug-In.
    How can that be done?

    In addition - I must admit I'm having some difficulties accessing the docs. ie, I couldn't find the full API docs of the Verification API, and couldn't locate the full technical specs of the OpenExchange format - what exactly can be published, how does Studio downloads and installs the Plug-In, and can I really run my own installer together with the downloaded Plug-In.
    Could you please point me to those resources?
  • 0 in reply to Memi Lavi
    Hi Memi,

    with reference only to the issue you are having with the app.config file, as follows:

    I am guessing from the previous responses that you receive an exception when you try to instantiate the web service or maybe a database whose connection settings are located in the app.config, correct?

    If this is the case, then one way to avoid this exception is by writing the binding information for connecting with the web service or database directly in the class as opposed to a dependency on recovering that data from the app.config file during run-time. It should be possible to recover various examples of this on the net.
  • 0 in reply to Patrick Andrew Hartnett
    Thanks Patrick,

    Yes, this is what I ended up doing, but I really don't like it.
    Isn't there any way of having a configuration file for the Plug-In that I can access?
    I found out that using ConfigurationManager gives me access to the Trados' config file, not to the Plug-In's one.
  • 0 in reply to Memi Lavi
    Hi Memi,

    It should also be possible to load the information from the config file, but only if you separate the concern by including the logic for connecting with your web service and/or database in a separate assembly. You would most likely install this assembly in the Studio installation directory with the config file (i.e. with the same name of the dll + .config).

    does this make sense?
1 2