The WPF Workspace – Quick Start


Nuget Package:

PM> Install-Package HBD.WPF.Shell

As the Workspace for WPF had been introduced a few day back. So is this post I would like to show you how to get started with that application.

I.  Module Implementation.

1. Add New Project

  • Open Visual Studio and create a new WPF User Control Library project with project name is WPF.Demo.Module.
  • Install the latest version of HBD.WPF.Shell from Nuget.
  • Add a new class named DemoStartup and inherited from HBD.WPF.Shell.Modularity.WpfModuleBase and then override 2 methods (GetStartUpViewTypes and MenuConfiguration(IShellMenuService menuSet)) as below.
  • Remember to add the ModuleExport attribute into your DemoStartup class.

2. Setup the Module_*.json

  • Add a new json named Module_Demo.json with the below content.

  • Set the build action of this config file is Copy Alway.

3. Add a new User control

  • Add a new class named ViewModel1.cs inside folder ViewModels as below.

  • Add a new User Control named View1.xaml inside Views folder with the code behind as below.

4. Setup the Public folder

  • Copy folder [Solution Directory]\packages\HBD.WPF.Shell\tools\Shell to [Solution Directory]\Published\Shell.
  • Right click on the project select Properties
  • Add below code into Post-build event

  • Set Start external program under Debug to [Solution Directory]\Published\Shell\HBD.WPF.Shell.exe
  • And set Working directory to [Solution Directory]\Published\Shell folder.
Debug Setup

5. Run the application with this Module.

  • After finished all above steps, the project shall look like below.

  • Build and Run the application you will see the new Demo menu had been added. When clicking on the child menu item the View1 will be open on the Tab control.

II. Source Code

Download the WPF.Demo.Module here.

Hope my Workspace is useful.

The Workspace for WPF Application Introduction


Nuget Package:

PM> Install-Package HBD.WPF.Shell

I. HBD.WPF.Shell Introduction

Similar with HBD.WinForms.Shell and HBD.App.Shell. In this post, I would like to introduce one more Shell Foundation for WPF Application. This open source project had been developed based on Prism and WPF technologies, that allow to add-in the Modules at run-time. So that you can use this project as a Foundation of your application and then develop and maintain your modules separately and independence.

The Main window

II. The Available Regions

When working with Prism, the region is one of the good features allow to organize display area and navigation of the controls in the application. As the screenshot above there are 7 regions are available in this Shell.

1. The Menu Region

This region will be used to display the main menu of the Shell. The main menu view will be loaded into the menu region when the application started and it can’t be replaced or deactivated and the menu view must be inherited the  HBD.Mef.Shell.Views.IShellMainView interface. So that the Shell will extract the view from Mef container based on this interface type.

The sample code of the main menu view.

The Main Menu View

2. The Right Region

This region will be used to display the notification center of the Shell. Similar to the main menu view. The notification center view will be loaded into the right region when clicked the bell icon on the menu view. However, it can be replaced or deactivated. This view also requires being inherited the  HBD.Mef.Shell.Views.IShellNotificationCenterView interface.

The Notification View

3. The Status Region

This region will be used to display the status view of the Shell. This view will be loaded at app start and can’t be replaced or deactivated. This view required to be inherited the HBD.Mef.Shell.Views.IShellStatusView interface.

4. The Main Region

This region will be used to display the Tab Control View that allows adding the custom views from the Modules. The same with Status View, This view will be loaded at app start and not allow to replace or deactivate. It also required being inherited the  HBD.Mef.Shell.Views.IShellMainView interface.

5. The Left Region

This region is available and will be shared for all modules. The look and feel are similar to the left region.

6. The Tab Region

This region must be defined in the Tab Control View to tell the Shell that all custom views from the modules will be displayed in the Tab Control.

The Tab Control View

7. The Title Region

When creating a custom view of the Module. The view header and view title need to be specified. The view title will be displayed on the Tab header and view header will be displayed in the title region.  However, only view title will be displayed when loading to the Left orRight region as the screenshot below. As the other view, this title view needs to be HBD.Mef.Shell.Views.IShellTitleView inherited the interface.

Title region

Just hightlight that all Views of this Shell had been implemented in the separate library named HBD.WPF.Shell.UI and export into Mef container. So that, you can customize the views by replace HBD.WPF.Shell.UI with the other library that content the full set of the above views.

Refer the source code of HBD.WPF.Shell.UI for more details.

III. The Built-inServices of the Shell.

Below built-in services had been developed along with this project. I will post a separate post for each service to discuss the usage and customization later. In this section just introduce the service functionality and how to use it.

Please note that all built-in service had been added into the HBD.WPF.Shell.ViewModels.ViewModelBase abstract class.  So recommend that all view model should be delivered from this class.

1. Dialog Service

The dialog service is providing the easy way to interact with the dialog as

  • Display a UserControl as dialog.
  • Open the file browser dialog
  • Open the Folder browser dialog.

The service is an instance of  HBD.WPF.Shell.Services.IDialogService interfaces and exported to the Mef container.

  • Sample code

  • Dialog screenshot

2. Message Box service

The message box service is providing the common dialog as Information, Alert, Confirm and Error message box and shared across the modules. So that message box will be displayed consistently.

This service is an instance of  HBD.WPF.Shell.Services.IMessageBoxService interfaces and exported to the Mef container.

  • Sample code
  • Information Box
  • Alert Box
  • Confirmation Box

3. Notification Service

The notification service allows to display a notification on the screen and added into Notification automatically.  This service is an instance of  HBD.WPF.Shell.Services.INotificationService interfaces and also exported to the Mef container.

  • Sample code
  • Notification Screenshot.

4. Status Service.

The status service allows displaying the message onto the Status bar of the Shell. This service is an instance of  HBD.WPF.Shell.Services.IShellStatusService interfaces and also exported to the Mef container.

  • Sample code
  • Screenshot

5. Other Services.

  • Navigation Executer: this service will help to execute the  INavigationParameter
  • Shell Option Service: this service will save the states of the application: current position, current theme, window state and more.
  • Shell Region Navigation Service: This service provides an easy way to navigation between the views and regions.

6. Upcoming Services.

The services below are under development and hope it will be release soon.

  • Authentication service: this service will be using the Open Authentication technology that allows the application interact with the OAuth services as Google, Facebook, Outlook, Linked-In, and Twitter.
  • Module management service: that allow downloading, import and manage the Modules in the Shell.

Just hightlight that all Services of this Shell had been implemented in the separate library named HBD.WPF.Shell.Services and export into Mef container. So that, you can customize the views by replace HBD.WPF.Shell.Services with the other library that content the full set of the services above.

Refer the source code of HBD.WPF.Shell.Services for more details.

IV. Implement the new Module.

Please refer here for the quick star with Module development here.

V. Source code

You can download the full source code of this Shell here. All the controls of this Shell had been customized from the Microsoft standard controls. So that feel free to use this project for your business.

The Workspace for Console application


Nuget Package:

PM> Install-Package HBD.App.Shell


This post, I Will share the other Workspace source code for Console Shell application as well. This one will provides the core foundation for the console application. That allows building a loosely coupled, module-able and maintainable application.

How does it work?

This Shell application had been developed based on HBD.Mef library that will automatic load all modules in the defined folder at run time. This application is suitable for those who want to develop a batch job that will be triggered by the scheduler and execute the particular plugin based on the input parameters.

Quick Start

1. Add New Module

  • Open Visual Studio and create a new Class Library project example project name is Job.Module.
  • Install the latest version of HBD.App.Shell from Nuget.
  • Add a new class named Job1 and inherited from HBD.Mef.ConsoleApp.ConsoleModuleBase and then implement 2 abstract methods (Initialize and Run(params string[] args)) as below. Remember to add the ModuleExport attribute into your Job1 class.

The function of this job is writing a message to the console and log file.

2. Setup Publish Shell folder.

  • Copy folder [Solution Directory]\packages\HBD.App.Shell\tools\App.Shell to [Solution Directory]\Publish\App.Shell

3. Update project’s properties.

  • Right click on the project select Properties
  • Add below code into Post-build event
  • Set Start external program under Debug to Publish\App.Shell\HBD.App.Shell.exe
  • And set Working directory to Publish\App.Shell folder.
  • And then set the Command line arguments is -job1 param1 param2 param3.

Job Module Debug

  1. Add Module config and Debug your module.
  • Add a new Module_Job_Demo.json file with the following content.
  • Set Build action of this config file as below

Job Module Json

  • Run your module, the Shell application will display as below.

App Shell Job1

How to run multi jobs with parameters

As the Command line arguments above you will see the first parameter is the JobName and then follow by the parameters for that job. If you want to execute multi-job you can pass the Command-line arguments following this format: -JobName1 param1 param2 param3 -JobName2 param1 param2 param3

This is a screenshot when executing multi jobs. App Shell Job1 Job2

If the Environment is Debug the console window will keep open unstil you press a enter key.

Source code

You can download the Job.Module source code here in Github – Job.Module

And the source code of HBD.App.Shell in here Github – HBD.App.Shell

Hope, this Shell will help you to develop a plugin-able application faster and easier. Your feedback and ideas are much appreciated. Please feel free to drop me an email with your opinion.

Sync The Source Code From TFVS to Github Automatically.


If you are using Team Foundation Visual Studio Online (TFVS) as your primary source control and your Github repositories as a public, sharing hub, that everyone can view and download the source code of your NuGet libraries and you want to keep your Git repository up to date with your TFS source code. Then this post may help.

In this post, I will show you how to create a build on TFVS that help to sync a particular source code folder on TFVS to a repository on

I. Generate Github Personal Token Key.

The personal token key on Github as an OAuth access key allow TFVS download and submit your source code to Github without your username and password.

You can generate a new token key here by login to Github -> Account Setting -> Personal access tokens under Developer Setting. The permission of this token should be in repo scope. That allow to download the source code from Github and commit the changes back to the repository.

Token permission
After generated a token your token will look like as below. Note down this token as you won’t be able to view it again after closed this page.

The generated Token
The URL format that will be used to pull and commit the source code to Github look like this https://[token][yourUserName]/[yourRepositoryName].git

II. Create a TFVS build definition.

Now, go to your TFVS and create a new build definition with following tasks.

1. Get sources task.

This is default task of the build definition will help you to download specific source code folder from TFS repository.


2. Config the variables.

As the URL format above will be used in many tasks below.In case if you want to changes your token key or repository name you need to go through all the tasks and changes one by one.

To make the life easier, I will create 2 variables in the Variable tab of the build definition as below.

  1. githubtoken with value is the token key had been generated in step 1.
  2. GitRepo with value is the name of the Github Repository that you want to sync the source code to.

So following is my new URL format with token and git repository now are the name of variables. Please remember to replace by username (baoduy) with your account.

3. The Git clone Task.

Now go back to the Tasks tab and Add new Command Line task and config the parameters as below. This task will help to clone a Github repository to the $(Build.SourcesDirectory)\GitRepo location.

  • Display Name: Run git clone
  • Tool: git
  • Arguments: clone https://$(githubtoken)$(GitRepo).git

4. The Delete files from GitRepo Task.

As the purpose of this build definition is sync the source code from  TFVS to Github. So that, the current source code in Github can be considered is the out of date code and will be clean up before copying the latest source code from TFS folder.

Add a new Delete File task and config the parameters as below.

  • Display Name: Delete files from GitRepo
  • Source Folder: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)
  • Contents:

5. The Copy Files Task.

This task will copy the file from TFS source code folder to the Github repository folder. The parameters will be configured as below

  • Display Name: Copy Files to: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)
  • Source Folder: $(Build.SourcesDirectory)
  • Contents:
  • Target Folder: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)

6. The Run git add Task.

This command will help to detect all changed files in the Github repository and prepare the changeset for the upcoming commit statement.

  • Display Name: Run git add
  • Tool: git
  • Arguments: add -A .

7. The Run git commits Task.

This task will execute the commit command on the local Github repository.

  • Display Name: Run git commit
  • Tool: git
  • Arguments: commit -m”Sync from TFVS”

8. The Run git push Task.

This is the final task to upload the changeset to the remote Github repository.

  • Display Name: Run git push
  • Tool: git
  • Arguments: push https://$(githubtoken)$(GitRepo).git –force

After done the task’s configuration your build definition will look like this:

Now save and queue your build. The results of the run should be as following screen shots.

1. The build ran successfully.

2. The source code had been synced to the Github Repository.

III. Trigger a new build from the Release process.

So example, you have a Release process that uploading your binaries to Nuget and when the upload task is done you want to execute the above build definition to sync your code to Github automatically.

There is an extension named Queue Build(s) Task that provides a nice feature for your release process that able to launch a new build of the build definition. You can install this extention and add 1 more task for your Release process as the configuration below:


If you want to clone the build definition for the other Github repository. Only 2 setting had been highlight with red color need to be changes the all tasks configuration will be work without any amenment required.

Hope this help.


The Workspace for WindowForms

Nuget Package:

PM> Install-Package HBD.WinForms.Shell


This post, I would like to share my Winforms Shell application, that provides the core foundation for the Winforms application. With this foundation, it can be load the external modules from the pre-defined folders when it started. So that you can add-in and maintenance the modules easily.

How does it work?

This Shell application had been developed based on HBD.Mef library to loading and executing external modules when it starts. For more information about HBD.Mef you can found in here.

Build-In Services

In this Shell there are a few services had been developed and exposed into Mef that helps you to interact with the Shell component. 1. The IMainMenuService will help to add Menu Item into the Menu-bar of Main window.

Menu Bar

  1. The IStatusBarService will help to set the status into the Status-Bar of Main window.

Status Bar

  1. The IMainViewService will help to interact with Tab Manager of the Main window. That allow to add/remove UserControl into TabManager.

Tab Manager

  1. The NavigationManager will provide the details in the below section. # Quick Start – Develop a new module for HBD.WinForms.Shell

1. Add New Module

  • Open Visual Studio and create a new Class Library project example project name is Demo.Module.
  • Install the latest version of HBD.WinForms.Shell from Nuget.
  • Add new class named StartupDemoModule and inherited from HBD.Mef.WinForms.Modularity.WinFormModuleBaseand  then implement 2 abstract methods (GetStartUpViewTypes and MenuConfiguration(IMainMenuService menuSet)) as below. Remember to add the ModuleExport attribute into your StartupDemoModule class.
  • Add 2 new User Controls Named View1 and View2 as below.

Demo Module Views

  • On each view overwrite the Text property and return the View Title and add the Export attribute as below.

2. Setup Publish Shell folder.

  • Copy folder [Solution Directory]\packages\HBD.WinForms.Shell\tools\WinForms.Shell to [Solution Directory]\Publish\WinForms.Shell 

3. Update project’s properties.

  • Right click on the project select Properties
  • Add below code into Post-build event
  • Set Start external program under Debug to Publish\WinForms.Shell\HBD.WinForms.Shell.exe
  • And set Working directory to Publish\WinForms.Shell folder.

Demo Module Debug

4. Add Module config and Debug your module.

  • Add a new Module_Demo.json file with the following content.
  • Set Build action of this config file as below

Demo Module Json

  • Run your module the Shell application will display as below.

Demo Shell

Navigation between the Views.

From version 1.0.1 a new interface had been added into HBD.Mef.WinForms.Common to provide the communication channel between the views. So that the view and navigate to the other view with the parameters.

1. Implementation.

If your view wants to be navigated from the other view you need to implement the INavigationAware interface and handle OnNavigatedTo(WinformNavigationContext navigationContext) method, This method will be called when navigating from the other view.

  • The interface
  • The view implementation

2. Using NavigationManager

The sample code below will handle the button event and navigate to the other view

Navigation Manager

When running the application and click the button. View2 will be open and display the message was passed from View1.

3. Recommendation

There are 2 base classes had been provided in HBD.Mef.WinForms for your Forms and Views. So that when you create a new Form or View, it can be inherited from this form instead.

  • The FormBase
  • The ViewBase
  • The Form implementation
  • The View implementation

Demo.Module source code

You can download the Demo.Module source code here in Github

Hope this Shell will help you to develop a plugin-able application faster and easier. Your feedback and ideas are much appreciated. Please feel free to drop me an email with your opinion.Nuget Dependences

Free SSL For Azure Website


In this post, I will show you how to get free SSL from Comodo for your personal Azure website.

Appsolultly, you can found so many articles about the SSL for Azure website on the internet. So In this post, I just want to show you the alternative way to get a free SSL from Comodo using window Internet Information Service (IIS). You may ask a question Why IIS and What’s related? Actually, I’m a lazy developer and prefer to use some tool instead of command line.

Before starting with SSL generation, just highlight that the custom SSL is for the custom domain only. Please check here if your Azure website doesn’t have a custom domain yet.

Note that, if you want to apply the SSL for the Production environment you should buy an SSL certificate that suits to your company. The free Certificate just for the testing purpose should be used for development environment only.

In the below steps, I will use my domain for the demonstration.

I. Generate CSR

  1. Open IIS and go to Server Certificate
  2. Click Create Certificate Request fill up your domain information in the pop-up window. By default, the cryptographic service provider will be Microsoft RSA SChannel Cryptographic Provider and Bit Length should be greater than or equals 2048.
  3. Save the CSR request into a text file.

    IIS Screenshots
  4. Go to Comodo website and paste the contain of CSR file into the first textbox and select the Microsoft IIS 7.x and later in the second one then click next.
  5. In the Domain Control Validation part 1 select HTTP CSR Hash in the Alternative Methods of Domain Control ValidationYou shall have 2 hash values names MD5 and SHA-1 at the end of this section.
  6. Create a text file with the name is MD5 value and contain is SHA-1 value and then in a separate line as the screenshot below.
  7. Upload the file into the wwwroot folder of your Azure website. You also can use the Kudo tool of Azure website to create a text file on the host directly.

    The SSL validation file.
  8. Click next and fill up all the require fields and finished the validation.

    The domain control had been validated.
  9. After then, you can use registered account to log in and download your the certificate. It may take 2 minutes to generate your SSL.

    SSL Certificate download.

II. Conver .crt to .pfx

After download and unzipped the certificate file you will have a folder with 4 .crt files. Now go back to the IIS and click Complete Certificate Request and provides required info into the popup window as below:

  • Filename is the location path of yourdomain.crt
  • Friendly name is your domain name
  • Certificate store is Web Hosting
Import certificate to IIS

Now, you shall have a certificate in the Server Certificate. Right-click on it and select export, specify the pfx file path and password then click ok to export the certificate back to the pfx file because Azure website only allows importing the pfx file.

III. Upload and Binding SSL to custom domain on Azure website

Open your website on the Azure portal and go to SSL Certificate setting upload your certificate and add a binding to the corresponding domain.

Binding SSL to the domain name.

Now, open your website with https and verify the Secure flag on your browser.

The free SSL certificate will valid in 3 months. So just remember to renew your certificate every 90 days.

Beside of Comodo there is the other website here also provide the free sll you may want to take a look as well. Both of them are using LetsEncrypt Certificate Authority.

If you would like to have an auto re-new SSL Sertificate function on your website then the post here will help you on that.

Apply custom domain for Azure website


If you are hosting a application on Azure and want to add an custom domain for your app then this post had been published for you. The custom domain feature will be supported from Basic B1 app service plan. So you have to ensure that your app service plan supports the custom domain before to buy a new domain for your app. you also can scale up your plan if current one is not supported custom domain.

App service plan

I. Domain configuration

  1. Note down your Azure website URL and IP address. The Azure site IP address and URL you found it on Custom domain setting.
  2. Login to your domain management and config your domain properties as below screenshot.
    App service plan

II. Azure Website Setting

  1. Now, go back to Custom domain setting of your Azure website, click add hostname then key in your domain name, validate and then add the hostname into your website.
  2. Congratulation, now you can access your website with the custom domain.
Custom domain setting

Anti Forgery Token and Machine Key


If working on Asp.Net MVC, you will know the anti-forgery token that helps to protect our website against cross-site request forgery.

To use this feature, call the AntiForgeryToken method from a form and add the ValidateAntiForgeryToken attribute to the action method that you want to protect.

  • Call AntiForgeryToken from a form

  • Add ValidateAntiForgeryToken attribute to the post action

How does it work?

When calling the AntiForgeryToken method inside a form, the AspNet will generate an encrypted AntiForgeryToken, pub into a hidden field and then send to the browser. When the browser submits the form back to the server, the token will be decrypted and validated to ensure that the request is genuine before execute the destination action method as long as the action method had been marked by ValidateAntiForgeryTokenAttribute.

The generated token looks like this:

What is the issue?

When deploy the website into an environment that has multi servers are load balancing together (web farm) you may facing with below issue when click the submit button.

The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster.

Why did this issue happen?

Assume that the environment has two servers are load balancing as the below diagram:

Farm servers diagram

Internally, the AspNet will use two keys (decryptionKey and validationKey) for token encryption/description and validation token. By default, these keys will be generated randomly when website start.

So, looks at the diagram above there are two instances of the website are hosting on different web servers in the single web farm. So that when both of them start a set of keys will be generated for each instance are differently.

Now, a request from user A had been redirected to the server 1 by the load balancer, the website in will response a view with an encrypted AntiForgeryToken. Later on, user A submits back the form to the load balancer and hopefully that the form will be captured and to be processed by the server 1.

Unfortunately, the load balancer now redirects that request to the server 2 instead and definitely, the token that had been encrypted by the server 1 can’t be decrypted on the server 2 because the keys are different. So the error was thrown.

The idea to fix this issue is ensuring all instances of the website using the same set of keys for the encryption/description and validation in the single web farm.

  • The keys should be different on each website on the same server. So if you have multi websites are hosting on the same server they keys should be unique.
  • The keys should be different on each environment for the same website. So if your website is hosting in multi-environments ensure that the keys on each environment are differently as well.

The solution for IIS

The idea is how to share the set of keys across the servers in the farm. So that the encrypt and decrypt process can happen on any server successfully.

Fortunately, When hosted an AspNet MVC website on IIS you can generate a set of keys by below steps

  1. Click on the website on IIS.
  2. Double click on Machine Key
  3. Uncheck all checkboxes and click Generate button at the right side and then click apply.
  4. The keys will be saved into the web.config file of the website.
  5. Open the web.config file, copy that keys and apply across to all website instances on the single farm.

Now, try the submit your website again. The issue should be resolved.

How to disable compatible view mode at the web application level


The Issue

As many companies had applied a global policy to enable the compatible view in IE for all intranet sites on all PCs. So that the old web application can be display properly.

Compatible view mode had been enabled in IE

However the new web application, especially using Asp.Net MVC and Bootstrap is not working fine with compatible view mode and definitely, we can’t ask our infrastructure to changes the policy of the company to disable the compatible view mode in app IE of all PCs. So how to disable the compatible view mode at the application level?

The website is not displayed property in the compatible view mode.

The Solution

Lucky to us is from IE11 Microsoft had supported to disable the compatible view mode by using metadata in the header of the page. So we can disable the compatible view mode in the application level by add below tag into the shared view of the application by default the shared view will be _Layout.cshtml in Views/Shared folder of the MVC application.

The website will display property in the compatible view mode.

For more information, you can find in here