Skip to content

Contact Us    Now Hiring

@meritweb on TwitterMerit Solutions on LinkedInMerit Solutions YouTube Video SeriesMerit Solutions on FacebookSubscribe to Merit Matters Blog


Managing SharePoint:DateTime Control Events from Client-Side

Starting from its 2013 version, SharePoint took a turn from classic ASP.NET approach towards more responsive client-side development in order to provide a richer and modern UI experience. And while this was great for the end users, as well as where the platform is generally heading, it also meant expansion of the JavaScript skill set for SharePoint developers.

Continue reading "Managing SharePoint:DateTime Control Events from Client-Side"

Introduction to TypeScript

If you have been wondering what exactly TypeScript is, here is definition from their official website:

TypeScript is a language for application-scale JavaScript development.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

So what is it really about?

Continue reading "Introduction to TypeScript"

Fiddler Tips and Tricks

Fiddler is a free web debugging tool which logs all HTTP(S) traffic between your computer and the Internet. Fiddler helps you inspect traffic, set breakpoints, and fiddle with incoming or outgoing data.

Below are a few Fiddler Tips and Tricks to help you when working with Fiddler. 

Continue reading "Fiddler Tips and Tricks"

Windows Azure Access Control Service - Improve User Authentication

Access Control Service is a Windows Azure service that provides an easy way of authenticating users who need to access your web applications and services without having to factor complex authentication logic into your code.

The following features are available in ACS:

  • Integration with Windows Identity Foundation (WIF),
  • Support for popular web identity providers (IPs) including Windows Live ID, Google, Yahoo, and Facebook,
  • Support for Active Directory Federation Services (AD FS) 2.0,
  • An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings,
  • A Management Portal that allows administrative access to the ACS settings.


Windows Azure ACS is built on the principals of claims-based identity - a consistent approach to creating authentication mechanisms for applications running on-premises or in the cloud. Claims-based identity provides a common way for applications and services to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet.

To complete the tasks in this guide, you should understand the following concepts:

Client - In the context of this how-to guide, this is a browser that is attempting to gain access to your web application.

Relying party (RP) application - An RP application is a web site or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority. This guide explains how to configure your application to trust ACS.

Token - A token is a collection of security data that is usually issued upon successful authentication of a user. It contains a set of claims, attributes of the authenticated user. A claim can represent a user's name, an identifier for a role a user belongs to, a user's age, and so on. A token is usually digitally signed, which means it can always be sourced back to its issuer, and its content cannot be tampered with. A user gains access to a RP application by presenting a valid token issued by an authority that the RP application trusts.

Identity Provider (IP) - An IP is an authority that authenticates user identities and issues security tokens. The actual work of issuing tokens is implemented though a special service called Security Token Service (STS). Typical examples of IPs include Windows Live ID, Facebook, business user repositories (like Active Directory), and so on. When ACS is configured to trust an IP, the system will accept and validate tokens issued by that IP. ACS can trust multiple IPs at once, which means that when your application trusts ACS, you can instantly offer your application to all the authenticated users from all the IPs that ACS trusts on your behalf.

Federation Provider (FP) - IPs have direct knowledge of users, authenticate them using their credentials and issue claims about what they know about them. A Federation Provider (FP) is a different kind of authority: rather than authenticating users directly, it acts as an intermediary and brokers authentication between one RP and one or more IPs. Both IPs and FPs issue security tokens, hence they both use Security Token Services (STS). ACS is one FP.

ACS Rule Engine - The logic used to transform incoming tokens from trusted IPs to tokens meant to be consumed by the RP is codified in form of simple claims transformation rules. ACS features a rule engine that takes care of applying whatever transformation logic you specified for your RP.

Access Control Namespace - A namespace is a top level partition of ACS that you use to organize your settings. A namespace holds a list of IPs you trust, the RP applications you want to serve, the rules that you expect the rule engine to process incoming tokens with, and so on. A namespace exposes various endpoints that will be used by the application and the developer to get ACS to perform its function.  

How does it work?

1. The client (in this case a browser) requests a page from the RP.

2. Since the request is not yet authenticated, the RP redirects the user to the authority that it trusts, which is ACS. The ACS presents the user with the choice of IPs that were specified for this RP. The user selects the appropriate IP.

3. The client browses to the IP's authentication page, and prompts the user to log on.

4. After the client is authenticated (for example, the identity credentials are entered), the IP issues a security token.

5. After issuing a security token, the IP redirects the client to ACS and the client sends the security token issued by the IP to ACS.

6. ACS validates the security token issued by the IP, inputs the identity claims in this token into the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims.

7. ACS redirects the client to the RP. The client sends the new security token issued by ACS to the RP. The RP validates the signature on the security token issued by ACS, validates the claims in this token, and returns the page that was originally requested.

What do you need to get it running?

  • An active Windows Azure account: If you don't have Windows Azure account, you could obtain free trial.

  • Visual Studio 2012: If you want to use latest feature of ACS 2.0 it is recommended using VS2012, but VS2010 could also work with little bit of work.
  • Identity and Access tool: This tool is great add-on for VS2012 which significantly ease connecting ACS with your application.

After few simple steps you should be ready to authenticate users to your application using Windows Azure ACS with identity providers like Microsoft, Google, Facebook etc.



Testing e-mail functionality in your Microsoft Dynamics AX/GP application/customization using external e-mail servers has always been a frustrating process. If your test e-mail somehow avoids anti-spam and other SMTP server services, it will still take several minutes to receive. Sometimes, it can take 5 – 10 minutes for your sent e-mail to arrive at the destination - and you can never be sure if your test e-mail is late or if delivery has failed due to an error in your application.

Wouldn't it be great to have a mock application that pretends to be a SMTP server and shows you what you sent immediately? That is exactly what SMTP4DEV does.

SMTP4DEV is free and you can download it from CodePlex at All you have to do is unpack and run, and make sure your mock SMTP server is listening.

Once you have SMTP4DEV running and listening, you can use the sample C# code to send an e-mail to your mock SMTP server. Notice the From and To e-mail addresses; they can be anything.

Execute the sample C# code and your test e-mail will immediately show in SMTP4DEV.

Now stop listening on port 25 and execute the same sample C# code again. Since SMTP server is no longer available, SmtpClient will throw an exception.


Windows 8 development - Process Lifetime Management

If you are a developer, starting to work on a Windows 8 application, one of the really important things to understand is the Process Lifetime Management or PLM. Even if you're not a developer, understanding what really happens when you run a Windows Store application or navigate from it could help you use the app better.

PLM is actually one of the major differences between a Windows 8 application and a desktop application. Unlike traditional Windows applications, which will continue to execute in background, Windows Store apps execute only when they are in the foreground. Windows 8 focuses on the apps in the foreground, keeping them responsive and providing excellent performance by allowing the app to use all of the available device resources. Applications that are snapped are running in foreground, too.

Once a user navigates away from the app, the operating system puts the application in the suspended mode to preserve battery. The application remains in memory but all of its thread are suspended. When the user navigates back to the app, it resumes execution where it stopped and you as a developer can't change this behavior. You don't even have to implement any code to make it happen.

This all seems easy and straightforward, but there is a catch. The operating system cannot guarantee that the application will stay in memory until a user decides to use it again. While the app is suspended, the OS can terminate it to free up additional memory. When an app is terminated, all state that has not been saved is lost. As a developer, you cannot allow for this to happen. Since we are not aware whether the application will be terminated, we must ensure the state is saved when the app is suspended and restore this state in case termination occurs.

But do not despair, Visual Studio 2012 does much of the heavy lifting for you. If your app is not complex, the VS project template takes care of this for you, completely. In the Common folder of your Windows Store app you will find the SuspensionManager.cs. VS added the OnSuspending method and following code to existing OnLaunched method in the App.xaml.cs to save and restore the app’s navigation state if the app was terminated by the operating system after it was suspended.

private async void OnSuspending(object sender, SuspendingEventArgs e)


var deferral = e.SuspendingOperation.GetDeferral();
await SuspensionManager.SaveAsync();


protected override async void OnLaunched(LaunchActivatedEventArgs args)


if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)

// Restore the saved session state only when appropriate await SuspensionManager.RestoreAsync();



In case your application requires anything more sophisticated than this, you will have to implement it yourself, but at least you have a decent starting point. To test how your application behaves when terminated, start the app from Visual Studio and select Suspend and shutdown from the Debug Location toolbar (to activate it, navigate to View > Toolbars > Debug Location).

Attending DevReach2012

Merit Solutions is highly devoted to investing in our employees, providing educational opportunities that enable all team members to improve their skills / talent and follow the latest industry trends. All team members are encouraged to attend trainings and conferences, take exams and earn valuable certification in their respective fields.

As an example of this commitment, this year, a couple of our engineers working with industry-leading technologies attended DevReach 2012, the premier developer conference in Central and Eastern Europe. For the 7th time in a row, Telerik, Microsoft, and other valued partners organized this renowned conference which concentrates on developers and testers.

Many prominent speakers presented more than 60 sessions on the following topics:

  • Cloud
  • Web Development
  • Mobile Development
  • Architecture
  • Agile & Testing

Our engineers had the opportunity to share ideas and knowledge and to discuss current projects with top industry experts and came back energized and with plenty of new skills and ideas.

To find out more about DevReach, visit

Benefits of User Acceptance Testing (UAT)

UAT (User Acceptance Testing) is often the final stage of the implementation process which is conducted to ensure that system requirements meet business needs. The UAT process allows for any issues to be fixed before the system goes live. Acceptance Testing often can be in the form of Alpha or Beta Testing, where the software is tested by the intended audience in the “real environment”.

Why the UAT is important? Despite resource deficits, they need to be managed to conduct proper tests when it comes to this phase. Even though this can be expensive, it is not close to possible cost damages that can be caused by bad requirements understanding. In the “ideal world”, acceptance testing would be performed by system users and they should decide if the deliverable is what they are intending to pay for.

During the Implementation process, the system is going through many types of testing by programmers, analysts and designers. So why focus on UAT? All other forms of testing are carried out by the engineering team to ensure that the system works technically, according to their understanding of the business requirements. UAT should be carried out by the users or business consultants to determine whether the software fits their use or not. Most engineering teams are often forced to perform ad-hoc testing based on the developed feature instead to plan the test effort per feature upfront. UAT can give a clear picture of what should be expected as the outcome.

How to create efficient UAT process? Performing and writing acceptance tests takes time, so UAT planning and conducting should be as efficient as possible:

  • Acceptance Tests should be based on User Stories
  • UAT Gives details about system layout and its reactions on user actions
  • Acceptance Tests should not define need, but behavior
  • UAT should be a contract between a client and a vendor
    • UAT as a deliverable 
    • UAT design and testing – through an iterative process so that risks regarding requirements can be dropped in the early implementation phase
    • UAT should be signed by the client
  • Acceptance Tests should be simple, understandable and cheap:

UAT is applicable on any implementation methodology, including agile and also recommended as a step in the Development phase if we use the Microsoft Dynamics Sure Step methodology.

Who benefits? The answer is simple – everyone.

  • The satisfaction of the clients is increased, as they are more confident that the requirements are met, without the ‘fear’ of how the product will behave in the real environment and if a critical issue will arise when least expected.
  • The quality criteria of the product is defined in the early phase of development/implementation
  • Vendors have improved communication, both with the clients and inside the team, as the requirements definition is improved through the acceptance tests and signed by the client
  • The engineering team ends up minimizing the pressure during the implementation and risks of post-implementation live fixes.
  • Stakeholders use the information gathered through UAT to better understand the target audience’s needs

The benefits of UAT significantly outweigh the investments. As the UAT can be planned to spend up to 5-10% of the project time, it can save almost 30% of the total waste. This is a good way for stakeholders to ensure a good ROI out of projects.