You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
.NET 6: remove the concept of binding projects and add support for binding native libraries/frameworks to normal library/executable projects #10254
There's nothing special about binding projects that couldn't also be made to work from other projects (library / executable) projects, so to simplify things, we should just make that happen for .NET 6.
Some care would have to be taken with regards to default compile includes, since there will be *.cs files in the project directory which should be pre-processed, and not passed to csc like other *.cs files (ApiDefinition.cs / StructsAndEnums.cs, etc).
Scenarios (to add tests for):
Creating a NuGet for a library project with a binding.
Referencing a library project with a binding from an executable project.
Referencing a library project with a binding in another library project.
Adding a binding directly to an executable project.
One way to implement this would be to set IsBindingProject=true if the project has any @(ObjcBindingApiDefinition) items. Then the concept of a binding project will really just be something we use internally, and customer projects can just remove IsBindingProject=true from their projects.
However, we'll have to check with any IDEs to see if they check @(ProjectCapability) for "<platform>BindingProject", because otherwise we might have a chicken-and-egg problem: if an IDE shows a custom UI for binding projects (to add api definitions for instance), but the project isn't a binding project (because it doesn't have an api definition yet).
That said, I'm not sure if there's a great benefit here, having a binding-project/class-library-project split isn't that onerous on us at the moment anyway
Yeah tbh having it being explicit seems more user friendly, than it being an obscure feature that customers need to know about ObjcBindingApiDefinition while templates solve the need to know probably it is also better for AI now having that property IsBindingProject around
Activity
rolfbjarne commentedon Jul 9, 2026
One way to implement this would be to set
IsBindingProject=trueif the project has any@(ObjcBindingApiDefinition)items. Then the concept of a binding project will really just be something we use internally, and customer projects can just removeIsBindingProject=truefrom their projects.However, we'll have to check with any IDEs to see if they check
@(ProjectCapability)for"<platform>BindingProject", because otherwise we might have a chicken-and-egg problem: if an IDE shows a custom UI for binding projects (to add api definitions for instance), but the project isn't a binding project (because it doesn't have an api definition yet).That said, I'm not sure if there's a great benefit here, having a binding-project/class-library-project split isn't that onerous on us at the moment anyway
dalexsoto commentedon Jul 9, 2026
Yeah tbh having it being explicit seems more user friendly, than it being an obscure feature that customers need to know about
ObjcBindingApiDefinitionwhile templates solve the need to know probably it is also better for AI now having that propertyIsBindingProjectaround