It's been a few years now since Xamarin.Forms was released into the world, and it continues to be a popular and evolving framework choice for Xamarin developers. Later this year Microsoft is planning to release Xamarin.Forms 3.0, its third major release of the framework, which is slated to ship with a lot of exciting features and improvements. While it certainly won't be comprehensive, as the feature set is large and still in motion, in this article I'll walk through some of the highlights of what's coming later this year for Xamarin.Forms developers.

Read the rest over at Visual Studio Magazine.

If you're building a mobile app, there's a lot of things you need to set up. How do you build and distribute your app? How do you authenticate your users? Do you have some sort of backend set up to store your data? How are you monitoring errors and usage? The list goes on and on.

Microsoft has a lot of different offerings targeting these very needs. There's Xamarin Insights for crash reporting and monitoring, Test Cloud for device testing, HockeyApp for distribution, Azure Mobile Services for storage and authentication, and Visual Studio Team Services for builds. These are great options, but it's still a lot to piece together for every app you need to manage. Microsoft recently introduced a new product to help consolidate the story: Visual Studio Mobile Center.

Mobile Center takes all of these separate services and unifies them into a single cohesive experience, allowing you to manage your builds, tests, monitoring, and back-end services in the same place.

Read the rest of the article over at Visual Studio Magazine

A couple years back I wrote an article covering how you could leverage many different languages in your Xamarin apps. In it, I included an F# portable class library that was referenced by the main application written in C#. That's still a completely valid approach, but I thought it was a good time to follow that up with a look at how, these days, you can use F# to build the entire app, and why it's a great fit.

F# often gets typecast as being useful for things in the math or science realms, due to its type system and built-in support for things like units, but what often gets lost in the conversation is how great it can be for "normal" everyday applications, as well.

This article isn't meant to be a real introduction to the F# language or its many features. Instead, I'll provide a quick look at how you can use F# to concisely define an application using the same underlying frameworks you'd be using from C#. No prior F# exposure is needed here, so don't worry if you're brand new to it.

Read the rest of the article over at Visual Studio Magazine.

In the early days of Xamarin.Forms, if you wanted to start customizing any of the built-in controls in ways beyond what were explicitly exposed on those controls, you probably found yourself creating a lot of custom renderers. Renderers can be a great way to hook into the Xamarin.Forms rendering pipeline and inject your own customizations, but it can quickly get unwieldy if you do it a lot, and is often a larger hammer than you would want to be swinging.

In more recent versions of Xamarin.Forms, the concepts of behaviors and effects were introduced that make these types of customizations much more approachable. In contrast to renderers, where you can only have a single implementation for any given control, behaviors and effects allow you to define customizations at a much more granular level. In addition, you can add any number of behaviors and effects to a control, meaning you can compose them together to get the outcome for which you're looking.

Read the rest of the article over at Visual Studio Magazine.

Recently I was reading a blog post by Scott Guthrie about the new syntax for HTML encoding output in ASP.NET 4, where he said the following:

This enables you to default to always using <%: %> code nuggets instead of <%= %> code blocks within your applications. If you want to be really hardcore you can even create a build rule that searches your application looking for <%= %> usages and flags any cases it finds as an error to enforce that HTML encoding always takes place.

It seemed like a fun exercise, so I decided to take up the challenge and build a simple rules engine for enforcing code conventions as part of the build. I know there already exist some tools out there for doing this, such as StyleCop, and they almost certainly do it more comprehensively than what I implemented. However, I thought this would be a good example of how easy it is to extend the build process with your own custom checks.

I’ve developed a bit of a habit lately of using IronPython whenever I would normally create a new console application. You get all the benefits of the .NET Framework, and the conveniences of a dynamic language. If you haven’t played with it at all, I would highly suggest doing so since dynamic languages are really takin off in the .NET space.

To start off, I had to decide what it was I wanted to try and enforce in my build. I decided to keep it simple, and have a list of rules that said which file types it should check, and what string it would search the files for. Again, in keeping it simple, I decided to just do a line-by-line check, so violations that wrap over a line break would not get caught. For basic checks, this is more than sufficient.

The Enforcer

First, let’s start writing the IronPython script to do the work for us.

import System
from System.IO import *

# assuming that we got one command line argument, which is the base
# directory to start processing in
base_dir = System.Environment.GetCommandLineArgs()[2]

Now we imported the namespaces we need, and grabbed the base project directory from the command line arguments. As you can see, even though Python has its own methods of accessing command line arguments, we’re going to stick with the .NET methods.

Next, we’ll establish the structure for the rules:

rules = [
        {
            "extensions": [ "aspx", "ascx", "Master" ],
            "searchTerm": "<b>",
            "type": "Warning",
            "message": "Please use 'strong' instead of 'b'."
        },
        {
            "extensions": [ "aspx", "ascx", "Master" ],
            "searchTerm": "<i>",
            "type": "Warning",
            "message": "Please use 'em' instead of 'i'."
        }
    ]

Each rule has a list of extensions it applies to, the string to look for, the type of violation it is (can be either “Warning” or “Error), and the message to display in the build error. The first two examples there will look for the old style bold and italic tags, and warn you that there are better tags to use.

Next, let’s define a function that given a file and a rule, will check for violations of the rule within that file.

def process_file(file, rule):
line_number = 0
line = None

reader = StreamReader(file)
line = reader.ReadLine()

while line != None:
    line_number += 1

    # does this line violate the rule?
    if line.ToLower().Contains(rule["searchTerm"].ToLower()):
        System.Console.WriteLine("%s (%d): %s: %s" % (file, line_number, rule["type"], rule["message"]))

    line = reader.ReadLine()

reader.Close()

You might be wondering why the only thing we do when we find a violation is to print it out. As it turns out, if a post-build step outputs something in the correct format, Visual Studio will treat it as an error or warning as appropriate. Including the line number makes it so that double clicking on the error brings you to the offending line. That’s all there is to it!

Now we just need to call that function on all the rules and corresponding files. For each extension found in the rules, we’ll create a bucket of all the rules that apply to it to help narrow down the number of file reads we need to do.

# explode the rules out to a dictionary with one key per extension
rule_buckets = {}

for rule in rules:
    for extension in rule["extensions"]:
        if not extension in rule_buckets:
            rule_buckets[extension] = [ rule ]
        else:
            rule_buckets[extension].append(rule)

# now start checking the rules, one extension at a time
for extension in rule_buckets:
    for file in Directory.GetFiles(base_dir, "*." + extension, SearchOption.AllDirectories):
        for rule in rule_buckets[extension]:
            process_file(file, rule)

Post-Build Hook

All that’s left is to plug this script into the post-build process of our project. In the properties section for your project (right click on the project in Visual Studio and click on Properties) go to the Build Events tab. Under “Post-build event command line” enter the following:

"C:\Program Files (x86)\IronPython 2.6\ipy.exe" "C:\projects\Scripts\convention-enforcer.py" "$(SolutionDir)\$(ProjectName)"

Obviously, replace the paths for IronPython and the python script with your own. For the “Run the post-build event” setting immediately afterwards, choose for it to run “On Successful build.” There is no reason to run these checks on a build that already failed for other reasons. The macros in the command will make sure that the checks are limited to files within the current project.

Testing the Rules

So now we have our rule enforcer tied into our project, but does it work? Let’s give it a test run. Earlier we defined a couple rules to check for bold and italic tags, so we’ll try those out. I created a new MVC project, and created a master page that contains this:

<b>This is some bold text</b>

I also created a view containing the following:

<i>This is some italicized text.</i>

Very uninteresting, but these are just test cases. When building the project, Visual Studio now reports warnings for both of these lines.

More Rules

As I mentioned earlier, this post was inspired by the Scott Guthrie post about a new tag for properly encoding HTML output, so naturally we should implement that rule. First, we extend the rules in the IronPython script to include:

{
    "extensions": [ "aspx", "ascx", "Master" ],
    "searchTerm": "<%=",
    "type": "Error",
    "message": "For security reasons, please use '<%:' instead of '<%='."
}

Now add this line to the view:

<%= ViewData["Data"] %>

As expected, the build now breaks with an error about using the outdated tag.

So far, all of the rules have been for frontend code files, so just for completeness let’s include a rule for a C# file. Perhaps you’re a pure old school developer who refuses to embrace all of this new fangled LINQ voodoo. You can now toss in a rule to the script that breaks the build if the System.Linq namespace is imported. Using this rule:

{
    "extensions": [ "cs" ],
    "searchTerm": "using System.Linq",
    "type": "Error",
    "message": "When I was your age, we didn't have any fancy LINQ to help us."
}

Now, though I wouldn’t recommend it, your build will break once the namespace gets imported.

And there you have it. By mixing some IronPython with the Visual Studio build process, we created a simple and extensible engine for quick convention checks on every successful build.