search

fsprojects / FSharp.Configuration

The FSharp.Configuration project contains type providers for the configuration of .NET projects.
http://fsprojects.github.io/FSharp.Configuration/
Other
114 stars 63 forks source link

PackageReference & FSharp.Configuration #130

Closed pchalamet closed 11 months ago

pchalamet commented 6 years ago

Description Nuspec is broken when using PackageReference. This can be observed when compiling project using PackageReference (instead of package.config or Paket) as SharpYaml.dll is missing from output.

Analysis Here is an excerpt from 1.3 nuspec:

    <dependencies>
      <dependency id="FSharp.Core" version="4.0.0.1" />
    </dependencies>
    <references>
      <reference file="FSharp.Configuration.dll" />
    </references>

SharpYaml.dll is available in lib folder of the package - but there is no reference, no runtime dependencies & no package reference to SharpYaml... which is pretty much a problem with PackageReference as it's picky about what is referenced vs what is copied.

All in all, with PackageReference, SharpYaml.dll never goes to output folder.

How to fix The build is using SharpYaml package - ideally the dependency shall be materialized in nuspec. But this was a tricky considering #77. Probably add a reference to SharpYaml.dll but won't play nice with other packages.

    <references>
      <reference file="FSharp.Configuration.dll" />
      <reference file="SharpYaml.dll" />
    </references>
sergey-tihon commented 6 years ago

This is done intentionally because you should not need SharpYaml.dll in the end application. It is a design-time dependency. Type provider use it to read yaml file and provide types and your application should not have dependency on the library.

Do you have any issue because of the fact that library does not add to your app?

vasily-kirichenko commented 6 years ago

SharpYaml is not design time only dependency, it’s used to parse input when Load method is called at runtime.

pchalamet commented 6 years ago

Yes exactly - apps are crashing on parsing at runtime.

vasily-kirichenko commented 6 years ago

I tried to switch SharpYaml dependency from nuget to paket's github one. It works, but I'm not sure we solve any real problem with this approach. Thoughts?

pchalamet commented 6 years ago

You mean, just adding <files /> in nuspec ?

vasily-kirichenko commented 6 years ago

No. I mean removing SharpYaml nuget package dependency entirely and use Paket's github dependency, see https://github.com/fsprojects/FSharp.Configuration/compare/master...vasily-kirichenko:sharp-yaml-via-github-ref?expand=1

vasily-kirichenko commented 6 years ago

I think we can create our own shrunk SharpYaml C# project.

pchalamet commented 6 years ago

But couldn't we just run an ilmerge step instead ?

vasily-kirichenko commented 6 years ago

Yes.

sergey-tihon commented 6 years ago

ilmerge means that all users of FSharp.Configuration will not be able to reference SharpYaml from their projects

pchalamet commented 6 years ago

even if all types (of SharpYaml) are internalized ? SharpYaml is not exposed in the interface - must be fine.

sergey-tihon commented 6 years ago

I am not a big fan of using ilmerge for libraries that you distribute. It is great tool to pack all references inside your application, what will happen in runtime when user add a reference to a newer version of SharpYaml and add assembly redirects?

@pchalamet I did release version 1.3.1 that pack SharpYaml.dll inside. Could you please try it and check if it works for you?

pchalamet commented 6 years ago

Yes this works.

On the other hand, it's still a problem to ship assemblies from other packages. Asking myself if adding a dependency on SharpYaml would not be better while still leaving SharpYaml.dll in FSharp.Configuration (but without any reference nor file asset). There would still be discrepancies between Paket/NuGet and PackageReference thought. But it's up to you :-)

You can close the issue since it's now the same previous behavior. Thanks !