Monday, August 27, 2012

Out-Of-Memory error and Visual Studio crashes


As part of assignment, I was working on a project, which is having 137 projects Windows Form in a solution. Whenever I was building my solution, I was getting Out-Of-Memory error and due to this my Visual Studio use to get crash. Then the only solution left with me was to restart my Visual Studio L. Earlier I as facing this issue once a while, but from last week, it is occurring frequently. Hope you can imagine, how painful it is restart the Visual Studio every now-and-then, especially when your solution contains such a huge number of projects. My error was something like this: “The "ResolveManifestFiles" task failed unexpectedly.System.OutOfMemoryException: Insufficient memory to continue the execution of the program.” 


The only thing, which was coming into my mind, was that it is due to Visual Studio’s memory limits. I also tried to minimize Visual Studio, but no luck :(.
After consulting with few people, I got an idea to breakup my solution into multiple solutions. But again, it was not the best solution for me because my project was already on the last stage (about to over) and it was not the correct time to take this much big risk. So, I dropped this suggestion also.  

After hitting my head for 4-5 days, I reached to some conclusion. One of the reasons was Heap fragmentation, due to which, my Virtual Memory was keep raising and ultimately it was affecting my GC. But this reason was also not 100% correct. Because Virtual Memory will rise, only when I’ll run my application. But in my case, I was getting error during build itself. So, again no luck :(

While doing analysis on the same, I thought, let’s open manifest file and check once. And luckily I got the clue. On opening manifest file, I found that there are lot of hash values which are nothing but my image files. In my project I was using approx 150 image files. According to my project requirement, we were not supposed to deploy those image files. Then what those files were doing there, why they are part of my manifest?  Now a very BIG question was, how those image files became part of my manifest?

This happened because Visual Studio, by default sets image’s ‘Build Action’ property to ‘Content’. As soon as I changed this property to ‘None’, my error goes off. This one small property worked like a charm for me :)

By setting ‘Build Action’ property to ‘None’, I was able to reduce the size of manifest file to approx 0.9GB.

I shared this as a tip, so that you need not to spend 5-6 days, to analyze the issue :)

Wednesday, August 15, 2012

Starting with Prism - Part 2 of n

Background

Continuing to my Prism series 1 of n, in this series, I am going to talk about a few more interesting concepts like Modules and Views.

Modules

In this article, we will talk about how to take other views/logic and broken down into a small pieces called Modules and use them in your Prism application. We gonna start-up by talking about What a Module is, then registering Modules, loading Modules and then we will talk about how to initialize a Module.

What is a Module?

You can think Module as a building block for our Prism application. It is a package that contains all the functionalities and resources required for our application. Prism provides a support for run-time Module management in our application, in which each Module can be developed and tested independently. Prism application loads the Modules as and when they are required. Before moving forward, let’s have a look at how our application was architected inside Visual Studio prior to the concept of Modules.
In above figure, we have single solution and inside that we have single project and within that project we have every single view, all our services, and all our business logic. I mean, single project contain each and everything, which is required for my project. Now, we want to identify, how we can break down our application into smaller pieces called Modules as shown in below figure:
Now, if you look at our solution, you will see that we still have that main project with Shell and Regions in it whereas all the major functionality is defined outside the main project. From above figure, we can see that each Module is independent of each other. Here each module can be single class library or a DLL or a XAP, that includes a collection of other related components.
Each Module has a central class that implements the IModule interface and this is what identifies as a library to a Prism library. This interface has a single method in it called Initialize, which is responsible for initializing a Module and integrating it to your Prism application and all can talk later on with this module.
Creating a Module
In order to create a Module, one needs to add below reference to the project:
  • Microsoft.Practices.Prism.dll
Next we need to add a class library and inherit IModule interface, as:
public class MyModule : IModule 
{ 
   public void Initialize()
   { // TO DO: } 
}

Registering and Discovering Modules

All the Modules need to be loaded at runtime in particular application. ModuleCatalog contains information about all Modules to be loaded, it knows the location and it knows the order in which they are going to be loaded. It even knows that a particular module is dependent on another Module. I hope, one thing is clear that we need to register our Module to ModuleCatalog via code, XAML or by a configuration file. 

Loading Module

Well, next process in Module lifetime is loading a Module. All of the assemblies that contain the Module need to be loaded into the memory. This can be from disk, directory or the web link (only for SL). Prism allows us to control, when to load a module. They can be loaded as soon as possible, which is known as ‘When available’ or can be loaded, when a application need them, which is known as ‘On-demand’. 

Guidelines for loading the Module

It is always good to decide prior that when we want to load our Module. Never forget to think on below points: 
  • Is it required to run the application – If it is, then it must be downloaded with the application and has to be initialized when the application loads 
  • Always used – If it is, it can be downloaded in the background, when it becomes available 
  • Rarely used – If this is the case, then it can be downloaded in the background and can be initialized on demand

Initializing Module

The last phase in the Module’s lifecycle is initializing Modules. IModule.Initialize() does this for us. In this method, we write a code to register our types, we can even subscribe to services or events. We can even work with shared services. We can also compose our view into the Shell. So, basically the Initialize() method is where you can put all your code which make your Module ready for consumption in our Prism application.

Views

Most of the applications require some type of interface with user can interact with. Here we will talk about Views, which will provide the interface to the user and will also see, how to add views to the Prism application. We will touch upon, what a View is, about View Composition, View Discovery and View Injection. 

What is a View?

In layman term, View is simply the interface that user uses to interact with the application. But in Prism application, this concept is bit different. In Prism, View is only the portion of user interface. It is a smaller unit of user interface, which encapsulates a piece of functionality and is coupled with other parts of user interface. Let’s take an example of Outlook. In Outlook, we have toolbar at top and a navigation bar on left side. If you will look closely into it, you will find that, both of these parts have no dependency. For example, outlook toolbar can probably have its own View and has no dependency on other parts of the application. Its main function is to send messages and the actions which are needed to be performed. And the same is true for navigation area, the email list, the content area and even for a status bar. So, we can see that a Outlook is composed of multiple Views. 
Composite View
In Prism, a View can be made up of multiple Views, which is also called as Composite View. Here Composite View can be think of Parent with, having its child view, again sub child view, etc. View can be composed of User control, Page, Data Template, etc. Basically, it can be anything, which can be used to display information to the user. We can also have multiple instances of Views. For example, tab control with a number of tabs showing the same view.
Please keep in mind, while creating a View, design patterns are not required. There is nothing specific to the Prism library that requires you to use the design pattern to bind a View. But one can use any of the available design patterns for creating a View.
Sample code for implementing Views
Let’s create a View, by adding a user control MenuBarView
<UserControl>
  <Button>MenuBar</Button>
<UserControl>
Please note, here I am not using any type of design pattern namely MVC, MVP to create my views. Next thing, we need to do is to register our View with container. In order to do that, you need to open your Module class. In theInitialize() method, we need to register our view with our container. And of course, in order to do this we need a reference to a container.
Likely, it is pretty easy again. Let’s start by adding reference of Microsoft.Practices.Unity.dll. Then we need to add a constructor for our Module class as:
public class MyModule : IModule
{
   IUnityContainer _container; 
   public MyModule(IUnityContainer container)
    { _container = container ;}
   public void Initialize()
    { _container.RegisterType<MenuBarView>(); }
}
So, what’s happening in above code. Here, whenever Module is created, Prism is identifying a container, which is Unity container here. Once the container is identified, our Initialize() method is called and we start registering our types with the container So, once our types are registered with container, we can start using them in the module.
Composing Views
So, next step is composing our views. Here, I am going to use MVVM. Most of us are already aware, that in MVVM, we start with creating interfaces. Here also, I am creating public interfaces named IView and IViewModel. Now,
Let’s create a View, by adding a user control MenuBarView:
public interface IView
{
  IViewModel ViewModel {get; set;}
}
and
public interface IViewModel
{
  IView View {get; set;}
}
Please remember, in MVVM, ViewModel can never have direct reference of View and that’s the reason, I createdIView. Now add another interfaces for our View and ViewModel named IMenuBarView and IMenuBarViewModel, as:
public interface IMenuBarView: IView { }
Now, go to the View (MenuBarView) code behind implement the interface IMenuBarView, as:
public partial class MenuBarView: UserControl, IMenuBarView
{ 
  public MenuBarView()
  { 
   InitializeComponent();
  }
  public IViewModel ViewModel
  {
   get{ return (IMenuBarViewModel)DataContext;}
   set{ DataContext = value; }
  }
}
Next thing, we need to do is, go to IMenuBarViewModel and implement IViewModel as:
public interface IMenuBarViewModel: IViewModel
{
  public MenuBarView()
  { 
   InitializeComponent();
  }
  public IViewModel ViewModel
  { 
   get{ return (IMenuBarViewModel)DataContext;}
   set{  DataContext = value; }
  }
}
Now, we will create a ViewModel named MenuBarViewModel,as:
public class MenuBarViewModel: IMenuBarViewModel
{
 public MenuBarViewModel( IMenuBarView view)
 {
  View = view; 
  View.ViewModel = this;
 }
 public IView View 
 {get; set;}
}
We are not yet done. First, we need to register all our new types to container, inside Module class, as:
public class MyModule : IModule
{
 IUnityContainer _container;
 public MyModule(IUnityContainer container)
 {
   _container = container ;
 }
 public void Initialize()
 {
  _container.RegisterType<IMenuBarView, MenuBarView>();
 }
}
What above snippet is doing is, whenever I’ll ask for type IMenuBarView, I’ll get instance of MenuBarView and we also have to do the same thing for our IMenuBarViewModel, as:
public class MyModule : IModule
{
 IUnityContainer _container;
 public MyModule(IunityContainer container)
 {
   _container = container ;
 }
 public void Initialize()
 {
  _container.RegisterType<IMenuBarView, MenuBarView>(); 
  _container.RegisterType<IMenuBarViewModel, MenuBarViewModel>();
 }
}
Now, if you will run your application, you will still get an empty Shell. This is because, we haven’t composed our view yet.

View Composition

View Composition is the process of constructing a view. View consists of many visual elements. As and when these elements will be created, Views will be displayed in the Regions, created by Shell. These items can be displayed using automatic View Discovery or by using View Injection.

View Discovery

With View Discovery, views are added to Regions automatically. To enable View Discovery, we need to set a relationship in the Region-View registry between a region’s name and a type of view. To do this, one can simply call the RegionManager.RegisterViewWithRegion(name, type). Typically this is done, when a Module initializes or when user performs an action. When the Region is created, it looks for all the view types that are associated with the Region and automatically instantiates those views.
A side-effect of this behaviour is that we don’t have explicit control of when to load and display a view inside a Region.
Sample code for View Discovery
Let’s open our MyModule class and add the following code:
public class MyModule : IModule
{
 IUnityContainer _container;
 IRegionManager _manager;
 public MyModule(IUnityContainer container, IRegionManager manager)
 {
  _container = container ;
  _manager = manager;
 }
 public void Initialize()
 { 
   _container.RegisterType<IMenuBarView, MenuBarView>();
   _container.RegisterType<IMenuBarViewModel, MenuBarViewModel>();
   _manager.RegisterViewWithRegion(RegionNames.MenuBarRegion, typeof(MenuBarView));}
 }
Now, whenever the Region is created, the Region will automatically initialize and instantiate our MenuBar item. Now at this point, if you will run this, you will see your MenuBarView in Shell.
Here, we have very limited control on how and when MenuBar is initialize and instantiated.
View Injection
With View Injection, views are added programmatically to the Region. This can also be done, when a Module initializes or as a result of user interaction. One can achieve View Injection by couple of different ways. This can be done by calling RegionManager.Region[“Name”].Add(view, name) or we can get an instance of an IRegion from aRegionManager and then work with the Region directly as IRegion.Add(view, name).
Please keep in mind that while programmatically adding views, one need to activate/deactivate views. For example, if your content control has a Region, which already contains a view and if you add a new view to it, you need to deactivate the current view for the newly injected view to show.
So, as we can see View Injection gives us more control over views to be loaded and display. We can also remove views from the Region.
One thing to keep in mind with View Injection is that you can’t add a View to Region that has not been created. For View Discovery, view is automatically created when a Region is created. So, one should be aware of what all Regions have been created, before you try to inject a view into it.

Sample code for View Injection

Let’s again open our MyModule class and add the following code:
public class MyModule : IModule
{
  IUnityContainer _container;
  IRegionManager _manager;
  public MyModule(IUnityContainer container, IRegionManager manager)
  {
   _container = container ;
   _manager = manager;
  }
  public void Initialize()
  { 
    _container.RegisterType<IMenuBarView, MenuBarView>(); 
    _container.RegisterType<IMenuBarViewModel, MenuBarViewModel>();

     var viewModel = _container.Resolve<IMenuBarViewModel>(); 
    _manager.Regions[RegionNames.MenuBarRegion].Add(viewModel.View);
 }
}
Now, run the application, you will be see your MenuBar view. Sometimes, we need a more control of the Region and in that case, we can get instance of the Region using IRegion as:
public class MyModule : IModule
{
  ...
  ...
  public void Initialize()
  {
   ... 
   ...
   var viewModel = _container.Resolve<IMenuBarViewModel>();
   IRegion region = _manager.Regions[RegionNames.MenuBarRegion];
   region.Add(viewModel.View);
   }
}
Now run the application, and you will get the expected output.
Hope you enjoyed reading this article. 
Just watch my next article of this series, which is going to publish soon !!!

Friday, August 10, 2012

Starting with Prism - Part 1 of n

Introduction 

Prism provides the guidance to create composite applications and help us to design loosely coupled components, which can be integrated and developed in seamless manner. Like every other application, Prism application also need to get start from somewhere. And when coming to Prism, it is Bootstrapper and Shell. These two things help any Prism application up and running. In this article, we will look more into Bootstrapper and its process. So, gear up and let's get started...

Bootstrapper

So, what is Bootstrapper? Bootstrapper is the class, which is responsible for initializing our application. Now question is what to initialize? So, the first thing is to initialize is the Core Services and then the Application Specific Services.
Core Services: These are non-application specific services that Prism library provide to us. These services include:
  • IModuleManager - Responsible for retrieving application's modules
  • IModuleCatalog - It is used to register the modules
  • IModuleInitializer - Responsible for initializing the modules
  • IRegionManager - These are visual containers for our UI
  • IEventAggregator - It allows us to create events
  • ILoggerFacade - This is wrapper for logging mechanism
  • IServiceLocator - This is used to give application access to your container
Application Specific Services: Apart from core services, Prism also initializes some application-specific services. These are the services, which are specific to our application and which is common among all application modules. For example, if you are working on RSS type application, in that case, RSS Feed service will be application-specific service, which will be used by almost all the modules to read the feeds. 

Bootstrapper Process 

Bootstrapper is the very important class, which gives us control of every component, application gets wired up. Prism library provides a default abstract Bootstrapper base class, that has number of virtual methods. Let's go ahead and take a look a Bootstrapper process. Keep in mind that most of the stages of this process will be covered in more detail in subsequent articles.
  • First thing is to create a LoggerFacade, which will mainly deal with logging
  • Next one has to configure Module Catalog
  • Then one has to create a container and one can use any container of their choice such as Ninject, Unity, MEF, etc. Prism library actually includes, two Bootstrapper classes. One called the UnityBootstrapper and another one is MEF, which includes most of the functionality necessary to use Unity or MEF as your dependency injection container
  • Next one has to configure default Region Adapter Mappings. So, we have to create a custom Region Adapter, which we will register there
  • Next we would configure our default Region Behaviors
  • Then we will register our framework Exception Types
  • Next we would create the Shell
  • Then Shell will be initialized
  • And lastly Modules will be initialized
Please keep in mind that we need not to implement each and every single stage.

Sample code for UnityBootStrapper  

In order to use Unity, one needs to add below references to the project:
  • Microsoft.Practices.Prism.dll
  • Microsoft.Practices.Prism.UnityExtensions.dll
  • Microsoft.Practices.Prism.Unity.dll
Next we needs to add a class named Bootstrapper, as:  
public class Bootstrapper : UnityBootstrapper
{
    protected override System.Windows.DependencyObject CreateShell()
    {
        return Container.Resolve<Shell>();
    }

    protected override void InitializeShell()
    {
        base.InitializeShell();

        App.Current.MainWindow = (Window)Shell;
        App.Current.MainWindow.Show();
    }
}
public partial class App : Application
{
    protected override void OnStartup(StartupEventArgs e)
    {
        base.OnStartup(e);
        Bootstrapper bootstrapper = new Bootstrapper();
        bootstrapper.Run();
    }
}

Regions   

Here I am going to talk about the role of Regions in any Prism application. Here we will discuss, what Regions are and what role they play in our application. We will also look into RegionManager and how it manages our Prism application. We will also touch upon RegionAdapter and the relationship between Region and RegionManager. Then we will see, how to create a custom region as it is necessary for the controls, which Prism doesn't support.

What are Regions?  

A Region is simply a placeholder for any dynamic content, which is going to be presented in our UI. Regions are similar to the ASP.NET's content placeholders. It is simply a named location, that one can use to define, where our View will appear. I hope, you remember, we talked about the concept of the Shell earlier and how the Shell can contain Regions, where we will inject our Views into. 
Now let's take an example quickly. In this example, we will have MenuBar Region and a Content Region.
These regions define areas of the UI, where our View is going to be injected. Each Region should be explicitly named and describe the type of content in which we are going to inject the Region. So, given a Module with a two views named MenuBar View and Content View. These views will be injected to their respective regions. It means, each Region will have it's corresponding View. Here MenuBar View will be injected to MenuBar Region and Content View will be injected to Content Region.
Now, keep in mind, that we just don't have to be in the Shell as Region can also be defined in another View. 
Regions have no knowledge of Views. We can locate content to a Region, without exact knowledge of how and where the Region is defined. This allows the layout change without effecting the Views in the Module. Eg; In above figure, we can shift 'MenuBar Region' to left of 'Content Region', but our 'MenuBar view' will be injected to 'MenuBar Region' and 'Content View', will be still placed into 'Content Region'. So, in this way, we are able to re-design our Shell, without having to re-code any type of infrastructure code. 
Regions can be created in code or in XAML. One thing, which we need to keep in mind id, Region is not a control, but is a host control and it always implements a IRegion interface. This is important to know as it will be used, when you will programmatic access your Region.  

Region Manager 

I hope, as many of you have probably guessed that a Region Manager is responsible for managing the Regions in the application. It does this, by maintaining the collection of regions. It also provides a RegionName property. This is actually an attached property, that is used to create Regions by applying it, to the host control and this can be again done through XAML or through code.
Region Manager also maps RegionAdapter to controls. Now, RegionAdapter is responsible for associating a Region with the host control. In order to expose, UI control as a Region, it must have a RegionAdapter and each RegionAdapter adapts a specific type of UI control.
Prism provide us with four RegionAdapter:
  • ContentControlRegionAdapter - which adapts controls of type content control
  • ItemsControlRegionAdapter -   which adapts controls of type content control
  • SelectorRegionAdapter - which adapts controls provided by Selector class, such as tab control
  • TabContorlRegionAdapter - this is contained only by SL version because in SL, it is not a part of Selector class and behaves bit differently from WPF control
Now, if Prism provided RegionAdapter, doesn't meet our need, we can definitely create our own.
Region Manager also provides a RegionContext attached property. This property is similar to the concept of DataContext. It is a technique to share a data between a parent view and a child view. RegionContext can also be set form the code or from XAML. 

Sample code snippet to create a Region  

In order to create a Region, one needs to add below references to the XAML (Shell):
xmlns:local="http"//www.codeplex.com/prism" 
Next we needs to create Regions as , as:  
<DockPanel>
  <ContentControl DockPanel.Dock="Top" local:RegionManager.RegionName="MenuBarRegion"/>
  <ContentControl local:RegionManager.RegionName="ContentRegion"/>
</DockPanel>
Now, go to the Module class and add the following:
public class MyModule : IModule
{ 
   IUnityContainer _container;
   IRegionManager _regionManager;
   public MyModule(IUnityContainer container, IRegionManager regionManager)
   {
      _container = container; 
      _regionManager = _regionManager
   } 

   public void Initialize()
   {
      regionManager.RegisterViewWithRegion("MenuBarRegion", typeof(MenuBarView));
      regionManager.RegisterViewWithRegion("ContentRegion", typeof(ContentView));
   }
}

Custom Region   

There are times, when we need to use third party control or a custom control as a Region host. There is no issue, as far as our custom control can use the Prism provided RegionAdapters. But it can not be the case always. So, we need to create our own RegionAdapter to adapt a custom control as a Region host. There are only a few steps, we need to follow:
  • Derive your class from RegionAdapterBase<T>
  • Implement CreateRegion method - this method returns one of the following objects
    1. SingleActiveRegion (mainly used for content control)
    2. AllActiveRegion (mainly used for items control)
    3. Region (mainly used for controls derived from the Selector class)
  • Implement Adapt Method - this is to actually adapt your control
  • Register your adapter
Just watch my next article of this series, here.