we passed from Cells 7.3.2.4, Slides 6.7.0.0. Words 11.8.0.0 to respectively 7.4.2.0,7.1.0.0,13.1.0.0 and since then we noticed an increased loading time of the assemblies.
It is sure related to customer machine having a reduced set of certificates, and probably the true slow down is during the SetLicense of Aspose, than the loading itself. What I noticed is that after loading the assemblies, the program scans all the certificates on the machine and then tries to connect to internet trough the proxy (probable to fetch some certificates from network). This is so slow that the start time passed from few seconds to more than 40-50 seconds on the same machine.
We are having a set of screenshots of customers certificates and two Process Monitor logs (x64) and we can give this to you under NDA, otherwise we are not free to post them around.
In the meantime if you knows about potential “crystallographic” changes during license verification or assembly loading that could be the culprit.
Thanks for your inquiry. Unfortunately, I have not completely understood your query. It would be great if you please share some more detail about your query along with your working environment. We will investigate the issue on our side and provide you more information.
What environment are you running on?
OS (Windows Version or Linux Version)
Architecture (32 / 64 bit)
.NET Framework version (or Java version )
Please supply us with the code from your application that is causing the issue
I have made this forum thread as private. Now only you and Aspose members can access this thread.
that is the problem: we don’t know which code slows down the start of the application because in our test systems we don’t have it.
In customer systems instead the previous versions load wonderfully and the new ones are slow. As I said I think it is all related to the SetLicense code
var licenseStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(“NPrinting.Reporting.ReportingApp.Powerpoint.Aspose.Total.lic”);
if (licenseStream!=null)
{
try
{
license.SetLicense(licenseStream);
licenseloaded=true;
}
catch
{
}
}
Our code at the start of the application loads all the needed assembly and in the case of Aspose ones it is also setting the license. I don’t think the slow down is related just to the loading but more probably to the license setting because what we noticed in the Process Monitor log is that it begin to scan for certificates and then (probably because a certificate is missing) it tries an network connection to acquire something (probable the missing ones). The previous versions of aspose are not doing this, so I suppose there is a change in the way the license is tested or something like that.
I can give you all that I could collect from customers related to the problem. The Logs are in Process Monitor x64 format and are logging the start with and without aspose.slides and aspose.words, the screenshots are the certificates that the cusomer kept, after deleting almost all of them. All these are under NDA.
As I repeat I think the slow down is generated by SetLicense.
I have observed the issue highlighted by you where by you have shared that you suspect that the loading of license can be cause of Slowness. I may request you to please verify on your by working with specified old and new product versions belonging to Aspose.Words, Slides and Cells independently that in actuality which product is responsible for slowness. You may please also share the statistics with us for old and new product versions for all mentioned products. You have shared the part of code where by it is related to PowerPoint loading. Does this mean that the issue is with Aspose.Slides only or it includes license loading issue with other products as well.
Please share the sample application with us reproducing the specified along with complete environment details and statistics achieved on your end with both old and new versions. I will verify the issue further on my end in light of information shared by you.
sorry Mudassir, as I said, what I attached is everything that we can collect and observe.
The problem is sure related to Aspose.Slides, because when we use the SetLicense we are doing it to Aspose.Slides as first and exactly after this the slowdown began in the new version. With the old version, everything was ok.
We are not able to collect something else, because the system is our customer system, it is a bank, and we are not able to further collect more informations apart what I could collect.
Please, contact your developers team and ask them if they changed certificates or the way they control the license.
I like to share that I need the statistics in terms of performance for loading the license in terms of time consumed for two versions of Aspose.Slides for .NET mentioned by you. This thread is private and you can share the requested data. You can even shared the data via private message as well by following the guidelines mentioned here. I am also trying to reproduce the issue by generating sample application on my end and will share my findings with you shortly.
I have developed a sample application on my end for loading the Aspose.Slides license using Aspose.Slides for .NET 7.4.0 and Aspose.Slides for .NET 6.7.0. It took 0.24 seconds for me to load license using both version of API’s and I have not been able to reproduce the issue. I have performed my testing on Core I7 machine with 8 GB ram and Windows 7 x64. For your kind reference, I have attached the sample application.
I request you to please share the sample application that you are using on your end to reproduce the issue and also providing the statistics achieved on your end by using both versions. Please also share the environment details where by you are using Aspose.Slides on your end. We really wish to help you out but need your cooperation in this regard to proceed further.
in testing your sample did you delete all the certificates from your machine until reaching the ones that our customers kept installed (as per the screenshots that i attached previously)?
Right now, I think to develop a small delphi win32 app that will load aspose.cells, aspose.slides and words in a way similar to what we are doing right now, to see where is the problem.
I also like to share that we have just released Aspose.Slides for .NET 7.5.0 as well and you can try the mentioned version on your end. That will be really appreciable, if you may please give a try on your end and provide us with a sample project along with statistics achieved with use of latest version, if the issues still persist.
I attached the source program that I tested in customer in a configuration similar to what we are using for our product. I couldn’t attach part of the sources of our product, so you can’t compile it, but you can compile the assembly adding back an aspose.total.lic in the root folder of each assembly project.
If you will run the program using as parameter “old” or “new” or another folder name, it will make the assembly load the aspose.slides and aspose.words from there.
In few words, the exe programs scan plugins for assemblies that containes the static class ModuleInitializer and calls their Run method, then you can see the run method create a new License and set it from the in corporated resource.
In customer machine, this code took always (no metter the version of slides and words) 10 seconds. In my development machine just 200ms. The only difference between this program and our official product is that before them we are doing the same for Aspose.Cells and this can explain the different that we are seeing between old and new version of slides and words. But the end it doesn’t matter, 10 second to set a license is still too much, seen that in my machine it takes just 200 ms and that the customer pc is far more powerful than mine (mine is a virtual machine with three cores and 3 gb of ram always full).
The fact is that, as I attached before in previous screenshots, the customer maintained in a different way the list of certificates and it is seen that Aspose when checking the license probably is checking also the Authenticode on the assemblies? Probable while doing it, it tries to fetch the missing certificates from the network slowing down the start of the program. We had a similar problem with our product and we solved it verifying just that the signature of the product is valid instead of checking also the validity of certificate path with the central store of Windows.
I attached again the process monitor logs that shows you what’s happening.
I hope you can solve the problem now. I remind you that I think that the problem is mainly caused by the removal of almost all root certificates in the window store.
Thanks for sharing the details. First of all, I like to make a small correction that my name is Mudassir instead of Mussandir. :). I have created an issue with ID SLIDESNET-34379 as investigation in our issue tracking for further investigation of issue. I also like to request you to please share the details of your production environment where by you are having issue as you have stated that you are not able to reproduce the issue even on your machine. So, it turns out that the issue is in fact not end on Aspose.Slides end probably. Please share the requested information with us. I will share the further information with you as soon as it will be shared by our development team.
sorry for the mistake, I read it once and I tought I read it correctly
We didn’t try to reproduce the problem on our side because it was clearly an Aspose problem and the only thing I could think of was that the License system of aspose is forcing windows to contact internet for missing certificates. As I posted before in Upgrading Cells- Slides and Words generated long loading time of Assemblies you can see clearly that there are plenty of missing certificates and if you give a look to the Process Monitor logs you can see clearly that while scanning them it is then trying to contact an internal server in the customer network.
We had this problem in the past too with our system and we changed it to a softer version changing the way we were calling the WinVerifyTrust Win32 API.
The customer doesn’t have a special machine, it is a standard Windows 2008 R2 on a virtual machine that is more powerful than mine. If you really would like more detailed specifications I will look for them, but seen the PM log they dosn’t matter… the program slows down because of internet connection to fetch certificates not because of slow pc or strange Windows. If you will ask me which particular specifications you are wanting to know I will ask the customer.
Thanks for sharing the additional details. I have appended the information with the concerned issue in our issue tracking system and will share the feedback with you as soon as it will be shared by our development team.
I am going to address your query with respect to the Aspose.Words component. Well, it could be that the problem occurs because you are using digitally signed assemblies of Aspose.Words from either net2.0_AuthenticodeSigned or net3.5_ClientProfile_AuthenticodeSigned folder. Please note that digitally signed assemblies come with an Authenticode and Signed assemblies may load slower than those without Authenticode.
Also, during the first time you run a digitally signed assembly, the .NET Common Language Runtime tries to determine whether the signature is valid or not. It does so by contacting thawte or verisign servers. In case you don’t have an Internet access on the machine you’re getting this problem on, the time out or delay can occur because thawte or verisign servers cannot be reached (this only happens for the first time after which the assembly is allowed to continue without any warning). Please visit the following link to learn more about it:
Our development team has observed the issue specified in detail. They have looked process monitor logs. This delay is nothing to do with a license checking. Production machine doesn’t have an access to the Internet, so CLR unsuccessfully trying to download certificate revocation list. It does so on any attempt to load a signed assembly, and will try until certificate revocation list will be updated. For detailed description and ways to fix please read:
