Closed gshackles closed 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!
@fabiocav As soon I have time I will get back to you.
@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.
@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.
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).
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.
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
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.
@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
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.
The fix will be live on the next deployment.
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:
Here's a
project.json
that reproduces the issue: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
Create a new F# function
Add the
project.json
file above💥
Expected behavior
The function should compile
Actual behavior
The function fails to compile