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

Enable ResxProvider on net5.0-windows #164

Open danabr opened 2 years ago

danabr commented 2 years ago

This provides an upgrade path for projects moving from .NET Framework to .NET 5+.

danabr commented 2 years ago

I've manually tested this by enabling and running the ResXProvider tests in the FSharp.Configuration.Tests project. I was only able to run the tests through Visual Studio after the applying the workaround in #146. I've left those changes out, though, since I haven't tested that they work on all platforms and outside Visual Studio.

I am a bit confused regarding src/FSharp.Configuration/FSharp.Configuration.fsproj. Is that still used? If so, should I add the "net5.0-windows" target there as well? I am wondering since it is referring to source files that do not exist.

danabr commented 2 years ago

I see there are more things that need to be done in order to build the net5.0-windows configuration and get it included in the nuget package. I'll see if I can figure it out on my own.

dsyme commented 2 years ago

Likely the whole TP still needs updating for netcore

@baronfel any idea where we're at on this one?

sergey-tihon commented 2 years ago

@dsyme other TPs were migrated here https://github.com/fsprojects/FSharp.Configuration/pull/139

danabr commented 2 years ago

If I create a NuGet package with the latest changes on this branch, I am able to successfully use the type provider from within Visual Studio (2019) and compilation works fine. However, it does not work when using dotnet build. Then I get the error:

 error FS0039: The type 'ResXProvider' is not defined. [C:\cygwin64\home\daab\dev\resx\resx.fsproj]

Any clue what may cause the type provider to work with VS, but not with dotnet build?

I'll mark this PR as a draft until this is resolved, and to avoid spamming you guys too much.

sergey-tihon commented 2 years ago

The downside of this fix is that after the merge we will have to build NuGet package always on Windows (because of use net5.0-windows).

TPDTC loading rules were developer before .NET 5. I am not sure if net5.0-windows is fully supported. @dsyme can you please confirm that net5.0-windows can be used as TPDTC runtime?

@danabr meanwhile, you should be able to test it. You can add some code inside ENABLE_RESXPROVIDER condition check that runs only when msbuild load TPDTC compiled for net5.0-windows, that code can create file on file system for example, then run dotnet build and check for if file is created.
If there will be no file that mean that dotnet build load wrong version of TPDTC

danabr commented 2 years ago

Unfortunately, I am not able to build the tests even on the master branch. I get build errors like the following (this is after switching to the master branch and running git clean -fxd to ensure a clean environment):

       CoreCompile:
         C:\Program Files\dotnet\dotnet.exe -o:obj\Release\net5.0\FSharp.Configuration.Tests.dll
         --debug:portable
         --noframework
         --define:TRACE
         --define:RELEASE
         --define:NET
         --define:NET5_0
         --define:NETCOREAPP
         --define:NET5_0_OR_GREATER
         --define:NETCOREAPP1_0_OR_GREATER
         --define:NETCOREAPP1_1_OR_GREATER
         --define:NETCOREAPP2_0_OR_GREATER
         --define:NETCOREAPP2_1_OR_GREATER
         --define:NETCOREAPP2_2_OR_GREATER
         --define:NETCOREAPP3_0_OR_GREATER
         --define:NETCOREAPP3_1_OR_GREATER
         --optimize+
         --resource:obj\Release\net5.0\FSharp.Configuration.Tests.Resource1.resources
          -r [...]
          --target:exe
         --nowarn:NU1603,NU1604,NU1605,NU1608
         --warn:3
         --warnaserror:3239
         --fullpaths
         --flaterrors
         --highentropyva+
         --targetprofile:netcore
         --nocopyfsharpcore
         --deterministic+
         --simpleresolution
         obj\Release\net5.0\.NETCoreApp,Version=v5.0.AssemblyAttributes.fs
         obj\Release\net5.0\FSharp.Configuration.Tests.AssemblyInfo.fs
         AppSettingsProvider.Tests.fs
         ResXProvider.Tests.fs
         YamlProvider.Tests.fs
         IniFileProvider.Tests.fs
         Program.fs
         Could not execute because the specified command or file was not found.
         Possible reasons for this include:
           * You misspelled a built-in dotnet command.
           * You intended to execute a .NET program, but dotnet-@C:\Users\daab\AppData\Local\Temp\tmpba50db7601614f3eb25cd2e107f3f279.rsp does not exist.
           * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
     2>C:\Program Files\dotnet\sdk\5.0.303\FSharp\Microsoft.FSharp.Targets(281,9): error MSB6006: "dotnet.exe" exited with code 1. [C:\cygwin64\home\daab\dev\compat\FSharp.Configuration\tests\FSharp.Configuration.Tests\FSharp.Configuration.Tests.fsproj]

I might give up on using type providers for the time being, and just go with code generation for my project instead.

sergey-tihon commented 2 years ago

@danabr Is it result of execution build.cmd? (it works on Github Actions, including your branch)

danabr commented 2 years ago

Yes, this is using build.cmd from a VS 2019 developer command prompt. Thanks for the link to the Github Actions output. I see the same error is present there:

           * You intended to execute a .NET program, but dotnet-@C:\Users\runneradmin\AppData\Local\Temp\tmpf9770f2245f84e7e854503dc8c23db4d.rsp does not exist.
           * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH

Comparing some other invocations of dotnet.exe, it seems like the path to fsc.dll is missing. Compare this working call with the call that gave the error above.

danabr commented 2 years ago

I'm closing this for now, since I've not been able to get even the master branch to build cleanly on my system (using build.cmd). I might revisit this later.

sergey-tihon commented 2 years ago

@danabr plz keep it open. it is good piece of works that should be merged at some point of time.

I already take a look and already understand why it does not work on you machine (it uses fsc.props to build project using full framework version of FSC)

I still looking for a working sample of TP with dependencies that build with .NET 5/6. When I find out how it should work .... I will merge migration to .NET 6 https://github.com/fsprojects/FSharp.Configuration/pull/165 and then this PR.