Skip to content

convert FCS MSBuild references to a NuGet package#6439

Merged
KevinRansom merged 1 commit intodotnet:masterfrom
brettfo:fcs-msbuild-nuget
Apr 8, 2019
Merged

convert FCS MSBuild references to a NuGet package#6439
KevinRansom merged 1 commit intodotnet:masterfrom
brettfo:fcs-msbuild-nuget

Conversation

@brettfo
Copy link
Copy Markdown
Member

@brettfo brettfo commented Apr 5, 2019

An internal audit found some binaries that shouldn't be in this repo that need to be retrieved externally. One probable group are the MSBuild 12 binaries used under fcs/.

PR marked as draft until we get the final word on if the Microsoft.Build.*.dll binaries need to be removed.

Other PRs to follow for other offending binaries.

@brettfo brettfo requested review from KevinRansom and dsyme April 5, 2019 22:12
@brettfo brettfo marked this pull request as ready for review April 6, 2019 19:39
Copy link
Copy Markdown
Contributor

@KevinRansom KevinRansom left a comment

Choose a reason for hiding this comment

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

Sweet, It's good to remove these binaries from our repo.

@KevinRansom KevinRansom merged commit e2ce51e into dotnet:master Apr 8, 2019
@dsyme
Copy link
Copy Markdown
Contributor

dsyme commented Apr 8, 2019

@baronfel Note this one

Also I'm pretty sure this whole v12 DLL can be well and truly nuked from FCS.

@brettfo brettfo deleted the fcs-msbuild-nuget branch April 8, 2019 17:01
@baronfel
Copy link
Copy Markdown
Member

baronfel commented Apr 9, 2019

@dsyme do you mean during the integration that we move this reference to paket dependencies? Or that we can remove the creation of the FSharp.Compiler.Service.MSBuild.v12 component entirely?

@dsyme
Copy link
Copy Markdown
Contributor

dsyme commented Apr 9, 2019

@dsyme do you mean during the integration that we move this reference to paket dependencies? Or that we can remove the creation of the FSharp.Compiler.Service.MSBuild.v12 component entirely?

Ideally we should remove this DLL entirely. Also the ProjectCracker DLL, which deals with legacy project formats.

I need to understand of Ionide depends on this in any way

@cartermp
Copy link
Copy Markdown
Contributor

cartermp commented Apr 9, 2019

Ionide does depend on it for non-SDK style projects

@dsyme
Copy link
Copy Markdown
Contributor

dsyme commented Apr 9, 2019

Ionide does depend on it for non-SDK style projects

DO you know if it depends on FSharp.Compiler.Service.MSBuild.v12? There is the "SimulatedMSBuildReferenceResolver" which is normally an adequate replacement

cc @Krzysztof-Cieslak

@auduchinok
Copy link
Copy Markdown
Member

It would be great to have the same code used in assembly resolution for scripts in VS and other tools. If we're to use the simulated resolve everywhere it'd be great to update the VS integration too.

@Krzysztof-Cieslak
Copy link
Copy Markdown
Contributor

FSharp.Compiler.Service.MSBuild.v12

As far as I remember FCS ProjectCracker depends on it for cracking any projects with ToolsVersion < 14.0. The good news is:

  1. It may not be needed in practice because it’s basical about projects created in VS 2012 that weren’t updated at all since then
  2. @enricosada project cracker handles also old-style projects and we will move to it for all cases ( we already are using it - there is just one combination where Cracker is used - FSAC Net runtime and old-style project) dropping Cracker dependency completely

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.

7 participants