Localizing WPF Application

I am currently working in WPF application. Many time I get a requirement from my business side is that they want to localize the application in different languages. But this becomes a problem when the requirement comes in later stage of development. Now there could be lots of effort required to achieve completely localized software. There could be many approaches for localizing WPF application. First of all and very common approach is the use of satellite assembly. Second very new approach is the use of tool called LocBaml from Microsoft. LocBaml is very great tool which helps in easily localizing WPF application.

LocBaml, a sample tool in the Windows SDK. LocBaml help in reducing overhead off manually finding localizable control in XAML and manually apply indirection to all of them. When you invoke LocBaml from the command prompt of visual studio, it complete all the manual task of finding and applying indirection to all the localizable controls.

Below are the Steps of creating a satellite assembly with the help of LocBaml:
1. Set Default culture of an application through .csproj file using <UICulture>--> 
The UICulture element should be added under any or all PropertyGroup elements corresponding
to the build configurations you want to affect (Debug, Release, and so on), or to
a property group unrelated to build configuration so it automatically applies to all of
them. Default setting for en-US(English culture) i shown below:
<Project>

     <PropertyGroup>
<UICulture>en-US</UICulture>
</PropertyGroup>
 </Project>
If you rebuild this project with this setting, you will find en-US folder created in same location of your executable assembly. Inside this folder AssemblyName.resources.dll assembly will get created for en-US culture.

You should also mark your assembly with the assembly-level NeutralResourcesLanguage
custom attribute with a value matching your default UI Culture setting, as follows:
[assembly: NeutralResourcesLanguage(“en-US”,
UltimateResourceFallbackLocation.Satellite)]

2. Create user interface with Localization ID's
Now we need to create user interface and apply Uid directive from XAML namespace to every object element that needs to be localized. The value of each directive should be unique identifier.
sample Uid is "<TextBlock x:Uid="TextBlock_1"> Sample string1 </TextBlock>". Suppose you are going to develop huge application then this could be quite tedious and time taking task if done manually. But thanks to LocBaml which does this automatically by simply invoking one simple command from VS command prompt.

Command as follows: msbuild /t:updateuid ProjectName.csproj. When you run this command, it will add Uid to every XAML element with the unique value. We can add this as a task in msbuild script.

3. Creating a new Satellite assembly with LocBaml:
Now you can run the LocBaml tool from the Windows SDK on a .resources file generated by the build process (found in the obj\debug directory), as follows:
LocBaml /parse AssemblyName.g.en-US.resources /out:en-US.csv. The csv files contains a key value pair for en_US culture. You have to just open file the using excel and provide value against the individual resource keys.
Now point comes in mind how to convert .csv files into a satellite assembly. So below is the command for converting a csv files into a satellite assembly.
LocBaml /generate ProjectName.resources.dll /trans:en-US.csv /cul:en-US. The same can be done for any other culture very easily, just copy  the file for some different culture name and import it similarly using the above command lines. 

4. Set application culture : 
Now our satellite assembly is ready and we have to just set the application culture and get ready to use the resources from the particular culture. 
Below is the code for setting application culture : 
            Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
            Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Thats all we have to do, nothing extra is required for the localization in WPF. It is really very simple and time saving task.

Silverlight and WPF Application development Using PRISM

Silverlight and WPF share common programing paradigm. In simple words we can say that Silverlight as a subset of WPF. Both WPF and Silverlight is based on XAML(Extensible Application Markup Language), but they are based on some different aspect in sense that Silverlight is cross browser and cross platform support and client side technology, whereas WPF is Desktop based client application. So Silverlight act as subset of WPF, it shares most of the features of WPF except few but it doesn’t have features like extensive 3D support and Routed command properties, doesn’t support right click, doesn’t support COM inter-operability and many others.
Here we want to discuss how we can set our development strategies so that our application can run in Silverlight version as well as WPF version. For this same purpose Microsoft has come up with new frame work called PRISM. PRISM is basically a set of guidelines that we have to follow to achieve our WPF and Silverlight parallel development. PRISM gives the development strategy to build loosely coupled applications, so that any changes in the any of the interacting module would not ripple to other modules in the application and more over it gives us the independence to build our modules independent of view and it can be unit tested separately.
This feature was already there in other framework like MVVM but what is new in PRISM? It is more than separating view from business logic and data, it talks about how one module is independent of the other, it takes benefit other framework like UNITY, Dependency Injection and MVVM.
Architecture of PRISM:

Interacting modules in PRISM:
1. App.XAML: Call BootStrapper on Application_Startup
2. BootStrapper: This is a class file that calls Shell (Shell.XAML) and so creates catalogue of module.
3. Shell: This is like a Master Page having regions.
4. Region: It is like placeholders to register views.
5. View: This is XAML file having User Interface
6. Module: Each module can have one or more View(s) which are registered to Region (in the Shell) through RegionManager:




WPF and Silverlight Code Sharing Technique:
We may find cases where we need both WPF and Silverlight versions of an application. For instance, when the user is in the office and needs access to full functionality, but may be occasionally offline from the network, the WPF version would be used. On the other hand, if the user is out of the office and needs access to a subset of the application’s functionality while online at a coffee shop, the Silverlight version would be used.
Supporting a different codebase for each version of the application, when there’s a lot of overlap between them. Duplicating a code for both the application would create huge mess in our situation because our application would be huge and it is very much difficult to manage each version independently. The two applications could probably share all the data access, business logic, and most of the UI logic, provided that we built the application with separation of concerns in mind.
Project Linker feature of Silverlight:- Our above problem can be solved using project linker utility that helps us in code sharing between Silverlight and WPF project. Project linker ships free with PRISM and can be integrated with Visual studio. Idea here is to create one common project and that maintains two different project one for Desktop version and other for web version, so that we can gain maximum code reusability, less maintenance cost and saves our development time.

Multi-Targeting Strategies
In order to ease the development effort when building an application targeting both WPF and Silverlight from the get-go, we should consider the following strategies:
Start with the lowest common denominator. It is usually easier to go from Silverlight to WPF than the other way around, so create the views (that is, the UI) in Silverlight first.
Adopt separated presentation patterns. Make sure to create views as thin as possible, allowing as much code as possible to be shared between the two platforms. Look into patterns such as the Model-View-ViewModel.
Aim to have single source files that are cross-compiled between the two versions of the application.
Create a parallel project structure between the two targets; that helps when trying to find where things are, and it helps the ProjectLinker add-on do its job.
We will find cases where we cannot use pieces of a source file as-is in both WPF and Silverlight, and we will need to add some special handling. we can address those cases as follow:

1. Conditional compilation: we can branch code using the #ifcompiler directive. Every Silverlight project is configured with the SILVERLIGHT conditional compilation symbol. We can use #if SILVERLIGHT to branch code accordingly.
2. Partial classes: Put all the code for a class that our application can use as-is in both WPF and Silverlight into a single file anything, specific to WPF around that class goes into a partial class whereas anything specific to Silverlight goes into another partial class .
3. Partial methods: Within some class we make calls to a partial method, which may or may not be implemented by a partial class in one of the projects. If the partial method is not implemented, the compiler takes care of removing any calls to it.
4. Separated class: If none of the options above fit our case (most likely because the code to support something is drastically different between the two platforms), create totally separated classes for each. Make sure to not depend directly on those classes, though; make them implement an interface, and have the classes used only by means of the interface.

The Shell--(PRISM)
Building the shell of a Silverlight application isn’t different than building one for a WPF application:

1. Create the shell as a UserControl (as opposed to a Window, which is usually the case in WPF).
2. Add named regions to it, which are going to have views injected during runtime.

Helping hand from Data Templates and View Model:
The Composite Application Guidance for WPF and Silverlight brings up an interesting suggestion for those building applications following the M-V-VM, or Model-View-ViewModel (or Presentation Model) pattern: instead of creating a view as a user control, use a data template. WPF has a great future called data template that determines how some data should be shown on the screen. A data template can target a specific data type. In an M-V-VM scenario, the ViewModel can be the data type for a data template. Same thing applies to Silverlight application.

Support for Commands for Silverlight App: Silverlight doesn’t have any in build support for Routed commands like we have in WPF, so to have the similar features in Silverlight application PRISM library extends the feature via attached property to the controls. Generally command is available in Silverlight to controls which are inherited only from button base, but with the help of this attached property exposed from PRISM we can bind command to any UI controls.

Support for Hand Held Devices , Touch screens and Tablet PC’s:
As per the screen resolution and size of the application is concerned, this is automatic features supported by WPF, we don’t have to bother much about screen resolution. Most important thing to consider is stylus input, for the same purpose we have ink canvas support in WPF. It is like normal canvas but it can listen to stylus events. It can be used in normal desktop version also. So in places we might be thinking of user input from stylus we can use Ink canvas instead of normal canvas.
For more information on Ink canvas we can find more in detail on MSN and on
Codeplex: http://inkcanvascontrols.codeplex.com/.
From Code project: http://www.codeproject.com/KB/WPF/Ink1.aspx
If we are working in palm tops or any hand held devices then memory will be constrained, so it is not suggested to make very heavy application and application would be not too much graphic intensive. But in case of tablet PC it wouldn’t make any difference if we replace our canvas with Ink canvas and add some stylus related events.

Support for Linux platform: With the advent of Silverlight, we can also target Linux community to use our application on their Linux Box. Silverlight is a cross bowser and cross platform technology, so it can be easily browsed on Linux machines without any difficulties. As we know that Silverlight is rendered in browser, so there Linux machine can easily render Silverlight pages. More over there is open source community called moonlight based on Silverlight which gives us programing guide line to develop application with keeping Linux environment in mind.
I haven’t explored much on this, if required I will explore it further.

Conclusion:
The Composite Application Guidance for WPF and Silverlight Applications provides developers with great direction for building applications that are loosely coupled, testable, and extensible. It works around limitations of both WPF and Silverlight, features a Composite Application Library containing the main plumbing for the proposed architecture. So in our App development we have to restructure our development environment targeting the PRISM guidelines and we will start with Silverlight Development and parallel with WPF. This will certainly going to save our development time and give us multi targeting application.

How to create Non Zero Base index Array in C#

We can use the following code to create a non zero based index array.

 Array.CreateInstance(typeof(int), new int[] { 10 }, new int[] { 100 });

//Parameters:

1: tells the type of array to create

2: int[] which tell the size of arrays, means we can tell the size of different dimensions of array.

3: int[] which tell the non zero based index of the array.