Codestock Session

I’d like to thank all of you who attended my session today at CodeStock. I had a great time talking with you all and sharing my experiences with SharePoint and TFS with you all.

Downloads from today’s session:

• Powerpoint Deck
• My customized version of STSDev
• The Samples I built in prep for today
• The samples we built during the session today

Also, I promised a collection of links for the tools I had installed.

• STSDev on CodePlex (this does *not* contain most of the fixes demonstrated today)
• SharePoint Installer
• Sand Castle
• Sand Castle Help File Builder
• Zoomit – Utility for zooming in and out during a presentation
• Smart Tools Enhanced Site Actions

Customizations to STSDev 1.3

As part of my session on Deployment and build using TFS and SharePoint for CodeStock 09 I took the source code from the STSDev project on CodePlex (http://stsdev.codeplex.com) and made a number of modifications. Some of these I would classify as clearly bugs, but most of them are simply adjustments to the core to fit my needs/desires. I’m documenting them here and providing a zip of the source for the benefit of those attending my session. These changes and source code are completely unsupported and you use them at your own risk. That being said, I hope that they are helpful and speed you in your integration between SharePoint and TFS. NOTE: unless specified, all of these changes are to the “Core” project.

1. First minor change is that I moved the solution file up one level to the parent folder. This is truly nothing but a nit-pick but seems to make source control trees happier and therefore something that I almost always do.
2. Upgraded the projects/solutions to Visual Studio 2008
3. Added an app.config file with an assembly binding redirect pushing old references to Microsoft.Build.Framework to utilize version 3.5.0.0. This is one of the changes needed to get support for .NET 3.5 working properly.
4. Changed the target framework property for the stsdev.csproj to .NET Framework 3.5. This change, in concert with the previous, allows the 3.5 selection in the UI to work properly.
5. Major Change: Support for alternate bin paths. The 1.3 version as published on CodePlex always uses the compiler output in projectdir\bin\debug when assembling the *.wsp file. This happens regardless of what build configuration you have selected (yes, even release). This doesn’t work for TFS builds since the output is, by default, in a different location on the build server. To support this use case, the following changes were made:
   • Program.cs: Changes were made prior to calling SolutionBuilder.RefreshDeploymentFiles to support the passing in of an additional parameter indicating the alternate bin path.
   • Changed the Create method of Builders\DeploymentFiles\CabDdfBuilder.cs to accept the alternateBinPath as an additional parameter.
   • Changed the Create method of Builders\DeploymentFiles\CabDdfBuilder.cs such that, if an alternate bin path is provided, it will use that value when adding references to assemblies rather than the otherwise-hard-coded /bin/debug/
   • Updated the first overload of the RefreshDeploymentFiles method in SolutionBuilder.cs to pass the alternate bin path to the second overload of RefreshDeploymentFiles.
   • Updated the second overload of the RefreshDeploymentFiles method in SolutionBuilder.cs to build the TargetPath from the alternateBinPath if provided and otherwise to use the default.
   • Updated the second overload of the RefreshDeploymentFiles method in SolutionBuilder.cs to pass the alternateBinPath parameter to CabDdfBuilder.Create().
   • Updated the CompleteSolution method in SolutionBuilder.cs to pass an empty value for alternateBinPath to RefreshDeploymentFiles since, during the initial project creation, it is ok to utilize the default /bin/debug path.
6. Major Change: When creating a project, always create a parent solution directory in the same way that Visual Studio defaults to. This is helpful when working in a source controlled environment with multiple projects in the same solution. To support this feature, the following changes were made:
   • Changed the <REFRESH /> property in Resources\Common\Microsoft.SharePoint.targets.xml to utilize the $(ProjectDir) variable rather than $(SolutionDir).
   • Changed the Create method of SolutionFiles\SolutionFileBuilder.cs to accept the solution directory as an additional parameter.
   • Changed the Create method of SolutionFiles\SolutionFileBuilder.cs to change the directory for where the solution file is created
   • Changed the Create method of SolutionFiles\SolutionFileBuilder.cs to reference the *.csproj file in subdirectory rather than in the same directory as the *.sln file.
   • Added  a property called ProjectDirectory to SolutionBuilder.cs to hold the full path to the project directory (now distinguished from SolutionDirectory).
   • Updated the RunCreateSolutionWizard method in SolutionBuilder.cs to set the Project Directory property.
   • Updated the InitializeSolution method of SolutionBuilder.cs to create the new (child) project directory and update the location appropriately
   • Updated the InitializeSolution method of SolutionBuilder.cs to set the SolutionBuilder.TargetPath based on the ProjectDirectory property rather than the SolutionDirectory value.
   • Updated the CreateDeploymentFiles method of SolutionBuilder.cs to use the proper path for the files (based on ProjectDirectory).
   • Updated the RefreshDeploymentFiles() (first overload) method of SolutionBuilder.cs to optionally set the ProjectDirectory property if it isn’t already set.
   • Updated the second overload of the RefreshDeploymentFiles method of SolutionBuilder.cs to set the current directory to the value of ProjectDirectory if it is set, and otherwise to use the SolutionDirectory value.
   • Updated the second overload of the RefreshDeploymentFiles method of SolutionBuilder.cs to utilize the ProjectDirectory value rather than the SolutionDirectory path.
   • Updated the LoadSolutionConfigFile method in SolutionBuilder.cs to use the ProjectDirectory property and remove the pathing ambiguity that was leading to incorrect path lookups.
   • Updated the CompleteSolution method in SolutionBuilder.cs to pass the SolutionDirectory property to SolutionFileBuilder.Create() since it can no longer assume that the solution file should be in the same directory as the project file.
7. Major Change: Added support for the Release|AnyCPU project configuration to support integration with TFS Build. In support of this feature, the following changes were made:
   • Added <REFRESH-TEAMBUILD> property in Resources\Common\Microsoft.SharePoint.targets.xml file. The value of this property is similar to that of <REFRESH /> but has an additional parameter referencing the alternate bin path that TFS creates by default.
   • Added a Release target in Resources\Common\Microsoft.SharePoint.targets.xml. This is targeted specifically at the TFS build and is therefore similar to the ReleaseBuild target but calls the $(REFRESH-TEAMBUILD) exe rather than $(REFRESH)
   • Added a “Release” value to the Configurations string array in SolutionBuilder.cs. This causes the release config to be added to the generated solution and project files.
8. Major Change: We utilize SharePoint Installer to create a nicely-packaged version of the resulting solution making it nearly brain-dead easy to install a new solution. The only real thing unique or project-specific in a SharePoint Installer package is the setup.exe.config file that passes a number of parameters to the executable allowing it to adapt for your particular solution package. This feature change causes STSDev to generate the initial draft of this file and to add it to the solution items. To this end, the following changes were made:
   • Created a new file, SolutionFiles\SetupConfigFileBuilder.cs to represent the template and logic for the SetupConfigFileBuilder class.
   • Updated the CompleteSolution method in SolutionBuilder.cs to call SetupConfigFileBuilder.Create and create the new config file.
   • Updated SolutionFiles\SolutionFileBuilder.cs to include a pointer to setup.exe.config and thereby include it in the solution.
9. Major Change: We utilize Sand Castle and Sand Castle Help File Builder to produce developer-targeted API documents for our projects. Sand Castle Help File Builder needs a configuration file (xml) with a number of property values to configure it to run properly. This feature allows the basic file to be generated by STSDev and for it to be added to the solution items collection. To this end, the following changes were made:
   • Created a new file, SolutionFiles\SandcastleHelpFileBuilder.cs to represent the template and logic for the SandcastleHelpFileBuilder class.
   • Updated the CompleteSolution method in SolutionBuilder.cs to call SandcastleHelpFileBuilder.Create and create the configuration file.
   • Updated SolutionFiles\SolutionFileBuilder.cs to include a pointer to the generated *.shfb file and thereby include it in the solution.
10. Major Change: By default, STSDev would not only generate manifest.xml and the ddf file, but it would add these files to the project. While in many cases this is innocous, it causes heartburn in a source-controlled environment. Firstly, purely generated files have no business being in your source tree. Secondly, since the user doesn’t edit them, once they are checked in, they are most often left as such, resulting in errors on compile because the files are marked as read only, preventing stsdev.exe from updating them properly. To this end, the CreateDeploymentFiles method of SolutionBuilder.cs has been updated to remove the calls to ProjectBuilder.AddSourceFile() following ManifestBuilder.Create() and CabDdfBuilder.Create().
11. Added an image, PlanetIcon.gif to the resources section and replaced all hard-coded references to africanpith.jpg with references to PlanetIcon.gif. This is nothing more than a branding change for the output projects and has no other affect on the program’s functionality. Affected files include: stsdev.csproj, SolutionProviders\SimpleFeatureSolutionProvider.cs (AddSolutionItems method), Builders\SourceFiles\FeatureBuilder.cs (Create method)
12. Adjusted the InitilaizeSolutionProviders method of  UserInterface\SelectSolutionType.cs to select by default the Web Part Solution (C# Assembly) project type on load rather than the empty solution. This change is nothing other than a convenience feature during testing and use (that’s almost always the project type I use).
13. Adjusted the RefreshDeploymentFiles method of SolutionBuilder.cs to fix some seemingly obvious bugs in Console output using incorrect values.

Following the session on Friday, I’ll update this post with the actual source code and any other changes made during the presentation.

Project Templates for SharePoint Development

I've had the privilege of working with an organization for almost two years now doing alot of SharePoint development. There's a team of approximately 75 developers that cover the gamut of skill sets and experiences, most of whom are working, to some degree, with C# and SharePoint development. One of the things that has come up repeatedly, is "how do I get started"? or "what project template should I be using"? These are good questions without a completely clear answer. This post (and hopefully some following) are intended to discuss what we are using, how it evolves, what options we discarded, and why. I spent last Friday teaching a class attempting to bring our team up to speed as to how to structure their SharePoint solutions/projects in VS and get them integrated with Team Build and packaged for deployment in our organization. As the day wore on, I realized how "janky" the "elegant" solution I had been using felt to someone new to the problem set. The supposed elegance was simply relative to the pain I had been experiencing doing it the "old way"... there has to be a better answer for the causal SharePoint developer.

I should stop here to add a caveat that prior to this assignment I spend a year or so (on and off) working on a custom VSIP toolkit for Visual Studio that included custom project and item templates as well as menu items, dockable tool windows, custom build tools, etc. so I'm a bit biased towards using the built-in extensibility hooks for Visual Studio (especially since its gotten so much easier with the 2008 release).

A year and a half or so ago we started by looking at the WSS Extensions for Visual Studio.. these were interesting and "felt" like the right answer because "they were from Microsoft... certainly they must be the best approach". While this sounded good (and in theory should have worked out) we ended up with a handful of issues... the first being their very slow support for VS 2008. Secondly, we often found a webpart project that suddenly stopped working (i.e. F5 deploying) and couldn't figure out how to get it working again... there seemed to be a bit too much "magic" going on behind the scenes. Also, It was completely unclear how one would take the resultant project and integrate it into a build system (i.e. Team Build). I'm sure it is possible, but it didn't seem to add much value beyond the initial development.

We then looked at STSDev (codeplex.com/stsdev). This is an interesting project that is *almost* my silver bullet. I like the way the template projects are setup, the layout, and the work that the post-build events work (automatically maintaining the ddf and manifest files as well as building the wsp). I have a handful of gripes with how they layout the project structure (no root folder for the solution) and the variables they use (or don't) for certain things. My biggest gripe is that I'm left wondering why they didn't leverage the existing, built-in templating features for Visual Studio (i.e. why can't I go File --> Add New --> web Part). Why should I have to train developers on yet another paradigm for creating their projects? Is their launcher really any better? I think not.  That being said, to this day, this is still the mechanism we are using for the majority of our work, but my dissatisfaction with the tool is the driver for this post and quest for a better end-to-end solution.

Because many of our developers were building webparts based on the SmartPart, we found ourselves looking at the SmartTemplates project. There was some very interesting things learned from the way in which Jan implemented this, but still some difficulties presented themselves when we tried to look at this tool relative to the larger problem of our entire SharePoint development environment (webparts, "standard" features such as menu items or application pages, smart parts, and Team Build).

While at PDC, I found myself talking with the Blueprint guys (http://codeplex.com/blueprints). Near as I can tell this is the successor to the GAX tools and looks to be very interesting. I spent part of yesterday afternoon studying the approach and found some very nice features (i.e. ability to update/maintain the platform via an RSS subscription). Unfortunately, the platform is still in beta and, at least in my testing, doesn't feel ready for primetime... maybe in a few months...

So, today I'm going to start out very basic and investigate simply building a custom project template that uses the built-in T4 templating features of VS. The objective is to have a project template that a developer can click on that will create a web application project, configured for development of ascx controls as smart-parts, along with a folder structure similar to what STSDev gives you supporting the build and auto generation of wsp files, as well as preparing the project for Team Build. 

Stop (re-)Inventing the Wheel!

This is more a personal reminder than anything else…

In my “day job”, I’m working with an organization wherein we are coaching a group of about 80 developers to view opening Visual Studio as their last viable option when looking to solve a problem. This doesn’t mean coding is bad (I certainly hope not… if so, I think I’d be out of a job soon), but rather represents a mind-set that recognizes that we have an enormous collection of functionality/tools already available to us (we are building on top of MOSS 2007) and we need to fully vet the OOTB functionality prior to deciding we need to “roll our own” anything. Directly tied to this approach is the theory that using OOTB functionality and/or configuration of such (rather than raw coding) leads to better long-term maintainability and upgrade-ability, not to mention helping to avoid “hit by a bus” syndrome.

However, sometimes the “preacher” needs to look inwardly and I found myself doing that this weekend. I was working on a project for a non-profit organization I work with, and found myself looking at what I had amassed for solving the problem of site-wide search and was displeased. I immediately reverted to my “code first” tendencies (something I think every developer is born with) and began (mentally) listing the discrepancies with the current solution and designing a “right” solution. Thankfully, prior to actually writing any code, I was kicking around some blog posts and something in one of them (honestly don’t remember what/which) got me thinking of the various “existing” search engines and the fact that they often provide site-specific, nearly OOTB search dialogs that you can embed into your site. I kicked a couple of them around, and settled on one (ended up with the live.com search using the XML web services API), and, rather quickly had a fully-functioning search platform on my site…

The “purist” in me immediately thinks of a couple of reasons why this solution “isn’t as good as what I would have built” (i.e. less control over the actual search results/order, less “immediacy” to updating the index, etc), but then my more realistic side kicks in and I realize that I’m not a search engine expert… not even close… Some might argue as to whether or not those at live.com are either :), but I can guarantee you that they are more so than I, and that the solution “they delivered” is much more accurate and flexible than I would have built…

I found myself reminding myself to focus on where I can add value, and to leave the rest to others… that’s the only way to consistently deliver adaptable solutions in an environment where the surrounding technology is changing so quickly…

MSFT/BPM/SOA Session 5

This session was titled: "The Human-Facing SOA: Realizing the Value of Web Services with Microsoft Office SharePoint Server 2007" presented by Hugh Taylor (Senior Marketing Manager, MSFT)

So, reading the title of this session, I assumed it was a technical presentation focused on SharePoint web services.... however, that was not the case. Rather, it was a business-focused presentation that centered completely on the "users" of any given SOA. While not being exactly what I expected, it was a very good session and well worth the time to sit through it.

As with the other sessions, it's a little easier for me to simply comment on poignant comments from the speaker than to attempt a proper summary, so here goes:

• People are often the missing ingredient for SOA business value
• If you are trying to measure the ROI of your SOA project, you'll likely be disappointed. Some common reasons are:
  • slower than anticipated uptake
  • training takes more time than planned
  • various Governance and security hang-ups
• One of the factors in all of this is a lack of a familiar interface
• We, as technologists and system designers MUST learn to focus on the user, rather than the technology. Hugh Macleod has a comic that aptly puts what I want to say here:
  
  
• We seem to get so wrapped around the axle with respect to how the system interacts with itself or the technology deployed within the system that we fail to realize that without a user, our system is useless.
• He stressed the importance of accurate communication at all levels of the SDLC. Often business drivers and technologists are "talking past" each other.
• He noted that as software developers and coders we often underestimate the power of habit, organizational norms, etc. Just because it's "better" doesn't mean that it's "better".

At this point he started talking specifically about the MSFT platform and the talk became less interesting to me :)

All in all, one of the best, most thought-provoking sessions I attended.

MSFT/BPM/SOA Session 4

The fourth session I attended was titled "BPM Best of Breed: Accenture, Avanade, IDS Scheer, and Microsoft - Delivering Closed Loop BPM and was presented by Brian Wilkinson (Accenture), Altan Enginaleve (IDS Scheer) and Dana Kaufman (Microsoft).

The objective of this session was to do a "deep-dive" into the demo that these same folks presented during the keynote earlier that day (which was very interesting).  What I had feared was the case, worked out to be, in fact, reality - the demo was a bit more duct-tapped together than I had hoped. The intent of the project was to illustrate to us and their customers what could be done ("paint the picture" if you will).

I have to admit that the ARIS platform was very intuitive and interesting, although I found myself a little turned off by the extensive use of Java and JDBC connections (I know, I know, but I bleed blue...). As with many of the sessions, the speakers made some general comments/points that I thought were interesting...

• Many organizations have very well documented business processes, however, those rarely reflect reality (no direct impact on execution)
• They (as consultants and based on their experience) encourage people to avoid "as-is" process modeling and focus more on "target" process modeling. In their experience, it is not uncommon to find that upwards of 80% of the "process" that existed was not tied to true requirements, but rather historical, or "just because that's how we do it" reasons. Simply focusing on what *really* needs to happen (almost ignoring for a little while how it is currently being done) can be a great source of improvement to efficiency.
• As often is the case, the starting point is processes - processes can be documented, metrics can be understood - this is not a technology problem. These (both processes and the metrics that you want to collect about those processes) must be worked out prior to any "silver technology bullet" "fixing" things.

Think Big, Start Small, Scale Fast.

MSFT/BPM/SOA Session 3

The third session I attended was a lunch session sponsored by K2 (http://www.k2.com). I was looking forward to this presentation as I've heard quite a bit about K2, and they've been doing workflow in SharePoint long before MSFT was.

During this session, they focused on their "Black Perl" product which is the current release. Based on the demo, a quick summary of the product is as follows:

- Middleware platform that provides workflow and reporting based on the concept of "business entities"

- They have a concept of a "SmartObject" which is mechanism for creating, what I would call a composite object/view of a singe entity within the organization regardless of the data source. This means, I could create a smartobject which represents an "employee", for which some of its attributes/values are derived directly from SAP, others from AD, and maybe still others in a custom built SQL DB. This object abstracts for the user all of the complexities of interacting with the data sources on the backend. In the demo, the showed creating a smart object for which the data resided in SAP and then exposed that "entity" in a number of different places (SSRS report, workflow, etc.).

All in all, the demo was pretty interesting and there is some applicability to the problem set I'm currently working with, but I had a hard time imagining a non-developer using their "non-developer" focused tools. I'm certain that it would come with time, but seemed like a higher barrier to entry than I was looking for.

That being said, as mentioned before, their demo focused specifically on the Black Perl product and, having spent some more time on their web site since, there are clearly other products/updates to existing products in the works that might make the entire platform much more of a "fit" for the scenario we are trying to fix.

Base Template for MOSS Master Pages

I'm posting this more for my own benefit (able to find it later) than anything, but while working on a master page customization for a client I stumbled across a posting on MSDN on how to create a minimal master page (http://msdn2.microsoft.com/en-us/library/aa660698.aspx).

I ran into a few issues simply using the code as presented...

1. SPD didn't like the ASP.NET style comments... that really threw it for a loop and it kept removing items from the code with no warning... changing those comments to HTML-style fixed things
2. The first item in the community content section didn't seem to apply... things looked fine.
3. The second item in the community content section was correct.
4. I also had to add a content placeholder stub for "PlaceHolderTitleRightMargin" in order for everything to work properly for me

Why Can't I Create a Master Page in the Site Collection???

Chalk it up to being a newbie at SharePoint v3/MOSS 2007 development, but I expected that since I was a site "owner" of both a sub-site as well as the site collection that I should be able to create a master page using SPD and save it to the site collection's master page gallery... silly me.

With some assistance from a co-worker, it was discovered that being a site owner doesn't give you rights to do this. You have to also be a member of the "Designers" group. I understand this role, but it seems odd that the "owner" doesn't have this permission as well...