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.
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.
can we store viewstate other than in hidden field in asp.net
Yes. There are a number of different implementations out there for moving ViewState to Sql Server, for example. But often, when you want to do this a better option is to make a few smaller changes to your site to reduce the number of postbacks and the amount of information placed in viewstate in the first place.
Try this: Moving ViewState to the Session Object and more Wrongheadedness
How can we disable the Control State of dynamically created controls in Asp.Net 3.5?
You can't. You can disable viewstate but not control state.
You can't, this is one of the big advantages of MVC over WebForms - you get to move away from being dependent on bloated ViewState and ControlState blocks on every page.
ControlState is used by lots of WebForms server controls - you can't disable it, but you can avoid it by writing your own ones that render their own HTML.
OK, I generally agree with Rune that you can't do it, but just a random thought:
To use control state, a control explicitly has to call
Page.RegisterRequiresControlState(this);
on Init. If the controls you add to the page do this, and you reverse it after you've added them to the Controls collection what happens? Can it be reversed?
This sounds a bit stupid, but you might explore.
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!
Is there a way to avoid postbacks with gridview every time a row is added to it?
In other words, can I store the DataTable on the client and pass it on to the server control when I am done to save, rather than do postbacks every time the row is added?
I searched and searched....all I could find was web services, JSON, and I have a feeling it's redundant here...it's a simple task I am sure everyone had to do at some point.
Can anyone shed some light on this?
There is no avoiding postbacks if you're dealing with a standard ASP.NET GridView that utilizes ViewState.
You can however, disable ViewState and manually (programmatically) render the control on every page load. This will let you control every aspect of row creation/removal/updates, but you'll have to do it all manually. And yes, you'll utilize AJAX to read from or update on the server.
I don't konw of anything that lets you do that with the gridview out of the box, except the UpdatePanel, but that doesn't really count. If you want to implement I a full AJAX grid I would look into using the ListView Control, which will give you much more control over the resulting html.
Heres a great article from MSDN Magazine http://msdn.microsoft.com/en-us/magazine/cc337898.aspx