Now that the big news of the Silverlight 4 Beta release is out, we can announce that we've been working hard to update our course to include Silverlight 4 material. Since Silverlight 4 is only in Beta (and no go-live license to boot), the Silverlight Tour will continue to teach Silverlight 3 and show the Silverlight 4 material in addition. This way whether you're building a short-term application you can get your Silverlight 3 needs met, but if you want to learn Silverlight for a long-term project, you can be sure that the Silverlight Tour will prepare you for the Silverlight of tomorrow.
As many of you don't know, I was previously known as "The ADO Guy" so of course my first jump into the new Silverlight 4 bits was to play with the new Data Binding changes. The improvements aren't dramatic but they do fill several key holes that existed in the earlier versions. Let's take these changes one at a time.
Prior to Silverlight 4, in order to support data binding, the object had to derive from the FrameworkElement class which left out some key objects including Transformations. Now data binding works on any object that derives from DependencyObject (which is most of the Silverlight 4 framework). You can see this in the example below. (Note, you can also see the CompositeTransform which lets you set transformations of all four types in a single transform):
As noted in Scott Guthrie's keynote early, Silverlight 4 is now in beta. But what does that mean to you? Silverlight 4 Beta does not have a go-live license, so if you're building something to be released soon, I would stick with Silverlight 3. In contrast if you're working on a longer term project, especially a line-of business application, you'd be crazy to not look at Silverlight 4. Here are some of the major changes in this release:
I've recently been looking at the PagedCollectionView class. For those who are not familiar with this class, it allows you to automatically show sections of a collection in a paged way (especially when paired with the PagerControl). There is a good example on MSDN here:
One week into my European Conference tour and I thought it was time to send you lot a update. My first stop was Sofia, Bulgaria to join the great folks at DevReach. I got in a couple of days early so I could relax and get my time change down.
As some of you may know, I am a contributor to the SilverlightContrib open source project. Recently this project and the Silverlight Extensions open source project (also know as SLExtensions) decided to merge to create a single place for a lot of interesting functionality.
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.
As RIA Services is plodding towards a release, many people are looking at it to help them with validation of data in Silverlight. Using this validation in Silverlight 3 is pretty straightforward but there are some caveats. I want to show you under the covers so you understand what is happening. In this first part of the series, let's look at what it means to use validation from the outside.
Back when Dynamic Data was being developed, a set of attributes was created to help tell the Dynamic Data folks about validation and other metadata so they could create smart scaffolds. These include:
We have made some adjustments in the Fall/Winter schedule for the Silverlight Tour. As Fall is often our busiest time of year, we decided to move some dates around to not conflict with the PDC and other conferences. Here is the new Schedule for the Silverlight Tour and the Advanced Silverlight Workshop:
Today I was working with a client and ran into a problem I didn't expect. This particular problem had to do with Silverlight consuming a WCF Service. Sometimes WCF causes me to spew four letter words. There is a class of WCF problems that cause this: connection rejection. WCF has been designed to prevent common DDoS and other attacks that could cause servers to fail or at least not serve honest requests. To this end the default size of a request is quite small. In fact, its usually 64K in size. This size is fine for most every request but occassionally when a client wants to send a collection of things to the server this size is too small. But we'll get to that in a minute. First, some background...
This particular client has a large service that's been working for quite a while, then suddenly a single call he has was being rejected. The new service call he was making was sending back a list of a couple of hundred of POCO classes. He had been downloading large lists before so on the surface this should have worked. But it didn't.
If you've been following my blog, you should know that I am keeping a pretty close watch on ADO.NET Data Services. The team recently released a second CTP of the new version with some interesting features. This CTP has some pretty compelling additions, but I am going ot focus on one in particular.
I've been teaching and using ADO.NET Data Services for a long time and I like showing off exposing a LINQ-based provider (Entity Framework, NHibernate or others) to a Silverlight application. While ADO.NET Data Services does expose its API through a REST API, the magic for me is in its use in Silverlight. In case you haven't been following along, using the Silverlight client you can issue a LINQ query through the Silverlight client (though in fairness, the full power of LINQ is not supported in the client):
If you've never had the chance to visit my sister site (http://www.silverlightdata.com), now's a good time. I've updated my examples there to include my MVVM, Prism and Declarative UI examples (to go with the skinning/switchable Astoria example). Take a look if you're doing Silverlight data-based applications.
|Using Visual Studio Code for ASP.NET Core Projects (new)|
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||184.108.40.206||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.25211.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|