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.

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

Paket fails on projects that target multiple frameworks #2496

Closed
teo-tsirpanis opened this Issue Jul 8, 2017 · 21 comments

Comments

Projects
None yet
5 participants
@teo-tsirpanis

teo-tsirpanis commented Jul 8, 2017

Description

I made a very simple project that only depends on one package. It targets both .NET Standard 1.6 and .NET Framework 4.6.2. Running paket install and paket restore gives no errors. But when it run dotnet restore, Paket says this:

C:\code\paket_bug\.paket\Paket.Restore.targets(22,5): error MSB3073: The command ""C:\code\paket_bug\.paket\paket.exe" restore --project "C:\code\paket_bug\Hello.fsproj" --target-framework " exited with code 1. [C:\code\paket_bug\Hello.fsproj]

The target framework is empty!

Repro steps

hellp.fsproj

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net462;netstandard1.6</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="Library.fs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
  </ItemGroup>
  <Import Project=".paket\Paket.Restore.targets" />
</Project>

paket.dependencies

framework: net462, netstandard1.6

source https://api.nuget.org/v3/index.json

nuget Chessie

paket.references
Chessie

Possible cause

In the project file, there is a TargetFrameworks section, not the TargetFramework that paket.restore.targets asks for. paket.restore.targets should handle it somehow. On projects that target one framework and have the TargetFramework property, Paket works like a charm.

Version information

paket --version: Paket version 5.5.3
dotnet --version: 2.0.0-preview2-006497

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 8, 2017

Member

This sounds like an issue with dotnet cli itself. Why is it not providing the target framework information?

Member

forki commented Jul 8, 2017

This sounds like an issue with dotnet cli itself. Why is it not providing the target framework information?

@teo-tsirpanis

This comment has been minimized.

Show comment
Hide comment
@teo-tsirpanis

teo-tsirpanis Jul 8, 2017

Which of them? .NET Standard 1.6 or .NET Framework 4.6.2? I will test it with the stable CLI.

teo-tsirpanis commented Jul 8, 2017

Which of them? .NET Standard 1.6 or .NET Framework 4.6.2? I will test it with the stable CLI.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 8, 2017

Member

We I tested multi target it actually called paket restore two times. One with every framework

Member

forki commented Jul 8, 2017

We I tested multi target it actually called paket restore two times. One with every framework

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 8, 2017

Member

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

Member

matthid commented Jul 8, 2017

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid
Member

matthid commented Jul 8, 2017

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Jul 8, 2017

Member

Or a breaking change in 2.0.0-preview2-006497?

Member

matthid commented Jul 8, 2017

Or a breaking change in 2.0.0-preview2-006497?

@teo-tsirpanis

This comment has been minimized.

Show comment
Hide comment
@teo-tsirpanis

teo-tsirpanis Jul 8, 2017

Or a breaking change in 2.0.0-preview2-006497?

I guess so. But I uninstalled the preview CLI and the same error appeared. I also tried to "bisect" the bug by trying with Paket 5.0.0, but it happened again. I guess it's something else in my machine that changed. In the past I could make cross-framework packages with Paket and without problem.

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

I will try to see if it does anything. Currently, my project only targets .NET 4.6.2. 😢

teo-tsirpanis commented Jul 8, 2017

Or a breaking change in 2.0.0-preview2-006497?

I guess so. But I uninstalled the preview CLI and the same error appeared. I also tried to "bisect" the bug by trying with Paket 5.0.0, but it happened again. I guess it's something else in my machine that changed. In the past I could make cross-framework packages with Paket and without problem.

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

I will try to see if it does anything. Currently, my project only targets .NET 4.6.2. 😢

@teo-tsirpanis

This comment has been minimized.

Show comment
Hide comment
@teo-tsirpanis

teo-tsirpanis Jul 8, 2017

I will try to see if it does anything. Currently, my project only targets .NET 4.6.2. 😢

No luck. 🙁

teo-tsirpanis commented Jul 8, 2017

I will try to see if it does anything. Currently, my project only targets .NET 4.6.2. 😢

No luck. 🙁

@Mpdreamz

This comment has been minimized.

Show comment
Hide comment
@Mpdreamz

Mpdreamz Jul 14, 2017

Contributor

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

Can confirm that the plural works $(TargetFrameworks). I was hit by this error too:

error : argument '--target-framework' must be followed by <framework>.

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1
Contributor

Mpdreamz commented Jul 14, 2017

We should probably use the TargetFrameworks variable. the TargetFramework variable only is syntactic sugar afaik.

Can confirm that the plural works $(TargetFrameworks). I was hit by this error too:

error : argument '--target-framework' must be followed by <framework>.

.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 14, 2017

Member

@Mpdreamz can you please upload a zip with a repro

Member

forki commented Jul 14, 2017

@Mpdreamz can you please upload a zip with a repro

@Mpdreamz

This comment has been minimized.

Show comment
Hide comment
@Mpdreamz

Mpdreamz Jul 14, 2017

Contributor

Working on a PR with integration test 😄 hopefully I get somewhere otherwise will upload a repro

Contributor

Mpdreamz commented Jul 14, 2017

Working on a PR with integration test 😄 hopefully I get somewhere otherwise will upload a repro

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 14, 2017

Member

even better ;-)

Member

forki commented Jul 14, 2017

even better ;-)

@teo-tsirpanis

This comment has been minimized.

Show comment
Hide comment
@teo-tsirpanis

teo-tsirpanis Jul 17, 2017

The bug seems fixed with Paket 5.7.0.
However, why is Paket run three times while dotnet restoreing a project that targets two frameworks?

teo-tsirpanis commented Jul 17, 2017

The bug seems fixed with Paket 5.7.0.
However, why is Paket run three times while dotnet restoreing a project that targets two frameworks?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 17, 2017

Member

I think one is for discovering the cli tools

Member

forki commented Jul 17, 2017

I think one is for discovering the cli tools

@seanamosw

This comment has been minimized.

Show comment
Hide comment
@seanamosw

seanamosw Jul 18, 2017

Contributor

With the latest Paket.Restore.targets I still wasn't able to get this to work.

eg.

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net461</TargetFrameworks>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>
  ...
C:\myproject\.paket\Paket.Restore.targets(23,5): error MSB3073: The command ""C:\myproject\.paket\paket.exe" restore --project "C:\myproject\myproject.fsproj" --target-framework """ exited with code 1. [C:\myproject\myproject.fsproj]

However, this works:

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net461</TargetFrameworks>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>
  <ItemGroup>
    <TargetFrameworks Include="netstandard1.6" />
    <TargetFrameworks Include="net461" />
  </ItemGroup>
  ...

This makes sense to me, given the usage of the @ in Paket.Restore.targets. As far as I knew @ only worked with ItemGroups. Unless there is "magic" where the dotnet cli/msbuild is supposed to convert the TargetFrameworks property into items?

Contributor

seanamosw commented Jul 18, 2017

With the latest Paket.Restore.targets I still wasn't able to get this to work.

eg.

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net461</TargetFrameworks>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>
  ...
C:\myproject\.paket\Paket.Restore.targets(23,5): error MSB3073: The command ""C:\myproject\.paket\paket.exe" restore --project "C:\myproject\myproject.fsproj" --target-framework """ exited with code 1. [C:\myproject\myproject.fsproj]

However, this works:

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;net461</TargetFrameworks>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>
  <ItemGroup>
    <TargetFrameworks Include="netstandard1.6" />
    <TargetFrameworks Include="net461" />
  </ItemGroup>
  ...

This makes sense to me, given the usage of the @ in Paket.Restore.targets. As far as I knew @ only worked with ItemGroups. Unless there is "magic" where the dotnet cli/msbuild is supposed to convert the TargetFrameworks property into items?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 18, 2017

Member

@seanamosw oh. can you please suggest a PR with a fix to the targets file so that thefirst thing works?

Member

forki commented Jul 18, 2017

@seanamosw oh. can you please suggest a PR with a fix to the targets file so that thefirst thing works?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 18, 2017

Member

@Mpdreamz do you see the issue?

Member

forki commented Jul 18, 2017

@Mpdreamz do you see the issue?

@Mpdreamz

This comment has been minimized.

Show comment
Hide comment
@Mpdreamz

Mpdreamz Jul 18, 2017

Contributor

I have not yet tested the new release or the updates but my original commit splitted the tfm

Mpdreamz@513491b

Which then allows @ to itterate each item.

Now we pass the string verbatim and let paket expand it internally (👍) it should be $(TargetFrameworks) here https://github.com/fsprojects/Paket/blob/master/.paket/Paket.Restore.targets#L23

Contributor

Mpdreamz commented Jul 18, 2017

I have not yet tested the new release or the updates but my original commit splitted the tfm

Mpdreamz@513491b

Which then allows @ to itterate each item.

Now we pass the string verbatim and let paket expand it internally (👍) it should be $(TargetFrameworks) here https://github.com/fsprojects/Paket/blob/master/.paket/Paket.Restore.targets#L23

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 18, 2017

Member

ok changing it right now!

Member

forki commented Jul 18, 2017

ok changing it right now!

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 18, 2017

Member

fixed. @seanamosw can you please try it?

Member

forki commented Jul 18, 2017

fixed. @seanamosw can you please try it?

@forki forki closed this Jul 18, 2017

@seanamosw

This comment has been minimized.

Show comment
Hide comment
@seanamosw

seanamosw Jul 18, 2017

Contributor

Can confirm the change to $(TargetFrameworks) works. I had been using this exact change as temporary workaround locally.

Contributor

seanamosw commented Jul 18, 2017

Can confirm the change to $(TargetFrameworks) works. I had been using this exact change as temporary workaround locally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment