Silverlight 2: Communicating Between Controls

In an attempt to keep pace with the one a week challenge, here is another post! Does two in one week make up for none in the last?

I have been working on my first production Silverlight application, using Silverlight 2 Beta 1. I have been playing around with how best to structure the site, with maintainability in mind. As a result, I have several user controls that encapsulate specific pieces of functionality. I am treating the Page.xaml that is loaded when my site loads conceptually as my "Master Page", containing different user controls, etc. All in all, I am pretty satisfied.

I came across the need for a user control to communicate with another user control. I started down the route of raising an event and registering handlers. Problem is that my first user control is contained in another user control, and I didn't want to add events and handlers to both user controls to propagate all the way up to my parent page.

I wrote a quick extension method that uses Generics that solves my problem. You can use it to retrieve a specific ancestor of an element... quite useful.



Here is how I called it within my user control...



In unit testing, I saw a variety of StackPanels, Grids, and UserControls on the way to my desired Page. Its important to note that if you have a reference to a Control, its .Parent property will usually give you a container such as a Grid, Canvas, or StackPanel. If you need an "Grandparent" or "Great Grandparent", this extension works well.

Managing Environment-Specific Settings In Your Projects

Having an automated build and deployment process is a key and sometimes overlooked component to building software. Part of that process is implementing a mechanism that will manage the changes to environment specific settings that need to be applied to your configuration files when deploying to a specific environment. And if your current mechanism is using notepad to edit your web.config/app.config once your code is deployed....please continue reading :-).

A few months ago, I was turned on to the Enterprise Library Configuration Tool, a new component introduced in Microsoft's Enterprise Library. David Hayden has a good post about how to use this tool. Patterns and Practices explains it here. It addresses this very issue, and provides a user interface to view your settings and apply environmental-specific overrides. I started using this tool, and found that I enjoyed using that UI because I could easily see all the values for a setting across my environments.

I was able to automate the merging of the delta files created by the configuration tool into my build process with a executable provided by EntLib, called MergeConfiguration. I updated my MSBuild project file, TFSBuild.proj, with a target to run this executable after my code was dropped.

The downfall to this method was a limitation I discovered in the Configuration Tool. The settings I was allowed to manage and override were limited to Enterprise Library configuration sections, connection strings, and application settings. I could not change values of settings in sections such as System.Web and System.Net. Hmmm. My honeymoon phase with this tool was officially over.

Another solution to this problem that I like is a solution that Scott Hanselman talks about here. It is pretty simple and here are the steps...

1. Create a new configuration in Visual Studio for each of your environments, such as Staging, Production, etc. You can model each one after the existing Release configuration for starters.
2. Create a separate configuration file (i.e. web.config) for each of your environments. So you would end up having web.config.staging, web.config.production, etc.
3. Create a Pre-Build Event that swaps the environmental-specific web.config for the existing one based upon the configuration that is being built. You can get a version that does this in Scott's post.

After trying this method, I found a couple of things I did not like. First of all, I didn't like having to create environment-specific configurations within Visual Studio. In some solutions, I have multiple configurations for code that will be deployed to different locations. I don't like idea of duplicating configurations for all those existing configurations, that all are essentially the same. Secondly, in larger solutions, you will have to copy that "pre-build" event into each project that has a configuration file. This spreads this very similar logic across my solution in different places I need to keep track of.

So...I have been using a hybrid approach that addresses these issues for me...

1. I create a separate configuration file for my different environments (web.config.staging, etc).
2. I add a target to my MSBuild project file (TFSBuild.proj when using TFS) to copy the correct configuration file to the root of my application after it is built. This way, if I have to copy multiple files for multiple configurations, all of the statements are right here.
   
3. (Optional) I modify the properties on the configuration files in the root of my projects to set their Build Action to "None". This means that they will not be included in the build. I like the settings in those files to be local development settings, and know that they will not be replicated to other environments. So what is deployed is either the correct environment-specific config copied in Step 2, or none at all.
   

The downside with this method (and the one Scott describes) is that you have multiple web.config files to manage. Some people really do not like this. I don't mind it. If you make use of the fact that you can split out configuration sections that do not change across environments into separate includes, you can eliminate a lot of the redundancy. To me, you are either going to have multiple config files, or multiple delta files. It probably just depends on preference.

There are definitely other ways to solve this problem. If you have other good solutions, I would love to hear about them....

TFS Blog Series: Overview (Part 1)

Welcome to the first post of the TFS Blog Series! Greg Martin, my friend and Slalom Consulting collegue, and I will be doing a series of posts about Visual Studio Team System, focused around Team Foundation Server. We will cover a wide range of topics, and hope to give you an in depth look at some of the key features. This series will mostly be from a developer point of view. The majority of the content of the series will apply across both the 2005 and 2008 versions of Team System.

This first post will be an overview. I hope to explain a bit about the what and the why with TFS. The where, when, and how are probably mixed in there somewhere as well.

What is Team System?

Visual Studio Team System is an integrated Application Life-cycle Management (ALM) solution. There are several products designed for individuals serving different roles on a project, from Architects to Developers to Testers.

Team System centers around Team Foundation Server (TFS). TFS is the collaboration server, the "hub" of the system, and integrates all of the supporting products. It stores information about a project and provides project-related services, both figuratively and literally. The services that TFS provides for a project include:

• Work Item Tracking
• Source/Version Control
• Reporting (via SQL Server Reporting Services)
• Build Services (via Team Build)
• Project Portal (via SharePoint)
  

So what are those other products that make up Team System besides Team Foundation Server? They are the different Team Editions of Visual Studio:

• Visual Studio Team System Architecture Edition
• Visual Studio Team System Development Edition
• Visual Studio Team System Database Edition
• Visual Studio Team System Test Edition
• Visual Studio Team System Test Load Agent
• Visual Studio Team Edition Team Suite (a.k.a all of the above)
  

It is important to note that you DO NOT need one of these Team Edtions to use TFS. The regular Visual Studio versions (Standard and Professional) can be used. However, you will miss out on some of the features in the specific editions designed for Team System.

Here is a nice picture provided by Microsoft that visually depicts Team System:


Why should you use it?

To me, here are some of the key reasons for why you would want to use TFS on a project.

• Promoting Best Practices
  Using TFS promotes you to follow best practices, plain and simple. Because you are provided with just about all the pieces you need to full manage a team project, you would have to make a conscience choice to NOT use features, and not follow best practices. It is entirely opposite when you are not using a product like TFS. Then, you have to make the effort to incorporate best practices into your project. With TFS, its all right there for you to use. And you will.


• Providing One Common Tool Suite
  Having a common tool suite is very nice. I personally love not having to leave the Visual Studio IDE to check/modify work items, find documents, view reports, use source control, and run builds. In the past, think about all of the different third party solutions that would come into play. I am sure you probably have worked on a project with VSS or Perforce, NANT, Cruise Control, NUnit, some custom deployment solution, and some sort of Work Item tracking tool. Throwing out all of those in exchange for just ONE product is great. Less time spent getting all of these to play together, and more time spent on the actual delivery of the project.
  
• What You Get Out of the Box
  I love to do a presentation where I show what I get with TFS when starting a new project. I say.... "Lets see what I get in 10 minutes of work". After the 10 minutes I have a new project created, complete with different security groups set up. I have initial Iteration 0 work items assigned to project team members in the Work Item Tracking system. I have some initial documents uploaded into the SharePoint portal for our project. I have reports showing the upcoming work, even displaying in that portal. I have source control set up and my initial code solution imported. And I have an automated, continuous integration build established for that code solution, with the first build complete. IN TEN MINUTES!!! Granted I am talking very fast and I know my way around. But you can see just how much you have at your disposal when starting a new project. No time is wasted getting all of these pieces set up individually.

So on what type of a project would you use TFS? To me, it is for everyone on any software development project, regardless of project size or team size. I have worked on software projects by myself, and I still use TFS. It's great for giving me a source control and a place to plan out and prioritize my work. And if my team of one were to grow, even to two, the project would be all ready for a collaborative work effort. In teams of larger size, it is a no-brainer.

What do I need to get started?

The first thing you will need is to identify a Team Foundation Server instance to use. Your company may already have an instance ready for you to use. If you are going to be responsible for installing an instance yourself, check out some TFS server planning. If you don't have an instace at your disposal, and you don't want to install/maintain one, you aren't totally out of luck. There are TFS hosting providers starting to pop up as well. Check out TeamDevCentral.

The next step is to install Team Explorer ( 2005 version 2008 version ). Team Explorer will allow you to manage the projects and project components of a TFS instance from within Visual Studio. You may be surpised to know that you do not need a specific Team Edition of Visual Studio to install Team Explorer and use TFS. You can actually install Team Explorer without having Visual Studio installed at all. Team Explorer will install the shell itself. If your TFS instance does not have TFS Web Access configured, Team Explorer will be the primary mode of interaction with your team project.


Here is a example of what the Team Explorer window looks like in the IDE:





You can see the different areas of Work Items, Documents, Reports, Builds, and Source Control are all nicely viewable in the Visual Studio IDE. One of the nicest things about TFS is its integration within the IDE.

Summary

If you aren't using TFS, check it out. That's it. I hope you will continue to follow this blog series. There will be some great posts on some specific topics in the near future.

Here are some additonal TFS / Team System resources:

• patterns and pratices: Team Development with TFS Guide
• Visual diagram of TFS/Team System resources