When EnableViewState = false, GridWeb is unable to load its instance from Session during subsequent requests. Re-enabling ViewState resolves the issue immediately.
Questions:
Does Aspose GridWeb require ViewState to be enabled?
Is there a supported way to use GridWeb with ViewState disabled?
Are there additional settings required to persist the GridWeb instance in Session when ViewState is disabled?
Is this behavior expected or a known limitation?
Could you please advise on the recommended approach?
Thank you for providing the code snippet and the environment details regarding this issue.
We have successfully reproduced the error you described. Our investigation confirms that when ViewState is disabled, the GridWeb control encounters a failure while attempting to restore its state from the Session during postback, leading to the “Cannot load GridWeb control instance from session” message.
While we work on addressing this behavior in the GridWeb control, we suggest you also evaluate our GridJs component. GridJs is a more modern, lightweight, and client-side focused spreadsheet solution that does not rely on ASP.NET ViewState, making it an excellent alternative for web applications requiring high performance and compatibility.
the document:
the demo:
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CELLSGRIDJS-2583
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
We would like to seek your advice regarding the recommended deployment approach for GridWeb in a load-balanced environment.
Our application is deployed on multiple web servers behind a load balancer, with the ASP.NET Session configured to use a SQL Server (database) session state provider.
Based on your previous explanation:
When ViewState is disabled, GridWeb fails to restore its state from the Session and throws the error:
“Cannot load GridWeb control instance from session.”
However, when ViewState is enabled, the page fails to load and we encounter the following exception:
PX.Common.PXSerializationException
This appears to occur because our application framework serializes the page state, and the GridWeb control may not be compatible with this serialization mechanism.
Given these constraints, could you please advise:
What is the recommended way to use GridWeb in a load-balanced environment where Session State is stored in SQL Server?
Does GridWeb officially support SQL Server Session State or other out-of-process session providers?
Are there any configuration changes or best practices that would allow GridWeb to function correctly in this scenario?
If GridWeb requires InProc Session or ViewState to function properly, is there any supported workaround for applications that cannot use these options?
We would appreciate your guidance, as our production environment requires support for load balancing and distributed session management.
Thank you for following up. We understand that you are encountering serialization issues when using SQL Server Session State in a load-balanced environment, alongside the session restoration error when ViewState is disabled.
Regarding the PXSerializationException, this typically occurs because some internal objects within GridWeb are not marked as serializable, which is a requirement for Out-of-Proc session providers like SQL Server. Our development team is currently investigating this behavior to improve compatibility with external session state management.
As a temporary workaround for load-balanced environments, we recommend using Sticky Sessions (Session Affinity) on your load balancer. This ensures that all requests from a specific client are routed to the same server instance, allowing you to use InProc session mode. This configuration avoids the serialization requirements of SQL Server session state and bypasses the current limitations regarding ViewState restoration.
We will continue to track this issue and will update you as soon as a more permanent fix or a specific configuration for SQL Server session state is available.