What happens when you access a query string parameter in a visual web part?
A web part is just part of the ASP .NET SharePoint page, so one could safely assume that it is an ordinary and a correct thing to get the value passed to the page through a query string parameter. The visual web part control has access to the Request object which contains the data passed to the server as part of the request, including query string and form data. Of course the web part control and its child controls rely on the Web Forms View State, and that is also passed with the request.
So, what is the issue? My experience with SharePoint hastaught me that even the smallest things can go wryly wrong.
It took me hours of experimentation and guesswork to realize that creating a visual web part that expects a parameter that is innocently called “ID” makes something under the hood, go haywire. I haven’t reversed engineered SharePoint to realize this, but it’s surely not just an ASP .NET issue. Because of course ASP .NET has no reason to restrict you from using any query string regardless of name.
SharePoint on the other hand, seems to treat a request with an ID in the query string, in a special way. ID is the same query string parameter used to show List Items, such as the pages to Edit and View list items. Request to these pages looks like: http://mysharepoint/sites/mysite/mylist/view.aspx?ID=1. And what I was trying to do was just let one web part page create links to another page with ID passed in the query string, and that page would have another web part that checks for the ID passed.
The problem happens specifically when you request a Wiki page with the ID parameter. In my scenario, I created a couple of web parts and added them to different Wiki Pages. Then they link to each other using the ID parameter. The issue happens even if you don’t use web parts at all. Just create a Wiki page, and add ID=1 to its query string (e.g. http://mysharepoint/SitePages/TestWikiPage.aspx?ID=1).
It simply doesn’t work and one must choose another query string parameter name. Choose for example: MyID or CustomerID instead of ID. Read about another SharePoint mystery here: SharePoint application page 404 error!
Try it! Just create request a SharePoint Wiki page with the ID parameter passed as a query string parameter in the request URL. Please let me know if it magically works for you, because for me, it doesn’t work even if I don’t use web parts or any kind of customization. This is one more example of how the various SharePoint components interact in complex subtle ways creating such unexpected behavior. Things should be simpler and I talk about that here: Diagnosing SharePoint Errors.