• State Not Answered
  • Replies 1 reply
  • Subscribers 138 subscribers
  • Views 61 views
  • Users 0 members are here
Options
Related

Inexplicable IPublishPostProcessPlugin error: "Cannot initialize plugin XXX."

Eric Bruno

Context
Tridion Docs 14 SP4.
IPublishPostProcessPlugin load failure.

Summary
A custom assembly that includes several IPublishPostProcessPlugin output plugins is not found by the Publish Postprocess Plugin engine.

Details
The assembly started as a .NET port of a prior scripting implementation. It was supplied back in 2023 by RWS Professional Services, when we upgraded to TD14.4.
It was deployed under C:\InfoShare\App\Plugins, as documented, to all 3 environments (DEV, QA and PROD) and has been running as designed since.
All 3 environments are logically and version-wise the same. 

Recently, a change of behavior was required for one of the plugins. We - Edwards Lifesciences - requested the C# project code, added a new plugin implementation, modified the XML Publish Plug-In settings accordingly, followed the documented deployment procedure to update the assembly on DEV, and tested it there. All tests passed. From this we know that a) the assembly implements the required interface, b) the existing and new code works, c) the publish plugin configuration is correct, and d) the deployment procedure is effective.

The time has come to validate (software QA) the new version prior to deploying to PROD. Accordingly, the assembly was deployed, again as documented, to the QA environment (the instance we use for validation). A test was run. It failed.

The core of the error message is always:

Plug-in initialization failed. "Cannot initialize plugin XXX. The plugin implementation with handler YYY implementing IPublishPostProcessPlugin was not found.

The interesting parts of the above are:

  • XXX is not the new plugin: it existed in the initial implementation and remains unmodified by the recent change
  • by design, XXX is executed before ISHRUNDITAOT, excluding a problem with the DITA Open Toolkit

Many attempts have been made to address this: change the .NET build environment, restart services, reboot servers, remove dependencies on external components, build and deploy a separate assembly with just the new plugin, scrutinize logs... all to no avail. The same error message comes back, again and again. 

Oddest but perhaps most interesting: after all these tries, restoring the original assembly - the 2023 dll that runs normally on the PROD enviroment to this day - also fails with the same error message. Exactly what you get if you remove the assembly altogether from C:\InfoShare\App\Plugins.

So as the stack trace says, the PublishPostProcessPluginEngine doesn't find the plugins. How can we get it to see and load them?

We have an open support case with RWS for this - among other things they recommended asking this Community. So here we are - any advice or hint is appreciated. 
emoji
Rate translation
×
Suggest better translation
×
  • 0

    Hi Eric,

    From this description I think there are some problems crossing each other. However by leaving the exact before and after source control project in the black box (understable) we are trying to check the community for similar experiences. The error means that when you deployed it the "host" (so Tridion Docs BackgroundTask executable in this case), is not able to retrieve the MEF-based plugin.

    To inspire, I was thinking off...

    1. When you edited the source code, did you introduce new dependencies? Like a reference to a new helper DLL or upversioned the helper DLLs?
      1. In turn did you deploy these DLLs on DEV but not the same or all of them on PROD. Cross-server folder compare can inspire.
      2. This could also explain that when you restore the old working version DLL but with more recent upversioned helper DLLs that it stops working.
    2. Also compilation. Same platform (.NET Framework 4.8, .NET Standard 2.0 or .NET 6+) and/or the right integration assemblies. I believe .NET Framework 4.8 as Tridion Docs 14SP4 is in essence on the Tridion Docs 14 architecture launched in 2019. For other reading this, the soon to be released Tridion Docs 15.3.0 is on .NET 10 for all services.
    3. While trying to resolve it you might have done changes to the host machine and software that even made the earlier working DLL not work when restored. So restoring to previously known good, so  rolling back to having your 2023 dll working correctly again is important.

    Best wishes,
    Dave
    emoji