Posts Tagged ‘Silverlight’

After reading about various ways of using the Silverlight Toolkit (http://silverlight.codeplex.com/) for Windows Phone 7 development, I gave up and tried a different approach.

I am using Windows Phone Developer Tools CTP – April Refresh, which you can download here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cabcd5ed-7dfc-4731-9d7e-3220603cad14

Instead of including Silverlight Toolkit dlls in my Windows Phone 7 Silverlight project, I included only specific source files that I needed. It worked without too much trouble, so unless you need a bunch of controls from the Silverlight Toolkit, I would recommend this simple approach for the DockPanel and WrapPanel controls. I suspect that it will also work for other simple controls.

1. Add a new class-library project to your Windows Phone 7 solution.

2. Add a reference to Microsoft.Phone.

Controls. Your reference list should now include the following: Microsoft.Phone.Controls, mscorlib, system, System.Core, System.Net, System.Windows, and System.Xml. Not all of those may be needed, but they were included by default.

3. Go to http://silverlight.codeplex.com, then switch to the Download tab. At the right, you’ll see a box called Other Downloads. Find the Silverlight 3 Toolkit November 2009 Stable release. Download and install it. (I did not try the April 2010 release because I had been told that not all Silverlight 4 classes will work for Windows Phone 7. Let me know if you succeed with the April 2010 release for Silverlight 4.)

4. Find the source code that you just installed. On my Vista system, I found it here: C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\Nov09\Source.

5. Drag/drop the following source files to your newly created class-library project: Dock.cs, DockPanel.cs, LengthConverter.cs, NumericExtensions.cs, OrientedSize.cs, TypeConverters.cs, and WrapPanel.cs.

6. Also drag Resources.Designer.cs and Resources.resx from the Controls.Toolkit\Properties project to your new project. Once they are in your project, drag/drop them into the Properties sub-folder of your project. In that sub-folder, you should now see three files: AssemblyInfo.cs, Resources.Designer.cs, and Resources.resx.

7. Build it. If it all went well, include this project with any of your other projects that need DockPanel or WrapPanel.

8. Please tell me if these steps worked for you!

Thanks,

Dale Barnard

I like to build abstraction layers over Windows to insulate my applications from the low-level details of the operating system. For example, instead of writing code like

System.Windows.Window window = new System.Windows.Window();

I would instead make my own Window class, which for this example, I’ll call ZWindow. Now the code looks like this:

ZWindow window = new ZWindow();

The ZWindow class will in turn likely create a System.Windows.Window window, which is a WPF window. However, on Silverlight, it might instead create a System.Windows.Controls.Grid since Silverlight does not have a System.Windows.Window class. Thus, the ZWindow constructor might have code like this:

#if SILVERLIGHT
System.Windows.Controls.Grid grid =
new System.Windows.Controls.Grid();
#else
System.Windows.Window window =
new System.Windows.Window();
#endif

If you write an application that uses a ZWindow class, you need not care about the difference between WPF and Silverlight.

After experimenting with various ways of organizing my abstraction layer’s projects and solutions in Visual Studio to accomplish this shared codebase between WPF and Silverlight, I have settled on the following approach:

  1. You cannot mix WPF and Silverlight within the same Visual Studio project. Thus, you need two projects that share the same source files.
  2. Do not think of one project as the primary and the other as the secondary. Treat them equally.
  3. Put your shared source files in a folder of their own—not in the same folder as any Visual Studio project files.
  4. In your two Visual Studio projects (one for WPF and one for Silverlight), link to all of the source files that need to be shared. Thus, you’ll have three folders total—one for the shared source files with no projects, one for the WPF project file with no source files, and one for the Silverlight project file with no source files. (NOTE: In Visual Studio, to link to source files without it automatically copying them to your project’s folder, select “Add Existing Item,” and then instead of clicking the Add button to dismiss the dialog, click the little down arrow on the right side of the Add button and choose Add as Link.)
  5. Create one Visual Studio solution for WPF and another for Silverlight. Do NOT try to cross compile within the same Visual Studio solution. While technically sound, I do not recommend it due to solution clutter. The projects in each solution will look the same, but will be specific to WPF or Silverlight.
  6. Create additional solutions for any applications that need to be compiled with the abstraction layer for either WPF or Silverlight. Do not combine application-specific projects with framework types of projects.

Thus, instead of this:

Folders with shared files:
Project 1 Shared Files
Project 2 Shared Files
Cluttered Solution:
Project 1 WPF
Project 1 Silverlight
Project 1 Smartphone
Project 2 WPF
Project 2 Silverlight
Project 2 Smartphone

Try this:

Folders with shared files:
Project 1 Shared Files
Project 2 Shared Files
WPF Solution:
Project 1 WPF
Project 2 WPF
Silverlight Solution:
Project 1 Silverlight
Project 2 Silverlight
Smartphone Solution:
Project 1 Smartphone
Project 2 Smartphone

In my experience, as projects get larger, the second approach scales more elegantly.

Please feel free to provide feedback for this blog entry and to share your own experiences with multi-platform development.

Thanks,

Dale