Aspose.PDF issue with MEF container

Aspose.PDF Product Family
1

Hi,


I downloaded the latest Aspose.PDF from the nuget site: NuGet Gallery | Aspose.PDF 23.11.0

Our web application uses MEF container for dependency injection, something like below:

RegistrationBuilder registrationBuilder = new RegistrationBuilder();
registrationBuilder.ForTypesDerivedFrom().Export();
registrationBuilder.ForTypesDerivedFrom().Export();
registrationBuilder.ForTypesDerivedFrom().Export();
try
{
((AggregateCatalog)this.mefContainer.Catalog).Catalogs.Add(new DirectoryCatalog(“bin”, registrationBuilder));
}
catch (ReflectionTypeLoadException reflectionTypeLoadException1)
{ /*log */ }

The issue is we run into is that the MEF fails with exceptions like:
2017-01-31 15:46:37.2204|ERROR|ServiceHost|Loaded Exeception Type FileNotFoundException, Message: Could not load file or assembly ‘Aspose.Foundation, Version=17.1.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56’ or one of its dependencies. The system cannot find the file specified.
2017-01-31 15:46:37.2204|ERROR|ServiceHost|Loaded Exeception Type FileNotFoundException, Message: Could not load file or assembly ‘Aspose.JavaScript, Version=17.1.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56’ or one of its dependencies. The system cannot find the file specified.
2017-01-31 15:46:37.2204|ERROR|ServiceHost|Loaded Exeception Type FileNotFoundException, Message: Could not load file or assembly ‘Aspose.Font, Version=17.1.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56’ or one of its dependencies. The system cannot find the file specified.

It appears Aspose.PDF is referencing these and other assemblies, which causes MEF to error out. Screenshot attached for your reference.

Your nuget package does not provide these assemblies, so I presume they are not really needed for the functionality to work. On the other hand, these references present cause our application load to fail, and we use an enterprise-wide hosting library, so we cannot quickly move away from the MEF setup.

Would it be possible to either
a. Provide the additional libraries, though they may not have any functionality within them (I cannot create them for our consumption as they are signed assemblies)
or b. provide us an updated Aspose.PDF with these assemblies not referred?

Thanks!

2

Hi there,


Thanks for your inquiry. After initial investigation we have logged a ticket PDFNET-42214 in our issue tracking system for further investigation and rectification. We will keep you updated about the issue resolution progress.

We are sorry for the inconvenience.

Best Regards,
3

Hi Tilal,


Thanks for the update. Can you give a tentative timeframe for when this fix might be available? We have work planning to start but since our service hosting cannot consume the library, we are blocked.

A interim workaround would be fine too to get us started. E.g. what I suggested earlier about skeleton assemblies for the referenced libraries, so that MEF container we use will see all is good with the aspose set of libraries.

Thanks!
4

Hi there,


Thanks for your inquiry. I am afraid we can not share any timeline with you at the moment, as we have recently logged the issue and it is pending for investigation. As soon as our team completes the issue investigation then we will be in a good position to share an ETA or some workaround. We will keep you updated about the issue resolution progress.

Thanks for your patience and cooperation.

Best Regards,
5

Hi there,


Thanks for your patience. Our product team has investigated above logged issue and found it is not a bug. MEF could have a problem because it uses the light version of reflection API which does not honor module initializers. Thus the embedded dependencies could not be resolved during MEF’s composable parts introspection. To workaround the issue, please consider to preload the assembly beforehand or register it as AssemblyCatalog.

Please feel free to contact us for any further assistance.

Best Regards,

6
Hi Tilal,

Thanks for the update, I wanted to understand your suggestion better. Your recommendation is about changing the MEF load process to treat the Aspose PDF assembly differently. Please correct me if I got this wrong. The catch is that library hosting our WCF service is from a different team and its source is not under our control.

Thanks
7

Hi there,


Thanks for your feedback. Yes we have recommended to change load process of Aspose.Pdf dll. However we are further discussing issue with the product team and will update you accordingly.

Best Regards,
8

Hi there,


Thanks for your patience. We have double checked with our product team, you have to change Aspose.Pdf assembly loading. You may contact your other team to preload the assembly beforehand or register it as AssemblyCatalog.

Best Regards,
9

Thanks for the update Tilal. As I mentioned earlier, as the hosting component is outside our team, I cannot make that change. The current approach I have gone ahead with is to maintain the Aspose.PDF assembly outside the bin folder and referred using the element within web.config. This seems to work ok. Please let me know if you see any potential impact.


Thanks!
10

Hi there,


Thanks for your inquiry. It is good to know you have found a workaround. I am coordinating with the product team and will update you with the findings.

Best Regards
11

Hi there,


Thanks for your patience. We have discussed your solution with the product team and they confirmed that API will work in shared approach and apparently no potential impact. Please feel free to contact us for any further assistance.

Best Regards,