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.

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

Fixes #3012 #3013

Merged
merged 3 commits into from
May 8, 2018
Merged

Fixes #3012 #3013

merged 3 commits into from
May 8, 2018

Conversation

msatina
Copy link

@msatina msatina commented Jan 25, 2018

fix #3012

Get TargetFramework(s) from runtime as a fallback in case they are not defined in csproj file.

…t defined in csproj file

Get TargetFramework(s) from runtime as a fallback in case they are not defined in csproj file directory.build.props .
Copy link
Collaborator

@enricosada enricosada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems ok (i need to test it locally later)

@msatina awesome work, can you add an integration test?

like

[<Test>]
let ``#3000-a dotnet restore``() =
let scenario = "i003000-netcoreapp2"
let projectName = "c1"
let packageName = "AutoMapper"
let workingDir = scenarioTempPath scenario
let projectDir = workingDir @@ projectName
[ packageName; (packageName.ToLower()) ] |> Seq.iter clearPackage
prepareSdk scenario
directDotnet false "restore" projectDir |> ignore
directDotnet false "build --no-restore" projectDir |> ignore
for no TargetFramework in csproj, but in Directory.Build.props

@enricosada
Copy link
Collaborator

as a note, VS need to fix this scenario probably #2863 (comment)

<!-- Do a global restore if required -->
<Exec Command='$(PaketBootStrapperCommand)' Condition="Exists('$(PaketBootStrapperExePath)') AND !(Exists('$(PaketExePath)'))" ContinueOnError="false" />
<Exec Command='$(PaketCommand) restore' Condition=" '$(PaketRestoreRequired)' == 'true' " ContinueOnError="false" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that calling paket restore is by design here. We tweaked paket restore for maximum performance (including skipped command line parsing). With this change restore will most likely be a lot slower if stuff was already restored.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm trying to say is that we either need a different solution / carefully tweak performance for this case or some other trick

@forki
Copy link
Member

forki commented Jan 31, 2018

ping

@forki
Copy link
Member

forki commented Feb 5, 2018

@matthid @enricosada better?

@forki
Copy link
Member

forki commented May 2, 2018

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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