Casting operators
Many times we’ve encountered the need to cast a variable
from one type to another. On many occasions we couldn’t
and therefore had to write our own conversion methods. Many
of these occasions the conversion methods involved our own classes.
In this post I will demonstrate the casting operators that will allow
as to have an implicit or explicit conversions between our types.
These operators has the reserved words implicit and explicit inside
their declaration without operator sign (+, –, =, == etc.), and it
looks like this:
public static implicit/explicit operator MyTargetType(MySourceType parameter)
It is important to mention that I cannot implement both explicit and implicit
casting at the same direction That’s because If I’ve already implemented
an implicit casting I can call it explicitly as well, and implementing the
same casting both implicitly and explicitly will cause ambiguity and
won’t compile.
I’ve chose to demonstrate casting between to type of List-derived
custom class called MyList. My Goal is to cast between MyList<MyAbstract>
and MyList<MyDerived> where MyDerived derived from MyAbstract but
that is of course not the case between MyList<MyAbstract> and
MyList<MyDerived>.
At the end of the process the code written below will be operational:
MyList<MyAbstract> abstractsList = new MyList<MyAbstract>();
//Implicit
MyList<MyDerived> derived = abstractsList;
//Explicit
abstractsList = (MyList<MyAbstract>)derived;
MyList declaration will look like that:
public class MyList<T> : List<T> where T : MyAbstract
Implicit casting:
To have our implicit casting work we have to write an implicit operator
that will look like this:
public static implicit operator MyList<T>(MyList<MyAbstract> list)
{
MyList<T> result = new MyList<T>();
//Note : If the item is not of type T - a null value will be entered
list.ForEach(item => AddItem(result, item));
return result;
}
private static void AddItem(MyList<T> result, MyAbstract item)
{ T itemToAdd = item as T;
if (itemToAdd == null && item != null)
{
throw new InvalidCastException(string.Format("Invalid cast between {0} and {1}" , item.GetType().Name, typeof(T).Name));
}
result.Add(itemToAdd);
}
In order to simplify the operator I’ve extracted the casting logic to a different method
called AddItem, which is responsible to add the item to our list and throw the
InvalidCastException in case of an illegal casting.
Explicit casting:
Almost the same as implicit casting operator with one difference: The reserved word
explicit is written in it’s declaration. Let’s see onefor example:
public static explicit operator MyList<MyAbstract>(MyList<T> list)
{
MyList<MyAbstract> result = new MyList<MyAbstract>();
list.ForEach(item => result.Add(item as MyAbstract));
return result;
}
Because I used the explicit operator to cat between the generic
type parameter (T) and it’s base type (MyAbstract) I didn’t
have to use any validation.
By opening RedGate’s reflector and browse through to the Nullable<T>
implementation you can find another great example:
Implicit casting between T and T?:
public static implicit operator T?(T value)
{ return new T?(value);
}
Explicit casting between T? and T
public static explicit operator T(T? value)
{ return value.Value;
}
Summary:
Casting operators has the same goal as every other
operator overloading : simplify our code. In this post I’ve
demonstrated the implementation of these operators for
casting between two types of List<T> derived classes.
Deployment using Marge Module
I was asked by one of Sela’s customer’s the following question:
We’ve developed two add-ins, each one has it’s own setup project
ad we’d like to include them in one MSI.
It didn’t take very long to come up with an answer: “Use Merge Module”
So, What is Merge Module?
Let’s say you have an application that is consists of multiple assemblies (Isn’t
it the case most of the time?) . Deploying the application by one setup project
is a common scenario and most of the time it will suit you best. But what happens
where more than one assembly is independent and has to perform some
installation logic?
If it wasn’t for Merge Module we would have been forced to do one of the following:
1. create different Setup project for each assembly and run them all manually or
automatically by some manager program, or even a batch file.
2. Add all independent assemblies to the output folder and add their custom actions
to the various installation events.
However, we can have Merge Module for each assembly. This project has what
regular setup project has minus the user interface and launch conditions,
It means that we can have your own custom actions for custom actions .
After having our merge modules ready we can simply add them to our installation
project.
OK – But is it better than simply add our project outputs to one deployment project?
Well, Keeping in mind adding the custom actions (if needed) also,
it is technically almost the same. However, the advantage or Merge Module comes
when wishing to reuse it. Packing the same assembly in various setup projects is much
easier in Merge Module than repeating your actions over and over. (Sounds like reasoning
code reuse, isn’t it?)
To sum up
Merge Module enables as to encapsulate components installation inside our application setup.
It is also enables us reusing it for various installation packages.It is not in use very often but
it sure can be helpful in many cases, Including our customer’s case.
