You can find an article of 4 pages concerning Windows Azure AppFabric and Windows Server AppFabric in the French Programmez magazine No.137 written by me and Jean-Luc Boucho.
First Page and Second Page (low resolution)
Second and Third Page (low resolution)
The article is written in French but as always I will write some English articles on my Blog in the next weeks. So stay tuned if you are interested in knowing how Windows Azure AppFabric compares to Windows Server AppFabric.
In my last posts I showed you the new features of C# 5.0 concerning asynchronous programming based on the CTP of October. In this article I am going to focus on exception handling in such an asynchronous environment.
So how would you add exception handling to something that is executed asynchronously? Well in C# 4.0 this was very difficult to achieve. In C# 5.0 it is much more straightforward because you just have to wrap the asynchronous function call with a standard try/catch block.
Adding Asynchronous Exception Handling
Lets take the asynchronous function call which I introduced last time and add some exception handling by wrapping it as explained with a standard try/catch block.
Additionally I added code to throw a simulated exception within the function that calculates the factorials. We will then be able to analyze what happens when this function throws an exception.
When executing the application we see that everything is working correctly. The exception is caught and we may look in detail what properties values it contains.
The CTP added some new exception language features that you can now see in action. Looking at the exception details and the stack trace you may note that the Source is the AsyncCtpLibrary and that the TargetSite/ReflectedType is System.Runtime.CompilerServices.TaskAwaiter.
Conclusion
You see that the CTP adds features that greatly simply asynchronous exception handling. Exceptions get more comprehensible and easier to exploit in such an environment. Developers do not have to learn any new methods or use complex workarounds to handle exceptions correctly. There is no difference for them between synchronous and asynchronous code which is a great help!
My last article introduced the new asynchronous features in C# 5.0. I took an easy development example that calculates factorials for showing you how you may implement it in a synchronous and asynchronous C# 4.0 environment - a time consuming and not so easy task for the common developer.
In this article I am going to explain how you could do it when using the latest C# 5.0 features that were released with the current CTP. You will see the code necessary to make your synchronous code asynchronous and how simple and comprehensible it is done when using the new async / await language features!
Factorials Asynchronous Code in C# 5.0
For being able to develop the C# 5.0 version of the code you need to have the CTP October Release installed and to reference the “AsyncCtpLibrary.dll”. Then you are ready to test the new features.
The main function gets a new section that calls the asynchronous C# 5.0 code. All three cases can now be executed from the main function for being able to compare the results.
Now we need to implement the calling function that will start the asynchronous processing and wait for the asynchronous result. There are already changes in the function prototype since you need to add the async keyword before the function return type to mark the function to be asynchronous.
Furthermore you can see that I use the new await keyword in front of the function call which is done inside the function body. This will assure that the code inside of this function below this line is only executed when the asynchronous processing is finished. A calling function must have at least one and can have multiple await keywords.
The main differences exist in the implementation of the function that will execute the factorials calculation code. You already see that the keyword async is used before the return type (similar to the function above).
But if you look carefully you can see that the Task<T> class which was introduced in C# 4.0 for Parallel Programming is used as return type. Knowing that all asynchronous functions have to either return Task or Task<T>, this indicates that the new asynchronous features work hand in hand with the TPL.
Within the function body we create an execute a new Task<T> and define the code that should run asynchronously, which is exactly the same that was used in all examples before.
Please also note the await keyword after the return statement that indicates that the return will only be done when all asynchronous operations within the function are completed.
When executing the application the part that handles the asynchronous call makes that the factorial calculation is done in the background and the result is displayed when it is finished (similar to the example I presented in my last blog post).
Each step is marked in the logical order they are executed :
When starting the application and entering a valid value you see that there is no more delay getting the output for Step3 and Step4 (as you have already seen for the C# 4.0 example). The application is not blocked by the processing which is done in Step2. When the asynchronous processing in Step2 is finished the result is written to the Command Line. That is why the execution order is different from the logical order.
So the behavior is exactly the same but the code is much leaner, more elegant, easier to maintain and to understand. The async / await keywords greatly help to facilitate the migration of you synchronous code to its asynchronous version. No more hassle with synchronization contexts, delegates, events or wait handles. No more spaghetti code that has CallBacks allover the place where you may get very confused during design and even during runtime.
A developer may take this code and easily see what happens in which order. He may maintain or extends this kind of code very quickly. So in the end it leads to a higher productivity of developers who may concentrate once more on generating applications with high business value.
Conclusion
This article described the new features in C# 5.0 which will help to develop asynchronous code in a much quicker and cleaner way than it was possible before. Please take care that those functionalities are currently in CTP state so their final implementation may differ slightly from what I have shown you above. I will continue posting about those very interesting features and will give you updates if there are any changes in the final version of C# 5.0 which may still take some time to be released.
You can download the source code from the source code section of my Blog:
Most of todays applications are developed to work sequentially. Developers are quite used to the sequential approach since it is easy to be implemented and easy to understand. But it makes no sense to always respond to development problems by using this approach. Furthermore, the user has to wait until each of the sequential operations have finished until the next ones can be processed. Sometimes this means waiting for a result on the user side – and users don’t like to wait!
There are multiple reasons why developers may want to structure their code in an asynchronous way. Sometimes it is to allow a better user experience (not waiting anymore) or better perceived performances and sometimes it is due to technical restrictions (such as for Silverlight for example).
The current version of C# 4.0 integrates everything necessary to implement asynchronous code manually. But as you might already know asynchronous code quickly gets unreadable and hard to maintain. But this is going to change in the future version of C# which will include a new abstraction layer that will greatly ease asynchronous programming.
I will take the example of calculating factorials in a Command Line project during these blog posts. But you may take any other code that you want to render asynchronous.
In the first step I am going to write the synchronous C# 4.0 version of the code. I will then show you how you could modify your code in C# 4.0 and C# 5.0 to make the same code asynchronous.
Factorials Synchronous Code in C# 4.0
The main function in the example project contains the user input code as well as the synchronous function call. I did not add any error nor exception handling for simplicity purposes.
The synchronous function contains the main application logic: factorials calculated via a for loop (no recursion for simplicity purposes). I also added a Thread delay to simulate calculation time.
Each step is marked in the logical order they are executed:
If we start this application and enter a valid value you can see that there will be a certain delay until you will get the output for Step2 and Step3. This is completely normal and due to the synchronous calling.
So the processing is blocked until all operations in the synchronous order are completely finished. If you don’t like this behavior then look carefully at the next sections!
Factorials Asynchronous Code in C# 4.0
The next step consists of extending the existing project by adding some new functions and modifying the existing main function. In the main function a new asynchronous function call is added.
To render the code asynchronous we need to add a delegate which will be used to decouple the function call. In my example I also use a CallBack function and a AsyncOperation. You could do this differently but I choose this approach to show how complex it can get when migrating you code to be asynchronous in the current version of C#.
The function with the application logic is the same as in the synchronous version of the code. The only difference will be that it won’t be called directly but by using the delegate that was defined above.
The callback function contains the business logic that is applied when the asynchronous call is completed.
I added also some logic to be able to get informed via an event when the CallBack function has finished (not used anywhere in my code however). But you might need to be informed when the asynchronous operation has been terminated.
When executing the application the part that handles the asynchronous call achieves that the factorial calculation is done in the background and the result is displayed when it is finished.
Each step is marked in the logical order they are executed :
When starting the application and entering a valid value you see that there is no more delay getting the output for Step3 and Step4. The application is not blocked anymore by the processing which is done in Step2. When the asynchronous processing in Step2 is finished the result is written to the Command Line. That is why the execution order is different from the logical order.
In most of the applications high level modules are directly linked to low level modules (in other words are dependent on them). High level modules contain most of the time complex logic whereas low level modules serve for basic and primary operations. It is evident that this may lead to dependency problems between those modules.
An application that shows this problem could be structured like this: the Presentation Layer is dependent on the Business Layer which itself is dependant on the Data Layer.
In this layer design, modifications to low level modules force modifications to high level modules that are dependant on them. This leads to high level modules which can not be reused in different technical contexts.
The Dependency Inversion Principle (DIP) therefore explains that high level modules must not depend on low level modules. Both of them have to depend on abstractions. Furthermore abstractions must not depend on details but instead details have to depend on abstractions.
The underlying concept is that abstractions serve as links between high level and low level modules. Abstraction are most of the time expressed via interfaces but the Factory Design Pattern may also be used.
After having applied the principle, the class in the following example is completely independent from other classes, all references being expressed via interfaces.
In the next example, which is based on the Factory Pattern, the class ValidationManagerFactory is used to resolve all dependencies. It associates an object that is implementing the IValidatable interface with an object of type ValidationManager.
The introduction of interfaces allows the inversion of dependencies, which leads in the layers example to layers that are completely independent from each other.
To sum it up, the Dependency Inversion Principle (DIP) provides a high level of flexibility because modules really get reusable easily. All rigid links that may exist between modules are broken up. But by adding a higher level of abstraction, the code gets more complex to understand and to maintain. So this principle must be applied with caution.
This principle demands that clients should not be forced to depend on interfaces they do not use. An entity (class, service, …) is client of an interface, if it uses a class that implements the interface.
Applying this principle is fairly easy. A similar methodology to the one already used in the Single Responsibility Principle (SRP) must be applied. When developing services, it is often necessary to have classes with multiple responsibilities. The Interface Segregation Principle (ISP) permits to limit class coupling between the different classes in this case.
In the following example the class BusinessObject has multiple responsibilities (implements multiple functional groups) like creation, update, validation and deletion.
Please note the usage of the interface IBusinessObject instead of the class BusinessObject. This approach is called Interface-Based Programming. It allows programming against interfaces instead of concrete classes. Thus, all classes implementing the interfaces required by those functions can be passed as parameters to them. This already provides some degree of independency, but there are still flaws in this class design.
Each client only uses some aspects of the defined interface:
Modifications of methods concerning the validation imply modifications to the whole interface IBusinessObject and indirectly to the PersistManager class. Even though the PersistManager class does not even use those methods !!
We need to find a solution to achieve that different clients only depend on functionality and access methods that they really use.
The first step consists of regrouping all methods that belong to the same functional group in specialized interfaces. Similar to what we already did for the Single Responsibility Principle (SRP) only this time with specialized interfaces as output.
The interface IBusinessObject is separated into two more specialized interfaces IPersistable and IValidatable. It then inherits from those newly created interfaces.
Now it is possible to use the different functionalities Persistence and Validation separately as well as using both at the same time. Modifications can be done without any impact between those two functional groups, they evolve independently from each other.
The next step is to replace the current usage of the interface IBusinessObject with the specialized interfaces IPersistable and IValidatable where applicable.
To conclude I would like to underline that in terms of decoupling multiple specialized interfaces are better that one big global interface that contains everything. This approach can also be applied to abstract classes since they might somewhat be considered as interfaces.
This principle is complementary to the Open Closed Principle (OCP). It suggests that methods which use a certain class must be able to use its derived classes without even knowing them - a base class must be substitutable by its derived classes, without the necessity of changing any code in the method using it.
There are two violations of this principle: one more conceptual and the other more functional.
The conceptual violation is most of the time easy to detect because it violates the Open Closed Principle (OCP) at the same time. It consists of determining the concrete types of objects to do the adapted treatment in methods. Verifying concrete types or using casts may indicate this violation.
The following code example shows such a case :
In this example the PrintShapeArea(…) method needs to know the concrete type of the passed object for being able to call the adapted method which returns the correct shape area.
When a new shape type needs to be added, the PrintShapeArea(…) method needs to be modified (violation of OCP). Furthermore object that are used in this context get tightly coupled to the class that contains the PrintShapeArea(…) method.
To prevent this kind of violation the usage of cast, is, as and GetType (working with object types) must be avoided at a maximum.
A good solution is to apply the Open Closed Principle (OCP) as already explained. If we take the same class design from last time, we need to add a GetArea(…) method to the abstract base class Shape. The derived classes need to override this method with the correct shape area calculation.
The PrintShapeArea(…) method can now be simplified and is now able to handle all derived classes transparently without knowing them. The base class and its derived classes get substitutable.
The functional violation is much harder to find because it is not due to an error in class design but a modification of internal behavior. Methods may expect certain behaviors of classes they use. Derived classes may change this behavior and the results of operations may differ from the expected results.
The solution to this problem is the Design By Contract approach. This approach assures that functional constraints are respected all the time. It assures that the initial behavior stays the same and that objects always have the correct states.
There are three types of contracts:
The necessary classes and methods for the Design By Contract approach are already integrated in .NET Framework 4.0 in the CodeContracts namespace System.Diagnostics.Contracts. But they can easily be added in older versions of.NET.
The Open Closed Principle says that all software entities (like classes and methods) must be open for extension but closed for modification. This sounds odd, because those two rules seem to be contradictory. This article shows how to combine them and how to make your source code even more extensible and maintainable.
So how can a class or method at the same time be open for extension but closed for modification ?
A quick answer is : leave existing code unchanged and allow for extensions only by adding new code. This minimizes at the same time the possibility of regressions, behavior changes and bugs. The application gets more robust and provides a higher level of maintainability. Extension can be done without worrying about the overall stability of the application. All very good things !!!
But the code needs to be correctly structured to achieve this goal. Lets look an example, which shows the principle in action. In this example we start from an implementation that does not respect the Open Closed Principle. Then I apply the principle and you will see how the quality of the code will be ameliorated.
The current implementation contains a single class Shape with a property called ShapeType (possible values Square and Circle).
Furthermore, the application contains the method DrawAllShapes(…), that displays the different shapes on the screen.
This approach has a major flaw: if new shapes are added, then existing code needs to be changed (ShapeType, DrawAllShapes, etc..). This makes the code hard to understand, to extend and to maintain over time.
So what could be the solution in this case ? In object oriented programming we know the concept of inheritance, which should be applied to avoid the necessity to change existing code.
The complete class design must be changed !
A new abstract class Shape with an abstract method Draw(…) should be created. Then different classes for each shape type, that inherit from the abstract Shape class, need to be defined. They contain the specific code that serves for the display on the screen.
The DrawAllShapes(…) method must now be adapted and simplified in the last step. It should only contain the call to the Draw(…) method of objects that are treated.
If you now get the business need to add a new shape type, you only need to create a new class that inherits from the abstract class and implement the special Draw behavior. So extensions become very easy to do. And you do not touch the existing structure anymore (or at least only in very rare cases).
When respecting this principle, your code gets correctly encapsulated, easily reusable and much simpler to maintain.
This is the first principle that I want to show you that will help you to create code that is much less coupled. Code based on this principle becomes much easier to maintain, to evolve and to understand.
Most developers have the tendency to put too much functionality into a single class. Sometimes this is due to bad design, sometimes this is due to the extension of existing code.
Behaviors that should be independent are put together. Those behaviors get tightly coupled and dependant on each other. Changes to a single behavior might impact the other parts of the class (other behaviors).
This may lead to regressions and problems when code needs to be maintained or extended.
The Single Responsibility Principles explains that a class should only have one and a single responsibility. It should serve for only one purpose. Behaviors that belong together must be encapsulated in a single class. But behaviors that are independent from each other must be located in different classes.
When developing new code (or when extending existing code) there needs to be a first phase of conception and design. Within this phase an unordered list of all behaviors and methods is generated, necessary to fulfill the needs of the application (or describing the extensions).
Based on this list the developer creates the class model. Each class generated has a single responsibility. He takes each of the entries in the list and either affects them to existing classes or creates new classes (if the responsibility is not yet covered).
When looking at the following (very simple) example it becomes clear what needs to be done.
The class Modem has more than one responsibility:
To avoid this tight coupling 3 different class must be created that may then be used together in aggregation or composition.
Thus each class class has now only one responsibility:
Modifications to Connection Handling and Data Transfer can now be done independently in each corresponding class without any impact.
You can find an article of 4 pages concerning Visual Studio 2010 and UML Modeling in the French Programmez magazine No.135 written by me, Guillaume Rouchon and Loic Baumann.
Second and Third Page (low resolution)
The article is written in French but as always I will write some English articles on my Blog in the next weeks. So stay tuned if you are interested in knowing how to use Visual Studio 2010 for UML Modeling.
Anders Heijlsberg presented the future features and extensions of the next release of Visual C# 5.0 during his PDC talk.
The most interesting feature is the new approach to asynchronous programming. Today it is possible but not always very easy to go fully asynchronous. Developers have to write complex code that gets quickly very ugly and incomprehensional.
This is going to change in the future. The next version of Visual C# will get new keywords (async / await) that greatly help to simplify asynchronous programming.
Developers will write their code in a synchronous approach (nothing will change at all). And they will be able to make the code asynchronous just by using the “async” and “await” keywords in the right places.The rest in abstracted out from the programmer.
As it was already done in the Parallel Programming approach, the goal of Microsoft is to keep Asynchronous Programming as simple as possible. Developers may concentrate on added business value and not the environment. These new language features will make C# and .NET even more beginner friendly and will help developers to be much more productive.
You can download the CTP version that you can use for R&D and testing here.
MSDN page that fully explains the new async features :
http://msdn.microsoft.com/fr-fr/vstudio/async%28en-us%29.aspx
Get this free eBook on Windows Phone 7 programming written by Charles Petzold and published by Microsoft Press. It contains 24 chapters and around 1000 pages that will help you build Windows Phone 7 application fast. This is an exclusive possibility to learn how to program for the new version of Windows Phone.
Get the PDF here. And the code samples here.
After multiple years of experience in the software development sector it becomes clear that the principles of object oriented programming are often misused, not correctly applied or simply just ignored by many developers.
Even if the basics seem to be easy, there are often big problems in their realization which may lead to:
The S.O.L.I.D. design principles that help to prevent all of these problems and allow the writing of high quality code are:
I am going to present and explain each of these principles in detail. I am also going to show examples in C# that will help you to understand how to apply them in your code.
You can find an article of 5 pages concerning S.O.L.I.D. Software Design Principles (applied in C#) in the French Programmez magazine No.133 written by me and a colleague.
Second and Third Page (low resolution)
Fourth and Fifth Page (low resolution)
The article is written in French but as always I will write some English articles on my Blog in the next weeks. So stay tuned if you are interested in knowing how to write clean and robust code using the S.O.L.I.D. Principles.
Microsoft has released its first Visualization & Modeling Feature Pack for Visual Studio 2010 Ultimate. It adds new functionality to Visual Studio 2010 and is completely free for MSDN Subscribers. The new UML features really help and are indispensible in your daily work when modeling and working with code at the same time.
Feature Pack Content
Increased Visualization Support
Increased UML support
Increased support for Layer Diagram Extensibility
MSDN Download Link
You can download it from here (MSDN Subscribers only):
http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx
The last article concerned migration issues and their possible solutions. This part of the series talks about obsolete functionality in the latest version of the .NET Framework and what happens if you still need to use those functionalities.
Usage of obsolete types and members
Each new .NET Framework version adds new types and members that provide new functionality. Existing types and members change. Sometimes types are replaced because the technology that they where used for was deprecated. In other cases new types and members are more complete and easier to use.
To assure the highest possible compatibility with preceding versions, those obsolete types and members are not directly deleted. Instead they are marked as obsolete using the attribute “ObsoleteAttribute”. They still work even in the latest .NET Framework versions.
If code that is using obsolete types or members is recompiled, the compiler might raise warnings or in some cases even errors (which must be modified). Code that was compiled with an old version of the compiler and that uses obsolete types and members will however always execute correctly, even after the migration to the .NET 4.0 Framework.
Obsolete Types
Obsolete Members
Additional Information in MSDN
For further information on this subject and much more obsolete types and members, please visit Microsofts MSDN site:
http://msdn.microsoft.com/en-us/library/ee461503%28v=VS.100%29.aspx
http://msdn.microsoft.com/en-us/library/ee471421%28v=VS.100%29.aspx
The last part of the series showed the Visual Studio 2010 Conversion Wizard. This part explains what needs to be done in case of migration issues.
Most of the changes in .NET 4.0 do not require any code modifications. But sometimes you will encounter problems and that is where you will need to apply some workaround solutions. I am going to show you some examples of these solutions in this article.
Core
Access to configuration files was modified. If your configuration file is named “MyApplication.config” you will have to rename it to “MyApplication.exe.config”.
ASP.NET
When using the Conversion Wizard within Visual Studio 2010 to convert your ASP.NET 3.5 applications to ASP.NET 4.0, the Web.config file is also modified in the process. It contains new parameters that might not be exactly configured as you like it.
Windows Presentation Foundation (WPF)
The XAML parsing was modified. XAML attributes cannot contain more than one period anymore.
The following are valid examples after the migration:
<button Background="Red"/>
<button Button.Background="Red"/>
The following is not accepted anymore after the migration:
<button Control.Button.Background="Red"/>
Additional Information in MSDN
For further information on this subject and much more workaround solutions, please visit Microsofts MSDN site: http://msdn.microsoft.com/en-us/library/ee941656%28v=VS.100%29.aspx
The last article showed basics on how to migrate to Framework .NET 4.0. This article shows the Conversion Wizard of Visual Studio 2010.
Conversion Wizard Visual Studio 2010
Visual Studio 2010 provides a Conversion Wizard that helps converting old projects and solutions to the new Visual Studio 2010 format (similar to the conversion wizard within Visual Studio 2008 ).
The converted projects and solutions replace the existing ones so take care to do some backups before the migration.
If projects cannot be converted, they are marked as unavailable in the Solution Explorer until the problems are resolved and they are correctly converted.
To migrate multiple projects or solutions it is possible to create batch files and execute the migrations in batch mode.
The new version of .NET Framework 4.0 was released last month together with Visual Studio 2010. An important question is how to migrate existing applications. This series of articles provides information on how to proceed and what you can expect when doing the migration.
Version Compatibility
In most cases the .NET 4.0 Framework is fully compatible with applications that were developed using past versions of the .NET Framework (1.1, 2.0, 3.0, 3.5).
Version Compatibility assures that an application that was developed using a past version of .NET should also work on a more current version. Moreover, source code that was written using an old version should also compile on the current version.
Simple migration
After installing the new Framework version, the old assemblies do not need to be recompiled. Instead you may execute old and new assemblies Side-By-Side (SxS). It is now possible to to have different versions of the CLR running in the same application and they can even communicate with each other.
If you need to force the usage of CLR 4.0, you only need to add an application configuration file that contains the version specifications. You do this by specifying one or multiple <supportedRuntime version="vX.X" /> elements (the first being your preferred version).
The following values are currently possible:
| Framework .NET Version | Version String |
| 4 | v4.0 |
| 3.5 | v2.0.50727 |
| 2.0 | v2.0.50727 |
| 1.1 | v1.1.4322 |
| 1.0 | v1.0.3705 |
Example of a configuration file for .NET 4.0:
If you need to migrate a large amount of applications it makes more sense to do the migration on machine level. There is the registry key “OnlyUseLatestCLR” that serves for this purpose.
To deactivate la functionality, you only need to reset the value of the key to OnlyUseLatestCLR=dword:00000000.
You can find an article of 3 pages concerning .NET Framework 4.0 migration in the French Programmez magazine No.130 written by me and a colleague.
Second and third page (low resolution)
The article is written in French but I plan to write some English articles on my Blog in the next weeks. So stay tuned if you are interested in knowing how to proceed when migrating your .NET applications (1.1, 2.0, 3.5) to the latest .NET Framework version!
A quite interesting event for all Microsoft Certified Trainers is coming this year in April (and it’s for free !!!).
This is the place to connect to other MCTs and get information on the latest technologies and training techniques. Don’t hesitate and inscribe yourself.
You can find the agenda here:
http://www.mctvirtualsummit.com/Uploads/MCTEducatorVirtualSummitDownloadAgenda.pdf
