A weird little annoyance I’ve only just noticed is that using validation groups with the ASP.NET validators always results in a postback on form submission and client-side validation doesn’t intervene. Oddly enough, client-side validation does engage when tabbing between fields.
As much as I love the ASP.NET validators and the validation framework for simple scenarios, its limitations are significant when it comes to anything more significant.
Peter Blum, here I come!
The Disable –> Script menu option in the IE dev toolbar has baffled me for a while now: sometimes it’s enabled, sometimes it’s disabled (as in grayed out and unselectable), and whenever I need to use it I can’t. I’ve also noticed some of the tabs (namely Script and Profiler) occasionally disappear—easily solved by restarting IE—so I’ve put down the Script menu issue to bugginess.
With the IE dev toolbar now built into IE8 and IE being the defacto intranet/corporate browser that it is, I can see why this would be locked down for non-admins; I suppose you don’t want those pesky information workers and power users hacking your corporate forms. What a hassle though.
.If you’re shunting SharePoint content databases around between environments using the stsadm deletecontentdb and addcontentdb commands, you may find a couple of new errors in your events logs:
Failure trying to synch web application {guid}, ContentDB {guid} Exception message was A duplicate site ID {guid}(http://yoursite) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.
followed by:
A runtime exception was detected. Details follow.
Message: A duplicate site ID {guid}(http://yoursite) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.
After restoring a production content database to my dev environment, I was finding these two errors every hour on the dot.
Importantly—and despite what this error message notes as a possible cause—Todd Carter details why you shouldn’t be using stsadm preparetomove in a modern (post-IU) SharePoint environment. It seems like preparetomove actually fixed up some GUIDs before a detach/attach operation and it’s still documented with no warnings on Technet but hey, there’s something to be said for collective community wisdom when it comes to Sharepoint ;)
The problem itself seems to lie with SharePoint’s inability to update database IDs during the detach/attach process and (possibly) the fact the content database consumes an SSP. I’m a bit unclear on how the Infrastructure Update may have addressed this but at the end of the day I just want a clean event log and stable environment.
To correct this problem and clear both error messages, I ran the following stsadm command:
stsadm –o sync –DeleteOldDatabases 0
Despite it’s name, the DeleteOldDatabaes parameter doesn’t delete databases, only the “old records corresponding to these databases.” The zero value instructs the command to delete all records that have not been synchronized for the specified number of days. For a report of what might be cleaned up, run stsadm –o sync –ListOldDatabases 5 first.
Planning an evaluation (or trial) migration/upgrade from TFS 2008 to TFS 2010 seems to be a rather confusing affair; with most Google results still referring to the beta or RC, I haven’t come across many definitive guides pertaining to the RTM release. I haven’t spend any time with the TFS beta either and have never migrated a TFS install so the entire process is new to me. A throwaway install would therefore be required—preferably one that doesn’t impact the production 2008 install!
Most importantly, remember the tfsconfig import is a destructive command. Just stop and think before you do anything—or at least back up your existing databases! Also, a disclaimer: there may be other ways to accomplish the same thing using the upgrade wizard (at install time?? as an in-place upgrade??) but I didn’t follow up this option since I wanted to maintain the existing TFS 2008 environment; it may be worthwhile investigating in your case.
In short, I want to use my existing TFS 2008 data in a clean 2010 environment while the 2008 environment ticks along until the real migration can be scheduled.
So, step-by-step:
1. Install and configure TFS 2010 in a test environment; make sure everything’s working—create a test project collection and project, dill around with it for while, etcetera.
2. Backup the following databases from the data tier running your TFS 2008 environment:
3. Restore the 2008 backups via SQL Server Management Studio to the data tier in your TFS 2010 environment. In my case the 2008 database names were different than the 2010 database names so no name clashes occurred.
IMPORTANT NOTE: Do not follow this advice in production. You’ll likely want to point the tfsconfig import command at your old production server and, if not, there are safer ways to go about the database restore process.
4. Navigate to C:\Program Files\Microsoft Team Foundation Server 2010\Tools in a command window and kick off the import, which will effectively importing from your 2010 environment to your 2010 environment (if pointed to a production server, this process is destructive!):
tfsconfig import /sqlinstance:dev-tfs /collectionName:Imported /confirmed
It took this command 208 steps to do its thing.
Much to my surprise, the TFS 2008 databases restored previously were gone when I next checked in SQL Server Management Studio! Gasp!
5. Open Visual Studio and connect to your new team project(s).
6. Brian Harry also suggests changing the GUID of the migrated database for Beta 2; in my experience, the changeserverid command completed successfully after a warning that I shouldn’t be doing this to “a set of Team Foundation Server databases that have no application tiers configured” but the subsequent registerdb command failed with the following:
TF246017: Team Foundation Server could not connect to the database. Verify that the server that is hosting the database is operational, and that network problems are not blocking communication with the server.
This is a single-server environment with the command being run locally and the database itself is seemingly happy so I doubt a communication problem. At any rate, the mighty Google is silent on this problem and the environment seems kaput—revert, revert! I won’t explore this further as this step isn’t required for a real migration but I suppose it could be related to step 5 where I access the new environment; maybe I should have run these two commands first?
Brian also advises disabling SharePoint and Reporting Services via the Admin Console but I have yet to do that.
Update: After upgrading, we came across an issue where changesets that were previously merged "came back to life" in the merge candidate screen in VS 2010/TFS 2010. This KB article describes the problem and a hotfix is available to correct it. I'm not sure what the official MS stance is on this hotfix but you might want to apply it just in case.
Thanks to http://www.devh.de/post/Team-Foundation-Server-2010-Beta-2-Import-finally.aspx for the Beta 2 steps.
The TFS 2010 install is reportedly a walk in the park by comparison with previous versions so I thought it would be fun to give it a spin as we prepare to move from TFS 2008 to the latest and greatest.
First of all, if you’re doing a test install (or any kind of install, for that matter), the TFSInstall.chm guide included in the root of the installation media has a very well-documented process for installing both SQL Server 2008 and TFS. Unlike previous guides I’ve attempted to wade through, this one is actually quite a light read and presents just the information required to get up and running.
Apart from installing Windows Server 2008 R2 with Analysis Services and Reporting Services, I also installed SQL Server 2008 and SP1 before dropping into the TFS installer; the installer will add .NET 4, the Web Server (IIS) feature, WSS 3.0 if required, and SQL Server 2008 Express if required. I reused existing service accounts on the domain for SQL Server and TFS and created a new service account for Reporting Services. Some other bits were left to run as Network Service.
When installation completes, the configuration wizard kicks off. I went with the advanced option since I didn’t want to install SharePoint.
The entire process was a smooth experience until I ran into an old nemesis for those of us opposed to daylight saving here in Western Australia:
tf255356 Error occurred while executing servicing step Create Warehouse for component TfsWarehouse during Install: The supplied DateTime represents an invalid time. For example, when the clock is adjusted forward, any time in the period that is skipped is invalid.
This is interesting because the push for daylight savings was defeated a while back and the latest timezone updates were reported to be installed on my new R2 machine.
Luckily Andreww posted a work around on the connect issue: change the timezone from (UTC +8:00) Perth to (UTC +8:00) Tapei (where daylight savings is also not observed and Windows recognises the fact…). Before I could continue I had to delete both the TFS_Configuration and TFS_Warehouse databases as they were created before this problem cropped up.
All good from there… configuration completed successfully. But groan nonetheless, Microsoft!
With everything working admirably in development I was greeted with the below error message when attempting to create a new page after today’s fresh deploy to UAT (and eventually prod, where I gave up):
Error No parameterless constructor defined for this object
No fun but luckily the problem was easily isolated and a work around arrived at—although I have yet to unearth the root cause.
By way of more detail, I was attempting to create a new page instance in a new sub site using a branded master page and page layout. This isn’t normally a problem and seems to be limited to this master page/layout combo as I can successfully create page instances in the same sub site using another layout known to be good. The problematic page layout contains a single rich text field and webpartzone but, unlike other posts discussing the same error message, the <zonetemplate> element is empty and I’m not attempting to deploy web parts to the page using the AllUsersWebPart crappiness. I just want my basic page!!
Most of the suggestions out there for resolving the above error lead you to the web part editor maintenance screen (see below) where you’ll find one or more ErrorWebParts, which can then be deleted. The problem with this approach is maintaining the page’s web parts requires the page layout to be checked out and that customises the layout, meaning future feature-based deployments of that layout won’t “take”. Of course, my layout isn’t supposed to have any web parts so go figure where the single mysterious ErrorWebPart originates… there seems to be a (related?) issue accessing web part programmatically in which ErrorWebParts objects are returned instead so I wonder if this is a different web part than how it’s represented…
Others suggest redeploying the layout after deleting it from the gallery but that didn’t work in my case.
In the end, I created a page from a different layout using the same content type as my desired page and then changing the layout. All fine from there but not at all usable—luckily this was for a short-lived campaign site.
How to open a page layout in web part maintenance mode
Just as a page instance can have web parts, a page layout can also have web parts. To manage those web parts, check out the layout within the Master Page Gallery, and click View Properties from the context menu. Next, edit the item and click the ‘Open Web Part Page in maintenance view’ link at the bottom of the page.
Alternatively, you can substitute your page layout in this URL:
http://<server>/_catalogs/masterpage/<page layout name>.aspx?contents=1
Running MOSS 2007 with SP2 and a stack of cumulative updates still seems to leave those users running IE8 in IE8 Standards mode in the dark.
In particular, editing a page and clicking into a rich text field triggers a slew of javascript errors which seem to stem from a null reference in the RTE_TB_ClearButtonDisabledect function (form.js). In particular, you may face the ‘null’ is null or not an object error.
To work around this, use the IE Dev Toolbar (F12) to change the Document Mode to IE8 Compatibility View:
Interestingly, this issue was supposedly fixed with a hotfix and then SP2…
I somehow mucked up the provisioning of a default SSP in a clean dev environment and figured this would be a good opportunity to figure out how to delete a default SSP using stsadm; the Delete option on the context menu in Central Administration was greyed out (most likely because this was the default SSP but conceivably because provisioning failed) and simply editing the SSP properties was not an option as SharePoint was complaining about empty strings or some such stupidity associated with the underlying problem (a database login issue). Of course the “normal” way to do this would be create a new SSP and pull across any sites before marking it as the new default SSP.
As usual, where the Central Admin UI is somewhat limited and incomplete, stsadm saves the day with the deletessp operation. Simply provide the SSP title (enclosed in double-quotes if it contains spaces). In my case I also wanted to cleanup the databases so I supplied the –deletedatabases parameter.
stsadm -o deletessp -title "Default SSP" -deletedatabases
The operation failed with an error message about dependent objects.
An object in the SharePoint administrative framework, "SharedResourceProvider Name=Default SSP parent=SPFarm Name=SharePoint_Config_dev-moss-mh6", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objects are as follows:
SPWebApplication Name=x Parent=SPWebService SPWebApplication Name=y Parent=SPWebService
Not surprisingly there are posts out there detailing the use of the stsadm deleteconfigurationobject operation to force disconnection but this involves retrieving GUIDs from the configuration database and others have suggested additional mess will need to be cleaned up in the same way. Instead, just use the –force parameter on the deletessp command.
Once complete, you should see an Operation completed successfully message.
If you’re receiving an Access denied error when attempting to run an stsadm command under Windows Server 2008, user access control is likely interfering with the application.
Instead of opening a command window by simply double-clicking the shortcut, right-click the shortcut and select Run as Administrator (even if the logged on account is already a Windows administrator); alternatively disable UAC.
Oh the pain: your solution builds and deploys with no error messages but something’s awry, your feature files are where they need to be in the .wsp/.cab and the target file system but SharePoint is none the wiser. So you lather, rinse and repeat (er, rebuild, redeploy, re-activate) to no avail; everything’s working yet nothing’s working!
We have our stsadm –o activatefeature commands tucked away in our deployment scripts and they just happen to use the –force parameter. This is normally fine, except when the feature breaks; in this case the feature is still force activated—as requested—but error messages are suppressed… in other words everything seems okay but it’s all really all horribly wrong. Even the event log is clean as a whistle.
So to figure out what’s going on, drop the –force attribute (you may need to deactivate the feature manually first), and reactivate. Behold the error message in all its glory.
Have you ever needed to “flatten” a pretty-printed XML file for pasting into a web service test page? XmlSpy and the like will happily display ugly XML in a nicely-indented format but the version I have doesn’t un-pretty-print (or flatten) XML for me.
Custom tool to the rescue! Announcing my very first codeplex project and the XML Flattener!
This first alpha release is a simple WinForms apps with zero error handling and very limited capabilities allowing you paste in an XML document, flatten it, and copy out the flattened string. The hard work is accomplished by—wait for it—leveraging the default formatting of the XmlDocument’s OuterXml property (which isn’t formatted, unlike other XML-related classes which do return formatted documents).
Enjoy!
For some reason I’ve always used the System.ComponentModel.Category attribute to configure the category or group under which a web part property is displayed when viewing the web part’s settings. This approach always worked fine but it also felt a little dirty—especially because I always knew an alternative existed (but was never certain what that alternative might be ;-)
At long last I’ve determined the alternative to be the SPWebCategoryName, which works identically to Category:
[Personalizable(true),
WebBrowsable(true),
SPWebCategoryName(“My Category”),
WebDisplayName(“My Property”),
WebDescription(“My property description.”)]
public string MyProperty ( get {…} set {…} )
The SPWebCategoryNameAttribute type lives in the Microsoft.SharePoint.WebPartPages namespace so you’ll need to add a using statement or fully-qualify the type name.
