Webparts and STSDEV

I'm pretty used to doing 2007 development with STSDev and I've gotten really comfortable with it. However, one of the things I haven't built yet, amazingly enough, is a webpart.

So, last week, I was trying to find a world clock webpart that would properly observe DST where applicable. Amazingly, only one I was able to find does, but it sources external Flash content as part of its rendering. Instead, I decided to get the CKS release of the Bamboo World Clock and Weather webpart and put proper DST support within.

The code itself is...amusing to say the least. If I didn't know better, I'd say it was intentional to have the main namespace "CKS.Bamboo.WorldCockAndWeather".

At any rate, the CKS project makes a solution, but it's not feature-activated. STSDev has support for webpart-based projects, but crashes when parsing ClassResources. So, in my infinite wisdom OCD, I'm moving the Bamboo code into a STSDev project, and now I find myself modifying the source of STSDev to incorporate support for copying ClassResources into the Manifest, and proper storage of the data within the DDF.

2010 can't come soon enough.

Visual Studio versus VSTA

In taking over the duties of another developer who did part-time InfoPath maintenance, I've also been presented with an opportunity to clean out some dusty code closets.

All of the forms I've touched during my time here are in Visual Studio projects, but we still have a few forms that I haven't been directly involved in which were developed exclusively in VSTA. This change of guard has presented me with the opportunity to bring these other forms into alignment with our existing codebase, which is nice.

The first time I tried to migrate a VSTA project to Visual Studio, it was a nightmare. Not knowing how InfoPath 2007 integrated with VS08, I frequently found myself checking in-and-out code to avoid the dreaded "Operation could not be completed" errors. I was actually surprised earlier this week when I was able to successfully migrate a project in under half an hour, complete with renaming some extensionless files in the manifest and schemas.

The first pointer I learned for this task is a fairly simple one. If Visual Studio won't open the form, navigate to the manifest.xsf file, right-click on it, and select to Design the form in InfoPath. If there's a schema error in the form, the InfoPath client will point you straight to it. Visual Studio will not.

This will only carry you so far, of course. If you have a non-critical file missing that is specified in the manifest (such as a datafile for a data source), InfoPath will load your form in Design mode while Visual Studio will fail. Visual Studio also likes to complain when it can't get exclusive file locks on every file specified in your manifest.xsf, and accordingly, Visual Studio will refuse to open those files if the embedded InfoPath client is loaded (which also means that text searches will exclude those files!). Better keep that copy of Notepad2 handy.

Additionally, should Visual Studio lose its file lock on *any* of those files opened during Design mode, it will refuse to save any further changes, so save often!

This certainly seems like a lot of misery, but it's the best way to handle TFS integration, and it offers better debugging than you'll get out of VSTA, so it's a necessary evil. If you're prepared upfront and get some experience under your belt, it doesn't have to be a nightmare.