Closed AlexeyRaga closed 2 years ago
That matches the version stamped on the DLL itself
but separately the version of that DLL should probably be fixed.
Hmmm, you are right @baronfel! I haven't checked that assuming that the version is == to the package version and I now feel stupid :)
But if it is installed, do you have any idea of how to make it available?
I think (and it may again be an incorrect guess) that when the runtime package does
[<assembly:CompilerServices.TypeProviderAssembly("AvroProvider.DesignTime.dll")>]
it cannot see libraries that are installed with nuget. How do people normally workaround it?
I took a look and noticed a few things
The Runtime DLL should not reference the TPSDK https://github.com/AlexeyRaga/FSharp.AvroProvider/blob/52adec5c287e69fa129ce5f0c30643686a985c9b/src/AvroProvider.Runtime/AvroProvider.Runtime.fsproj#L16
You need to make sure that the contents of the TPSDK end up in your package correctly
A few other things were wwrong with the setup that the default template was providing
The fixes are here, they will also be in a PR to this repo https://github.com/AlexeyRaga/FSharp.AvroProvider/pull/1
Description
Env:
.NET6
,F# 6
,MacOS
, nopacket
When creating a new provider and referencing
FSharp.TypeProviders.SDK
7.0.3
from Nuget, getting the following compilation error:There is no place in the project that references
FSharp.TypeProviders.SDK
1.0.0.0
, howeverAvroProvider/src/AvroProvider.DesignTime/bin/Debug/net6.0/AvroProvider.DesignTime.deps.json
includes this statement:I am not sure if it is a cause of a symptom of the problem.
Repro steps
Clone this project: https://github.com/AlexeyRaga/FSharp.AvroProvider
do
dotnet build
(I am building it on MacOS)Expected behavior
The provider builds and is accessible in the test project
Actual behavior
Known workarounds
I wasn't able to find any
Related information