If we want to still build/test older package versions like 6.1.0 or 5.2.0 on netcoreapp3.0, I recommend removing both changes in this file so we still build the application for all of the frameworks, and we can test locally in VS by setting ApiVersion to a version that's compatible with all of the TFM's we test against.

The changes you've made in tracer/build/PackageVersionsGeneratorDefinitions.json alone should be enough to ensure that CI won't build an incompatible package version/TFM

Ah yeah good point on that this removes the ability to test older versions
The issue that I was having with this specifically is that when I bumped the version to 6.2.0 it would attempt to build NET Core 2.1/3.0 here (which would fail).

I'll see if making Framework conditionals for the <ItemGroup> to have multiple PackageReference entries for ServiceStack does the trick.

I've swapped it to use two conditional ItemGroup one for .NET Core 2.1/3.0 and one for anything other than those.

Let me know if that looks good otherwise I can just revert it back to the original.

I was thinking that this way wouldn't work at first because there's this <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute> in the sample csproj and I thought that'd break the $(TargetFramework) value, but apparently not.

Oh right, the <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute> property controls whether the C# compilation should generate a [TargetFrameworkAttribute] that is applied to the resulting assembly. All the <GenerateXXXAttribute> flags operate just like this, so it doesn't affect the MSBuild properties but assembly attributes on the compiled application 👍🏼

Nice, thanks for the link 👍🏼

This comment is helpful, but maybe it could be placed somewhere else where we build/test? My first thought was adding it to tracer/build/PackageVersionsGeneratorDefinitions.json but I don't know if we can add comments there without breaking our JSON parsing 😞 I think the instrumentation here is only concerned with the method signature and the assembly dependency issue that was also introduced in 6.2.0 is a separate concern

Yeah I didn't really know where to put this, but it doesn't make a ton of sense here

I didn't think of attempting to add a comment to the ackageVersionsGeneratorDefinitions.json, so I'll try that and maybe also adding it as a comment in the sample csproj as well?

So I tossed a variation of the comment in the sample project.

I also learned that comments just aren't allowed in JSON whatsoever.

It looks like you're setting the same version value regardless of the TargetFramework, so maybe we can remove the PackageReference changes

The case I'm attempting to avoid with this setup is if you set the NuGet to 6.2.0 it'll cause the .NET Core 2.1/3.0 builds to fail in VS and then you can't run the tests.
So if you were wanting to test that version (or maybe higher versions?) you can just swap out the $(ApiVersion) in <ItemGroup Condition="'$(TargetFramework)'!='netcoreapp2.1' AND '$(TargetFramework)'!='netcoreapp3.0'">'s and avoid breaking the other NET Core targets. I don't think I did a good job explaining that reasoning in the comment in that csproj or maybe I'm just overthinking it

Ohhh I see what you're saying now. Maybe a more bulletproof (maybe not as clean?) way to do this is to just override the ApiVersion if we ever detect the bad combination of 6.2.0 and netcoreapp2.1/netcoreapp3.0. To do that you could restore the csproj to its original contents and then add a second ApiVersion line like this. What do you think?

<ApiVersion Condition="('$(TargetFramework)'=='netcoreapp2.1' OR '$(TargetFramework)'=='netcoreapp3.0') AND '$(ApiVersion)' == '6.2.0'">6.1.0</ApiVersion>

I like it, very nice 👍

Do you know what this string can contain and if it would be interesting to add it as a tag? I tried to check quickly but I'm not sure what it contains (if you don't know, don't mind me).

This has the function name of whatever called the SendReceive
I'm not really sure whether or not that'd be interesting information to add as a tag for us