Static linking: Understanding FS2009 warnings

[jaredpar]

Please provide a succinct description of the issue.

Repro steps

1. Clone https://github.com/VsVim/VsVim
2. Checkout the branch dev/jaredpar/fs2009
3. cd src\VimCore
4. run dotnet build

Expected behavior

The build completes cleanly

Actual behavior

The build produces several FS2009 warnings

Microsoft (R) Build Engine version 17.2.0-preview-22152-03+719247ede for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
FSC : warning FS2009: Ignoring mixed managed/unmanaged assembly 'System.Configuration.ConfigurationManager' during static linking [C:\Users\jaredpar\c 
ode\VsVim\Src\VimCore\VimCore.fsproj]
FSC : warning FS2009: Ignoring mixed managed/unmanaged assembly 'System.Security.Permissions' during static linking [C:\Users\jaredpar\code\VsVim\Src\ 
VimCore\VimCore.fsproj]
  VimCore -> C:\Users\jaredpar\code\VsVim\Binaries\Debug\VimCore\net472\Vim.Core.dll
  VimCore -> C:\Users\jaredpar\code\VsVim\Binaries\Debug\VimCore\net6.0\Vim.Core.dll

This project does link the FSharp runtime into the DLL which is likely the source of the FS2009 warnings. Unfortunately though I can't find any information on what this warning is, how to mitigate it, etc ... Looked in a number of places but coming up empty. Want to try and understand this warning so I can move forward with fixing this correctly vs suppressing and moving on.

[jaredpar]

A bit more detail. I noticed when looking at the binlog file that this warning is only happening when building the net6.0 target framework. The net472 target framework builds without any issues

[smoothdeveloper]

@jaredpar I've faced similar warnings, and the MSBuild output makes it hard to figure out which is the target framework that the message applies to.

Do you happen to know if this is specific to F# MSBuild targets or something upstream?

[dsyme]

My understanding is static linking shouldn't be used with .NET Core. We should deprecate it completely as it is an unsupported deployment scenario.

[jaredpar]

Curious: why is this not supported for .NET Core? Trying to think about what would make this harder compared to .NET Framework.

[jaredpar]

For context: the reason I'm using static linking in this particular project is to insulate VsVim from Visual Studio decisions on how FSharp.Core is deployed. In older versions of Visual Studio FSharp.Core was not deployed in a predictable manner. Some workloads deployed it, some did not and the versions involved were hard to predict. As a result I kept running into situations where VsVim couldn't be used because FSharp.Core was either missing or existed at the wrong version. I moved to static linking because it just removed the problem entirely.

The .NET Core build here is for other platforms where I don't think this issue exist. Hence it's not a big loss.

[KevinRansom]

@jaredpar , just to follow up from our earlier chat. This is absolutely supported on the coreclr, if it weren't then generative type providers would fail to work. We currently have a bug that adds an unnecssary reference, I haven't tracked down where and why yet, but I am working on it.