• State Not Answered
  • Replies 8 replies
  • Subscribers 7 subscribers
  • Views 9085 views
  • Users 0 members are here
Options

Project Automation API: License check failed, with exception: Sdl.Core.PluginFramework.PluginFrameworkException: No Application specific plug-in directory found.

Andrew Jameson

This problem - noted in the title - appears to be a common one: Here are just a small sample of form threads where people are looking for solutions to this

SDL Trados API question
License check failed, with exception: Sdl.Core.PluginFramework.PluginFrameworkException: ...
SDL 2015 API :License check failed, with exception: ...

In the first two threads the users were possibly unaware of the AssemblyResolver project; in the last thread the user is in the same situation as am I: I'm implementing the AssemblyResolver but I still encounter the exception.

Romulus' response in that last thread is 

I know AssemblyResolver should take care of that but the exception is not about missing reference but rather the plugin framework is looking the plugin folders inside your application folders.

I'm not quite sure what this means. I don't (knowingly) have any plugins and in the standalone Project Automation API that I'm working on I don't believe I'm using any plugins. So why does it throw this exception? Perhaps Romulus could provide more details?

Also, building the application to the ~SDL\SDL Trados Studio\Studio4\ folder is a huge inconvenience due to my project using different - newer - versions of some references also used by Trados (for example, log4net, Newtonsoft.Json, ...), which I believe is the same problem cited by SDL when explaining why they don't publish their assemblies to the GAC.

I currently have one standalone application which uses the Project Automation API in conjunction with AssemblyResolver and it runs without any problems. But in a second application which I'm now developing to replace the first, I encounter the same old problem:

License check failed, with exception: Sdl.Core.PluginFramework.PluginFrameworkException: No Application specific plug-in directory found.
at Sdl.Core.PluginFramework.DefaultPluginLocator..ctor()
at Sdl.Core.PluginFramework.PluginManager.get_DefaultPluginRegistry()
at Sdl.Common.Licensing.Provider.Core.LicensingProviderManager.get_LicensingProviderFactories()
at Sdl.Common.Licensing.Provider.Core.LicensingProviderManager.CreateProvider(ILicensingProviderConfiguration config, String preferredProviderId)
at Sdl.Common.Licensing.Manager.ApplicationLicenseManager.GetCurrentLicensingProvider()
at Sdl.Common.Licensing.Manager.ApplicationLicenseManager.GetProduct()
at Sdl.Common.Licensing.Manager.ApplicationLicenseManager.GetLicenseWithoutConsumingSeatsOrUsages()
at Sdl.ProjectAutomation.FileBased.FileBasedProject.CheckLicense()

Perhaps someone could suggest how I get around this problem, or at least suggest why one of my applications runs fine and the other throws this exception?
Rate translation
×
Suggest better translation
×
Parents
  • 0

    SDL Trados Studio has 2 type of plugins. One type is considered to be "internal plugins", are developed by SDL and released together with the product. The second type is 3rd party plugins that can be developed by anyone and are distributed via the appstore or however the developer wants. With this in mind when you use the project automation api there's always going to be a license check (this is available only with professional license) and as part of that license check the plugin framework is initialized and the piece described by Jesse is executed. That piece of code will look after the "internal plugins" folder which is inside SDL Trados Studio folder. 

    I already raised this with the development team and it's on the backlog. If you want this to get more priority you can contact support or the account manager and ask for LTB-1136 to be implemented.

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

  • 0 in reply to Romulus Crisan (former member)

    Hi Romulus, Is this issue still on the backlog? If it's already fixed, could you explain a bit more in detail what exactly was fixed?

     

    Also, can you tell if the error I'm getting is related to this issue?  The error is:

    Sdl.ProjectAutomation.FileBased.LicensingException: License check failed, with exception: Sdl.Core.PluginFramework.PluginFrameworkException: Cannot validate SDL plug-in: Sdl.Common.Licensing.Provider.SafeNetRMS.SafeNetRMSicensingProviderFactory

    This is with SDL 2017 and Groupshare 2017.

    Thanks!
    Rieko Matsunaga
Reply
  • 0 in reply to Romulus Crisan (former member)

    Hi Romulus, Is this issue still on the backlog? If it's already fixed, could you explain a bit more in detail what exactly was fixed?

     

    Also, can you tell if the error I'm getting is related to this issue?  The error is:

    Sdl.ProjectAutomation.FileBased.LicensingException: License check failed, with exception: Sdl.Core.PluginFramework.PluginFrameworkException: Cannot validate SDL plug-in: Sdl.Common.Licensing.Provider.SafeNetRMS.SafeNetRMSicensingProviderFactory

    This is with SDL 2017 and Groupshare 2017.

    Thanks!
    Rieko Matsunaga
Children