Hello,
Our client is using combit LL27 from NuGet and are expreriencing same issue. Slow startup of LL and slow pdf generation.
We’re feeding data to report manually using AddFromObject which for a POCO object takes up 7-8 seconds. One invoice printout takes 30 seconds.
The customer migrated their platform to Windows Server 2019 / Windows 10 on Citrix. The programming language used is C# on .NET Framework 4.8.
I hope somebody can point me in the right direction.
Is there any way to change the data supply to using an ObjectDataProvider? Most performance issues with object data sources turn out to be caused by complex hierarchies that tend to be deeper than expected. This can be fine-tuned with the provider.
If that is not feasible, could you share the definition of your POCO object? We could then try to reproduce the issue.
I will have to investigate migrating to ObjectDataProvider. The solution is from LL16! And updated over the years to new LL versions.
My problem was showing when the OS was upgradet from 2008 R2 to 2019.
The POCO definition og my object is:
ref Invoice
string cardCodeField
string cardNameField
string addressField
string shipToCodeField
string address2Field
string cntctCodeField
string cntctNameField
string numAtCardField
string currencyField
string docNumField
string docStatusField
System.DateTime docDateField
System.DateTime docDueDateField
string docTypeField
string slpCodeField
string slpNameField
string commentsField
double docTotalField
double docTotalFCField
double vATField
double vATFCField
double discPrcntField
string trnspCodeField
string trackNoField
string blockDunnField
string paymGroupField
string paymGroupNameField
string projectField
string paymentRefField
string indicatorField
string licTradNumField
string comesFromField
string ownCompanyField
string ownPhoneField
string ownFaxField
string ownTaxIdField
string ownPBSNumberField
string ownDflBnkCodeField
string ownDflBnkAcctField
string ownDflBranchField
string ownStreetField
string ownZipCodeField
string ownCityField
string vATCodeField
string sWIFTField
string iBANField
List<InvoiceLine> linesField
dynamic OrgInvoice
dynamic OrgCreditnote
InvoiceType (enum) Type
string BaseInvoice
int errCode
string errString
string VirkInfo
bool IsPerson
string AddressCountryISO
string AddressCity
string AddressZipCode
string AddressStreet
string Address2Country
string Address2City
string Address2ZIP
string Address2Street
string CustomerRef
string PurchOrderFormNum
ref InvoiceLine
InvoiceLineType lineTypeField
string discLineField
string printLineField
double discountPriceField
string discItemCodeField
string itemCodeField
string descriptionField
double quantityField
string currencyField
double priceField
double priceFCField
double lineTotalField
double lineTotalFCField
double discPrctField
double vATField
double vATFCField
string textLineField
At first glance, it doesn’t look that complex. It should not take up to 7-8 seconds.
To be able to analyze the behavior more precisely, we would like to ask you to create a minimized sample for us. Please create a new Supportcase and upload the sample.
We will of course share a possible solution for all users here in the forum.
Thank you very much.
I tried this weekend to make a prototype, and actually I have some properties in the “POCO” that extend into another system (including web requests, but these properties aren’t used in LL).
In LL26 on Windows 2008R2 this wasn’t an issue.
In LL26 and LL27 it becomes an problem. How does LL extract the data from the POCO?
And is it possible for me to hide properties by modifier for LL?
I recognize that Windows 2019 includes Defender with real-time protection and that no exclusion is set up for my program.
If LL reads the not-so-POCO properties and thereby makes web requests it could be Defender scanning all the time.
By the way I can confirm my plain POCO is read immediately in LL in the test project I would have send to you if that wasn’t the case 
You could add the Browsable(false) attribute to the properties in question 
.