I managed to cover quite a bit of material at TechEd on Thursday – a bit about upgrading custom sites from WSS 2.0 to 3.0, some good info on SharePoint features and templates, a nice intro to Team Foundation Server, some new ideas for SharePoint workflow, and more vendor tools.
As a quick aside, I’m wondering what the more common pronunciation is for "Guid"? I’ve always said "goo-id" but most of the presenters here say "gwid". Feel free to leave a comment with your preference.
WSS 2.0 to 3.0:
I know some people have had major challenges upgrading from WSS 2.0 to 3.0. The Solutions Accellerators group covered a process here for helping to get thru the difficulties posed by customized 2.0 sites. Of course, this assumes the database upgrade runs smoothly 🙂 Find the TechNet article here.
I know some people have had major challenges upgrading from WSS 2.0 to 3.0. The Solutions Accellerators group covered a process here for helping to get thru the difficulties posed by customized 2.0 sites. Of course, this assumes the database upgrade runs smoothly 🙂 Find the TechNet article here.
SharePoint Features & Templates:
The coolest thing about this session by Ed Hild was the idea of kicking off code when a feature is activated. You can leave certain features deactivated in a custom site by default, and when the feature is eventually activated by the user you can run code to do things like create dependent lists, associate workflows, or do anything else that may be required by the feature.
The coolest thing about this session by Ed Hild was the idea of kicking off code when a feature is activated. You can leave certain features deactivated in a custom site by default, and when the feature is eventually activated by the user you can run code to do things like create dependent lists, associate workflows, or do anything else that may be required by the feature.
You can also kick off code when a site is created. I can see a real use for this in a deployment with custom site definitions with webparts or other custom functionality that needs defaults or other input set dynamically with data only available when the site is being created. You may not want to count on certain variable data to be available from another source (like the URL) that you can set at create time.
Keep an eye out here – Ed said he’d be posting code samples.
TFS:
Team Foundation Server (TFS) is the server product of Visual Studio Team Services. The first thing that may pop into your mind when you hear TFS is source control, which it does do nicely, but it is more powerful than that. Use it for:
work item (issue) tracking
version control
build automation
project portal (based on SharePoint)
reporting (based on SQL Reporting Services/SQL Analysis Services)
Team Foundation Server (TFS) is the server product of Visual Studio Team Services. The first thing that may pop into your mind when you hear TFS is source control, which it does do nicely, but it is more powerful than that. Use it for:
work item (issue) tracking
version control
build automation
project portal (based on SharePoint)
reporting (based on SQL Reporting Services/SQL Analysis Services)
SharePoint workflow:
I’ve had some pretty extensive exposure to SharePoint workflows, but Ted Pattison and Scott Hillier’s presentation got me thinking about an issue I’ve had with the way workflow is implemented in SharePoint. The problem is that you can only have one running instance of a given workflow on any given SharePoint item. I can envision many scenarios where you may want to allow the user to run more than one instance at a time. My initial thought was to build the workflow in such a way that it can dynamically create multiple instances of each task in the workflow, probably via Modification forms. I think this may work with certain, simple workflows – but it seems like a lot of work and something that you’d need to build deeply into the design of the workflow from the outset. But something simpler came to mind while watching their demos – you can simply run code that checks for a current running instance, and if one is there, dynamically create a second association of the workflow template to the current list. In the future, you can use this new association whenever a running instance exists, and can create more associations when needed.
I’ve had some pretty extensive exposure to SharePoint workflows, but Ted Pattison and Scott Hillier’s presentation got me thinking about an issue I’ve had with the way workflow is implemented in SharePoint. The problem is that you can only have one running instance of a given workflow on any given SharePoint item. I can envision many scenarios where you may want to allow the user to run more than one instance at a time. My initial thought was to build the workflow in such a way that it can dynamically create multiple instances of each task in the workflow, probably via Modification forms. I think this may work with certain, simple workflows – but it seems like a lot of work and something that you’d need to build deeply into the design of the workflow from the outset. But something simpler came to mind while watching their demos – you can simply run code that checks for a current running instance, and if one is there, dynamically create a second association of the workflow template to the current list. In the future, you can use this new association whenever a running instance exists, and can create more associations when needed.
Of course, you may have a bit of a training issue with end users, but this could even be transparent to the end user when you use the solution I describe here coupled with a solution that supresses the default workflow columns in the list default views. Just a thought, and I haven’t tried it yet, but it should be workable.
Apologies for being a bit tardy on this entry, but I should also get Friday’s review up today as well.
