Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Updated] .NET Framework app crashes at runtime when referencing a .NET Standard library #4263

Closed
cartermp opened this issue Jan 25, 2018 · 39 comments
Closed

[Updated] .NET Framework app crashes at runtime when referencing a .NET Standard library #4263

cartermp opened this issue Jan 25, 2018 · 39 comments
Labels
Area-Library Issues for FSharp.Core not covered elsewhere Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code.

Comments

@cartermp
Copy link
Contributor

cartermp commented Jan 25, 2018 •
edited

F# applications cannot run on 15.6 Preview 3:

image

To repro:
ConsoleApplication18.zip

Using the above project, ctrl-f5.

Old issue

System.IO.FileLoadException: Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed.

https://www.nuget.org/packages/FSharp.Core/

What's going on here?
@cartermp cartermp added Area-Infrastructure Impact-High (Internal MS Team use only) Describes an issue with extreme impact on existing code. Area-Library Issues for FSharp.Core not covered elsewhere labels Jan 25, 2018
@btrepp
Copy link

btrepp commented Jan 25, 2018 

System.IO.FileLoadException: Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)

@forki
Copy link
Contributor

forki commented Jan 25, 2018

yes same here. reverting paket upgrade.

@dsyme
Copy link
Contributor

dsyme commented Jan 25, 2018 •
edited

After being notified about this and after reviewing the above I decided to unlist the package https://www.nuget.org/packages/FSharp.Core/4.3.0.

"The package has been unlisted. It may take several hours for this change to propagate through our system."

@KevinRansom
Copy link
Member

Ouch!!!!

It turns out that we started creating the nuget packages before we sign the assemblies in them. @brettfo and I will see what we need to do to fix that.

This was missed because sn-Vr is still in widespread use, curses ... and ... dotnet cli doesn't really care about the signing hashes.

Sorry for the inconvenience, we will address it quickly.

Kevin

@forki
Copy link
Contributor

forki commented Jan 25, 2018 via email

@brettfo brettfo mentioned this issue Jan 25, 2018
Merged
@KevinRansom
Copy link
Member

KevinRansom commented Jan 25, 2018 •
edited

Okay ... pushed 4.3.1 to nuget with signed binaries.

@forki, The serialization issue was a compiler bug, that is now fixed and does not require a netstandard 2.0 build. The fix should be shipped in the next preview.

@forki
Copy link
Contributor

forki commented Jan 26, 2018 via email

@forki
Copy link
Contributor

forki commented Jan 26, 2018

Ok where is the difference between 4.3.1 package and 4.3.2 package?

@forki
Copy link
Contributor

forki commented Jan 26, 2018

This seems to be fixed. (At least our build is now green again) Thank you very much!

@cartermp
Copy link
Contributor Author

Closing as the immediate issue is fixed. Linking #4269 as the long-term solution

@cartermp
Copy link
Contributor Author

From Preview 3

image

@cartermp cartermp changed the title Strong name validation failed on FSharp.Core 4.3.0.0 Strong name validation failed on FSharp.Core 4.4.3.0 Jan 29, 2018
@cartermp cartermp reopened this Jan 29, 2018
@cartermp cartermp changed the title Strong name validation failed on FSharp.Core 4.4.3.0 [Updated] Strong name validation failure on FSharp.Core 4.4.3.0 results in .NET Framework/.NET Standard unable to run on 15.6 Preview 3 Jan 29, 2018
@forki
Copy link
Contributor

forki commented Jan 30, 2018

Yes I also saw issues when I pushed to azure functions. I suggest we unlist 4.3.x

@KevinRansom
Copy link
Member

@forki, What were the issues?

@forki
Copy link
Contributor

forki commented Jan 30, 2018 via email

@KevinRansom
Copy link
Member

KevinRansom commented Jan 30, 2018 via email •
edited

@forki
Copy link
Contributor

forki commented Jan 30, 2018 via email

@KevinRansom
Copy link
Member

Could you try again and capture the output.

@forki
Copy link
Contributor

forki commented Jan 30, 2018

no I'm rather not changing it before the big presentation next week. After that I can do it - but there were no interesting details shown.

@KevinRansom
Copy link
Member

sounds good.

@forki
Copy link
Contributor

forki commented Jan 31, 2018 

Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621). Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

@forki
Copy link
Contributor

forki commented Jan 31, 2018

even in the azure functions logs there is nothing more to see.

@KevinRansom
Copy link
Member

@cartermp, @forki.

Can someone give me straightforward repro steps to see this error. Or better yet an oss repro that demonstrates this error.

My intuition is that this is a publish error with the app having a dependence on the 4.4.1.0 dll, and a component dependent on the 4.4.3.0 dll. I think I will need to look at the moving parts to see how the error is introduced.

Kevin

@forki
Copy link
Contributor

forki commented Jan 31, 2018 via email

@cartermp
Copy link
Contributor Author

@KevinRansom Does the repro link at the top not do this for you? The repro steps are to run ctrl-f5 on that project with 15.6 Preview 3.

@cartermp
Copy link
Contributor Author

Argh, I'm stupid. I uploaded the wrong solution that repros this on my machine. I'll do that when I get home.

@KevinRansom
Copy link
Member

Thanks ... and probably not stupid, just a small error.

@cartermp
Copy link
Contributor Author

cartermp commented Feb 1, 2018

Updated here:
ConsoleApplication18.zip

@KevinRansom
Copy link
Member

Okay, I know what is going on here.

The solution was created with an earlier version of VS and so the console app targets FSharp.Core: 4.4.1.0

<snip>
    <TargetFSharpCoreVersion>4.4.1.0</TargetFSharpCoreVersion>
</snip>

The netsdk project targets the latest version of fsharp.core.dll, from FSharp.Core nuget package 4.3.

The AutoGenerate binding redirects, for the console application says .... Hmmm!!!! you picked FSharp.Core.dll, v 4.4.1.0 and yet your dependency needs 4.4.3.0, I'm going to pick 4.4.1.0 and warn you. Which it does:

2>C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2058,5): warning MSB3277: Found conflicts between different versions of "FSharp.Core" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.

The issue arises because legacy windows projects always picks a specific version of FSharp.Core and dotnet sdk, floats using nuget.

There are two choices to solve this:

  1. Edit desktop project to have the line:
<snip>
    <TargetFSharpCoreVersion>4.4.3.0</TargetFSharpCoreVersion>
</snip>

or edit the netsdk project to have the line:

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <FSharpCoreImplicitPackageVersion>4.2.*</FSharpCoreImplicitPackageVersion>
  </PropertyGroup>

I hope this helps:

@KevinRansom KevinRansom mentioned this issue Feb 1, 2018
Closed
@forki
Copy link
Contributor

forki commented Feb 2, 2018

I don't think it's what my issue is. Paket always pins versions - so nuget can't float.

@KevinRansom
Copy link
Member

If you have a repro that I could examine, or maybe zip up the deployed files, I can examine your failure.

@cartermp cartermp changed the title [Updated] Strong name validation failure on FSharp.Core 4.4.3.0 results in .NET Framework/.NET Standard unable to run on 15.6 Preview 3 [Updated] .NET Framework app crashes at runtime when referencing a .NET Standard library Feb 6, 2018
@forki
Copy link
Contributor

forki commented Feb 12, 2018

I wonder how to proceed. it only happens on azure functions for me.

@dsyme
Copy link
Contributor

dsyme commented Feb 12, 2018

@forki I think you might have to report a bug on Azure Functions

@forki
Copy link
Contributor

forki commented Feb 12, 2018 •
edited

Yeah. But all these reports were going to dev/null in the past. Sorry I have zero confidence in that process.

@cartermp
Copy link
Contributor Author

@forki this is the v2 runtime, yes?

@forki
Copy link
Contributor

forki commented Feb 12, 2018

Yes it's beta runtime.

@jakzale
Copy link

jakzale commented Mar 8, 2018

@forki If you try to load a dll that is already included in azure functions runtime, but at a different version, the runtime will prevent that dll from being loaded. (Which is a well known source of pain Azure/azure-functions-host#992)

Since the V2 runtime comes with FSharp.Core.dll version 4.4.1.0, it will prevent loading FSharp.Core.dll at version 4.4.3.0 and fail with such criptic message.

If you pin FSharp.Core to 4.1.18, then it should work.

@forki
Copy link
Contributor

forki commented Mar 9, 2018

I'm well aware of that issue, but I didn't assume they bundle a fsharp.core. That's weird. Also I'm currently using fsharp.core nuget package 4.2.3 which works. But upgrade does not.

@dsyme dsyme added Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. and removed Impact-High (Internal MS Team use only) Describes an issue with extreme impact on existing code. labels Apr 12, 2018
@dsyme
Copy link
Contributor

dsyme commented Apr 12, 2018

Closing as this is an Azure Functions issue and not the same (urgent) issue tracked originally. If there's a remaining F# issue here please open a new issue

@dsyme dsyme closed this as completed Apr 12, 2018
@cartermp
Copy link
Contributor Author

Actually the repro project in the OP is not Azure Functions, but I think we can consider this issue out of date now that we have shipped an updated FSharp.Core binary in VS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Library Issues for FSharp.Core not covered elsewhere Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@forki @btrepp @jakzale @KevinRansom @cartermp @dsyme