For the uninitiated, type forwarding is a way of letting know your .net consumers that the previously existing types have been moved to some other assembly. To be more in detail, assume we had a franctic deadline to meet and so built a single dll with both database connection and loggging abilities coded into it.
namespace MyDB
{
class Logger
{//code for logger goes here}
class DBHelper
{
//code for DB helper goes here
//DB helper also uses logger functions
}
}

You have shipped the dlls to your consumers and they are happy to use it. Now, here comes our performance/design team saying its bad to have different functionalities in the same assembly and it would make sense from design perspective to move them to different dlls. example dbhelper.dll, logger.dll. Yes you do agree but how on earth am I going to pullback on the running applications?

Here comes type forwarding to our rescue. All you need to do is, do like this:

push the logger class into a different file/assembly. So logger.dll contains only logger functions and the DBHelper.dll now contains only DB related functions.

On top of the DBHelper class, add the following attribute:

[assembly: System.Runtime.CompilerServices.TypeForwardedTo(typeof(Logger)))]

Now ship the dbhelper.dll and logger.dll together to your existing consumers and next product release. The directive above ensures, if existing consumer applications try to access logger functions in dbhelper.dll, they would be redirected to logger.dll instead. So in this way your backward compatibility is maintained and your design team is also happy.