Azure / azure-functions-host

The host/runtime that powers Azure Functions
https://functions.azure.com
MIT License
1.94k stars 441 forks source link

F# Compilation Failure: Multiple references to 'mscorlib.dll' are not permitted #1027

Closed gshackles closed 7 years ago

gshackles commented 7 years ago

I'm running into a scenario where adding a few NuGet packages to my F# function results in the following error being spit out multiple times during compilation:

2016-12-04T21:05:16.249 commandLineArgs(1,1): error FS215: Multiple references to 'mscorlib.dll' are not permitted

Here's a project.json that reproduces the issue:

{
    "frameworks": {
        "net46": {
            "dependencies": {
                "FSharp.Data": "2.3.2",
                "FSharp.Data.SqlClient": "1.8.2",
                "Microsoft.Azure.Search": "3.0.1"
            }
        }
    }
}

It's also worth noting that this happens regardless of what's in the function itself, so is caused simply by adding the references.

Repro steps

  1. Create a new F# function

  2. Add the project.json file above

  3. 💥

Expected behavior

The function should compile

Actual behavior

The function fails to compile

ghost commented 7 years ago

I also ran into this issue. Am using Paket according to this post now for dependency management because the "magical" way this is designed to work frankly is not very good.

fabiocav commented 7 years ago

@gshackles will have a fix for this ASAP and see if we can squeeze it in with the next release (which also brings some other F# fixes)

@stefan-akelius the process is a bit less "magical" than what described in the post :) For NuGet referenced packages, the behavior you get is similar to what you'd get with .NET Core or Visual Studio, where the appropriate package assemblies are referenced, so there's no special way to reference those assemblies with a #r (or need to do so). I don't want to hijack the issue, but I would like to hear more about what you dislike with the current process, as we're always looking to improve (including exposing the right hooks to enable other flows and better integration with other tools like Packet, which is something that has been discussed) if you could either open an issue with more details or contact me directly at fabio.cavalcante@microsoft.com, that would be great!

ghost commented 7 years ago

@fabiocav As soon I have time I will get back to you.

dsyme commented 7 years ago

@fabiocav Could add logging that reports the full set of command line args passed to Compile please? That would help in the future.

I suppose the error is likely to be because the C# resolution process is reporting multiple mscorlib.dll and passing those to the compiler. I didn't expect that, I'd like to see the full set of DLLs being passed through and the project.lock.json. If it's just a matter of filtering for duplicates then that is easy - if it's a conflicting set of mscorlib.dll then that's harder.

dsyme commented 7 years ago

@fabiocav I suppose the process feels a bit magical because it doesn't lead you to use a resolution phase (paket update) where you get to inspect the transitive resolutions and decide if they are the right ones which you want to commit to. Also it doesn't tend to show the full sets of inferred coimand line arguments. Getting the full set of F# compilation command-line arguments used logged by default will help.

You can probably use an explicit lock file along with a github repo but the UI doesn't really lead you in that direction.

fabiocav commented 7 years ago

Makes sense.

I'll add the command line arguments to the logs. I'm hoping the issue is that we're ending up with duplicate references, and not conflicting versions (I'll validate that).

fabiocav commented 7 years ago

I ran a quick test and validated that we're dealing with duplicate references from different locations, in this case, the framework folder and the GAC (those are the same assembly):

fsc.exe
--noframework
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
-r:C:\Users\facaval\.nuget\packages\FSharp.Data\2.3.2\lib\net40\FSharp.Data.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml.Linq\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.Linq.dll
-r:C:\Users\facaval\.nuget\packages\FSharp.Data.SqlClient\1.8.2\lib\net40\FSharp.Data.SqlClient.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_32\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll
-r:C:\Users\facaval\.nuget\packages\Microsoft.Azure.Search\3.0.1\lib\net45\Microsoft.Azure.Search.dll
-r:C:\Users\facaval\.nuget\packages\Microsoft.Rest.ClientRuntime\2.3.4\lib\net45\Microsoft.Rest.ClientRuntime.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http.WebRequest\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.WebRequest.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.Serialization\v4.0_4.0.0.0__b77a5c561934e089\System.Runtime.Serialization.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
-r:C:\Users\facaval\.nuget\packages\Microsoft.Rest.ClientRuntime.Azure\3.3.4\lib\net45\Microsoft.Rest.ClientRuntime.Azure.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http.WebRequest\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.WebRequest.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
-r:C:\Users\facaval\.nuget\packages\Microsoft.Spatial\6.15.0\lib\portable-net45+win+wpa81\Microsoft.Spatial.dll
-r:C:\Users\facaval\.nuget\packages\Newtonsoft.Json\6.0.8\lib\net45\Newtonsoft.Json.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.dll
-r:C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.CSharp\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.CSharp.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0dd888ad\30c388ef\assembly\dl3\5f9c21c6\00f087be_e44cd201\Microsoft.Azure.WebJobs.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0dd888ad\30c388ef\assembly\dl3\6221abf3\00b273ca_e44cd201\Microsoft.Azure.WebJobs.Host.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0dd888ad\30c388ef\assembly\dl3\eb10c799\24052cc7_1b3ad201\Microsoft.Azure.WebJobs.Extensions.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0dd888ad\30c388ef\assembly\dl3\0895250c\00ebcb58_f23ad001\System.Web.Http.dll
-r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0dd888ad\30c388ef\assembly\dl3\48e1f92a\00dda451_f23ad001\System.Net.Http.Formatting.dll
-r:System.Linq.dll
-r:System.Reflection.dll
-r:System.Linq.Expressions.dll
-r:System.Threading.Tasks.dll
-r:System.IO.dll
-r:System.Net.Requests.dll
-r:System.Collections.dll
-r:System.Runtime.Numerics.dll
-r:System.Threading.dll
-r:System.Runtime.dll
-r:System.Numerics.dll
--optimize-
--debug+
--tailcalls-
--lib:D:\src\gh.fabiocav\azure-webjobs-sdk-script\sample\HttpTrigger-FSharp\bin
--out:C:\Users\facaval\AppData\Local\Temp\f9e0fa10-4e39-4259-9a99-4c6085b5ec8c\f-HttpTrigger-FSharp__1101818315.dll

I'll try to have that addressed ASAP, also fixing the package assembly resolver to remove some of the actual duplications we see above. Moving forward, will also be logging that output in verbose mode to make things simpler.

dsyme commented 7 years ago

It does look like the fix needs to be in the general .NET/C# arena, since we're using the C# resolver here.

From a tactical perspective, you can just choose any (e.g. the last) of those mscorlib.dll references. Indeed in general the F# compiler should never be given two DLLs with the same simple names, though it will only complain about that for mscorlib and FSharp.Core.

I'm glad to see there are not "Reference Assemblies" in the path, though the resolutions from the GAC are a surprise

fabiocav commented 7 years ago

Agreed. The fix will primarily target the .NET package assembly resolver and metadata resolver, but I'll also make some enhancements to the F# compilation service, including the logging enhancements mentioned above. My goal is to have this (and #890) addressed on the next update, which should happen before the end of the month.

dsyme commented 7 years ago

@fabiocav Let us know if there's anything you need us to do here. I think we don't have any specific F#+AF work items at the moment // cc @sylvanc

fabiocav commented 7 years ago

I'm wrapping up some items to clear my plate and focus on the issues impacting F# next week. If I run into anything then, I'll definitely reach out.

I think we'll be in a good spot once those last few items are addressed.

fabiocav commented 7 years ago

The fix will be live on the next deployment.