I have a page that has a really huge viewstate (>300KB). ...Yeah, I know. I've narrowed this anomaly down to one user control, but am having trouble determining what exactly that control is putting in there.
I've overridden SavePageStateToPersistenceMedium in the page, but am not great at working with the viewstate object passed in. Could I pass it in to some recursive function that would print out everything that's in the object?
I've tried using freely available viewstate decoders, but none have worked. I always get errors when it attempts to deserialize the viewstate.
I'm pretty much looking for a code snippet here.
Thanks,
Mark
Thanks for the traceing suggestion, esp. the trace.axd thing. But that still only tells me how big the controls are, it doesn't tell me what's in the viewstate. I want to be able to see if there are objects that I'm erroneously serializing to viewstate.
I used to use trace.axd. It lists each request and dumps the contents of the viewstate. You'll have to enable tracing in web.config. If you've got lots of requests you'll want to update the cache size to more than 10.
Fritz Onion's ViewState Decoder is what you need!
I would just add Trace="true" to the page directive on your local machine. The control tree section will show you the viewstate size of each control.
Regarding the issue with viewstate decoders, you might have the viewstate encrypted. Check this post with comments/links on it: http://www.testingreflections.com/node/view/3424.
Update: try turning it off completely on the pages element in the web.config:
<pages ... viewStateEncryptionMode="Never" ... />
View the view state section in this msdn doc How To: Configure MachineKey in ASP.NET 2.0
Related
This is 10KB in my HTML source:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTEyOTAwODE4Nw9kFgJmD2QWAgIDD2QWBGYPZBYEAgEPDxYCHgdWaXNpYmxlaGRkAgIPZBYIAgEPFgIfAGdkAgMPDxYEHgRUZXh0BQNUb20eC05hdmlnYXRlVXJsBQt+L3VzZXJzL1RvbWRkAgUPFgIfAQUFMSwzMjZkAgcPDxYCHwIFCH4vTG9nb3V0ZGQCAg9kFgQCEA9kFgICAQ8WAh8BBXk8YSBhZGR0aGlzOmRlc2NyaXB0aW9uPSJTaGFyZSBTY2lycmEiIGFkZHRoaXM6dXJsPSJodHRwOi8vMTI3LjAuMC4xL3NjaXJyYW5ldy9ibG9nLzM5L3dlZWVlIiBjbGFzcz0iYWRkdGhpc19jb3VudGVyIj48L2E+ZAIUD2QWEAIBDxYCHwBnFgICAQ8WAh4EaHJlZgUifi9BZG1pbmJsb2cuYXNweD9hY3Rpb249ZWRpdCZJRD0zOWQCAw8WAh8BBQ0xNyBBcHJpbCAyMDExZAIFDxYCHwEFBVdlZWVlZAIHDxYCHwEFDjxwPm9ya2dyZ3I8L3A+ZAIJD2QWAmYPZBYCAgMPFgIeC18hSXRlbUNvdW50AgMWBmYPZBYCAgEPDxYGHwEFBEJsb2ceB1Rvb2xUaXAFH090aGVyIHJlc291cmNlcyByZWxhdGVkIHRvIEJsb2cfAgULfi90YWdzL2Jsb2dkZAIBD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMR8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMR8CBRJ+L3RhZ3MvY29uc3RydWN0LTFkZAICD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMh8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMh8CBRJ+L3RhZ3MvY29uc3RydWN0LTJkZAILDw8WBB8CBQt+L3VzZXJzL1RvbR8BBQNUb21kZAINDw8WBB8CBRh+L2Jsb2cvMzkvd2VlZWUvY29tbWVudHMfAQULMTAgY29tbWVudHNkZAIPD2QWAmYPZBYGAgIPFgIfBAIKFhRmD2QWDgIDDw8WBB4IQ3NzQ2xhc3MFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQeBF8hU0ICAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzozNToyNC45MjAwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjM1OjI0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQeCEltYWdlVXJsBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFoAM8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPndlZiB3ZSBmIHdmZTwvZGl2PjxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+cGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGg8L2Rpdj48ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPnBpbGx1dcO6w7ogdHQgdCBoIHRoIHRoIHRoIHRoIHRoPC9kaXY+PGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPkNvbW1lbnQgYnkgPHN0cm9uZz5Ub208L3N0cm9uZz48YnIgLz48YnIgLz5waWxsdXXDusO6IHR0IHQgaCB0aCB0aCB0aCB0aCB0aDwvZGl2PmQCAQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjNUMTc6Mjk6MjkuMjQ3MDAwMCI+MjMgQXByaWwgMjAxMSBhdCAxNzoyOToyOTwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUyPGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPnJlZ2c8L2Rpdj53ZWYgd2UgZiB3ZmVkAgIPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI4OjIzLjM2NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjg6MjM8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFH1tRVU9URV1yZWdnWy9RVU9URV13ZWYgd2UgZiB3ZmVkAgMPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI3OjU1Ljk1NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjc6NTU8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFdDxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+T2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzITwvZGl2Pk5vIHByb2JsZW1vZAIED2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzoyNzoyNy45ODcwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjI3OjI3PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBXA8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPk9rIG5pY2Ugb25lIDotKSBMb3ZpbmcgdGhpcyE8L2Rpdj5UaGFua3MhZAIFD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQxNDozOToyMy4xMjAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDE0OjM5OjIzPC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBR90cmhoIHJ0aCAgcnRocmhoIHRyIGhydCBocnQgcmh0ZAIGD2QWDgIDD2QWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDozOTozNC45NDAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjM5OjM0PC9hYmJyPmQCAw8PFgYfAgURfi91c2Vycy9DaGVlc2VCb3kfBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFCUNoZWVzZUJveWRkAgUPDxYEHwIFEX4vdXNlcnMvQ2hlZXNlQm95HwUFJkNoZWVzZUJveSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyL2ZjMjE2Nzc4ZjYzOGM4N2FmODZhNjI0MWNhMzZiM2EyP3I9cGcmcz04MB8FBRRDaGVlc2VCb3kncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBTFMb3ZpbmcgdGhpcyBibG9nIHBvc3QgdGhhbmtzIGZvciBpdCwgKzEhICBHbCBsb2whZAIHD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDoxMzowNC44NTMwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjEzOjA0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBRdlZyBlICBnIGdlIGcgZyBnIGcgZyBlZ2QCCA9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjFUMjM6MzA6NTAuNjMzMDAwMCI+MjEgQXByaWwgMjAxMSBhdCAyMzozMDo1MDwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUcT2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzIWQCCQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjBUMDA6MDE6NDcuNjY3MDAwMCI+MjAgQXByaWwgMjAxMSBhdCAwMDowMTo0NzwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUgcGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGhkAgYPZBYCAgEPDxYCHglNYXhMZW5ndGgC9ANkZAIIDw8WAh8AaGRkZAx0/0RvMYX4SKMMjV5pXc+cjNqDEEepI0JWzIxpxOzG" />
This represents ~50% of the entire size of the page.
Why does it do this, why so long? Can I do anything about it? It's bad for mobile users.
What is this view state anyway and how to mitigate its size
In Asp.net WebForms every control saves its state because HTTP protocol is stateless and Asp.net WebForms pages bypass that by saving every control's state in this Base 64 encoded string. This is the only way for Asp.net framework to know whether some control's value has changed or not. But... This automatically means that static controls that don't get POSTed back to server (like label for instance) don't need to save their state. You can always set their EnableViewState="false".
Unfortunately this can't be set without any other code changes on other controls, that do get POSTed back (every server-side control that renders some sort of an input in HTML). This basically means that setting EnableViewState="false" on page level (within #Page directive) will have consequences that are seen as controls loosing their values, controls not firing certain events etc.
So, the more server-side controls you have the larger it will get (without turning it off on certain controls).
But I wouldn't worry if its size is 10k. That will go back and forth rather fast and painless. You will have problems when it gets much larger. I once worked on a project and we had an issue with a certain page (done by less experienced developer) where view state grew over 1MB. Imagine that. What a slowdown!
How to turn it off completely on page level
When you turn view state off on page level you have to be aware that certain controls that were loaded (or better said data bound) in on of your page's events, will have to be reloaded each time your page gets POSTed back at server. Otherwise they will show up as empty when your page gets back to the client.
Your server controls are filling the ViewState with data they will need on postback. If your page does not postback you can just disable the ViewState for the page.
To disable ViewState for the page you can just add EnableViewState="false" to the #Page directive. Please be aware you should only use this as a solution if you are 100% sure the page does not postback.
You also might want to check this MSDN article to get a better idea of what the ViewState does.
Disable viewstate for static controls, like a gridview.
Check out this question for more info:
If you are concerned about the viewstate on the client side, then think about storing it on the server side. Perhaps in a session variable. Take a look at this article as there is statistical comparison given. Download the solution and check out how to store it on the server side.
An Analysis of Keeping ViewState out of the Page
This article explained it neatly to me in the past: Taking a Bite Out of ASP.NET ViewState.
Basically viewstate's on by default and, depending on which controls you use, it can get out of hand pretty fast. Especially data controls like the gridview are responsible for massive injection of viewstate. You can disable that on a per control basis by setting the EnableViewState property to false. Be careful however as taking out viewstate might also take out functionality of the controls. So do it one by one and test test test.
Another way, and likely better for mobile, is to make use of ASP.NET MVC instead which doesn't have to deal with automatic viewstate injection.
I have a page which contains a user control. The structure of the page is as shown below:
Incase your not able to see the above image, please check it at http://i54.tinypic.com/2r4id5f.jpg Now, apart from the contents of the UserControl, I'd like to cache the entire page. I tried using the OutputCache attribute in the .aspx page, however it caches the contents of the UserControl as well.
Kindly let me know how will I be able to cache the contents of the page except that of the user control.
Thanks in advance.
I think you can use the asp.net Substitution control to achieve this. Here is a link to ScottGu walking through an example.
The basic idea is that you cache you whole page as per usual, but mark parts for substitution that can be replaced for each request.
I think you are looking for VaryByControl. Also check out this post on fragment caching
Look at using substitutions.
This should help
However, the snag is, since substitution is done outside of the Page lifecycle, you can't render a user control for your substitution. You have to write a method that returns a string for the substitution. But this may work for you.
Have you tried adding the #OutputCache to both the usercontrol and the page but the usercontrol set the varyByParam="qsvalue;postvalue" where qsvalue is a generated query string you make random for every call of the page and postvalue is the same for postback.
The user control will still get cached, but in theory it should never get a chache hit as the qsvalue/postvalue is always different from that cached. It may not scale well - best set duration to the minimum as well, to prevent large numbers of them building up in the cache.
I have a couple of pages that are bulky due to the viewstate. I have following question:
is there any tool that can track viewstate of individual control on page and tell me which control is taking maxm viewstate
also can i know which controls viewstate is not being used and disable it?
There are some Viewstate Utilities listed here http://blogs.msdn.com/rextang/archive/2007/05/25/2868250.aspx. I always store Viewstate in the database rather than send it back and forth over the internet. Example Code here http://www.componentworkshop.com/blog/2009/06/27/advanced-net-storing-viewstate-in-a-database
You can turn on trace on the page and that should show how much viewstate is used for each control.
I have no good answer to your second question, but one rule of thumb I use when i develop webforms is that i set EnableViewState=false immediately after I've created an Ascx.
That way I can turn it on when I actually need it and not wonder if my databound controls uses alot of viewstate.
I have a page which contains some search fields to query a database, and display results. The viewstate is required to retain the lists of items in dropdowns.
Everything works fine in Firefox (3) & Chrome, but fails in Internet Explorer, but only sometimes (certain actions, such as resetting the form, which really just does a response.redirect with some querystring parameters)... what happens in the Viewstate gets dumped on the URL, and an error page is thrown.
Has anybody come across this before? Perhaps some pointers as to what might be causing this to occur in IE?
Thanks heaps,
greg
UPDATE:
On further investigation, i have determined that the actual error is this:
"Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. "
Some more information that might help: This is caused by a user control that is being hosted in a content management system (Umbraco), which might have something to do with why the viewstate is being passed to the page (as the control is contained within a greater page in the CMS). I will investigate this a little further, but any other suggestions would be much appreciated.
cheers
greg
UPDATE 2:
Can anybody suggest why this only happens in IE (and not in FF or Chrome)?? Seems hardly likely its an issue with controls changing or machine keys or other suggestions I've read around the place, if other browsers can deal with it fine.
Any ideas what IE does differently that could cause this failure??
SOLUTION:
Turns out it was a really silly problem - I was using the wrong master template in the CMS, and therefore had 2 form tags. Remove extra form tag, problem solved!
Thanks heaps to bendewey for helping me solve this problem (see the comments in bendewey's post).
That's 4 hours of my life i'd love to get back... but glad i can move on now. Thanks again Stack Overflow community :)
It seems a bit wierd that your viewstate is posting to the the Url. The would happen if you had some custom form tag that was using a GET method instead of the default asp.net page level form tag.
If you need a form tag with the GET method I would set EnableViewState="false" on the Page declaration and setup some sort of list caching. Here is a sample, but you can find much better samples online (specifically ones that do double check locking). This way you can call this every postback and not worry about storing anything in the viewstate.
List<string> getCachedFields()
{
var searchFields = Cache["searchFields"] as List<string>;
if (searchFields == null)
{
searchFields = GetFieldsFromDbOrSomewhereExpensive();
Cache["searchFields"] = searchFields;
}
return searchFields;
}
We've fixed this problem using this blog's suggestion. Please have a look at it ...
I had to remove EnableViewStateMac="false" from the <pages> element to avoid the error in IE.
On my journey into the depths of custom ASP.NET control development I am obviously getting my head around the ASP.NET PostBack model and how it affects control development.
I understand that controls have no "lifetime" in ASP.NET, and therefore must be re-initialized on each and every page load. We overcome this by persisting the objects values/parameters to the ViewState.
Many articles I read therefore suggest not using PostBack since this can add considerable overhead to the Page. I am not looking for how to disable it, I know that.
What I am looking for is:
What alternatives to we have to using the PostBack model to initialize controls?
I know we could use the QueryString, but that seems awfully messy, and obviously unreliable.
Ideally you could give me an overview of the architecture/design of a different approach and the pro's/con's of it..
Many thanks ^_^
Well, Session State is a server-side solution, with its own pile of cruft to deal with if you want to avoid ViewState altogether. Really though, using ViewState in a custom control is all fine and good - just be picky about what you store - only store deltas from the declared control state, don't store anything you're going to get on postback anyway (e.g. from a DB call), etc.
You have to store the values somewhere, so you are limited to the query string and hidden form fields. If you relate that to HTTP, basically it's either GET or POST parameters.
I suppose you could use cookies, but that would be really messy.
Store your object state in the session context: this will shift the burden of keeping state from the client to the server, which may be acceptable for small-scale intranet apps. For sites on the capital-I Internet, this won't work;
AJAX-enable your control: in this case, only state changes need to be posted back. Picking the right framework is key here; see http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the official MS approach; many others are possible.
If you're truly looking for alternatives to the PostBack model altogether, then I would suggest researching the ASP.NET MVC Framework. I would love to kick WebForms to the curb and do all my stuff in MVC, but alas, legacy code is a tarbaby and rewriting is almost never the answer, so I plug onwards...
I think you still mis-understand controls somewhat. Controls only have the problem you describe when you add them to the page dynamically. If you declare your controls upfront in the aspx code then they build along with the page.