Confluent-kafka-dotnet: VS 2017 Project system - Project load fails

[enzian]

I have VS2017 installed and we have a base library (netstandard1.5) that references the confluent kafka package. Now when every this project is loaded, it will fail:

The base library also shows a strange behavior - There are ominous x64 and x86 folder in the solution:

As far as I can tell, this is caused by the contnetFiles in the NuGet package!

One workaround here is to delete the obj folder everytime befor the solution containing the problematic projects is opened - but that's really not a permanent solution!

[treziac]

Here is what grpc do on their side to load unmanaged lib with platform support:
https://github.com/grpc/grpc/blob/5098508d2d41a116113f7e333c516cd9ef34a943/src/csharp/Grpc.Core/Internal/UnmanagedLibrary.cs
(basically, do not use DLLImport but GetProcAddress (for windows and equivalent for other) after loading the lib, and include librdkafka_x86.dll and librdkafka_x64.dll in bin rather than in separate folder on windows, so will also need an update on librdkafka.redist for packaging)
Should also make it easier to resolve #91

Will look at it this we

[mhowlett]

I'm no longer seeing this issue when I load the Confluent.Kafka.sln file in VS 2017 (I was before). I'm guessing this is probably a result of moving to msbuild - the .csproj files I made by hand differ meaningfully from those auto generated by the migration tool. Also, I don't see the issue when creating a new project that references the 0.9.4 nuget package (in visual studio or via the cli, .net framework or .net core).

I recall seeing some warnings that looked related when using dotnet pack on a project that referenced the 0.9.4 nuget package, though I'm struggling to reproduce them now.

I'll leave this open for now, but won't do any more related testing until we are packaging and testing for the next release.

[treziac]

I had this solve by modifying my librdkafka.redist nupkg, putting the props in build folder in a new build/net and modify the prop accordingly (it's only a problem on standard net framework) It solves the problem as long as we don't target net framework in apps using the lib

Didn't give a try on the link I gave before

[edenhill]

@treziac Can you upload that hand-crafted .nupkg so I can have a look?

[treziac]

I didn't recreate a nupkg but modified the structure in the unpackaged one in my %userprofle%/.nuget
/build
| /net
| | librdkafka.redist.props
/runtimes
| /...

props is the following now:

<?xml version="1.0" encoding="utf-8" ?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-x86\native\*">
      <Link>x86\%(Filename)%(Extension)</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>False</Visible>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win7-x64\native\*">
      <Link>x64\%(Filename)%(Extension)</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Visible>False</Visible>
    </Content>
  </ItemGroup>
</Project>

(removed project.json check and add a parent folder path)

Didn't tested it too much, my only use case was netcoreapp an standardlibrary
Would have to test it :

• On VS2017 targeting net45, libstandard, netcoreapp and any mix of those
• On old csproj with net45 and/or libstandard
• On PCL
  ...

Also saw yesterday an other props file where they changed the project.json check to a package.config check, might worth a test too

Edit: see #133

[treziac]

On this: x64/x86 folders still appear sometimes when opening. This is because the library target both net45 and netstandard, and net45 will make the folders appear in obj (but it's a .net core/VS bug : the contents are effectively hidden and the folder should not appear)
The initial problem (duplicated contents) should be corrected on 0.9.5 - can you confirm @enzian?

[enzian]

i will evaluate and come back to you in the next 2 working days!

[mhowlett]

i believe this is now resolved. projects have changed since this was reported and the issue hasn't been reported in a long while.