C＃-使新类不属于System.Object

Question

I have a huge code base and I recently made a change where I changed the type of a parameter from String to a custom class. On the next compile I got all the areas where the impact was, but areas where the input type was of type Object failed. for eg

String str = "32"
int i = Convert.ToInt32(str)

Now I have changed String to a new custom type lets say MyCustomClass I would now want following code to fail on next compile

MyCustomClass str = new MyCustomClass("32")
int i = Convert.ToInt32(str)

but it won't as Convert.ToInt32 also accepts type Object . Is there some way I can make a change in MyCustomClass that it's not considered Object anymore. Please note : Convert.ToInt32 is only used for sample I have many more such functions, so please focus your suggestion/answer to question asked.

Answer 1

Override ToString() and IConvertible

You said in the comments that your intentions are to find places where your object, which had previously been treated as a string, and are now being treated as an object.

In these situations typically, the third-party code would call .ToString() on your object to get something which it can use.
So, Convert.ToInt32(str) is equivalent to Convert.ToInt32(str.ToString()) .

If you implement ToString() and IConvertible to return whatever your old version of str looked like then it should continue to work in the same way as the old version.

Probably.

Sorry I know that is not the 100% perfect compile time answer you were looking for, but I think you also know very well that your MyCustomClass will always be considered object.

Answer 2

Possible compile time answer:

• Write a tool which uses reflection to iterate over every class/struct/interface in every system/third-party DLL.

• Output a load of CS files which contain all these same classes, but just throw NotImplementedException.
  (T4 could help you do this)

• Compile these classes into dummy.dll

• Your .csproj now references only this one dummy.dll, instead of the real dlls.
  Your project should compile fine against the dummy dll.

• Look at your dummy.cs files and delete any use of object.

• Re-compile... and suddenly you get a load of compile time errors showing you anywhere you are using an object.

Answer 3

Impliment an implicit cast from MyCustomClass to String.

public static implicit operator string(MyCustomClass str)
{
    return "Legacy respresentation of str";
}

This allows the complier the choice of choosing ToInt32(Object) or ToInt32(String), and I bet it favours the later.

This way all your existing function calls will remain the same so you wont have to be concerned about third party implentation details.

(Sorry, I am not at a computer right now so I can`t test that my assumtion is correct. If you do test this, be sure to consider extension methods, as they can affect the conpilers desision making in unexpected ways)