Effective work item management is crucial for any software development project. Azure DevOps Service, a powerful suite of tools provided by Microsoft, offers a robust solution for managing work items throughout the development lifecycle. In this blog post, we will explore the key features of Azure DevOps and provide practical tips for optimizing work item management. From creating and tracking work items to leveraging automation and collaboration, this guide will help you streamline your development process and enhance productivity. Let’s dive in!

Section 1: Understanding Azure DevOps

Azure DevOps is a cloud-based platform that provides end-to-end software development tools, enabling teams to plan, develop, test, and deliver software efficiently. Its work item management capabilities are centred around three key elements: work items, boards, and backlogs.

# Work items: Work items represent tasks, issues, or requirements within a project. They can be customized to suit your team’s needs, with various types such as user stories, bugs, tasks, and more.

# Boards: Boards in Azure DevOps offer a visual representation of work items. You can create customizable Kanban boards, Scrum boards, or task boards to track the progress of work items and gain visibility into the development process.

# Backlogs: Backlogs provide a prioritized list of work items that need to be completed. They serve as a central repository for capturing and managing requirements, allowing teams to plan their work and schedule iterations effectively.

Section 2: Creating and Tracking Work Items

To effectively manage work items with Azure DevOps, follow these best practices:

# Clear item descriptions: Ensure work items have concise and descriptive titles and descriptions. This helps team members understand the task at hand and prevents ambiguity.

# Categorization: Use appropriate tags, areas, and iterations to categorize work items. This enables easier searching, filtering, and reporting, making it simpler to find and prioritize tasks.

# Establish relationships: Utilize parent-child relationships between work items to represent dependencies or hierarchies. This enables tracking progress at both micro and macro levels, enhancing transparency.

# Assigning and tracking progress: Assign work items to team members and set appropriate effort estimates. Regularly update the status and progress of work items to keep everyone informed and identify potential bottlenecks.

Section 3: Automation and Collaboration

Azure DevOps offers several automation and collaboration features that can streamline work item management:

# Automated workflows: Utilize Azure Pipelines to automate the creation and tracking of work items. For example, you can configure triggers to automatically create a bug work item when a test case fails.

# Integrations: Leverage integrations with popular development tools such as Visual Studio, GitHub, and Jenkins. These integrations allow seamless synchronization of work items, enabling teams to work in their preferred environments.

# Notifications: Configure notifications to keep team members informed about changes to work items. Azure DevOps provides flexible notification settings, allowing users to receive updates via email, Teams, or other channels.

# Real-time collaboration: Azure DevOps supports real-time collaboration, enabling team members to discuss and resolve issues directly within work items. This promotes effective communication and reduces delays caused by back-and-forth conversations.

Section 4: Reporting and Analytics

Azure DevOps provides powerful reporting and analytics capabilities to track project progress and identify areas for improvement:

# Dashboards: Create customized dashboards to display key metrics and charts related to work item management. This allows stakeholders to visualize the progress of work items and make data-driven decisions.

# Query and charting tools: Use Azure DevOps query and charting tools to slice and dice data, analyze trends, and identify bottlenecks or areas requiring attention.

# Burndown charts: Burndown charts provide a visual representation of the work remaining versus time, allowing teams to track progress and adjust their plans accordingly.

Conclusion

Efficient work item management is vital for successful software development projects. With Azure DevOps, you have a powerful suite of tools at your disposal to streamline work item creation, tracking, automation, collaboration, and reporting. By following the best practices outlined in this guide, you can enhance productivity, foster effective collaboration, and deliver high-quality software on time. Start leveraging Azure DevOps with Almo and take your work item management to the next level. Happy coding!

Almo’s Background Server

Almo’s CPU and memory-intensive tasks are run by an out-of-process server process that communicates via Almo’s Outlook Client using named pipes on a user’s machine. Almo client periodically interacts with the server to either do Azure DevOps-related operations or for features such as Auto Pilot. When the server is running it will be listed in Windows Task Manager as shown below:

Potential Issues

However, network or machine administrators may have policies that prevent stand-alone executables from running in the background. Should this happen, Almo’s Outlook client will cease to function and display this warning in the Ribbon and as a user-interactable message.

Almo’s Outlook client is designed to detect the server’s runtime status and attempt to run it if it detects that the server is not running. 

The Almo client refers to registry settings in a specific parent node to identify the location of the server and initiate its execution.

Resolution

You can use these steps to ensure that the right registry settings are in place for Almo’s Outlook Client to launch the server or failing that, launch it manually.

Step 1: Locate the Almo Server

Follow these steps to locate the Almo server on your machine:

– Open File Explorer

– In the address bar, type or copy-paste the following path: “C:\Program Files (x86)\vi8\server\almo\”

– Look for a file named “Vi8.Ipc.Server.Almo.exe” in that location

– Ensure that the server is present in the specified location and that you have the rights to access and launch the exe. It is OK to double click and launch it manually at this stage.

Step 2: Confirm Registry Settings

We need to verify the registry settings to ensure that Almo can detect and run the server. Here’s how you can do it:

– Press the Windows key + R to open the Run dialogue box

– Type “regedit” and press Enter. This will open the Registry Editor

– In the Registry Editor, navigate to the following path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\vi8\Server\Almo

– Confirm that the registry settings in this location match the two data points mentioned below:

            – Key with the name “InstallDir” should have a string value of C:\Program Files (x86)\vi8\server\almo\

            – Key with the name “Name” should have a string value of Vi8.Ipc.Server.Almo.exe

You can also download the registry settings here. Please rename the file to “.reg” and use Window’s registry editor to import them into your registry. Restart Outlook and you should be good to go.

It’s important to bear in mind that Outlook will be running under your user context and Almo’s Outlook client would be running under Outlook as a process. Both Outlook and Almo must be allowed to programmatically read the registry settings so that they can launch the server as needed.

Step 3: Run the Almo Server Manually

If the Almo server is not running or if it was blocked by your network or machine administrators, you can manually start it by following these steps:

– Go to the location C:\Program Files (x86)\vi8\server\almo\ in File Explorer

– Locate the “Vi8.Ipc.Server.Almo.exe” file

– Double-click the “Vi8.Ipc.Server.Almo.exe” file to run the server

Conclusion

By following these steps, you can troubleshoot and resolve the “Unable to Start Critical Almo Component” error in Almo. Ensure that the Almo server is present in the specified location, confirm the registry settings and manually start the server, if needed. These steps should help you get Almo back to its normal function and improve your productivity with its features.

If you have any questions or need additional help, please, don’t hesitate to contact us. We are happy to assist you.

Almo for Outlook periodically refreshes your license from our servers. This process is non-deterministic to a large extent and happens transparently in the background. However, you might want to force a refresh of the license yourself in some cases.

Should this be the case, please follow these steps:

1. Go to the Almo toolbar in Outlook and click on ‘Open Help.’

2. The License Details screen will open. Click on “Check for an updated license” to fetch your latest license from our servers.

Do write to us if you need further questions. We are happy to help!

In my last post Deadlocks when using Tasks I explained how this innocent looking piece of code can cause a GUI app to deadlock and die. I proceeded to explain the reasons behind this behaviour. In this post I aim to discuss one possible solution to this problem and highlight some potential design considerations that you should be aware of while working with TAP code that uses asynchronous calls mixed with synchronous wait calls. For convenience this is the piece of code that would deadlock your application

public static class NiksMessedUpCode
    {
        private static async Task DelayAsync()
        {
            await Task.Delay(1000);
        }
 
        public static void Test()
        {
            // Start the delay.
            var delayTask = DelayAsync();
            // Wait for the delay to complete.
            delayTask.Wait();
        }
    }

 

Solution

Modifying the code as shown below will remove the deadlock. Can you spot what we did here?

public static class NiksMessedUpCode
{
    private static async Task DelayAsync()
    {
        await Task.Delay(1000).ConfigureAwait(false);
    }
 
 
    public static void Test()
    {
        // Start the delay.
        var delayTask = DelayAsync();
        // Wait for the delay to complete.
        delayTask.Wait();
    }
}

 

Yes we added a ConfigureAwait(false) to the Delay method call on our Task. Go on try this code in the GUI app. This should not deadlock anymore.

Explanation

As you are aware when a Task execution is started .NET runtime effectively captures the existing context under which the application was currently running and immediately returns. Once the awaited Task has finished its execution the .NET runtime would execute the remainder of the async method on the same context that it captured before the Task was awaited. In a VERY simplistic manner you can imagine something like this (borrowed from Stephen Toub’s article on MSDN here). Logically you can think of the following code:

await FooAsync();
RestOfMethod();

as being similar in nature to this:

var t = FooAsync();
var currentContext = SynchronizationContext.Current;
t.ContinueWith(delegate
{
    if (currentContext == null)
        RestOfMethod();
    else
        currentContext.Post(delegate { RestOfMethod(); }, null);
}, TaskScheduler.Current);

This logical execution however changes when ConfigureAwait is added to the mix.

Using ConfigureAwait(false) actually instructs the .NET runtime to not bother with capturing the context before the await statement and hence execute the remainder of the method execution post await statement on any thread pool context.

As I mentioned in my previous article the cause of the deadlock was that there is no way for the await call in the DelayAsync method to signal its completion as the delayTask.Wait() statement is blocking up the SynchronizationContext from running any other chunk of code. This then becomes the cause of the deadlock. You can read the whole explanation here

Using ConfigureAwait however enables the await to execute the remainder of the code in DelayAsync method on a thread pool context and thus gets us around the deadlock. The main SynchronizationContext which was waiting on the delayTask.Wait() statement gets to know about the completion of the await call and hence can execute the rest of the code.

Caution with ConfigureAwait

The fact that using ConfigureAwait signals the await mechanism to run the remainder of the method on any thread pool context and not necessarily on the original context which was used to run the code before the await system has an important implication.

Given that using ConfigureAwait causes an effective loss of the original context you should not use ConfigureAwait within any code block that directly manipulates GUI elements.

For instance following is an example where you cannot use ConfigureAwait

private async void Button_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                button1.IsEnabled = false;
                //CANT USE CONFIGUREAWAIT HERE!!!!
                await SomeTask();
                
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message);
                //do somethingwith the exception here
            }
            finally
            {
               /// When the await is over this line of code will have to be run on the original thread that created the button element
               /// thus we cannot use configureawait in the preceeding await.
                
                button1.IsEnabled = true;
            }
        }

        private async Task SomeTask()
        {
            await Task.Delay(3000);
            
        }

If you were to try and use ConfigureAwait in the button click handler you will see an exception being raised. Go on try using the above code.

You can however use ConfigureAwait in the SomeTask method as shown below and in fact I would recommend you do this

      private async void Button_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                button1.IsEnabled = false;
                //CANT USE CONFIGUREAWAIT HERE!!!!
                await SomeTask();

            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message);
                //do somethingwith the exception here
            }
            finally
            {
                /// When the await is over this line of code will have to be run on the original thread that created the button element
                /// thus we cannot use configureawait in the preceeding await.

                button1.IsEnabled = true;
            }
        }

        private async Task SomeTask()
        {
            // Yup can use ConfigureAWait here even though the button handler calls this. Why? Read my blog!!
            await Task.Delay(3000).ConfigureAwait(false);

        }

Remember each async method has its own context! Thus when we call into the method SomeTask it starts with its own context which is different from the main SynchronizationContext that was running the button click handler. It is then perfectly valid to use ConfigureAwait in this method as when this code runs (and await returns) the .NET runtime would take care to marshal back the remainder of the button click handler on the original SynchronizationContext (and hence the correct thread) completely independently of where it ran the rest of the SomeTask method post its await statement.

A natural deduction of the above discussion is the recommendation that you use as minimum code as possible within the actual button click event handler and write the bulk of the code in other async method which you call from the actual click handler. This would free up the main GUI thread of your app to only handle the important GUI related messages while running the other async methods on different contexts thus bringing in an element of parallelism in your code and improving performance further.

Summary

As a conclusion I would recommend creating an effective barrier in your code between code that runs on or manipulates GUI elements and the rest of the code and have the rest of the GUI free code embrace COnfigureAwait to free up main GUI thread even further. For ASP.NET applications the context sensitive code would be any method block that works with HttpContext.Current, builds up HttpResponse or returns from controller methods.

Final thoughts and a small teaser!

Actually thinking more on this there are further subtle nuances on how the await mechanism captures contexts. You might be surprised if I state that there are legit cases when .NET runtime would not capture context at all before an await statement even if you do not use ConfigureAwait within that await statement block. That however is a topic for another post if there is an appetite for that. Let me know!

 

I have come across a few discussions on the topic of using Visual Studio 2012 along side Visual Studio 2010 while targeting .NET 4.0 from both of these IDEs. While in principle there shouldn’t be a problem adopting this strategy, it is important to be aware of some practical issues that exist in the above scenario.

Basically .NET 4.5 is an in-place upgrade of .NET 4.0 and replaces 4.0. It is not a side by side install (like 1..1, 2.0 etc. were). These two don’t co-exist on a box. There are quite a few problems that come up while using VS 2012 for applications that target .NET 4.0 runtime. Depending upon the client OS and the framework selection you make in Visual Studio an application can display selective bugs to a few client desktops whereas running fine for the others. This leads to further troubles as if you are using VS 2012 to build applications that target 4.0, you will not see these bugs at the dev time and hence will not be able to patch/fix them. What makes it further troublesome is that some of the most prominent problems appear on WPF space and while the stress these days is on Web based apps a lot of traditional organisations such as investment banks have a very heavy thick client application population.

These links will highlight the issues I refer to

http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/c05a8c02-de67-47a9-b4ed-fd8b622a7e4a/

http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40

So my advice to all development teams to be aware of the nature of applications that they develop and their audience. If for example your applications predominantly consist of web based apps, redistributable components, WWF or WCF applications then you should be fine using Visual Studio 2012 to target .NET 4.0. Examine your individual development scenarios and then take a decision on whether to upgrade to VS 2012 for .NET 4.0 development or not.

This post is a very quick one. I have been talking to a few people at www.stackoverflow.com who are quite keen to see if we can get WFSH (WorkflowServiceHost) to host coded WFs as opposed to XAML WFs. Further a couple of people also wanted to see if there is a way to get WFSH to host a WF without a Send/Receive activity pair.

I am much too busy with office to do a complete elaborate post right now but I am uploading a sample code base which shows exactly how to achieve all this. Basically using this approach you can have a coded WF or a WF without Send/Receive activities and still get WFSH to host that WF. The approach is almost a hack but hey a developer’s gotta do what a developer’s gotta do! It basically revolves around defining a virtual end point for a WF (which is defined in a different assembly). When IIS gets a request for this service it uses the custom end point to create a new instance of the workflow and start executing it in the WFSH. You will also notice that I am using a Custom worfklow service host factory. Using a custom factory enables us to setup extensions and configure the host the way we want to.

There is one limitation though, we are exposing our WFs as WCF services which we really shouldn’t have to do. However you can easily switch to net.pipe addresses (post coming up soon on these) and limit the access to these WCF services from outside world. Besides since they are WCF services you can limit the authorization/authentication to however you want.

It might be a bit tricky to understand the code at one go so if you need more explanations leave me a message here and I will type out a short synopsis.

You can download the code here.