.NET No need to recompile program after library editing

Question

Please consider this scenario:

public class TestType
{
    public string a
    {
        get;
        set;
    }
    public string b
    {
        get;
        set;
    }

    public override string ToString()
    {
        return string.Format("a: \"{0}\"\tb:\"{1}\"", a, b);
    }
}

TestType class is compiled in a class library, then I use it in this simple program:

    static void Main(string[] args)
    {
        TestType tP = new TestType();
        tP.a = "a";
        tP.b = "b";
        Console.WriteLine(tP.ToString());
        Console.ReadKey(true);
    }

Obviously it works(correct execution without errors).

Output: a: "a" b:"b"

Then I edit the class in the library like this:

public class TestType
{
    public string a
    {
        get;
        set;
    }
    public string b
    {
        get;
        set;
    }
    public string c
    {
        get;
        set;
    }

    public override string ToString()
    {
        return string.Format("a: \"{0}\"\tb:\"{1}\"\tc:\"{2}\"", a, b, c);
    }
}

I recompile just the library and re-run the program (without recompiling it). Now I expected a crash by the program, because it isn't aware of the changes on the class, but it works.

Output: a: "a" b:"b" c:""

How can it work if the type is different from the one it knows?

Why you expected a crash? Your changes are all backward compatible. — Hamid Pourjam, Mar 16 '15 at 08:44
this feature is what allows you to add code to an older version of a .dll, recompile it, and then use that new .dll in your program without recompiling the program. — U. Busto, Mar 16 '15 at 08:50

score 3 · Accepted Answer · edited May 23 '17 at 12:06

3

.NET DLLs have some degree of backwards-compatibility. Adding a field is not a binary-breaking change.

edited May 23 '17 at 12:06

Community

1
1

answered Mar 16 '15 at 08:45

Heinzi

167,459
57
363
519

Is there a complete list of edits that require the binary recompilation? I found http://blogs.msdn.com/b/jmstall/archive/2008/03/10/binary-vs-source-compatibility.aspx but it doesn't seem complete – Matteo Umili Mar 16 '15 at 09:56
@codroipo: I don't think that there is such a list. Otherwise, there would be no need for the (inverse) list I linked to. – Heinzi Mar 16 '15 at 10:00

score 2 · Answer 2 · answered Mar 16 '15 at 08:45

Your changes didn't break the interface of the class TestType (and are strictly additive) so there was no API-compatibility failure.

Remember, .NET programs are really compiled at runtime during the JIT process when errors like these would be identified. Note that .NET uses names as a means of linking rather than GUIDs or other identifiers, so you can replace any assembly with another provided it contains the same expected types with the same expected members - this is a security concern, hence why Strong Naming exists.

.NET No need to recompile program after library editing

2 Answers2