So a few days ago, I stumbled upon a baffling bug in SharePoint while using a data form web part to allow for editing a list item in a custom list. In the past, whenever I’ve created custom data form web part pages for editing, I’ve always followed SharePoint’s schema of using the “Id” query parameter to indicate which list item is being editted. In this case, I was already using “Id” in another web part on the same page, so I just modified my data form web part to use some other query parameter, like “ItemId”. Simple, right?
Anyone who has ever done any sort of custom development for SharePoint knows about .wsp files. If you don’t know, .wsp files are packaged (IE zipped) collections of files that are deployed to a SharePoint farm. This includes dlls, features, custom controls – just about anything done in a custom development situation for SharePoint gets packaged into a .wsp file for deployment purposes. You can view the .wsp files deployed to any SharePoint farm via central administration.
It turns out that there is a hidden system list on SharePoint Foundation (actually all versions of SharePoint, but much more useful in SharePoint Foundation). To view this list, you simply visit http://<YourSharePointSite>/_catalogs/users/simple.aspx or details.aspx.
After installing SharePoint 2010 SP1 with the June CU on a clients server. I ran the SharePoint 2010 Products Configuration Wizard like I always do and I got an error that said that it couldn’t connect to the database. The Actual message from the PSConfig log was:
I recently had a client with a unique situation regarding logging in to their Sharepoint environment. Without going into too much boring detail, the bottom line was the client needed to allow their Active Directory users to log in to a Sharepoint site that only used Forms-Based Authentication. (Sidenote: If you’re truly curious, the Sharepoint site itself wasn’t actively denying people using windows credentials. The problem was that the browser the client’s AD users were using to access this particular Sharepoint site didn’t play well with windows credentials).
Upgrading custom web parts from Sharepoint 2007 to Sharepoint 2010 can be an iffy prospect at best, but I recently ran into situation I had yet to encounter while doing such an update. I had a web part that used a few custom lists to both configure and control the web part and capture user input. While the web part itself was actually quite easy to get working in 2010 (when does that ever happen?), the lists posed a problem.
If you’re trying to access your SharePoint site via a host header from your SharePoint server you may encounter a series of login prompts followed by a blank screen. To remedy this, you can either make the site available on another port, or you can add a registry setting. This is how you would add the registry setting: