I'm pretty sure the only way is to define an implicit conversion operator:
http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx

Of course, it should be stressed: "Use it to enable implicit conversions between a user-defined type and another type, if the conversion is guaranteed not to cause a loss of data."

In fact, I think you shouldn't use implicit or explicit type conversion operators at all.

Why? What would you suggest instead?

Functions.

Ok, the only problem with that is that it is (i believe) not a usual way to do this. I might forget that the project used functions for conversion, and if someone else did need to use libraries written by me, they might not even think about the possibility that functions were used for conversion. Am I right? Is this good enough reason to use implicit/explicit conversion instead? Are there any other pros of using functions?

No. I would expect people to use plain old functions. There are large downsides to explicit conversion operators -- mainly that using them makes it hard to identify the places where you're using run-time casts, because they look the same. Implicit conversion operators make it difficult to read code outside of the IDE. Which we do at my workplace, in code reviews and when we don't want to open up a file from another branch in a whole new IDE instance. Using plain old functions, calling them with x.ToBar() or Bar.FromFoo(x) or possibly new Bar(x) doesn't have either disadvantage. Since using plain old functions reduces the probability of making an error, it makes sense to use them.

On the other hand, there might be advantages to using the TypeConverter framework that I'm not familiar with. But converting between equivalent types isn't exactly a hard problem.

Thanks for explanation. I'll use functions - I've found that my types are not so 'equivalent' as I thought. Thanks again!