Binding projects don't work properly when used as project references

[rolfbjarne]

Repro:

• Open tests/tests.sln in VSMac.
• Build the framework-test project.
• Open the FrameworkTests.cs file.

Any API used from the bindings-framework-test project are squiggly red, and intellisense doesn't work:

This is something we have to fix in our msbuild logic somewhere.

Note that building the solution actually works, this just affects editing experience in the IDE (intellisense doesn't work).

A potential workaround is to build the binding project separately, and then just reference the binding assembly (.dll) in the main project instead.

[rolfbjarne]

I believe the problem is that our MSBuild logic doesn't have support for design-time builds: https://github.com/dotnet/project-system/blob/main/docs/design-time-builds.md#what-is-a-design-time-build

[rolfbjarne]

Some very early and incomplete work: rolfbjarne@216aeca

[Hooterr]

I'm seeing exactly the same with net7.0 and a macOS binding library.
VS studio can't find the namespace or any types in it, but the project builds and works with no problems. It's quite annoying though, since you can't use Intellisense and you have to constantly refer to the ApiDefinition file.

[brunck]

I worked around this by referencing the binding project assembly directly, which I build in a separate solution. This allows Intellisense to work but does require a bit of gynmastics in my automated build process.

[rolfbjarne]

This is best done as part of making binding projects compile directly on Windows (#16611), because we don't want to do design-time builds remotely.

[microspaze]

My workaround is:

1. Modify binding project's output folder to bin root by setting '<OutputPath>bin</OutputPath>' and '<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>'

<PropertyGroup>
    <TargetFramework>net7.0-ios</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>true</ImplicitUsings>
    <IsBindingProject>true</IsBindingProject>
    <Configurations>Debug;Release</Configurations>
    <Platforms>AnyCPU</Platforms>
    <OutputPath>bin</OutputPath>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
  </PropertyGroup>

2. Add binding project's dll to consumer project as a Assembly refererence.

<ItemGroup>
    <Reference Include="xxxx">
      <HintPath>..\xxxx\bin\xxxx.dll</HintPath>
    </Reference>
  </ItemGroup>

[cho-trackman]

@microspaze it's not always enough for the IntelliSense to work properly at all times. On top of that the referenced framework/lib is often not updated without a hard clean (delete obj/bin) leading to unrecognized selectors.

My solution for now is to copy the intermediate generated files under obj (*.g.cs) to the main project. Also the <NativeReference ...> is in the main project. No project or dll ref. Only thing is <AllowUnsafeBlocks>true</AllowUnsafeBlocks> in the main project does not look "nice".
Anybody else found a better solution?

[microspaze]

@cho-trackman
<AllowUnsafeBlocks>true</AllowUnsafeBlocks> is not necessary if there is 'unsafe' keyword property in your binding project. And everytime you modify the binding project, you need to build the binding project. Then you can have the IntelliSense for the consumer project.

But I had nerver faced with the unrecognized selectors for referenced framework/lib issue. It works fine for me on my currently working-on project: IJKPlayer.Binding

[jurganson]

So this is still an issue in .NET MAUI (as I presume it's perhaps part of VS studio's IntelliSense?) and I was wondering if there is any movement on this. Otherwise, could it be moved to the .NET MAUI repository as an issue? Using the .dll as a reference is working for now, but I know some developers would like to keep their solutions together, for easier maintenance and transparency.

[rolfbjarne]

So this is still an issue in .NET MAUI

Yes, it's still an issue.

I was wondering if there is any movement on this.

I've started working on this, but it will take a while, because it's not very high priority and I ran into some complications. I'm hoping to get it done for .NET 9, but no promises.

Otherwise, could it be moved to the .NET MAUI repository as an issue?

No, because it's not an issue in MAUI specifically, but in this repository.

[jurganson]

Glad to hear its in the pipeline, thanks for the quick reply @rolfbjarne