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

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?

  • Hi Andrew,

    The comment from Romulus makes sense when you look at the internals of the default constructor in DefaultPluginLocator:

    Here is a simplified version showing what it's doing:

    string path = null;
    Assembly executingAssembly = Assembly.GetExecutingAssembly();
    if (executingAssembly != null)
    {
        string p = Path.Combine(Path.GetDirectoryName(executingAssembly.Location), "plugins");
        if (Directory.Exists(p))
        {
            path = p;
        }
    }
    Assembly callingAssembly = Assembly.GetCallingAssembly();
    if (path == null && callingAssembly != null)
    {
        string p2 = Path.Combine(Path.GetDirectoryName(callingAssembly.Location), "plugins");
        if (Directory.Exists(p2))
        {
            path = p2;
        }
    }
    if (!string.IsNullOrEmpty(path) && Directory.Exists(path))
    {
        this._systemPluginsDirectory = path;
        this.CreateThirdPartyPluginsDirectories(plugins, packages);
        return;
    }
    throw new PluginFrameworkException("No Application specific plug-in directory found.");

    As you can see the ctor calls

    Assembly.GetExecutingAssembly();

    and

    Assembly.GetCallingAssembly();

    and if your executable is located outside of the Studio4 that will cause the code to throw the PluginFrameworkException since it cannot find the plugins directory.

    I can only guess that your older plug-in does not trigger the call stack that starts with Sdl.ProjectAutomation.FileBased.FileBasedProject.CheckLicense() which is why it works.

    The only workaround I can think of is figuring out what is triggering the Sdl.ProjectAutomation.FileBased.FileBasedProject.CheckLicense() call and maybe you can workaround that, but it might be difficult...

  • Hi Jesse,

    Thanks for your response.

    Both of these projects (the existing, working application and the one which I'm now trying to develop) are not plugins but are instead standalone applications. Both have

    var project = new FileBasedProject(projectInfo);

    I.e., they both use the same constructor.

    I wonder if a different option in the projectInfo could make the difference?

    I suppose I could get the whole Studio-AssemblyResolver project (rather than just the compiled assembly), reference that and step through the code from both projects to see what is the difference between them.

     

    [Incidentally, I would have replied sooner but was expecting the forum to notify me when any replies had been posted. Such notification has still not arrived.]

  • Hi Andrew,

    I dug a little bit deeper. Right now I found out that

    new FileBasedProject(projectInfo)

    calls FileBasedProject.CheckLicense(),
    so that means there is no difference there.

    Is there any differences before you call new FileBasedProject(projectInfo)?
    I cannot think of any other reason why it would be different.

  • 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.

  • Thanks for the explanation, Romulus.

    I'm still puzzled though, and for a couple of reasons.

    1. Why does one of my standalone applications work (i.e., pass the license check) when run on my local computer while another fails the license check on a line of code which is also used in the passing application?
    2. I don't have any 3rd-party plugins. I'm aware that many of the out-of-the-box features in Trados are supplied via internal SDL plugins, so if my problem is caused by a plugin which is not passing the license check then it must be an SDL-provided out-of-the-box plugin, which then circles back to my first question: why would this plugin(s) work for one of my applications but not another?
  • 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

  • Hello Rieko,

    have you ever been able to resolve this problem? And if so, how? We get the same exceptions for some of our customers, but not all. We have already completely reinstalled Studio 2017 but had no success.

    Greetings,
    -Stephan Tandel-
  • If you've developed an application that uses ProjectAutomationAPI then you should deploy it under the Studio folder otherwise you will receive the error.