• State Not Answered
  • Replies 8 replies
  • Subscribers 7 subscribers
  • Views 9086 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

    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...
  • 0 in reply to Jesse Good

    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.]
  • 0 in reply to Andrew Jameson

    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.
Reply Children
No Data