Is This My Project or Yours?

In my post last week about Expression Blend, I mentioned that Blend creates and uses the same solution and project files produced by Visual Studio. This raises the question of who should control these files and the solution/project structure. Before we answer that question, we need to examine what we can do in Blend and Visual Studio with projects and solutions. Then, we can consider best practices for collaboration between designers and developers in maintaining projects.

Blend supports many of the same actions as Visual Studio: adding new or existing projects (WPF and Silverlight projects only), managing references, files, and folders, setting a single startup project, and building, rebuilding, cleaning, and running solutions. Blend also contains a few unique actions such as setting the startup XAML page or window and opening a solution, project, or file externally in Visual Studio.

While Blend provides access to some of the common tasks when working with projects and solutions, it is quite evident that many of the developer-centric functions are only available in Visual Studio. You can only edit solution, project, and file properties in Visual Studio. This includes items such as build events, assembly names, and Build Action settings. If you need multiple startup projects, Visual Studio is the key. Blend does not allow you to select a configuration to run. While you can delete files and folders and remove references, you cannot delete projects in Blend. Most importantly, apart from compilation errors, you cannot debug your application from Blend to analyze run-time errors; you must use Visual Studio for debugging run-time errors and obtaining detailed error messages.

If you are creating a prototype or simple application that only needs one project, it is okay to create the solution/project in Blend. Visual Studio can provide any required fine-tuning of the project files, but the simplicity of these types of projects should reduce the need for using Visual Studio to modify project files.

For complex, real-world applications, it makes sense to use Visual Studio for the majority of project creation and control. Developers should be in charge of anything not directly related to the user interface: business objects, data access layers, web services, etc. Blend does not even enter the equation here. Developers should continue using Visual Studio to create solutions and projects as they have been doing. The key here is to abstract the user interface from the rest of the application, eliminating as much conflict as possible between developer and designer.

For the user interface projects themselves, control of the project files should be handled within Visual Studio. This helps to maintain consistency across the entire solution. If a prototype was created, it should be merged with the main solution as soon as possible. However, some control of the structure can be retained by Blend users. Designers can use the ability to create folders in Blend to organize media or XML files that are needed by the UI. In addition, barring a need to have specific XAML files created, all of the XAML files can be created and edited in Blend.

In answering the question about control and structure, I have left out one important item: source code control. All files are manageable in source control; however, Blend does not currently support integration with Visual SourceSafe or other source code control software. Checking items in and out must be done in Visual Studio or using the SourceSafe GUI.