While working with a client today on some SharePoint 2010 code, the requirement can up to do some query based joins. I hadn’t done this before in SP 2010, but it’s pretty sweet. The only way I have gotten around it in previous versions was converting the list data into data tables and then working with it in that format. Natively working with it is a whole lot less code, whole lot less complicated too. Even for permanent join type stuff, you can use projected fields which is really nice.
So, what’s it look like? Consider the following snippet:
It seems I am never going to be rid of finishing these automating events! One problem that we tackled today dealt with TFS target injection, where you want to call other targets at different points in the build process. An example of this is when you want to wire a target before/after something like SolutionToBuild and ConfigurationToBuild, perhaps to do a little work before the build starts. In this case, the build was chained to **another** build to do a get on a separate VC instance, and build a related solution beforehand. There was also some WIT stuff to be done too.
Fortunately, TFS Build makes this pretty easy through the use of the Before* or After* targets (which are easily grafted from Microsoft.TeamFoundation.Build.targets), most you will ever need are existing but if you need a different one you can use a CallTarget with a MSBuild task. This can get even cooler, because you can actually start to build chained dependencies through something like:
So I am still in migration hell and fixing some build code. One of the problems we just ran into was chaining build events. Consider if you had SharePoint project X which contained and Exec command that triggered SharePoint project Y. The goal of their custom build is to query into the build status of SharePoint project Y, and display the build status in SharePoint project X’s build status. Put simply, I needed a mechanism where Project Y build status, like whether it returns Success, Partial Success, etc.
Fortunately, this isn’t terribly difficult using the Exec task to execute a command leveraging the exitcode to get the status. This looks like the following:
The exitcode return will be an integer, which is easy to correlate to the respective return values, Failure is 100, Partial Success is 1, Success is 0, Unknown is -1, and Unrecognized Command is 2.