System.Numerics.Vectors fails to install in an F# project

[mellinoe]

Hi, I'm resubmitting this issue over here, because I believe it may be a NuGet-specific issue:

https://github.com/dotnet/corefx/issues/3103

It is a pretty standard package, but it fails to install properly in an F# project. The main problem is that a element isn't emitted into the reference in the project file. This is probably because System.Numerics.Vectors exists in the .NET 4.6 reference assembly pack, so perhaps for F# projects this HintPath is not added. However, in C# and VB projects, it is included. Is there something special that needs to be done when we author the package, or should this work as-is?

[yishaigalatzer]

Looks like the F# project system returns the path to the DLL unlike what C# does. So the hack in nuget working around the project system issues for C# is skipped.

See code - https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/PackageManagement.VisualStudio/ProjectSystems/VSMSBuildNuGetProjectSystem.cs#L356

And screenshot

[yishaigalatzer]

I'm assuming at this point that the fix will happen in the F# project system, alternatively if we can get a guaranteed longterm and backwards compatible reliable behavior from the F# project system we can introduce the fix here.

[forki]

Could you please consider to fix it in NuGet? The F# project system should really not be changed because of the package manager (only if there is no other way).

https://github.com/Microsoft/visualfsharp/issues/939 shows it's an issue that is coming back again.

[yishaigalatzer]

The problem is that the thing that is non standard here is the project system rather than nuget, which is why we are suggesting fixing it there rather than having an explicit condition in nuget to work around the f# difference.

I'm glad to continue the discussion of if you can come up with a good pull request.

Adding @pilchie for further discussion

[forki]

Looks like the F# project system returns the path to the DLL unlike what C# does. So the hack in nuget working around the project system issues for C# is skipped.

and then

The problem is that the thing that is non standard here is the project system ... we are suggesting fixing it there in [F#]

I give up ;-)

[yishaigalatzer]

Mmm :( you are right

[dsyme]

@yishaigalatzer Thanks for reopening

[isaacabraham]

So is the solution to fix the C# project system to do the right thing then? What about .vbproj?

[dsyme]

@isaacabraham Our understanding is that the F# project system is doing something different to C# and nuget has exposed this. @yishaigalatzer will add details about what they found on https://github.com/Microsoft/visualfsharp/issues/939 - the screenshot above shows some details but they are still fuzzy.

In this case I believe we would adjust the F# project system to do the same thing as C#, that's the healthy thing to do in the long run.

[isaacabraham]

The reason I mentioned that was based on Yishai's comment about a hack in Nuget to "work around" the C# project system. Or did I misread, and it's an issue with the project system across all three languages.

[forki]

@dsyme yes adjusting the F# project system to make it behave more like C# is a good idea. But from users perspective: fixing it first in nuget would help users to actually work with it as expected (also with older and unpatched project system). Nuget has much shorter release cycle, so users would benefit greatly from a workaround here.

(the fix in F# project system is still a good thing)

[dsyme]

Given there are workarounds I believe the fix will be on the F# side, rather than getting into a cat-and-mouse game of mutual fixes.

[yishaigalatzer]

@isaacabraham to explain my comment: NuGet added a hack to fix a c# project system bug, f# has the same bug and also a slightly different behavior.

My recollection about the c# project system is tha the owners of the c# project system have a much higher spread and hence a much higher potential impact of things breaking down if it got fixed. Since it will probably go to CPS at some point, that would be the time to make such fixes happen.

At the end of the day this is still a very narrow case of

1. Using the new .net core packages
2. Using the .net core packages without project.json, where nuget still updates the project file.

One more point, nuget is revving at about the same speed as vs updates at the moment, due to the pretty large workloads coming from the new platforms development, and it mostly revs in the 3.0 (nuget.client) repo. We hardly port fixes to nuget2, and definitely not bugs at this level (at least at the moment).

[isaacabraham]

@yishaigalatzer thanks for the explanation. What do you mean by "spread" through? You mean the team is spread out or that there are lots more users of csproj?

P.S. What is CPS?

[yishaigalatzer]

What do you mean by "spread" through?

Yes, much more users and scenarios (and types of users), and hence much more concern.

CPS

Common project system

[yishaigalatzer]

Moved to discussion milestone, until we (fully) decide where the fix should go.

[jackmott]

At the end of the day this is still a very narrow case of Using the new .net core packages

This problem occurs when not doing anything related to .net core. You can't use SIMD in FSharp at all without manually hacking your fsproj file.

[dsyme]

@yishaigalatzer @jackmott What was the decision about this?

[idg10]

What are the workarounds? I see claims that they exist, but the only suggestion is to manually add the HintPath yourself. That doesn't work for me. Something removes it every time I rebuild the project.

As far as I can tell, this issue makes it impossible to use ASP.NET Core 1.1 components in an fsproj project. (I have an Azure Web Job implemented as an F# console app that needs to use full .NET Framework 4.6, and which also need to use ASP.NET Core 1.1. components because I've got some shared components between a web app and the web job, meaning that there are common dependencies.) Maybe VS2017 will solve all my problems, but that's not due for another 3 weeks and meanwhile I have a looming deadline.

[jackmott]

Only workaround I know about is to use Paket instead of Nuget, it handles this properly.

[emgarten]

This should work using PackageReferences instead of packages.config, both in traditional fsproj and NETCore SDK projects.