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.
Downloads from today’s session:
Also, I promised a collection of links for the tools I had installed.
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.
Following the session on Friday, I’ll update this post with the actual source code and any other changes made during the presentation.
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.
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…
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:
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.
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...
Think Big, Start Small, Scale Fast.
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.
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...
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...