vsbanner

Windows Workflow Foundation Build Errors in Visual Studio 2017

0 comments / December 6, 2016

I was recently trying the Visual Studio 2017 RC to test out the new features. To my surprise, when I loaded it up one of my Windows Workflow projects it just threw build errors. What was going on?

windows_10

As it turns out, it’s not a bug, it’s a feature! One of the headline features of Visual Studio 2017 is a smaller footprint and a MUCH faster install experience. A basic install of Visual Studio can now be stood up in less than 5 minutes. The only problem is that many features that previously “just worked” on a brand new install of Visual Studio now throw cryptic build errors since the supporting components aren’t installed. Thankfully, it’s easy to install these components.

In the Start menu click the Visual Studio Installer.

windows_10-2

Then click “Modify” for your version of Visual Studio.

windows_10-3

For Workflow Foundation we need to go to the Workloads tab and click…Office/SharePoint Development (Workflow is heavily used in SharePoint). For other components click on the “Individual components” tab and check the boxes for anything you want to install.

windows_10-4

Once the installer completes we can rebuild your solution and now our Workflow project builds!

windows_10-5

Hopefully Microsoft will improve the experience and prompt to install missing components instead of just displaying cryptic messages but until then it’s very easy to correct.

For a more in-depth review of the new Visual Studio install process check out this post from Samir Behara.
alexabanner

Building Amazon Alexa Skills With .NET

0 comments / December 5, 2016

Last week I attended the AWS Re:Invent Conference in Las Vegas. It was a great week filled with lot of information and cool announcements from Amazon. As part of the event the Alexa team ran a contest to see who could make the best new Alexa skills. My colleague, Robb Schiefer and I decided to enter the contest with a skill that allows you to manipulate Trello using your voice called Trellexa.

Unfortunately, we did not win, however, we learned a lot about building Alexa skills and we even built it with .NET!

First, here’s a list of the steps we took to create this demo.

  • Create a new project in the Alexa Developer Console
  • Develop an intent schema and sample utterances
  • Create an ASP.NET project to host our skill web service
  • Install the AlexaSkillsKit.NET Nuget package and configure with Alexa
  • Setup hosting in EC2 with a valid FQDN and SSL certificate
  • Install the Manatee.Trello Nuget package and configure with Trello
  • Test HelloWorld to prove connectivity between Alexa and service
  • Add logic in the service to handle each intent/utterence
  • Configure account linking to link the user to their Trello account

Next, let’s review some of the basic concepts of Alexa. An Alexa skill is simply a web service that responds to the REST calls made from Amazon when your skill is invoked. To control your skill you define “utterances” with all the possible things that a person might say (ex. “Create a new todo item”).

These utterances map to an “intent.” Intents are defined using a simple JSON schema. The intent data is sent to your service where you can then take the appropriate action. You can also collect additional info from the user by using “slots” in your utterances (ex. “Create a new todo item called {ItemName}.” Your utterance list should contain as many possible ways to trigger the intents as you can think of. At its core this is what is required to make a skill!

To ease our efforts we used the fantastic AlexaSkills.NET Nuget package created by a really cool service called FreeBusy. This package wrapped the Alexa calls into a nice friendly API which matches method for method with the official Java API.

Let’s take a look at how we handled a “CreateItem” request.

As you can see there is very little code needed to wire up to Alexa. Here is the code that builds to speech response.

Now we did run into a handful of issues, however, none of them were related to .NET. Amazon requires that all calls be made to an endpoint secured with TLS, even in dev. This added some complexity to our setup but were ultimately able to resolve it. Also, our application needed to link with Trello using OAuth. Amazon only supports OAuth 2 and unfortunately Trello only supports OAuth 1. This required us to get a little creative and build a wrapper to pass the request from Amazon to Trello.

Overall this was a very fun project and I was amazed that in around 2 days between conference sessions, Robb and I were able to learn two different APIs and build a working product. I will certainly be looking for other opportunities to build skills and I encourage you to give it a try too!

Here is a link to our code so that you can try it for yourself!

BHMDotNet/Trellexa

We love Trello and us it to manage everything. From our daily todo list to more specific project work with a full Kanban board. So naturally we wanted Alexa to help us manage that via spoken word instead of always typing on a physical device.

WiltChamberlinHeader

What Does Wilt Chamberlain and Many Software Developers Have in Common?

0 comments / July 6, 2016

wilt-chamberlain-03Wilt Chamberlain was the greatest basketball player who ever lived. His most notable achievement (in basketball at least) was in 1962, while playing for the Philadelphia Warriors he scored 100 points against the New York Knicks, a record that still stands today. Even more impressive that night was that Chamberlin, a player known for being a terrible free throw shooter, made 28 out of 32 free throws. The story of this game was recently discussed on the excellent “Revisionist History” podcast. In the episode, Malcolm Gladwell recounts how Chamberlain had switched free throw techniques and began shooting his free throws underhanded (sometimes known as a “Granny Shot“). Suddenly, Chamberlain went from a terrible free throw shooter to one of the best. He was now UNSTOPPABLE!

Except…not long after, he switched back to his old style of free throw shooting and his completion ratio tanked. He went from shooting 87.5% shooting underhanded back to shooting 40% overhanded. His only achilles heel had been his inability to shoot free throws and as soon as he’d mastered them he went back to the old way. Why would he do that? Well, Chamberlain put it this way in his biography, “I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.” Even though all the statistics proved that shooting underhanded was the best way to go and even after he had seen the success first hand in his record breaking game he still chose to ignore it. On the other hand Rick Barry, the greatest free thrower of all time understood the advantage of underhanded free throws and embraced it to great success.

I felt silly, like a sissy, shooting underhanded. I know I was wrong. I know some of the best foul shooters in history shot that way. Even now, the best one in the NBA, Rick Barry, shoots underhanded. I just couldn’t do it.

This may seem unthinkable to many people but as software developers many of us do the exact same thing. I’m talking about creating and maintaining a culture of “Sustainable Code.”

What do I mean by “Sustainable Code?” Sustainable Code is a methodology that intends to build software using proven techniques to ensure a lower defect rate, faster turn around time on features, shorter regression test period and better work life balance for the team.

How is this achieved? There are a couple of core disciplines that over the years I’ve learned can make a huge difference when it comes to building a culture that writes sustainable code, I will be going into these in more detail in future posts.

  • Test Automation
    • These include unit testing, integration testing, automated feature testing.
  • Pair and Squad Programming
    • Working with another developer on a single development task or even having the entire team in a room working on a single ticket.
  • Code Reviews
    • Sharing your work with the team and getting feedback.
  • Quick Iterations
    • Don’t get bogged down for weeks at a time working on a single feature. Write code, check-in and deploy often.
  • Close collaboration between devs, QA and business analysts.
    • We’re all one team, don’t just throw things over the wall.

Now, if you’ve been a developer any length of time you’ve probably run into every item in the list but based on statistics you most likely practice few if any of them. One study showed that TDD lowered defect rates between 40% and 90% when compared to non-TDD projects while only increasing development time 15%-35%. Even in the worst case scenario this is a net-gain!  However, just like in the case of Wilt Chamberlain, most developers chose to ignore the stats and keep doing what they’re doing. Most developers balk at having someone review their code or think unit testing is a waste of time and don’t think they need it.

I’ll be the first to say that early on I HATED writing unit tests. I thought they were so pointless and just took time a way from “real development.” I didn’t want to do code reviews because in my mind I was a good programmer and I didn’t want someone else telling me how to do my job. But as I matured as a developer I came to embrace testing. It lowered my stress level when doing a refactor because I always knew I had the tests to rely on to tell me if I’d done something wrong. The same goes for code reviews. I now look forward to them because its a way to learn new ideas and gain new perspective. I get great feedback and the entire team has a better understanding of what each person is working on.

Most importantly though as our organization has adopted agile practices, I’ve realized that without these things we could not really say that we’re practicing lean. Gone are the days of multi-week regression cycles, hours long deployments, huge backlogs of defects.

As a developer. don’t be like Wilt Chamberlain and ignore proven practices because of pride or other reasons. Be like Rick Barry and use these practices to your advantage.

Project Setup List

Workflow Foundation Tutorial: Part 3 – Project Setup

0 comments / February 16, 2016

Today will be a short post where we review the project structure of our sample project.

  • WarpCoreTechnologies.Activities
    • This is an “Activity Library” project used to hold our Workflows and custom activities.
    • Having a shared activity library allows us to reuse these components in multiple places such as a website or WPF project.
  • WarpCoreTechnologies.Database
    • This is our database project. It will be used primarily for storing configuration and Workflow settings. We want to version control our database schema and will be using DACPACs as part of our deployment. Robb Schiefer has a great post on using MSDeploy to deploy a database project.
      • We set it up using the “SQL Server Database” project type.
  •  WarpCoreTechnologies.OrderProcessing
    • This is our main service and will be the consumer of our workflows.
    • We set it up using the “WCF Workflow Service Application” project type.
    • This will create a new project with a placeholder “XAMLX” file as your endpoint.
  • WarpCoreTechnologies.WorkflowEditor
    • This is a WPF application that we will use to demonstrate the rehosted designer capabilities of Workflow Foundation.
  • WarpCoreTechnologies.Tests
    • At the heart of our system will be unit and integration tests.
    • This is a standard “MSTest” Unit Test project.

This is the last tutorial “foundation” post, in the next post we will begin writing our first Workflow to handle order validation!

Here is a link to the release in GitHub that corresponds to this part in the tutorial.

 

Screenshot_021216_033651_PM

Quick tip: Use AutoHotKey to make writing unit test names easier

0 comments / February 12, 2016

One of the most popular naming conventions for unit tests, and the one that we use is writing out the expected behavior as a sentence with underscores(_) instead of spaces.

The only problem is typing all those underscores is kind of a pain. That’s where AutoHotKey comes in! AutoHotkey (AHK) is a free, open-source macro-creation and automation software for Windows that allows users to automate repetitive tasks. It has a powerful scripting language that can allow us to intercept a key and replace it with another key. I’ve taken advantage of this to create an AHK script that detects if “Scroll Lock” is on and automatically replace spaces with underscores if it is.

Simply add the above code to a new AHK script and run it and you will now be able to toggle underscores for spaces by hitting the Scroll Lock button!

New Workflow Project

Workflow Foundation Tutorial: Part 2 – The Basics

3 comments / February 9, 2016

Before we get heavy into the code I think it’s important we go over exactly what Workflow Foundation is, why you would want to use it and some of the vocabulary used.

What is Workflow Foundation?

Workflow Foundation is a Microsoft technology built into the .NET Framework to give developers a declarative way to model the “flow” of their application. WF also includes APIs for handlling long running workflows as well as the ability to “rehost” the designer inside your custom application to give you an extreme amount of flexibility in building your workflows.  WF was first introduced with .NET 3.0 and completely overhauled in .NET 4.

Why would I use Workflow Foundation?

  • It’s visual.

    • Humans are naturally visual communicators and a lot of times it’s easier to describe complex ideas through visual imagery.
    • One of the hardest part of the development process is not writing code. It’s communicating across a wide range of people in different disciplines to learn and understand what exactly we’re building.
      • This is why the whiteboard has become the Roesetta stone of developers and business people. Business people don’t always  understand the code and developers don’t always understand the business vocabulary but we can both understand lines and boxes drawn a whiteboard.
      • Workflow gives you this same capability except you’re not showing an abstract 2nd hand representation of the code’s implementation of the process, you’re showing the actual code!
      • This makes it much easier to communicate and can help head off confusion earlier in the process.
      • You can even bring up a blank workflow and start dropping code activities on the designer to create a rough outline of what you’re going to build.
    • It just makes complex processes easier to understand.
  • It naturally lends it self to testability.

    • The smallest component of a Workflow is a Code Activity.
      • Each activity should do one thing and one thing only and you can write Unit Tests around them.
      • Code Activities pass data in and out of them through arguments which makes it extremely easy to Mock.
      • On top of that Workflow includes it’s own Service Locator pattern called “Workflow Extensions” which we’ve found to be easy to implement and efficient.
      • The next step up is the Workflow itself.
      • We tend to group all the activities for a particular process into a Workflow. For example in order processing we would group all the taxation related activities like checking if the customer was taxable, determining if we need to apply any special logic for particular tax scenarios.
        • We can write integration tests that test just this taxation workflow.
        • Just like Code Activities, Workflows have arguments that you can pass data into and get data out of so we can easily mock.
        • This can greatly speed feedback from tests because you don’t have to wait on external dependencies. An example is our order processing system.
    • Next we group these workflows into a main Workflow, commonly the Workflow hosting our service. We can then have our automated regression suite test the service from end to end.
  • It’s great for long running processes.

    • Combined with AppFabric you can have long running processes which can spin up and spin down as necessary. This means you can make more efficient use of your resources since when a Workflow isn’t running it’s state is preserved in the database and only processing at the moment an event causes it to reinitialize.
  • It’s built into the .NET Framework

    • There are no frameworks to download and install. It’s just there.
    • It’s built on some of Microsoft’s core battle-tested technologies like WCF and XAML.
    • You don’t have to go in whole hog. On existing apps you can identify a process you want to replace with Workflow and start from there. Workflows can be invoked from your existing code.
  • You’re not “locked in.”

    • If for some reason you decide you want to move away from Workflow you have a visual guide of how your processes are built and all your code activities are written in C#.

For a more in-depth review of why I think you might want to use Workflow Foundation in your solution, check out my appearance on .NET Rocks

Workflow Vocabulary

Next, let’s go over some of the vocabulary of Workflow Foundation.

TERM DEFINITION
Activity A unit of program behavior in Windows Workflow Foundation. Single activities can be composed together into more complex activities.
Activity Action A data structure used to expose callbacks for workflow and activity execution.
Argument Defines the data flow into and out of an activity. Each argument has a specified direction: in, out, or in/out. These represent the input, output, and input/output parameters of the activity.
Bookmark The point at which an activity can pause and wait to be resumed.
Compensation A group of actions designed to undo or mitigate the effect of previously completed work.
Correlation The mechanism for routing messages to a workflow or service instance.
Expression A construct that takes in one or more arguments, performs an operation on the arguments and returns a single value. Expressions can be used anywhere an activity can be used.
Flowchart A well-known modeling paradigm that represents program components as symbols linked together with directional arrows. In the .NET Framework 4, workflows can be modeled as flowcharts using the Flowchart activity.
Long-running Process A unit of program execution that does not return immediately and may span system restarts.
Persistence Saving the state of a workflow or service to a durable medium, so that it can be unloaded from memory or recovered after a system failure.
State Machine A well-known modeling paradigm that represents program components as individual states linked together with event-driven state transitions. Workflows can be modeled as state machines using the StateMachine activity.
Substance Represents a group of related bookmarks under a common identifier and allows the runtime to make decisions about whether a particular bookmark resumption is valid or may become valid.
Type Converter A CLR type can be associated with one or more System.ComponentModel.TypeConverter derived types that enable converting instances of the CLR type to and from instances of other types. A type converterr is associated with a CLR type using the System.ComponentModel.TypeConverterAttribute attribute. A TypeConverterAttribute can be specified directly on the CLR type or on a property. A type converter specified on a property always takes precedence over a type converter specified on the CLR type of the property.
Variable Represents the storage of some data that must be saved and accessed later.
Workflow A single activity or tree of activities invoked by a host process.
XAML eXtensible Application Markup Language

Additional resources:

The Workflow Way: Understanding Windows Workflow Foundation

David Chappell Chappell & Associates April, 2009 Download this article Everybody who writes code wants to build great software. If that software is a server application, part of being great is scaling well, handling large loads without consuming too many resources.


In my next post we will build out our project and start writing some code!

Warp Core Technologies Logo-Updated

Workflow Foundation Tutorial: Part 1 – Introduction

1 comment / February 8, 2016

I’ve found that the best way to learn a technology is to just go build something with it. Over the next several posts we are going to be building a complete order processing system using Workflow Foundation and since we need a fake client to build it for we will be taking inspiration from the Star Trek universe.

Our client: Warp Core Technologies. WCT is the leading provider of warp cores and warp core parts throughout the Alpha Quadrant. While the products they sell are cutting edge, their order processing system is not. We will be building a new order processing system using Workflow Foundation and by the end you should see the value that WF provides.

  1. Order Validation
    1. The Federation Council is always signing treaties or setting up blockades. We need to verify that the order is in compliance with Federation law before we proceed.
  2. Inventory Check
    1. Trade disputes mean we may not always have the requested parts on hand or there may be a delay.
  3. Currency Conversion
    1. WCT deals in Federation Credits but we serve clients using everything from Gold Pressed Latinum to Klingon Talons. We need to convert it.
  4. Taxation
    1. We need to cut taxes for the Federation and the destination planet.
  5. Invoicing
    1. We will generate a PDF (yes, they still use PDFs in the 24th century) and an email invoice.
  6. Payment Processing
    1. We need to take payment and notify our ERP system.

In addition to the basic requirements we also have some service requirements:

  1. Guaranteed delivery
    1. We will be using MSMQ to fire and forget the order. If the order processing system is down we want to hold the message until it comes back up.
  2. Support for user modifiable workflows
    1. We will be building a WPF application utilizing the rehosted designer functionality from WF to allow workflows to be modified on the fly.
  3. Testable
    1. We will be writing unit and integration tests to ensure compliance with business rules.

By the end of this series we should have a good overview of what Workflow Foundation can provide and how it will help our business.

Warnings Featured Image

Treating warnings as errors to help prevent technical debt

0 comments / February 3, 2016

Technical debt is a natural part of any project. Much like actual debt some is healthy to keep things going but you want to make sure you keep a close eye on your debt and you understand exactly what you’re taking on. My team uses SonarQube for helping to track and measure our debt. You can learn more about SonarQube in Samir Behara’s excellent post! However, we can manage a big source of growing debt with a simple project flag!

Most projects over time accumulate a large number of warnings. They aren’t really addressed because they don’t fail the build and they may not cause any perceived problems in your application but they can be sitting landmines. Many are just waiting to bite you during a framework upgrade or they may be trying to help you and show you a better way to implement a piece of code or remind you to remove some unused code.

Warnings box

One way we can address this is to turn on “Treat warnings as errors.”

  • Right click on the project you want to enable this on.
  • Select the “Build” tab.
  • Change “Treat warnings as errors” to “All”.

Treat warnings as errors

We have this option enabled for all our projects and it has made a significant difference in keeping our projects tidy.

One caveat, there are times you may want to exclude certain types of warning. For example, we exclude “Obsolete” warnings. Many times we will deprecate a property or API call and it will need to stay for a while, we just don’t want new people using it, so we mark is as “[Obsolete].” By default this will generate a warning (there is an overload that will generate an error). We don’t want this to prevent the build and luckily there’s a way to exclude it from the “Treat warnings as errors”. This is not to be confused with “Excluded warning type”, these will still show as warnings, they just won’t cause an error. All we have to do is:

  • Right click on the project and chose “Unload Project.”
  • Right click on the project again and choose “Edit”
  • Add ” <WarningsNotAsErrors>612,618</WarningsNotAsErrors>” above “<TreatWarningsAsErrors>true</TreatWarningsAsErrors>”


612: The compiler warning code for the [Obsolete] tag

618: The compiler warning code for the [Obsolete(“Message”] tag

Now, you must consistently check and make sure your removing calls to obsolete methods or properties on a regular basis but it will be much easier now that we’ve reduced the noise in our “Warnings” window. This is a feature I encourage everyone=

Microsoft GitHub

Porting Workflow Foundation to .NET Core

1 comment / February 1, 2016

When many people hear Microsoft and open source they may think that it’s a contradiction in terms but the new Microsoft has jumped into open source head first! And the best part is they aren’t doing like some companies do open source and simply make annual code dumps onto a public repo. They do open source the right way and engage with the community, solicit support and accept pull requests.

Recently, I came across the thread for porting Workflow Foundation (one of my favorite technologies!) to .NET Core. I really want to see WF ported to .NET Core as it would serve to make WF a more powerful tool in the developer toolbox. If you love WF and want to help drive it’s development please consider leaving a comment on the thread. It can be as simple as letting the team and the community know how you’re using WF or it can be technical and get into the nitty gritty details of implementation.

[Contribution] Port Workflow Foundation to CoreFx/CoreCLR · Issue #2394 · dotnet/corefx

Hello, I don’t see in the plans neither here and coreCLR for porting Workflow Foundation for CoreCLR… We want know how can we start porting it and add PRs for it here. Thanks

Another thread to check out is porting System.Xaml to .NET Core. This is really a necessary step to getting Workflow in .NET Core but XAML also brings with it many other opportunities and would be very beneficial to replace the limited version of XAML that UWP currently uses.

Port System.Xaml to .NET Core · Issue #5766 · dotnet/corefx

Filed as a result of the discussion in #2394. Note: this doesn’t represent a commitment from us to open source System.Xaml or to even port it to .NET Core — it’s simply capturing the community re…

Microsoft has committed to Open Source. Now we must make our voices heard and take ownership of these fantastic products and work to make them better each and every day.

WorkflowIntegrationTest

Integration Testing Workflows

0 comments / February 1, 2016
Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing.

In my last post I discussed unit testing code activities. Now that we’ve verified our custom activities behave the way we want we need to test the workflow as a whole to ensure they work together correctly. This is called integration testing. This is especially important for WF as much of the logic may be encompassed in out of the box activities and thus not have unit tests around them.

The best part is we test workflows just like code activities!

In our test init we will setup our base mock object.

Next, in our “Because” method we will wire up the call to our Workflow.

Finally, we write our test.

This is great for workflows that need to conform to a certain behavior and you want to test to verify it or the integration tests can serve as validation for user updatable workflows to ensure that any specific requirements are still maintained.

You can see this test in action in a sample project available on GitHub.

Older