I'll take the contrarian approach and say don't do it. The best of the solutions posted so far (use an alternate type such as FileInfo or Uri for one of the overloads) seems a bit hackish to me - goes against the principle of least surprise.
If you can construct using the content only without a filename, it follows that the filename is not essential. And similarly if you can construct with a filename only it follows that the content is not essential. Presumably you can subsequently set the missing filename/content later, e.g. by setting a property:
MyObject myObject = new MyObject(fileName);
myObject.Content = ...
MyObject myObject = new MyObject(content);
myObject.FileName = ...
Instead of trying to fight it, choose one of your parameters as being the most important (fileName in the following example), and create two constructurs as follows:
public MyObject(string fileName) : this(fileName, null)
{
}
public MyObject(string fileName, string content)
{
... implementation
}
You can allow null to be passed for either or both parameters if it makes sense. And you can insist that at least one is not null if that's appropriate:
public MyObject(string fileName, string content)
{
if (fileName == null && content == null) throw new ArgumentException(...);
...
}
In short, don't use hacks to work around restrictions like this.