Silverlight Toolkit March 2009 Release
This week we released an updated Silverlight Toolkit - the Silverlight Toolkit March 2009 release. This release has some new components, but we spent a lot of time working to make sure that the Toolkit can be updated in an agile way, but still fits in nicely with other platform and tools releases.
Goals for the March 2009 Release
1. Align the Toolkit with the SDK
The main thing that we wanted to establish was a smooth flow of components from the Toolkit into the platform, in this case the SDK. Most Toolkit components are things that people will want to have in their default tooling experience, and one of our goals is to minimize the number of things that developers must download to get productive with the platform. So the first order of business was to setup the Toolkit to be primarily an incubation vehicle for SDK components. So most components start in the Toolkit, and end up eventually in the SDK that comes with Visual Studio or Expression Blend.
This also meant pulling the existing SDK controls into the Toolkit package. With the March 2009 release, you'll find the source code for all of the Silverlight 3 versions of the SDK controls - DataGrid, Calendar, TabControl, etc. As with the rest of the Toolkit, this code is licensed under MS-PL so you're free to modify it or use it in your application.
2. Do the work to support Silverlight 2 and Silverlight 3
With Silverlight 3 coming into the picture, we needed to structure the Toolkit project to be able to handle both versions. Our philosophy is to do as much work in the Silverlight 2 Toolkit as possible, then just do things in Silverlight 3 that have a dependency on the new runtime. We'll continue to support Silverlight 2 up through the release of Silverlight 3, then we'll focus on Silverlight 3 exclusively as customers upgrade. On the Release page you'll see a Silverlight 3 Beta and Silverlight 2 installer.
3. Fully support the Blend and Visual Studio development environments
I've always been a big believer in delivering great design-time experiences. We've done a lot of work with the tools teams to make sure that our components work well with the designers, including having items in the Toolbox and having the right properties show up in the tool. This turned out to be more work than we had anticipated and we're hopeful that any customers that are writing components can use what we've done as a good example of how to make all of this stuff work. We'll keep pushing on making this a great experience over time.
4. Address critical customer feedback
The biggest piece of feedback we've gotten is to have our Samples available in VB.NET as well as C#, so we did the work to make that happen.
In addition, we've fixed the highest-voted bugs in components across the Toolkit including Charting, AutoCompleteBox, and TreeView. Thanks to everyone that took the time to file issues or vote, that data is very helpful to us. One catch here is that some of our components (like TreeView) need to maintain API compat with WPF, so that limits the type of changes that we can make.
We also now have an MSI-based installer package that installs the Toolkit for you and gets the Toolkit control items into the Visual Studio Toolbox or Blend Asset Panel automatically. This helps with the discovery of components and makes them easier to add to your projects. It also sets up a nice Start Menu entry as well:
5. Add new controls
We've also added some new controls - Accordion, DomainUpDown, and TimePicker, all of which are in the Preview band for this release. Check them out!
Toolkit Namespace and Assembly Changes
If you're upgrading from a prior version of the Toolkit, you'll notice that the namespace names for most components have changed from Microsoft.* to System.*. So for this upgrade, you'll need to go through the process of updating your code, so sorry for that up front.
This was something we spent a *lot* of time talking through. The original reason for making the Toolkit components be in Microsoft was so that we could add components to the SDK or the Core and not have them conflict with Toolkit versions. We wanted there to be an opt-in change when developers moved from a Toolkit control to the platform version - we'd delay the need for the user to make a change until the very end. But the user would need to update source code. The more we thought about this, and talked to customers, the more it seemed like this wasn't the right thing to do since it means more-and-more code that you'll need to fix up if you wait longer. Instead, for the components we expected to make it into the platform, it was better to put them into their final namespace and then physically move them into the platform assembly when they were fully mature. This meant having a new Toolkit build with each platform release that has those types removed. But that's something we do anyway, and doing it this way means that customers only need to update their references and maybe their XAML xml namespace, and that's it. Code should continue to run. We decided that was a better model.
In conjunction with that, we needed to make sure that installing or using the Toolkit was something that didn't disturb the supported platform release. So that meant Toolkit assemblies had to be able to sit side-by-side with SDK assemblies. To accomplish that, we appended the word "Toolkit" to the Toolkit assemblies and that makes an easy mapping for where things are in the Toolkit to where they will end up in the SDK.
Here is an example:
Today, System.Windows.Controls.Accordion is in System.Windows.Controls.Layout.Toolkit.dll. Someday in the future, Accordion will reach the Mature Quality Band and then a platform release will happen and it will be moved into the SDK. When the next version of Silverlight ships, we will ship a corresponding Toolkit and SDK. The Accordion component will move into System.Windows.Controls.Layout.DLL ( note no "Toolkit" in there), which is part of the SDK itself . Developers using this component will need to add a reference to that SDK assembly and (optionally) remove the reference to System.Windows.Controls.Layout.Toolkit.dll if it's not needed anymore. The developer would also need to update their XML namespace definition to point to the SDK version of the DLL so that the XAML parser knows where to find it. That should be it, and the project will now be using the SDK version of the component with no code changes.
What this unfortunately means is that we've got quite a few assemblies coming out of the Toolkit. We've tried to intelligently bucket the Toolkit controls into a few different assemblies so you don't have to pay to have a bunch of components in your XAP you're not using. We'll do the same thing for the SDK. But given the above, you get 2 assemblies for each bucket. Unfortunately, that's the simplest solution even if it's a little verbose.
Rebuilding SDK Components
As I mentioned above, the full source for the SDK components is now present in the Toolkit project. The Toolkit only includes source for these components, not the components themselves. Many parts of the system (for example Blend) are tested and built against the released version of the SDK components. We don't want the Toolkit updating these by default, but we do want to allow developers to make fixes to these components and deploy them with their applications if needed. In the Toolkit you'll find a Toolkit solution and an SDK solution so there is a nice separation there. If you do make a change to one of these components, you can just update the reference in your project to your rebuilt version and run against that.
Other Improvements
The Toolkit also includes two great new themes: Bubble Cream and Twilight Blue.
We've added AreaSeries in the Charts
Looking forward to hearing your feedback!
Comments
Anonymous
March 20, 2009
PingBack from http://blog.a-foton.ru/index.php/2009/03/21/silverlight-toolkit-march-2009-release/Anonymous
March 20, 2009
This week we released an updated Silverlight Toolkit - the Silverlight Toolkit March 2009 release.  Anonymous
March 20, 2009
Thank you for submitting this cool story - Trackback from DotNetShoutoutAnonymous
March 21, 2009
Thank you for submitting this cool story - Trackback from progg.ruAnonymous
March 21, 2009
You guys are doing great work. I believe that Silverlight will continue to succeed because of this type of dedication. Thanks a mil!Anonymous
March 25, 2009
The first and foremost thing that you missed if you didn’t attend Mix09 was the opportunity to hang out