Head over to Channel9 to read more about the official release. The setup package (available here) contains the components for .NET 3.5 SP1, .NET 4, Silverlight 4 and Windows Phone 7.
[Updated on 02 Jul 11 after the Rx official release: Renamed Run to ForEach]
[If you don’t know what Ix (Interactive Extensions for .NET) is, then I recommend reading my earlier post.]
There are very good resources (like this video) on Ix operators so I am not going to spend too much time on this but I am going to talk about a few of these operators (my top three) to show how the interactive extensions can make your code easier to write and read.
I will use unit tests to express the functionality I am expecting and will then provide potential solutions without using Ix, and finally showing how Ix would simplify the implementation.
For the code snippets, assume that all methods (excluding the test methods) live in a static class named MyEnumerableScrathPad.
You have an object of type T and want an enumerable sequence of T, which includes that object only.
[TestMethod]
public void ReturnTest()
{
var item = new object();
var returnedItem = MyEnumerableScratchPad.Return(item).Single();
Assert.AreSame(item, returnedItem);
}
public static IEnumerable<T> Return<T>(T item)
{
return new T[] { item };
}
public static IEnumerable<T> Return<T>(T item)
{
return EnumerableEx.Return(item);
}
You have an enumerable sequence of T and you want to add an instance of type T to the beginning of that sequence.
[TestMethod]
public void StartWithTest()
{
var count = 10;
var zero = 0;
var originalRange = Enumerable.Range(1, count);
var newRange = MyEnumerableScratchPad.StartWith(originalRange, zero);
Assert.AreEqual(zero, newRange.First());
Assert.AreEqual(count + 1, newRange.Count());
}
public static IEnumerable<T> StartWith<T>(IEnumerable<T> originalSequence,
T first)
{
var list = originalSequence.ToList();
list.Insert(0, first);
return list.AsEnumerable();
}
This will make the test pass but this implementation may force you to iterate through the items unnecessarily because of the call to ToList. We were also lucky that this implementation passed the test. If you change the value of count from 10 to int.MaxValue – 1, the test will horribly fail with an OutOfMemoryException. So the idea of converting the enumerable to a list is not a good one.
public static IEnumerable<T> StartWith<T>(IEnumerable<T> originalSequence,
T first)
{
yield return first;
foreach (var item in originalSequence)
yield return item;
}
This implementation does not suffer from the problem shown above and passes the test after a fairly long delay (around 10 seconds on my laptop), which is expected as a result of the call to Count, which will iterate through the sequence and one can argue that this is not a good test but it fits the purpose here.
public static IEnumerable<T> StartWith<T>(IEnumerable<T> originalSequence,
T first)
{
return originalSequence.StartWith(first);
}
Ix also has another overload for StartWith, which takes a param array of items to be inserted at the beginning of the sequence, which can be handy.
You have an enumerable sequence and you want to perform an action for each item of the sequence.
[TestMethod]
public void ForEachTest()
{
var list = new List<int>();
var range = Enumerable.Range(1, 10);
MyEnumerableScratchPad.ForEach(range, list.Add);
CollectionAssert.AreEqual(range.ToList(), list);
}
public static void ForEach<T>(IEnumerable<T> sequence, Action<T> action)
{ foreach (var item in sequence)
{
action(item);
}
}
Clearly this is a valid solution but we are looking for a more compact solution.
public static void ForEach<T>(IEnumerable<T> sequence, Action<T> action)
{
Array.ForEach(sequence.ToArray(), action);
}
public static void ForEach<T>(IEnumerable<T> sequence, Action<T> action)
{
sequence.ToList().ForEach(action);
}
Implementations #2 and #3 are not ideal as they both force the enumeration of the sequence before the iterating through the items begins. This is not necessarily a problem but there are some cases where you want to perform the action as soon as the sequence yields a new value.
public static void ForEach<T>(IEnumerable<T> sequence, Action<T> action)
{
sequence.ForEach(action);
}
Because most of the Ix operators including ForEach are ported back from the Rx world, there are some interesting additional overloads for ForEach. For example, there is one that takes action of T (the action that needs to be performed on each item) and then another action that will be performed when the iteration over the sequence is completed.
These three operators (Return, StartWith and ForEach) are among the simplest of the long list of Ix operators but nonetheless they are the ones I use most as they make code more concise and easier to read.
[Updated on 02 Jul 11 after the Rx official release]
I have to start this post with a clarification: “Ix” is not the name of an official product. I am just calling it so to highlight the benefits of this less known part of the Reactive Extensions or “Rx” (which is a real product by the way).
Interactive Extensions used to be part of the Rx library but they can now be downloaded separately. Rx is now officially released and the stable version can be downloaded from here. Ix is now packaged separately and its experimental release can be downloaded from here. Both of these components are also available on the main Nuget feed.
Even many developers who are using Rx are unaware of this interactive part of the library and I believe it deserves more attention. But let’s start with Rx, just in case you don’t know what it is.
Rx is a library developed by Microsoft, which allows you to write applications that react to events using a nice and clean implementation of the observable pattern. Rx started off as a Microsoft DevLabs incubation project but it proved to be very popular so its incubation period was ended in April 2011 and since then, it has been moved to the MSDN Data Developer Center.
I refer to the interactive part of the Rx product family as “Ix”, which deals with enumerable sequences (IEnumerable<T>) whereas Rx focuses on the observable sequences (Observable<T>).
If you have watched Inside the Rx video on Channel9 or read Bart De Smet’s blog post on this topic, you already know that enumerable sequences are the duals of the observable sequences. When the Rx team created the operators for the observable sequences, they also back ported some of those operators to the enumerable world and that is how Ix was born.
The following diagram shows the dependencies between major Rx and Ix components. Note that the reactive extensions come with a few more assemblies (related to async support, client profile and more) which are not displayed here.
So like Rx, Ix takes a dependency on:
- CoreEx: Providing the core functionality such as a selection of helpers for disposable objects, schedulers and concurrent data structures.
- System.Observable: Containing IObservable<T> and IObserver<T> interfaces. [Not applicable to .NET 4.0 as it is included in mscorlib 4.0]
The pre-release versions of the Rx product family consisted of various components such as System.Reactive, System.Interactive, CoreEx and System.Observable (for all runtimes except .NET 4.0). In the official release, the component structure is simplified and there are only two assemblies involved: System.Reactive and System.Interactive. All of the types required by those assemblies are now embedded in so for example, the IObservable and IObserver interfaces for runtimes other than .NET 4 now live inside System.Reactive. Same applies to the disposable and scheduler types.
If you are not using Rx family for whatever reason, it is now a good time to do so. I will go as far as saying:
If you are a .NET developer, then you should be using Rx and/or Ix in your projects or you are doing something wrong!
You might say I am taking it too far but I insist! If you are using Rx already, then you know what I am talking about. If you aren’t, you will know it when you start using it. Rx targets various platforms and frameworks including .NET (3.5, 4.0 for both client and full profiles), Silverlight (3, 4, 5), Windows Phone, Xbox and Javascript so you can use it in any .NET project.
These extensions can be downloaded by following the links on the product landing page on MSDN. You can also find a variety of Rx and Ix components on the official Nuget feed.
The primary type in Ix is the EnumerableEx type, which adds a long list of operators (in the form of extension methods) to IEnumerable<T>, plus a few operators for enumerable sequence of numbers (to support average, min, max, etc).When developers look at the list of operators provided by these extensions, most people ask “Why aren’t these included in .NET Framework anyway?”. I think (and hope) that this is just a matter of time before they make their way into the framework. Once you start using these extensions, you will soon find out that you cannot live without them, especially if you use LINQ frequently.
In the next post, I will briefly go through some of the Ix operators to show how it can help you in writing code that is easier to write and read.
WPF applications have one dispatcher associated with their main UI thread. The main UI thread is the thread the Application class is instantiated on. When you create a new thread in the application, WPF allows you to create a new dispatcher for that new thread. This enables the windows created on the new thread to process the user input and because this is happening on a different thread, the processing of messages doesn’t impact other windows in the application. This can be very useful if you are developing a responsive application with multiple views. However, you need to understand the impact of having multiple dispatchers on the WPF application model.
Like many UI elements, some of the properties of the Application object can be accessed from the main UI thread only. For example if you try to access the MainWindow or ShutdownMode properties from any UI thread other than the main one, an InvalidOperationException is raised saying you can only access it from the thread that created it.
The Application object also has a property called Windows, which is an enumerated list of windows created in the application. As you can expect, if you try to access this property from another thread, you will receive an error. Now what happens if you marshal the call back into the main UI thread by calling Dispatcher.Invoke (or BeginInvoke) or access the property from the main UI thread? It will only include the windows that were created on the main UI thread and it won’t enumerate the windows created on the other threads. If you need a list of all windows in the application, you need to manage this yourself. If your application creates windows on multiple threads, I don’t think creating a plain list of all windows created in the application would be a good idea anyway as you may need to handle interactions with those windows differently.
This is a link post with links to tutorials, samples and training courses covering the recent releases of Microsoft’s development platform tools and technologies.
Visual Studio 2010 and .NET Framework 4 Training Kit (June 2010)
Covers:
Identity Developer Training Kit (June 2010)
Covers:
Windows Azure Training Kit (June 2010)
Covers:
Windows Server AppFabric Samples (June 2010)
Covers:
Silverlight 4 Training (April 2010)
Covers:
The RTM version of Visual Studio 2010 and Team Foundation Server 2010 is now available for download as a virtual machine. The VM image also include a sample application and sample data to support the accompanying hands on labs. This image does not include the Visual Studio Lab Management 2010 but the team are working on it.
The virtual machine image comes in multiple flavours to support these virtualization technologies: Hyper-V, Windows Virtual PC (for Windows 7) and Virtual PC 2007 SP1. All of these images will expire on 15 Dec 2010.
Refer to Brian Keller’s post for additional details.
I find myself answering questions related to the presentation patterns repeatedly. Since I am a lazy person, I am writing this post to illustrate my understanding and interpretation of the Model-View-* patterns and their variations so I can refer back to this post later.
[Update] I have discussed these patterns and their contexts with my colleagues Josh and Rupert and have updated the post the reflect the result of our conversation. Thanks guys!
I understand the concerns the Model-View-* purists might have around the correctness and/or pureness of these diagrams so I do apologize for potential inaccuracies in advance and I welcome any suggestions / comments!
I am not going to explain every single Model-View-* pattern as you can find better explanations in other places. Instead, I will focus on the relationship between participant components in each pattern.
Let’s start with a list of patterns we are going to cover:
This is a typical implementation of the good old MVC pattern. The Controller displays the View, make changes to its state and manage the navigation. The Controller can also update the Model (or ask the Model to update itself) and these updates are subsequently reflected in the View.
* What Happened to the MVP Pattern? *
As you may have noticed, the plain MVP (Model-View-Presenter) pattern is not in the above list. If you want to know why, read Martin Fowler’s note on retirement of the MVP pattern. Basically, he has split the MVP pattern into two: Supervising Presenter and Passive View. By looking at the next two diagrams, you will notice why they need to be separated.
In the Supervising Presenter variation of the MVP pattern, Controller becomes responsible for implementing the complex view logic where the data binding between the View and the Model is not able to support that complex logic. Data binding is still the primary mechanism for the communication between the View and the Model and the Controller is used only in those scenarios where data binding support falls short.
Passive View is the other variation of the MVP pattern and it brings the level of supervision of the Controller to the next level. The View no longer updates itself based on the Model and Controller becomes responsible for updating the View based on the data in the Model.
In the MVVM pattern, the View Model inherits most of the functionality that would otherwise be in the Controller. The user gestures are captured by the View and the View uses the commanding feature of the underlying framework to invoke the operations defined in the View Model. Note that there is a dotted line showing the data binding between the View and the Model. This highlights the ability for the view to be bound to the Model via the View Model. Although the View Model can have its own properties the View binds to, but it is very likely for the View Model to publish the underlying Models as properties so the View is effectively bound to the Model (via the View Model).
MVVM makes an assumption that the framework the application is built on provides strong support for two-way data binding between the View and the Model. This diagram shows how simple the MVVM pattern is but this pattern would be really hard (if not impossible) to implement before WPF because of the lack of strong support for commanding and data binding. Even with WPF, implementing a non-trivial application that follows the design shown above can be tricky and will usually require a lot of additional helpers and constructs if we want to rely on data binding only.
The MVPoo (or M-V-poo to be more precise as defined by its creator, Dr. WPF) pattern acknowledges the fact that there is a difference between the ideal world and the real world so that nice and clean implementation of the MVVM pattern is not always achievable. As a result, there will be scenarios where:
So it is very likely that we will end up with a stinky version of the MVVM pattern. The MVPoo pattern acknowledges this fact and says this is okay but we need to try and make the components (with specific attention to the View Model!) less stinky as much as possible (by keeping the number of non-ideal elements/features in the View Model to a minimum).
Windows Server AppFabric simplifies the process of creating, scaling and managing web and composite applications that run on IIS and includes the following components:
You can get the RTW bits using the Web Platform Installer or downloading it directly from here.
The supported operating systems are both 32-bit and 64-bit editions of:
You will also need a version of .NET Framework, depending on the features you want to use (more info):
There are a number of additional resources linked from the landing page, including the Windows Server AppFabric wiki.
When you use the new operator to create an instance of a class, the class constructor is called before the reference to the newly created object is returned. This also applies to the reflection scenarios where you call Activator.CreateInstance, which finds the right constructor based on the number, order and type of the parameters provided.
This is the expected behavior in most cases as you don’t want to work with an object that might be in an invalid state. However, there are cases where you don’t need to run the constructor. A good example is when you are deserializing an object from a byte stream. During deserialization, you will be using the values embedded in the incoming byte stream to initialize the member variables so there is no point in initializing those members in the constructor as they will be overwritten.
The formatters that ship with the .NET Framework (such as BinaryFormatter and DataContractSerializer) follow this approach as you can expect. There is a utility class called FormatterServices, which provides some of the underlying services to the formatters, including but not limited to object creation.
namespace System.Runtime.Serialization { public sealed class FormatterServices { public static void CheckTypeSecurity(Type t, TypeFilterLevel securityLevel); public static object[] GetObjectData(object obj, MemberInfo[] members); public static object GetSafeUninitializedObject(Type type); public static MemberInfo[] GetSerializableMembers(Type type); public static MemberInfo[] GetSerializableMembers(Type type, StreamingContext context); public static ISerializationSurrogate GetSurrogateForCyclicalReference(ISerializationSurrogate innerSurrogate); public static Type GetTypeFromAssembly(Assembly assem, string name); public static object GetUninitializedObject(Type type); public static object PopulateObjectMembers(object obj, MemberInfo[] members, object[] data); } }
When you call GetUninitializedObject or GetSafeUninitializedObject, an instance of the class is created and returned without calling the constructor of the class. But note that the member variables are set to null and zero. FormatterServices is a public class so you can use its published functionality inside your application but you need to be very careful when using Get(Safe)UninitializedObject. As explained in the MSDN documentation, when you use these methods you should immediately populate all fields to make sure the object is not left in an invalid state.
There are some other interesting operations in FormatterServices. For example, GetSerializableMembers returns a list of members that will be serialized by the classic formatters.
One final point on this topic. If you are deserializing an object from a byte stream and want to run a piece of code to initialize the object before it is used (for example to calculate some of the fields that were not included in the serialized format), you will need to use the serialization attributes. See my earlier post on this subject for more information.
[Note: In this post, I am assuming that you are familiar with the TFS Branching Guidance. If you haven't read the guide, I strongly recommend that you do so! I will be referring to the branch names suggested for the basic branch plan.]
Scenario: After an application is released to the production environment, a defect has been raised by the users. The production support team decides to fix this defect before the next version is released so they start by modifying the appropriate files in the REL branch to fix the defect. When the developer working on the defect finishes his job, he shelves those changes and asks the support team lead to review those changes before they are checked in. The support team lead analyses the changes and because of the risks involved, she talks to the users and they agree to wait until the release of the next version to get the fix.
Challenge: When you create a shelveset, the server path of each shelved file is stored with the shelveset so when you try to unshelve that shelveset, the files in the same branch are modified. You cannot unshelve the shelveset to a different branch such as DEV so you will need to do this manually by unshelving to the original branch and then manually copying the modified files across, which is time consuming and error prone.
Solution: TFS 2008 Power Tools includes a command line tool (TFPT.exe), which allows you to perform advanced operations in TFS. One of these operations is the unshelve command, which allows you to change the server path of the files in a shelveset during the unshelve operation. This means you can use this command to unshelve any shelveset to a different branch. In our scenario, the shelveset was originally created in the REL branch so the development team can use the TFPT tool to unshelve the shelveset to the DEV branch.
So let’s assume that the support team have changed the source files in the REL branch and we want to unshelve this shelveset to the DEV branch. In order to do this, we need to:
- Make sure the TFPT command line tool is installed!
- Go to the command prompt and change the folder to a location that is mapped in the desired workspace.
- Run the following command:
TFPT.exe unshelve ReleaseHotFix1 /migrate /source:$/MyProject/REL /target:$/MyProject/DEV
Where ReleaseHotFix1 is the original shelveset name and $/MyProject/REL and $/MyProject/DEV are the server paths to the REL and DEV branches respectively.
When you run the unshelve command with the migrate option, the tool will prompt you to choose which version of the file (in origin or target) you want to keep. It will also allow you to perform a file merge if needed, which will be done in the merge tool.
The following diagram shows the sequence of events that need to happen across multiple branches in our scenario:
Events:
