dotnet/roslyn

The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs.

Leandro T. C. Melo

@ltcmelo

@Neme12 thanks for the heads-up, that's something I can keep my eyes on during upgrades
it's for my own consumption

Ashley

@Neme12

if it only broke you during updates that would be fine, but i'm not sure that's the case... what if you're referencing a version X and at runtime you get a higher version Y?

i'm worred that could blow up at runtime

Leandro T. C. Melo

@ltcmelo

I don't see how that could break in practice, given that the object is only consumed by myself and all implementaion belong to the "my" class (in my object code)
so there should exist binary compatibility for that restricted part of the object
otherwise, I'd imagine that a whole lot of interface-based things would be breaking in the wild

Ashley

@Neme12

but if the compiler adds new members to the interface and your implementation does't implement them, it could blow up i think

there's a reason that new members usually aren't added to interfaces for compact

in this case, Roslyn does that but that's because other people aren't supposed to implement them

CyrusNajmabadi

@CyrusNajmabadi

what we're basically saying here is: if you do this, you're on your own :)

Ashley

@Neme12

@CyrusNajmabadi is there a way to create custom symbols using the code generation API?

CyrusNajmabadi

@CyrusNajmabadi

e.g. we make no compat claims here.

no. definitely not. :)

note: if you want a real C# symbol, you can always jsut write out C# code, and then use the standard compoilation/semantic model operation to get the symbol for that code.

e.g. literlaly emitvoid Whatever(YourParamType yourParamName) { }

then go grab the IParameterSymbol for that IMethodSymbol.

Leandro T. C. Melo

@ltcmelo

I understand there are no guaranteeds
still, I don't think that can possibily blow up, given that the object in questions are of my consumption; in particular, could you give me a concrete example where it could blow up for such an object given that any (possibly) new member won't be accessed?
in fact, I suppose that this is guaranteed my msil spec

@CyrusNajmabadi the C# code approach would be too expensive

Ashley

@Neme12

oh I thought the code generation APIs were public, that's a shame

it doesn't matter that it's just for your consumption

i'll try to get a repro

Leandro T. C. Melo

@ltcmelo

it doesn't matter that it's just for your consumption

it makes in the sense that .NET is backward compatible, so "my" object code must continue working across versions
if this wasn't the case, we'd see a large amount of backward compatibility breakages accross new versions of .NET

Ashley

@Neme12

yup, it blows up

basically, if you have a dll that implements an interface from another dll you're referencing... and at runtime you get a higher version of that dll (which happens commonly when using Roslyn), and in that higher version there's a new member added to the interface, your code will blow up because you didn't implement that new member

Leandro T. C. Melo

@ltcmelo

@Neme12 based on your screen shot, you indeed made a backward incompatible change (it seems you removed a field)
of course, if backward incompatible changes are released, then things could break... a lot will

Ashley

@Neme12

I didn't remove a field

I added a property to the interface

here's the code in the class library:

public interface IMyInterface
{
    public string Name { get; }
}

here's the code in a console app that references it:

using System;

var myClass = new MyClass("name");
Console.WriteLine(myClass.Name);

class MyClass : IMyInterface
{
    public MyClass(string name)
    {
        Name = name;
    }

    public string Name { get; }
}

now, in the class library, I added a new property to IMyInterface:

public interface IMyInterface
{
    public string Name { get; }

    public string Description { get; }
}

I recompiled the library, didn't recompile the console app, and then ran the console app

this is what you'' get

Unhandled exception. System.TypeLoadException: Method 'get_Description' in type 'MyClass' from assembly 'ConsoleApp3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
   at Program.<Main>$(String[] args)

normally, libraries don't add new members to interface because of it, becasue it would break anyone who implements that interface

Leandro T. C. Melo

@ltcmelo

I think that's fine... it's acceptable that you get a load time error; undefined behavior errors aren't acceptable, though
in that specific case, where you're running an .exe, you could deploy self-contained versions of the app as well (we do that for our tool)

Ashley

@Neme12

but Roslyn does this with the symbol APIs because it states that you're not allowed to implement it anyway

oh right, if that's a custom app where you have a custom version of roslyn then yes, I assumed this would be something like an analyzer or VS extension

where you aren't guaranteed what version you'll get at runtime

in that case this would be really problematic

never mind then 😄

Leandro T. C. Melo

@ltcmelo

we also release non self-contained versions, which rely on the customer's runtime;
but we still run through .NET rather than through .exe
there always will be chances of runtime incompatibility, but isn't in my opinion a Roslyn specific issue... it's general

Ashley

@Neme12

it is a roslyn specific issue in this case, because the BCL doesn't make runtime breaking changes like that, by adding new members to interfaces

Roslyn is special in this because they tell you that they don't support customers implementing those interfaces and it's only supposed to be implemented by them

CyrusNajmabadi

@CyrusNajmabadi

@CyrusNajmabadi the C# code approach would be too expensive

expensive in what sense?

Leandro T. C. Melo

@ltcmelo

@Neme12 what I mean is that there's plenty of software with "private API's" (this isn't specific even to C#)

of course, I'd prefer to use official public API, but this isn't always an option (such as in this case)

@CyrusNajmabadi expensive in the sense of performance runtime

at least that's what I imagine (given that I'd trigger that parsing pipeline), but I didn't measure

CyrusNajmabadi

@CyrusNajmabadi

i'm skeptical :)

Joe4evr

@Joe4evr

it's just an interface, so you can always just instantiate one yourself.

I thought the I*Symbol types were interfaces because the domain benefitted from modeling multiple-inheritance in some cases and not meant for third-party implementation
there's even analyzers shipped in the Compiler SDK that prevent creating third-party implementations because the API surface won't be stable across compiler versions

Where communities thrive

People

Repo info

Activity