Paket restore silently fails when TargetFramework(s) are specified in Directory.Build.props and not csproj

[msatina]

Description

When TargetFramework(s) are defined in Directory.Build.props Paket restore silently fails, it should be able to get it from msbuild at runtime.

Repro steps

Have Directory.Build.props in solution root folder e.g.:

<Project>
 <Import Project=".\Versions.props"/>
  <PropertyGroup>
      <FullFrameworkVersion>net462</FullFrameworkVersion>
   </PropertyGroup>
</Project>

and then use the property to define TargetFramework in underlying project files, e.g.:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
   <TargetFramework>$(FullFrameworkVersion)</TargetFramework>
    <AssemblyName>SomeAssembly</AssemblyName>
...
  </PropertyGroup>
  <Import Project="..\..\.paket\Paket.Restore.targets" />
</Project>

Expected behavior

Paket restore shouldn't silently fail. Ideally it should be able to get Framework information from msbuild from runtime.

Actual behavior

Paket restore is not able to get TargetFramework(s) information from project file and silently fails.

Known workarounds

Don't define TargetFramework in Directory.Build.props .

3013

[msatina]

Repository with sample project demonstrating the issue is here - https://github.com/msatina/Paket-i003012 .

[vbfox]

Had the same type of problem today with this code

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;netstandard2.0</TargetFrameworks>
    <TargetFrameworks Condition="'$(OS)' == 'Windows_NT'">net45;netstandard1.6;netstandard2.0</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Test.fs" />
    <None Include="paket.references" />
  </ItemGroup>
  <Import Project=".paket\Paket.Restore.targets" />
</Project>

Sample repro: https://github.com/vbfox/paket_issue_3012

[matthid]

I briefly looked at it. The problem is that when we do the "lazy" generation of the *.paket.resolved files (because we detect one is missing) we fail to forward the framework to the paket call. So we call
"E:\Projects\paket.test\paket_issue_3012\.paket\..\paket.exe" restore --project "E:\Projects\paket.test\paket_issue_3012\Test.fsproj" But we probably need to add the framework here in order to detect such scenarios.

[vbfox]

Copy pasting from slack, after discussing why generating dozen of .paket.resolved could be annoying if there was no detection (and that all supported framework were generated):

A single XML file could be generated and read like this :

<paket>
    <dep fw=";netstandard1.6;netstandard2.0;">Microsoft.NETCore.Platforms,2.0.1,Transitive,Main,false</dep>
    <dep fw=";netstandard1.6;netstandard2.0;">Microsoft.NETCore.Targets,2.0,Transitive,Main,false</dep>
</paket>

    <Target Name="Xml">
        <XmlPeek
            XmlInputPath="Test.xml" Query="/paket/dep[contains(@fw,'netstandard2.0')]/text()">
            <Output
                TaskParameter="Result"
                ItemName="ItemsFromFile"/>
        </XmlPeek>
        <Message Text="Hello @(ItemsFromFile)" Importance="high"/>
    </Target>

(Instead of the current ReadLinesFromFile)

[matthid]

Actually I like the one from Slack more:

<paket>
    <framework name="netstandard2.0">
        <dep>Microsoft.NETCore.Platforms,2.0.1,Transitive,Main,false</dep>
        <dep>Microsoft.NETCore.Targets,2.0,Transitive,Main,false</dep>
    </framework>
</paket>

    <Target Name="Xml">
        <XmlPeek
            XmlInputPath="Test.xml" Query="/paket/framework[@name='netstandard2.0']/dep/text()">
            <Output
                TaskParameter="Result"
                ItemName="ItemsFromFile"/>
        </XmlPeek>
        <Message Text="Hello @(ItemsFromFile)" Importance="high"/>
    </Target>

;)

[vbfox]

I experimented with trying to reduce the size of the generated XML :)

[matthid]

Well maybe if it turns out to be easy to implement ;)

[matthid]

Looking at the corresponding code places I noticed that we have to ask @alfonsogarciacaro because fable depends on those files as well :)

@alfonsogarciacaro Is it a problem for fable to read the above XML schema instead of the raw text files we have right now?

Obviously not not break stuff we will generate both (or now 3 types of files actually) for quite a while :/

[alfonsogarciacaro]

If there's a reliable schema it shouldn't be a problem to check XML instead of plain text. Though I guess this will change again at some point so maybe it's better to find a way to communicate with Paket and ask for the dependency order... which may be problematic now Paket is distributed in different ways. Though the alternative (adding a Paket.Core dependency to Fable) isn't ideal either as the referenced Paket.Core version and the one used by paket.exe may differ.

...but all the problems would be magically solved if @enricosada could find a way so Dotnet.ProjInfo returns the .dll references in dependency order :wink:

[matthid]

better to find a way to communicate with Paket and ask for the dependency order

I guess every communication we choose will change somehow someway ;).
Also we can leave the existing files in it's current form there forever.

[forki]

There is only one file that fable reads. Just keep that one stable.

Am 13.02.2018 19:47 schrieb "Matthias Dittrich" [e-mail]:

better to find a way to communicate with Paket and ask for the dependency
order

I guess every communication we choose will change somehow someway ;).
Also we can leave the existing files in it's current form there forever.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3012#issuecomment-365364535,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNKp1MyfaP-GguOiYzidLzr_s2jP6ks5tUdingaJpZM4Rspl3
.

[matthid]

so we keep obj/<project>.references

[alfonsogarciacaro]

That'd be perfect, but if you do need to discriminate references by target framework, that shouldn't be a problem as we do have that info (I haven't been following the discussion so not sure if this is an issue).

Another question: is the algorithm to resolve the dependency order portable? Would it be possible to extract it to a library and use it from Fable?

[matthid]

@alfonsogarciacaro The algorithm is surprisingly simple. Problem is only getting the info of which package depends on which one. So you have that?

[matthid]

@alfonsogarciacaro
https://github.com/fsprojects/Paket/blob/7346d01d237ebe489a61bb699deb07ee8be8357b/src/Paket.Core/PaketConfigFiles/DependencyCache.fs#L34-L92

This basically is the implementation to get an order, implemented on package and on dll level. Basically all you need to have is a function getting dependencies. Here we use Mono.Cecil on dll-level and our own infos for package level

[forki]

The problem is for fable to get the dependency order of the referenced
packages. I don't know how you would do that by just asking the proj file

Am 13.02.2018 23:22 schrieb "Matthias Dittrich" [e-mail]:

@alfonsogarciacaro https://github.com/alfonsogarciacaro
https://github.com/fsprojects/Paket/blob/7346d01d237ebe489a61bb699deb07
ee8be8357b/src/Paket.Core/PaketConfigFiles/DependencyCache.fs#L34-L92

This basically is the implementation to get an order, implemented on
package and on dll level. Basically all you need to have is a function
getting dependencies. Here we use Mono.Cecil on dll-level and our own infos
for package level

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3012#issuecomment-365425399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNJQRKBSND4QeHtziw6wsu5I_ylt-ks5tUgsRgaJpZM4Rspl3
.

[alfonsogarciacaro]

Fable uses Enrico's dotnet-proj-info so we get all the arguments to be passed to the F# compiler including .dll references from an .fsproj (and we assume the nuget package is just two folders up, that's how we locate fable source files). Would that be enough to get the dependency order? Can @vbfox AssemblyReader be used for that (so we don't need the full Mono.Cecil dependency)?

[forki]

I don't think that's enough to do it easily.

[matthid]

@alfonsogarciacaro What is @vbfox AssemblyReader?

[vbfox]

@matthid A small experiment I did a few days ago to replace Assembly.Load usage in Paket bootstrapper to read the assembly informational version with something that doesn't really load the full assembly in memory. I took the parts of Cecil that load the assembly tables & use the minimum of it to read the single value that interest me : https://github.com/vbfox/AssemblyVersionReader/blob/master/ConsoleApp1/AssemblyVersionReader.cs#L535 . In the end while it's a LOT faster than Assembly.Load it's not good enough due to JIT: On first cold run it's approximately as fast as Assembly.Load and the bootstraper only need to read the value once :(

@alfonsogarciacaro My code doesn't read the AssemblyRef table because I didn't need it but it wouldn't be very hard to change that, just a differnt table to read. No idea if you would get what you want, what you get is :

The AssemblyRef table has the following columns:

• MajorVersion, MinorVersion, BuildNumber, RevisionNumber (each being 2-byte
  constants)
• Flags (a 4-byte bitmask of type AssemblyFlags, §II.23.1.2)
• PublicKeyOrToken (an index into the Blob heap, indicating the public key or token
  that identifies the author of this Assembly)
• Name (an index into the String heap)
• Culture (an index into the String heap)
• HashValue (an index into the Blob heap)

(And the same kind of values for the Assembly itself)

BTW what you would generate here is the assembly dependency graph, not the nuget dependency one that you get from paket (Don't know witch one you need)

[matthid]

As @alfonsogarciacaro only need to order a list of .dlls I actually think AssemblyRef would be enough

[alfonsogarciacaro]

I've been thinking about this over the weekend, and maybe I can just get the dependencies from the .nuspec file and then resolve the dependency order. Actually I'm already doing that for project references (which are not necessarily in order in the .fsproj).

[forki]

That's even more tricky since you need to understand all the frameworks and
how they play together - you will probably end up with reimplementing a lot
of paket code

Am 19.02.2018 01:38 schrieb "Alfonso Garcia-Caro" <[email protected]

:

I've been thinking about this over the weekend, and maybe I can just get
the dependencies from the .nuspec file and then resolve the dependency
order. Actually I'm already doing that for project references (which are
not necessarily in order in the .fsproj).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/3012#issuecomment-366563579,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNN-V-PXcTk5dzdw3diGGl95BeFqpks5tWMJ1gaJpZM4Rspl3
.