If you’re building a mobile solution in C# with Xamarin you will use the “Using” directive quite a lot.
As soon as you’re using functionality from an existing library or SDK you will find the Using Directive at the top of your code files. From basic functionality in the System namespace up to Xamarin.Forms functionality or a third party library. They will become accessible as soon as you’ve added the appropriate Using clause to your code file (and adding the necessary NuGet, if applicable).
But sometimes a name (for a class, for instance) is defined in multiple namespaces and the code doesn’t know which one to use. Aliases can be used to help you fix any issues that this might bring along.
That squiggly line underneath your name
Let’s take Microsoft App Center for example. When you’re developing a Xamarin application using Xamarin.Forms, the class Device is used to fetch platform specific information and read device-specific features.
As soon as you add App Center to your project and add the Microsoft.AppCenter namespace any code referencing to a property or function of the Device class will get that squiggly line under it. When you hover over the code Visual Studio will show you that there are multiple definitions available and that it cannot make up which one you need.
Alas, too bad that the compiler isn’t context sensitive (yet) when it comes to this kind of issue.
Luckily for us, you can fix this issue easily using one of two solutions:
Adding the full namespace
By using the full namespace in the code reference to the class that is causing issues, you’ll show the compiler what class implementation you want to use in your code.
For instance, using the Device class when you want to use the Xamarin.Forms implementation is as easy as adding the namespace in front of the class reference:
// example for using a Device class property with the namespacing added
var platform = Xamarin.Forms.Device.RuntimePlatform;
If you like to have your code readable and understandable independently (ie: while scrolling through the code), you’ll like this solution. This is the main advantage.
On the counter side, this might take some time depending on how often you’re referencing the duplicate class reference. Another issue is when you’re working on someone else’s code and might not always see what implementation is being referred to in the code.
Using the Alias Directive
If you like to build one line of code that fixes them all, this solution is more suitable.
The Using Directive permits one to create an alias so the compiler knows that whenever you reference a class, it will default to one of the multiple implementations that are found within the available namespaces.
To take the App Center example as a starting point for this solution, one could define the following alias definition in the Using declaration at the top of the code files that are impacted:
//Example for defining a Using Alias Directive
Using Device = Xamarin.Forms.Device;
var platform = Device.RuntimePlatform; // it will know it needs to use the Xamarin.Forms implementation now
This way you will only need to code the full namespace whenever you want to use the App Center implementation.
You could also implement another alias for the App Center implementation if you use that multiple times in your code. This way, the code is also more readable throughout the code.
This is a more clean way to point the compiler in the right direction on what implementation you’re targetting from your code. I noticed that not every C# and/or Xamarin developer is familiar with Using aliases. It might take them a bit longer to find out about this when first glancing at your code.
Personally, I skip looking at the Using clauses most of the time because I am more interested in the actual implementation of logic and functionality.
Hope this helps you in your quest to defeat those squiggle bastard! At least the ones that originate from multiple class definition issues.
Originally published at EEKAY ONLINE.