Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:12
    dotnet-maestro[bot] synchronize #61144
  • 13:12

    dotnet-maestro[bot] on dev17.0-vs-deps-e0b4ca26-1f06-4af7-a64c-cbf21a87cdc2

    Update dependencies from https:… (compare)

  • 13:12
    dotnet-maestro[bot] edited #61144
  • 13:06
    CyrusNajmabadi commented #61504
  • 12:51

    dotnet-maestro[bot] on darc-main-cade8067-d43a-4b54-be3b-8af56421c413

    (compare)

  • 12:50

    dotnet-maestro[bot] on darc-main-cade8067-d43a-4b54-be3b-8af56421c413

    (compare)

  • 12:22
    dotnet-maestro[bot] synchronize #61209
  • 12:22

    dotnet-maestro[bot] on darc-main-cfe1a973-8b72-4fdf-9473-8959aea8fb8e

    Update dependencies from https:… (compare)

  • 12:22
    dotnet-maestro[bot] edited #61209
  • 09:15
    Joe4evr commented #61490
  • 09:12
    Joe4evr commented #61490
  • 08:37
    Joe4evr commented #61490
  • 07:35
    Daxode edited #61504
  • 07:35
    Daxode edited #61504
  • 07:27
    Daxode edited #61504
  • 07:26
    dotnet-issue-labeler[bot] labeled #61504
  • 07:26
    dotnet-issue-labeler[bot] labeled #61504
  • 07:26
    Daxode opened #61504
  • 07:15
    msftbot[bot] milestoned #60808
  • 07:15
    mavasani closed #60808
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
image.png
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
no
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