Skip to content

Conversation

@brettfo
Copy link
Member

@brettfo brettfo commented Feb 6, 2018

Eventually we'll properly use Directory.Build.props and Directory.Build.targets, but for the time being I don't want the non-SDK projects contaminated, so I opted to name everything FSharp.Directory.Build.props/.targets and opt-in each project by adding it's own Directory.Build.props/.targets next to the converted project files that redirects to the FSharp. ones.

To properly handle restoring <PackageReference /> items, NuGet.config had to be moved to the root of the repo so that it's always up-path from every project file.

Also, to enable overriding the F# SDK targets, the -proto suffix had to be removed. The proto compiler is still built into it's own directory, though, so there won't be any conflicts.

All projects under the vsintegration/ directory have been converted to the new SDK except the property pages because that was giving me no end of grief and ultimately the projects are being converted to enable daily testing of the new project system work and the property pages project is VB anyways.

@dsyme
Copy link
Contributor

dsyme commented Feb 9, 2018

This is looking great - it will be such a relief to have this done

@cartermp cartermp changed the title [WIP] Convert vsintegration projects to SDK [WIP] Convert vsintegration projects to .NET Core SDK SDK Feb 18, 2018
@cartermp cartermp changed the title [WIP] Convert vsintegration projects to .NET Core SDK SDK [WIP] Convert vsintegration projects to .NET Core SD Feb 18, 2018
@cartermp cartermp changed the title [WIP] Convert vsintegration projects to .NET Core SD [WIP] Convert vsintegration projects to .NET Core SDK Feb 18, 2018
@brettfo brettfo changed the title [WIP] Convert vsintegration projects to .NET Core SDK Convert vsintegration projects to .NET Core SDK Feb 23, 2018
@dsyme
Copy link
Contributor

dsyme commented Feb 23, 2018

@dotnet-bot test Ubuntu16.04 Release_default Build please

@brettfo brettfo merged commit a44472c into dotnet:master Feb 23, 2018
@brettfo brettfo deleted the sdk-proj branch February 23, 2018 06:05
@cartermp
Copy link
Contributor

@dsyme
Copy link
Contributor

dsyme commented Feb 23, 2018

image

@brettfo
Copy link
Member Author

brettfo commented Mar 28, 2018

@smoothdeveloper What version of Visual Studio and MSBuild do you have installed? As for the 14.0 and 15.0 versions of the Microsoft.VisualStudio.Shell package, both are needed, but duplicate type information should be handled by the PrivateAssets="all" on the first package reference and the aliasing of the 14.0 assembly here.

Also, have you cleaned the repo? There might be some stuff left over in the obj/ directory.

@smoothdeveloper
Copy link
Contributor

smoothdeveloper commented Mar 28, 2018

@brettfo thanks for the explanations.

I'm using

C:\dev\projects\github.com\microsoft\visualfsharp2>msbuild /version
Microsoft (R) Build Engine version 15.6.82.30579 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.6.82.30579

(edit: VS2017 Community 15.6.4)

I tried from a clean clone and still having the errors: buildlog.txt

@brettfo
Copy link
Member Author

brettfo commented Mar 29, 2018

tl;dr - The evaluation order of targets appears to have changed. I'm looking into it now.

@smoothdeveloper Now I'm seeing the same thing on my box. Doing a quick look it appears that the ResolveReferences target is being invoked by CoreBuild, but that's happening after the Compile target which is what actually invokes csc. In short, Compile is happening before ResolveReferences which seems wrong to me.

Edit: I've created PR #4646 which gets me building on my local box again. We'll see if it passes CI.
Edit 2: CI has passed and I've merged the PR. master should be buildable again on the latest version of VS/MSBuild.

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.

4 participants