Fabulous - Drop Paket?

[TimLariviere]

Paket is used awkwardly in Fabulous. It doesn't really manage anything.

It is used to download FAKE 4, download some dependencies and lock version for the NuGet packages (paket.template).
But the .NET Standard libs manage their own dependencies using PackageReference, and the samples only directly reference the downloaded dependencies (Paket doesn't manage the samples).
https://github.com/fsprojects/Fabulous/blob/58bbfd79558f964270eeb66ba75acddea93f50da/Samples/AllControls/Droid/AllControls.Droid.fsproj#L91

It's quite confusing.

I would like to uniformize the repo by going either full Paket or full NuGet.
Problem is:

• Paket is not supported by Visual Studio for Mac (breaks IntelliSense, Restore working only with msbuild /t:Restore)
• Paket doesn't seem to support dotnet/SourceLink (something I'd like to add later)
• We have to make sure by hand that Paket and Fabulous use the same version of the dependencies

So I wonder: Maybe it would be better to drop Paket and go full NuGet (PackageReference)?
We can achieve the same "one place to manage all the dependencies" with a Directory.Build.props file.

What do you think?

[dsyme]

Yes, in this repo I've only really use paket to get a package resolution that I trust and then do the rest by hand.

The problem is that it's sort of a sanity check and a transitive package resolution I trust. I trust paket much more than dotnet to tell me about inconsistencies between packages (too often dotnet seems to give warnings rather than errors).

I'm not sure what to do about it. For this repo I don't want to use paket more than we do, and if we could continue to relegate it's role that is fine. But I don't want to give up on the sanity checking. Tricky

[dsyme]

We can achieve the same "one place to manage all the dependencies" with a Directory.Build.props file.

I think this approach may be consistent with using paket as a sanity checker. Basically the dependencies listed in Directory.Build.props would be a resolution of (some of) the transitive dependencies, and we can check the versions from a lock file against the props?

[TimLariviere]

I'm currently working with Directory.Build.props to find a solution to this issue.
The solution I came up with is to fix package versions in a props file.

<Project>
    <!-- Package versions -->
    <PropertyGroup>
        <FSharp_Core_Version>4.5.2</FSharp_Core_Version>
        <Xamarin_Forms_Version>3.1.0.697729</Xamarin_Forms_Version>
        <Xamarin_Forms_Maps_Version>3.1.0.697729</Xamarin_Forms_Maps_Version>
        <Newtonsoft_Json_Version>11.0.2</Newtonsoft_Json_Version>
        <FSharp_Compiler_Service_Version>23.0.3</FSharp_Compiler_Service_Version>
        <Dotnet_ProjInfo_Version>0.9.0</Dotnet_ProjInfo_Version>
        <OxyPlot_Core_Version>2.0.0-unstable0956</OxyPlot_Core_Version>
        <OxyPlot_Xamarin_Forms_Version>1.1.0-unstable0013</OxyPlot_Xamarin_Forms_Version>
        <SkiaSharp_Version>1.60.3</SkiaSharp_Version>
        <SkiaSharp_View_Forms_Version>1.60.3</SkiaSharp_View_Forms_Version>
        <Mono_Cecil_Version>0.10.0</Mono_Cecil_Version>
        <Microsoft_NET_Test_Sdk_Version>15.7.0</Microsoft_NET_Test_Sdk_Version>
        <MSTest_TestAdapter_Version>1.2.1</MSTest_TestAdapter_Version>
        <MSTest_TestFramework_Version>1.2.1</MSTest_TestFramework_Version>
        <Microsoft_SourceLink_Github_Version>1.0.0-beta-63313-01</Microsoft_SourceLink_Github_Version>
    </PropertyGroup>

    <PropertyGroup>
        <RestoreSources>
            $(RestoreSources);
            https://api.nuget.org/v3/index.json;
            https://www.myget.org/F/oxyplot;
            https://dotnet.myget.org/F/sourcelink/api/v3/index.json;
        </RestoreSources>
    </PropertyGroup>
</Project>

Then in the fsproj files, I do this

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="..\..\packages.props" />
  (...)
  <ItemGroup>
    <PackageReference Include="FSharp.Core" Version="$(FSharp_Core_Version)" />
    <PackageReference Include="Xamarin.Forms" Version="$(Xamarin_Forms_Version)" />
    <PackageReference Include="Microsoft.SourceLink.Github" Version="$(Microsoft_SourceLink_Github_Version)" PrivateAssets="All" Condition="'$(SourceLinkEnabled)' == True" />
  </ItemGroup>
</Project>

I think we can add a step in the build process to generate this packages.props file based on the resolution from Paket.
This is basically what Paket already does with paket.dependencies and the targets files, but this way it's at least supported by Visual Studio for Mac...

Also I replaced all paket.template files with unified packaging instructions in Directory.Build.props

<Project>
  <!-- NuGet Specs -->
  <PropertyGroup>
    <Version>0.22.0</Version>
    <Description>Add WPF to template</Description>
    <Authors>Fabulous Contributors</Authors>
    <PackageVersion>0.22.0</PackageVersion>
    <PackageRequireLicenseAcceptance>False</PackageRequireLicenseAcceptance>
    <PackageLicenseUrl>https://github.com/fsprojects/Fabulous/blob/master/LICENSE.md</PackageLicenseUrl>
    <PackageProjectUrl>https://github.com/fsprojects/Fabulous</PackageProjectUrl>
    <PackageTags>Xamarin.Forms;F#;Elmish;Elm;$(PackageTags)</PackageTags>
    <RepositoryUrl>https://github.com/fsprojects/Fabulous.git</RepositoryUrl>
    <RepositoryType>git</RepositoryType>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
  </PropertyGroup>
  <PropertyGroup>
    <!-- Support for arbitrary value in AssemblyInformationalVersionAttribute https://github.com/Microsoft/visualfsharp/issues/4822 -->
    <NoWarn>FS2003</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition="$(TargetFramework) == 'netstandard2.0' OR $(TargetFramework) == 'netcoreapp2.0'">
    <OtherFlags>/warnon:1182</OtherFlags>
  </PropertyGroup>
</Project>

I changed the build script to update this file to set the version and release notes, instead of generating AssemblyInfo files which are not recommended with the SDK-Style projects.

[slang25]

If you want to have your PackageReferences aligned on version numbers across projects, it might be worth looking at this, if you didn't already know about it:
https://github.com/Microsoft/MSBuildSdks/tree/master/src/CentralPackageVersions

[TimLariviere]

Ah thanks, this looks interesting!

[TimLariviere]

@slang25 This seems to work great. Except DisableImplicitFSharpCoreReference is required, otherwise CentralPackageVersions think that we're adding a reference to FSharp.Core without using Packages.props

[TimLariviere]

@slang25 Had to abandon CentralPackageVersions, because VS for Mac ignores it...
But I still used the way CentralPackageVersions work and replaced my variables with PackageReference Include/Update

[TimLariviere]

I'll close this issue and open a new one with the remaining work