CodeNamespace.Members does not include records

[PhilPJL]

Not sure where or how to report this but was redirected here from the developer community forum.
My original post is https://developercommunity.visualstudio.com/t/CodeNamespaceMembers-does-not-include-r/10035834

The issue boils down to EnvDTE does not currently support the record keyword.

[CyrusNajmabadi]

Yes, this is true. Codemodel is an extremely problematic legacy api. It's slow, mutable, and only usable from the ui thread. It is also not receiving updates. It has been superseded by the Roslyn syntactic and semantic apis. Those apis are much faster, immutable, and can be used safely off of the ui thread.

Thanks!

[PhilPJL]

It is also not receiving updates.

Point me at the MS statement that says that. As I understand it Entity Framework Core 7 is planning to use T4 templates so I'm assuming they're not deprecated.

[CyrusNajmabadi]

Point me at the MS statement that says that.

^ #62523 (comment)

We haven't updated code model, except for trivial issues, in more than a decade. It and codedom have been replaced with the Roslyn apis for getting full syntactic and semantic information about c# code. It's one of the reasons we made Roslyn in the first place :-)

Note: I believe the last time we even updated codemodel and codedom was around c#2 (maybe 3), or more than 15 years ago. They've been effectively in stasis since that point.

The codemodel design was fundamentally too limiting and unmaintainable. It had low fidelity, and a bunch of other issues due to it's COM roots. Roslyn is the modern replacement for it and has 100% fidelity with the language (and all it's updates) since the start, without any of those limitations. Every new release of the language gets full Roslyn support. That's because the Roslyn api is the api the actual compiler is using. It's not an overlay. So it always has to be complete so that the actual compiler can do it's job.

[CyrusNajmabadi]

Closing out as we are not updating codemodel for new constructs. Code should move to Roslyn if it wants to analyze C# as it's been the fully supported system that is kept up to date with every c# release for over a decade.

[CyrusNajmabadi]

Yes, this is true. Codemodel is an extremely problematic legacy api. It's slow, mutable, and only usable from the ui thread. It is also not receiving updates. It has been superseded by the Roslyn syntactic and semantic apis. Those apis are much faster, immutable, and can be used safely off of the ui thread.

Thanks!

[PhilPJL]

It is also not receiving updates.

Point me at the MS statement that says that. As I understand it Entity Framework Core 7 is planning to use T4 templates so I'm assuming they're not deprecated.

[CyrusNajmabadi]

Point me at the MS statement that says that.

^ #62523 (comment)

We haven't updated code model, except for trivial issues, in more than a decade. It and codedom have been replaced with the Roslyn apis for getting full syntactic and semantic information about c# code. It's one of the reasons we made Roslyn in the first place :-)

Note: I believe the last time we even updated codemodel and codedom was around c#2 (maybe 3), or more than 15 years ago. They've been effectively in stasis since that point.

The codemodel design was fundamentally too limiting and unmaintainable. It had low fidelity, and a bunch of other issues due to it's COM roots. Roslyn is the modern replacement for it and has 100% fidelity with the language (and all it's updates) since the start, without any of those limitations. Every new release of the language gets full Roslyn support. That's because the Roslyn api is the api the actual compiler is using. It's not an overlay. So it always has to be complete so that the actual compiler can do it's job.

[CyrusNajmabadi]

Closing out as we are not updating codemodel for new constructs. Code should move to Roslyn if it wants to analyze C# as it's been the fully supported system that is kept up to date with every c# release for over a decade.