net461 support and thrift.dll #178
Comments
|
I what perspective is the public API different? |
|
This Thrift: Adds this reference: Running my sample console app then bombs with Object explorer then shows this. Note the [Thrift] and [Thrift45] markers that are displayed where differences are recognized by my VS2017: This happens on a modern 64bit Win10 client, where I wanted to reproduce my problem. What puzzles me right now is that I have a different machine (32bit Win7 that I must support, sorry) where the two thrift.dll differences are more dramatic, e.g. there is no TProtocol at all, which hinders the thrift sender to compile. Nevermind though, I must investigate that issue in the first place. N.B.: additional references coming with thrift: |
|
You should not add a dependency on ApacheThrift yourself. Use the transitive dependency through Jaeger. Only that way you will end up with the correct netstandard version of Apache. See dotnet/sdk#1791 (comment) |
|
On API differences compiling and then a lot of which is probably caused by thrift's different async implementation model. |
|
Yes I checked the code base for thrift. net45 is only for comparability with code generated as „csharp“. We generate as „netstd“. Make sure to not reference ApacheThrift in your own csproj to avoid this problem. See the link one post above for an explanation. It’s a problem with how NuGet selects packages. And there is no other workaround than having a separate csproj targeting netstandard and inheriting the dependencies. As jaeger only targets netstandard, you just have to remove your manual NuGet reference. |
|
Yeah. Made a new net461 project, added the nuget I'm just probably too dumb for this. So sorry. Thanks for your help! |
|
@razbezhkin Glad that you found it out yourself. Just make sure to dispose your tracer (or call |
|
@Lercher Can you please advise how the problem solved on your end ? I'm facing the same issue: when creating a console application for Only after I copied manually |
|
@yury-kozlov Make sure to not reference If you try to run it on another machine, make sure to use the publish option instead of copying just the Let me know if that removes your problem, otherwise I will give it another look. |
|
@Falco20019 what do you mean:
As a nuget reference I only added official |
|
Can you check if you have a This should not happen if you do not reference .NET Framework 4.6.1 only has limited support for .NET Standard which is where this problem comes from. So if you are not bound to that version, I would always recommend a version of 4.7.2 or higher. A good explanation of why can be found here: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET Other than that, debugging directly should work and using publish should work. Only running it from bin directly will not work with 4.6.1 since the proxy DLLs are missing. Also your |
|
Yes I do have This is csproj from framework 4.6.1: |
|
I think you need to use You can also use the new SDK-style csproj format with See https://docs.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference on how to migrate. |
|
Unfortunately PackageReference instead of packages.config didn't help:
See contents of the new csproj: |
|
Hi all, everything was already answered by #178 (comment) As far as I remember, I just removed all references and added only the Jaeger one via nuget. Here is an excerpt from one of my vb.net project files. Hope that helps. <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0">
<PropertyGroup>
...
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
...
<ItemGroup>
<Reference Include="Jaeger, Version=0.3.7.0, Culture=neutral, PublicKeyToken=9516061555a213a8, processorArchitecture=MSIL">
<HintPath>..\packages\Jaeger.0.3.7\lib\netstandard2.0\Jaeger.dll</HintPath>
</Reference>
<Reference Include="Jaeger.Thrift, Version=0.3.7.0, Culture=neutral, PublicKeyToken=9516061555a213a8, processorArchitecture=MSIL">
<HintPath>..\packages\Jaeger.Thrift.0.3.7\lib\netstandard2.0\Jaeger.Thrift.dll</HintPath>
</Reference>
<Reference Include="Jaeger.Thrift.VendoredThrift, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9516061555a213a8, processorArchitecture=MSIL">
<HintPath>..\packages\Jaeger.Thrift.VendoredThrift.0.3.7\lib\netstandard2.0\Jaeger.Thrift.VendoredThrift.dll</HintPath>
</Reference>
...
<Reference Include="OpenTracing, Version=0.12.1.0, Culture=neutral, PublicKeyToken=61503406977abdaf, processorArchitecture=MSIL">
<HintPath>..\packages\OpenTracing.0.12.1\lib\net45\OpenTracing.dll</HintPath>
</Reference>
...My app.config contains nothing special. |
|
Thank you @Lercher. As I understand, your nuget is @Falco20019 This may be related: Could not load file or assembly Thrift, Version=0.13.0.0. In their fix I see that they explicitly provide a hint for Thrift.dll: |
|
That‘s a manual workaround that usually should not be necessary. I will need to look into it but won‘t be able to do so until around Thursday :( The problem here is the one that I linked earlier. The build chain is resolving the transitive dependency using .NET Framework 4.5 instead of .NET Standard 2.0 (which is wrong). But I don‘t really understand why it‘s doing that… The fix is also adding the following line for setting |
|
Thanks! From the readme:
|
|
Since this issue was closed, let‘s continue the discussion on #212 |
and others
Requirement - what kind of business use case are you trying to solve?
Instrumenting an existing .Net Framework 4.6.1 application and using UDP for communication with a local jaeger agent.
Problem - what in Jaeger blocks you from solving the requirement?
The Thrift reference. Adding
New Jaeger.Senders.Thrift.UdpSender()to the remote reporter builder raises the exceptionI've fiddled with this situation and I guess the root cause is that the nuget package of Apache thrift publishes a thrift.dll for netstandard and a thrift45.dll for net45, which is used for the net461 project. Moreover these two dlls expose quite a different public API. Manually referencing thrift's netstandard2 library seems to work formally, but I have a bad feeling about this.
Proposal - what do you suggest to solve the problem or improve the existing situation?
I really don't know. Experimentally copying the client's sources to new net461 cs-projects, using thrift's nuget and building it fails b/c of thrift's different API for net45/netstandard.
Any open questions to address
Importing thrift induces a lot of dependencies. If there is need to export a COM API all must be GAC-able and thus strong named. Moving all these dependencies to the jaeger agent (written in go, so there is no actual "moving") and having a very slim variant of the client that can only communicate with the agent via a single fixed protocol could be an option.
The text was updated successfully, but these errors were encountered: