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

Support modern MSBuild 15 like fsproj #2316

Closed
forki opened this Issue Jan 24, 2017 · 46 comments

Comments

Projects
None yet
@forki
Contributor

forki commented Jan 24, 2017

I have a project with MSBuild 15 see
https://github.com/fable-compiler/fable-suave-scaffold/blob/master/src/Server/Server.fsproj and works perfectly in ionide. Visual Studio 2017 RC says it is not supported.

@cartermp @KevinRansom @enricosada what's the plan for this?

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Jan 24, 2017

Contributor

@forki -- the dotnet sdk team are creating templates for F# VS and coreclr.

Contributor

KevinRansom commented Jan 24, 2017

@forki -- the dotnet sdk team are creating templates for F# VS and coreclr.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 24, 2017

Contributor
Contributor

forki commented Jan 24, 2017

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 24, 2017

Contributor

FTR: my sample project has absolutely valid fsproj according to dotnetcore and MSBuild. It works absolutely nice with paket integration and ionide understands everything correctly.
TBH we currently push a similar thing to azure about 5 to 10 times a day.

Contributor

forki commented Jan 24, 2017

FTR: my sample project has absolutely valid fsproj according to dotnetcore and MSBuild. It works absolutely nice with paket integration and ionide understands everything correctly.
TBH we currently push a similar thing to azure about 5 to 10 times a day.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Jan 24, 2017

Contributor

Sounds great ... looks like it's using the new dotnet SDK ... perhaps you can chat with them about what is missing ...

@enricosada might also be able to point you in the right direction.

Contributor

KevinRansom commented Jan 24, 2017

Sounds great ... looks like it's using the new dotnet SDK ... perhaps you can chat with them about what is missing ...

@enricosada might also be able to point you in the right direction.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 24, 2017

Contributor

who is them?

Contributor

forki commented Jan 24, 2017

who is them?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jan 24, 2017

Collaborator

@KevinRansom just to clarify the scenario:

  1. I create an MSBuild15-based F# project with the .NET CLI.
  2. I attempt to open this project in Visual Studio
  3. It fails, because we do not recognize MSBuild15 fsprojs

I'm not sure this is a CLI or SDK concern; I think this is squarely our problem to solve. As it stands, there is no way to open an F# project using the MSBuild15 fsproj in VS 2017. This is a bad situation because it means that you're locked out of anything .NET Core or .NET Standard for F# in VS 2017. This is what I get on the build with Brett's insertion:

msbuild15

Collaborator

cartermp commented Jan 24, 2017

@KevinRansom just to clarify the scenario:

  1. I create an MSBuild15-based F# project with the .NET CLI.
  2. I attempt to open this project in Visual Studio
  3. It fails, because we do not recognize MSBuild15 fsprojs

I'm not sure this is a CLI or SDK concern; I think this is squarely our problem to solve. As it stands, there is no way to open an F# project using the MSBuild15 fsproj in VS 2017. This is a bad situation because it means that you're locked out of anything .NET Core or .NET Standard for F# in VS 2017. This is what I get on the build with Brett's insertion:

msbuild15

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 24, 2017

Contributor

Thanks @cartermp - started to completely question myself.

Contributor

forki commented Jan 24, 2017

Thanks @cartermp - started to completely question myself.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 24, 2017

Contributor

I think the generated fsproj is fine dotnetcli is doing the right thing thanks to @enricosada. It's "just" VS is rejecting it. So it's definitely a VF# concern.

Contributor

forki commented Jan 24, 2017

I think the generated fsproj is fine dotnetcli is doing the right thing thanks to @enricosada. It's "just" VS is rejecting it. So it's definitely a VF# concern.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Jan 24, 2017

Contributor

@cartermp @forki,

Visual Studio is apparently not yet shipping with an SDK that installs enrico's sdk additions. I am looking at a build from the latest rtm branch.

I will follow up with the DOTNET SDK team directly, or someone can follow up with them on the dotnet cli repo. Piotr is in a one on one and then shiproom right now otherwise I would have a definitive answer.

Kevin

Contributor

KevinRansom commented Jan 24, 2017

@cartermp @forki,

Visual Studio is apparently not yet shipping with an SDK that installs enrico's sdk additions. I am looking at a build from the latest rtm branch.

I will follow up with the DOTNET SDK team directly, or someone can follow up with them on the dotnet cli repo. Piotr is in a one on one and then shiproom right now otherwise I would have a definitive answer.

Kevin

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jan 24, 2017

Contributor

@KevinRansom preview4 already works, What's needed always ship with sdk, after preview3 are just enhancement and cleanups. Also preview3 was working.
See my PR #2250 there there is also an example https://github.com/enricosada/visualfsharp/blob/use_net_core_sdk/examples/dotnetcoresdk/simple/console/ConsoleApp.fsproj who use FscTask too instead of dotnet-compile-fsc

AFAIK vs should

  • use Roslyn-project-system so we get all vs ui stuff (treeview etc)
  • I think we should add an FSharp capability (I can add that in the sdk target files, so is added for every fsproj, like the other props), that add the and initialize the languageservice parsing the compiler args from fsproj (similar on how now works) so intellisense works.

How vscode works now? How can have intellisense? On build a compile-fsc.rsp is generated who is the response file use for fsc, and ionide read that to initialize the FCS.
Now we can use FscTask (my pr) so compiler args gathering should change a bit (no response file).

If you want to try latest version with preview4, see my pr.

Contributor

enricosada commented Jan 24, 2017

@KevinRansom preview4 already works, What's needed always ship with sdk, after preview3 are just enhancement and cleanups. Also preview3 was working.
See my PR #2250 there there is also an example https://github.com/enricosada/visualfsharp/blob/use_net_core_sdk/examples/dotnetcoresdk/simple/console/ConsoleApp.fsproj who use FscTask too instead of dotnet-compile-fsc

AFAIK vs should

  • use Roslyn-project-system so we get all vs ui stuff (treeview etc)
  • I think we should add an FSharp capability (I can add that in the sdk target files, so is added for every fsproj, like the other props), that add the and initialize the languageservice parsing the compiler args from fsproj (similar on how now works) so intellisense works.

How vscode works now? How can have intellisense? On build a compile-fsc.rsp is generated who is the response file use for fsc, and ionide read that to initialize the FCS.
Now we can use FscTask (my pr) so compiler args gathering should change a bit (no response file).

If you want to try latest version with preview4, see my pr.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jan 24, 2017

Contributor

@KevinRansom what sdk version is used? Becuase fsproj works with all msbuild based preview3,4 and new rc.
Based on sdk version I can give you right templates (or just do dotnet new).

If we know a valid c# template is also easy to modify to be an f# one, changes are minimal.

I hope to have an installed VS2017 RC soon, to try it.

Contributor

enricosada commented Jan 24, 2017

@KevinRansom what sdk version is used? Becuase fsproj works with all msbuild based preview3,4 and new rc.
Based on sdk version I can give you right templates (or just do dotnet new).

If we know a valid c# template is also easy to modify to be an f# one, changes are minimal.

I hope to have an installed VS2017 RC soon, to try it.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Jan 24, 2017

Contributor

@ enrico so ...
C# is not helpful in this case, because it is supported in the box. I know that they intend to ship your modifications in the box, which will make this template fine. However ... it's not there yet.

Moving the project system to CPS should now be orthogonal. The "joy" of moving back to msbuild based projects means that our current project system should work reasonably well.

As I said I will chat with Piotr and find out why your stuff didn't yet ship. And see if there are some modifications we can propose to the templates.

Kevin

Contributor

KevinRansom commented Jan 24, 2017

@ enrico so ...
C# is not helpful in this case, because it is supported in the box. I know that they intend to ship your modifications in the box, which will make this template fine. However ... it's not there yet.

Moving the project system to CPS should now be orthogonal. The "joy" of moving back to msbuild based projects means that our current project system should work reasonably well.

As I said I will chat with Piotr and find out why your stuff didn't yet ship. And see if there are some modifications we can propose to the templates.

Kevin

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jan 24, 2017

Contributor

@KevinRansom about c# I mean seeing the template can show what version of f# template use. In Preview3 for example The f# is just an additional normal PackageReference, so nothing ship with sdk.
Anyway easier wait Piotr

About cps/Roslyn yes is orthogonal, but maybe we can start work on that on master branch, more work becuase need to be implemented, but less work to adapt current code to msbuild.
For example current project system reorder fsproj items on save, no multi fw support, reference but no PackageReference etc.
with Roslyn workspaces already implemented we have a good starting point. Lots of possible PR :)

Contributor

enricosada commented Jan 24, 2017

@KevinRansom about c# I mean seeing the template can show what version of f# template use. In Preview3 for example The f# is just an additional normal PackageReference, so nothing ship with sdk.
Anyway easier wait Piotr

About cps/Roslyn yes is orthogonal, but maybe we can start work on that on master branch, more work becuase need to be implemented, but less work to adapt current code to msbuild.
For example current project system reorder fsproj items on save, no multi fw support, reference but no PackageReference etc.
with Roslyn workspaces already implemented we have a good starting point. Lots of possible PR :)

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Jan 25, 2017

Contributor

@enricosada

It seems to me that Goal 1 should be that VS can load a dotnet/cli fsharp template so that we can edit the source. Since we are now using msbuild that should not be too bad a problem to solve.

Most of the project file editing would not have UI because we aren't yet on CPS but we should be able to add --- move, rename and remove F# source files. References will be problematic because they are quite different now and moving to CPS will help address that.

It seems that we are not at Goal 1 - Piotr on DotnetCLI and Daniel on the MSBuild team tells me that your SDK project is included in box for dotnet cli, but not included inbox for VS.

However, we should be able to author an F# template that doesn't use the SDK wiring which can be loaded into the F# Project System as is. For sure the current templates do not do so.

Contributor

KevinRansom commented Jan 25, 2017

@enricosada

It seems to me that Goal 1 should be that VS can load a dotnet/cli fsharp template so that we can edit the source. Since we are now using msbuild that should not be too bad a problem to solve.

Most of the project file editing would not have UI because we aren't yet on CPS but we should be able to add --- move, rename and remove F# source files. References will be problematic because they are quite different now and moving to CPS will help address that.

It seems that we are not at Goal 1 - Piotr on DotnetCLI and Daniel on the MSBuild team tells me that your SDK project is included in box for dotnet cli, but not included inbox for VS.

However, we should be able to author an F# template that doesn't use the SDK wiring which can be loaded into the F# Project System as is. For sure the current templates do not do so.

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Feb 27, 2017

Contributor

Any progress on this? A month has passed. Could you be more clear where people can click New -> F# -> .NET Core console application and it will work, including debugging? Are we waiting until @enricosada has finished something? MSBuild team? Other people?

Contributor

vasily-kirichenko commented Feb 27, 2017

Any progress on this? A month has passed. Could you be more clear where people can click New -> F# -> .NET Core console application and it will work, including debugging? Are we waiting until @enricosada has finished something? MSBuild team? Other people?

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Feb 27, 2017

Contributor

Are we waiting until @enricosada has finished something

@vasily-kirichenko i have nothing more to do for f# in .net core sdk 1.0 and the new fsproj afaik.
From command line all cli commands works (based on latest fsc released by vf# team), and everything is msbuild based (FSharp.Build.dll). Just minor bugfixes/improvement left, but can be done later (already logged in https://github.com/dotnet/netcorecli-fsc/issues ).
I need to do some work for community based FSAC (like vscode) to reenable intellisense, but is not related to VS.
Debugging in vscode already works too because the portable pdb work really well (thx about that @KevinRansom ) in my local tests with vscode debugger.

I added f# templates to dotnet new and these templates are imported as VS templates, for c# at least (used in New-> C#->.NET Core), but afaik are not going in for VS rtm (and is ok, because will not work).

About intellisense/projectsystem/debug/etc in VS dunno, i'll try to work on it, but on the long term roslyn-project-system based option, and later after rtm.

Contributor

enricosada commented Feb 27, 2017

Are we waiting until @enricosada has finished something

@vasily-kirichenko i have nothing more to do for f# in .net core sdk 1.0 and the new fsproj afaik.
From command line all cli commands works (based on latest fsc released by vf# team), and everything is msbuild based (FSharp.Build.dll). Just minor bugfixes/improvement left, but can be done later (already logged in https://github.com/dotnet/netcorecli-fsc/issues ).
I need to do some work for community based FSAC (like vscode) to reenable intellisense, but is not related to VS.
Debugging in vscode already works too because the portable pdb work really well (thx about that @KevinRansom ) in my local tests with vscode debugger.

I added f# templates to dotnet new and these templates are imported as VS templates, for c# at least (used in New-> C#->.NET Core), but afaik are not going in for VS rtm (and is ok, because will not work).

About intellisense/projectsystem/debug/etc in VS dunno, i'll try to work on it, but on the long term roslyn-project-system based option, and later after rtm.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Feb 27, 2017

Contributor

@vasily-kirichenko some wip by kevin about this in #2482

Contributor

enricosada commented Feb 27, 2017

@vasily-kirichenko some wip by kevin about this in #2482

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

@enricosada and I were trying to make it work. Results (VS RC4 + OSS VSIX built from current master):

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
  </ItemGroup>

</Project>
<DontRunFscWithDotnet>true</DontRunFscWithDotnet>
<FscToolExe>fsc.exe</FscToolExe>
<FscToolPath>e:\github\visualfsharp\release\net40\bin\</FscToolPath>

and we had to copy a bunch of assemblies from related packages to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\ so that it looks as following:

15-Feb-17  15:26               490 default.win32manifest
15-Feb-17  15:26             3,633 fsc.deps.json
15-Feb-17  15:26            25,744 fsc.dll
15-Feb-17  15:26               118 fsc.runtimeconfig.json
28-Feb-17  15:23            58,880 FSharp.Build.dll
28-Feb-17  15:23            69,120 FSharp.Build.pdb
28-Feb-17  15:23             1,465 FSharp.Build.xml
28-Feb-17  15:24        12,011,520 FSharp.Compiler.dll
28-Feb-17  15:24        13,129,216 FSharp.Compiler.pdb
28-Feb-17  15:24         1,050,766 FSharp.Compiler.xml
28-Feb-17  15:23         1,619,968 FSharp.Core.dll
28-Feb-17  15:23           430,744 FSharp.Core.optdata
28-Feb-17  15:23         2,731,520 FSharp.Core.pdb
28-Feb-17  15:23           561,214 FSharp.Core.sigdata
28-Feb-17  15:23           721,710 FSharp.Core.xml
15-Feb-17  15:26            25,040 Microsoft.DiaSymReader.dll
15-Feb-17  15:26            92,640 Microsoft.DiaSymReader.PortablePdb.dll
28-Feb-17  14:27    <DIR>          runtimes
11-Jun-16  23:13            21,704 System.AppContext.dll
11-Jun-16  23:13            22,184 System.IO.dll
11-Jun-16  23:14            22,728 System.Reflection.dll
15-Feb-17  15:26           432,872 System.Reflection.Metadata.dll
11-Jun-16  23:14            29,880 System.Runtime.dll
11-Jun-16  23:14            33,000 System.Runtime.Extensions.dll
15-Feb-17  15:26            47,304 System.ValueTuple.dll

and we had to copy FSharp.Core.dll/opdata/sigdata, FSharp.Compiler.dll and FSharp.Build.dll from e:\github\visualfsharp\release\net40\bin\ to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\, because it crashes with MethodNotFoundException.

After all these hacks:

  • The project is loaded to VS
  • It can be built inside VS
  • It can be debugged by attaching to process
  • All IDE features work

What does not work:

  • F5 does not start debugging because it cannot find *.exe file to run:

image
.NET Core console apps are DLLs which must be launched with dotnet run <dll> (@enricosada am I right?), so we should change something in ProjectSystem.Base or ProjectSystem I think.

  • There are phantom nodes in Solution Explorer:

image
which are from

<ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
</ItemGroup>

I think they should be moved to References node or a new Packages node.

Debugging:

image

Contributor

vasily-kirichenko commented Mar 1, 2017

@enricosada and I were trying to make it work. Results (VS RC4 + OSS VSIX built from current master):

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
  </ItemGroup>

</Project>
<DontRunFscWithDotnet>true</DontRunFscWithDotnet>
<FscToolExe>fsc.exe</FscToolExe>
<FscToolPath>e:\github\visualfsharp\release\net40\bin\</FscToolPath>

and we had to copy a bunch of assemblies from related packages to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\ so that it looks as following:

15-Feb-17  15:26               490 default.win32manifest
15-Feb-17  15:26             3,633 fsc.deps.json
15-Feb-17  15:26            25,744 fsc.dll
15-Feb-17  15:26               118 fsc.runtimeconfig.json
28-Feb-17  15:23            58,880 FSharp.Build.dll
28-Feb-17  15:23            69,120 FSharp.Build.pdb
28-Feb-17  15:23             1,465 FSharp.Build.xml
28-Feb-17  15:24        12,011,520 FSharp.Compiler.dll
28-Feb-17  15:24        13,129,216 FSharp.Compiler.pdb
28-Feb-17  15:24         1,050,766 FSharp.Compiler.xml
28-Feb-17  15:23         1,619,968 FSharp.Core.dll
28-Feb-17  15:23           430,744 FSharp.Core.optdata
28-Feb-17  15:23         2,731,520 FSharp.Core.pdb
28-Feb-17  15:23           561,214 FSharp.Core.sigdata
28-Feb-17  15:23           721,710 FSharp.Core.xml
15-Feb-17  15:26            25,040 Microsoft.DiaSymReader.dll
15-Feb-17  15:26            92,640 Microsoft.DiaSymReader.PortablePdb.dll
28-Feb-17  14:27    <DIR>          runtimes
11-Jun-16  23:13            21,704 System.AppContext.dll
11-Jun-16  23:13            22,184 System.IO.dll
11-Jun-16  23:14            22,728 System.Reflection.dll
15-Feb-17  15:26           432,872 System.Reflection.Metadata.dll
11-Jun-16  23:14            29,880 System.Runtime.dll
11-Jun-16  23:14            33,000 System.Runtime.Extensions.dll
15-Feb-17  15:26            47,304 System.ValueTuple.dll

and we had to copy FSharp.Core.dll/opdata/sigdata, FSharp.Compiler.dll and FSharp.Build.dll from e:\github\visualfsharp\release\net40\bin\ to c:\Users\<user>\.nuget\packages\fsharp.compiler.tools\4.1.0\build\netcoreapp1.0\, because it crashes with MethodNotFoundException.

After all these hacks:

  • The project is loaded to VS
  • It can be built inside VS
  • It can be debugged by attaching to process
  • All IDE features work

What does not work:

  • F5 does not start debugging because it cannot find *.exe file to run:

image
.NET Core console apps are DLLs which must be launched with dotnet run <dll> (@enricosada am I right?), so we should change something in ProjectSystem.Base or ProjectSystem I think.

  • There are phantom nodes in Solution Explorer:

image
which are from

<ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
    <PackageReference Include="FSharp.Core" Version="4.1.*" />
</ItemGroup>

I think they should be moved to References node or a new Packages node.

Debugging:

image

@slang25

This comment has been minimized.

Show comment
Hide comment
@slang25

slang25 Mar 1, 2017

Love seeing progress on this 😃

.NET Core console apps should be launched with just dotnet, like dotnet myapp.dll, dotnet run is for when you are in the project folder and want the cli to take care of figuring out if it needs building etc.

slang25 commented Mar 1, 2017

Love seeing progress on this 😃

.NET Core console apps should be launched with just dotnet, like dotnet myapp.dll, dotnet run is for when you are in the project folder and want the cli to take care of figuring out if it needs building etc.

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

@slang25 thanks :)

Contributor

vasily-kirichenko commented Mar 1, 2017

@slang25 thanks :)

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Mar 1, 2017

Contributor

Added dotnet/netcorecli-fsc#87 to locate dotnet, so netcore fsc will work (no need to override with .net full version of fsc)

Contributor

enricosada commented Mar 1, 2017

Added dotnet/netcorecli-fsc#87 to locate dotnet, so netcore fsc will work (no need to override with .net full version of fsc)

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Mar 1, 2017

Contributor

I'll add some todo there, but should be a checklist in another meta issue (not this one) about "modify current project system to handle new fsproj", with all open points, issues found.
Maybe is better if you @vasily-kirichenko open it, so you can update the description with status/checklist later? @KevinRansom can already update that as admin.

  • fix location of dotnet , ref dotnet/netcorecli-fsc#87
  • Manage projectguid (used also for project reference in the vf# project system afaik). Maybe read it from solution? because a solution file always exists, and guid there exists.
  • Special msbuild items (like PackageReference, DotnetCliTool) as nodes, filter out (fast) or add new node types (useful?)
  • make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.
  • use netcoreapp1.0 fsc or net40 fsc when building inside VS? as default?
  • use FSharp.Build.dll for net40 when building inside VS, but i think the current packaged in FSharp.Compiler.Tools has signing (read internal visible) issues?
  • propose dotnet restore at opening of project? because nothing works if is not restored already before open.
  • check build, ctrl-f5 run for netcoreapp
  • check build, ctrl-f5 run for net461 app
  • how crossgen (multiple target framework will work) will work? what is the current target fw executed by VS? a combo somewhere?
  • write a wiki with existing workarounds (like restore before load solution) may be enough for some things
Contributor

enricosada commented Mar 1, 2017

I'll add some todo there, but should be a checklist in another meta issue (not this one) about "modify current project system to handle new fsproj", with all open points, issues found.
Maybe is better if you @vasily-kirichenko open it, so you can update the description with status/checklist later? @KevinRansom can already update that as admin.

  • fix location of dotnet , ref dotnet/netcorecli-fsc#87
  • Manage projectguid (used also for project reference in the vf# project system afaik). Maybe read it from solution? because a solution file always exists, and guid there exists.
  • Special msbuild items (like PackageReference, DotnetCliTool) as nodes, filter out (fast) or add new node types (useful?)
  • make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.
  • use netcoreapp1.0 fsc or net40 fsc when building inside VS? as default?
  • use FSharp.Build.dll for net40 when building inside VS, but i think the current packaged in FSharp.Compiler.Tools has signing (read internal visible) issues?
  • propose dotnet restore at opening of project? because nothing works if is not restored already before open.
  • check build, ctrl-f5 run for netcoreapp
  • check build, ctrl-f5 run for net461 app
  • how crossgen (multiple target framework will work) will work? what is the current target fw executed by VS? a combo somewhere?
  • write a wiki with existing workarounds (like restore before load solution) may be enough for some things
@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

Add file dialog shows no templates:

image

Contributor

vasily-kirichenko commented Mar 1, 2017

Add file dialog shows no templates:

image

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.

I think it's not risky. That's the change VS made after warning level was changed via UI:

image

look pretty good.

Contributor

vasily-kirichenko commented Mar 1, 2017

make it readonly from ui. On save current vf# code will change fsproj and afaik that is risky. ihmo better tell everyone to manually edit fsproj.

I think it's not risky. That's the change VS made after warning level was changed via UI:

image

look pretty good.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Mar 1, 2017

Contributor

@vasily-kirichenko good, but that Condition is not what it's used normally in new fsproj. i mean the |$(Platform). If we can remove or change that condition is better

@vasily-kirichenko i am more scared about file moves/deleted/added, or references added

Add file dialog shows no templates:

that's probably because the fsproj has no f# project guid (is not used anymore in new msbuild, because all csproj is using cps capabilities instead). we can add that, but maybe is better not do so? (ref scared about add files)

Contributor

enricosada commented Mar 1, 2017

@vasily-kirichenko good, but that Condition is not what it's used normally in new fsproj. i mean the |$(Platform). If we can remove or change that condition is better

@vasily-kirichenko i am more scared about file moves/deleted/added, or references added

Add file dialog shows no templates:

that's probably because the fsproj has no f# project guid (is not used anymore in new msbuild, because all csproj is using cps capabilities instead). we can add that, but maybe is better not do so? (ref scared about add files)

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

@enricosada

  • Move up / down works OK.
  • Add does not work, see above.
  • Delete works OK.

So I think project modifying and saving inside VS is not the main concern right now.

Contributor

vasily-kirichenko commented Mar 1, 2017

@enricosada

  • Move up / down works OK.
  • Add does not work, see above.
  • Delete works OK.

So I think project modifying and saving inside VS is not the main concern right now.

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Mar 1, 2017

Contributor

Trying to add a reference:

image

Contributor

vasily-kirichenko commented Mar 1, 2017

Trying to add a reference:

image

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Mar 7, 2017

Contributor

After the really promising and unexpected work in dotnet/project-system#1670 to enable F# with CPS and new roslyn project system, ihmo is useless to do work to patch the old project system. @KevinRansom what do you think?

Contributor

enricosada commented Mar 7, 2017

After the really promising and unexpected work in dotnet/project-system#1670 to enable F# with CPS and new roslyn project system, ihmo is useless to do work to patch the old project system. @KevinRansom what do you think?

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Mar 21, 2017

How can this process be speed up? Which help is required?

xperiandri commented Mar 21, 2017

How can this process be speed up? Which help is required?

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Mar 21, 2017

Contributor

@xperiandri see comments in dotnet/project-system#1670
work is pratically finish that PR.
with FSharp.NET.Sdk 1.0.2 the msbuild fsc task should be ok

Contributor

enricosada commented Mar 21, 2017

@xperiandri see comments in dotnet/project-system#1670
work is pratically finish that PR.
with FSharp.NET.Sdk 1.0.2 the msbuild fsc task should be ok

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Mar 21, 2017

That is excellent!
How this affects ability to use it in Visual Studio 2017 soon?
Will Visual F# tools update just support it or it will require a new build of Visual Studio 2017 Update Preview to try this?

xperiandri commented Mar 21, 2017

That is excellent!
How this affects ability to use it in Visual Studio 2017 soon?
Will Visual F# tools update just support it or it will require a new build of Visual Studio 2017 Update Preview to try this?

@GiorgioG

This comment has been minimized.

Show comment
Hide comment
@GiorgioG

GiorgioG Apr 5, 2017

@cartermp any update on when we might see a usable (even if beta) release for VS2017?

GiorgioG commented Apr 5, 2017

@cartermp any update on when we might see a usable (even if beta) release for VS2017?

@vasily-kirichenko

This comment has been minimized.

Show comment
Hide comment
@vasily-kirichenko

vasily-kirichenko Apr 5, 2017

Contributor

AFAIK, July is a super optimistic estimate.

Contributor

vasily-kirichenko commented Apr 5, 2017

AFAIK, July is a super optimistic estimate.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Apr 5, 2017

Collaborator

@GiorgioG Current target is July. Issues tracking it are here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

The "15.3" milestone represents the third update to VS 2017, which is likely to be around July.

Collaborator

cartermp commented Apr 5, 2017

@GiorgioG Current target is July. Issues tracking it are here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

The "15.3" milestone represents the third update to VS 2017, which is likely to be around July.

@stanuku

This comment has been minimized.

Show comment
Hide comment
@stanuku

stanuku May 23, 2017

I apologize if I missed something, but here is my issue/question:

I created a FSharp project with dotnet new mvc -lang F#. Opening it in VS 2017 fails with the error (same as the image in @cartermp's post https://cloud.githubusercontent.com/assets/6309070/22265426/d4ca9dc2-e230-11e6-81dd-380b3de14828.PNG)

From command line:

  • MSBuild myproj.fsproj fails with same error.
  • dotnet build myproj.fsproj builds fine.

My understanding is that dotnet CLI uses MSBuild 15 engine (APIs) under the covers, so why does dotnet build work and not MSBuild?

My environment:

  • VS 2017 15.2 (26430.6)
  • .NET Core 1.1, SDK 1.0.4
  • MSBuild 15.1.1012.6693

Thanks

stanuku commented May 23, 2017

I apologize if I missed something, but here is my issue/question:

I created a FSharp project with dotnet new mvc -lang F#. Opening it in VS 2017 fails with the error (same as the image in @cartermp's post https://cloud.githubusercontent.com/assets/6309070/22265426/d4ca9dc2-e230-11e6-81dd-380b3de14828.PNG)

From command line:

  • MSBuild myproj.fsproj fails with same error.
  • dotnet build myproj.fsproj builds fine.

My understanding is that dotnet CLI uses MSBuild 15 engine (APIs) under the covers, so why does dotnet build work and not MSBuild?

My environment:

  • VS 2017 15.2 (26430.6)
  • .NET Core 1.1, SDK 1.0.4
  • MSBuild 15.1.1012.6693

Thanks

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada May 23, 2017

Contributor

@stanuku because VS msbuild doesnt include FSharp.NET.Sdk in the Sdks msbuild cache. Otherwise works the same in mono, VS, dotnetcli

See #2928 (comment)

If you copy %PATH_OF_DOTNET_EXE%\sdk\1.0.4\Sdks\FSharp.NET.Sdk into C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\FSharp.NET.Sdk\ will work in msbuild.exe (more info in https://github.com/dotnet/netcorecli-fsc/releases/tag/v1.0.3 )

But will not work in VS, because VS doesnt yet understand new project format ( more info in #3069 ) expected in July update

Contributor

enricosada commented May 23, 2017

@stanuku because VS msbuild doesnt include FSharp.NET.Sdk in the Sdks msbuild cache. Otherwise works the same in mono, VS, dotnetcli

See #2928 (comment)

If you copy %PATH_OF_DOTNET_EXE%\sdk\1.0.4\Sdks\FSharp.NET.Sdk into C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\FSharp.NET.Sdk\ will work in msbuild.exe (more info in https://github.com/dotnet/netcorecli-fsc/releases/tag/v1.0.3 )

But will not work in VS, because VS doesnt yet understand new project format ( more info in #3069 ) expected in July update

@stanuku

This comment has been minimized.

Show comment
Hide comment
@stanuku

stanuku May 24, 2017

@enricosada: Ok, understood. Thank you and please keep up the great work on F# front.

stanuku commented May 24, 2017

@enricosada: Ok, understood. Thank you and please keep up the great work on F# front.

@stanuku

This comment has been minimized.

Show comment
Hide comment
@stanuku

stanuku May 24, 2017

@enricosada I've copied the F# SDK to the MSBuild cache and when I opened the .fsproj I got this error:

image

Please let me know if I should wait till the next VS 2017 update or if there is a work around for this error. or post this error/issue in some other repo?

stanuku commented May 24, 2017

@enricosada I've copied the F# SDK to the MSBuild cache and when I opened the .fsproj I got this error:

image

Please let me know if I should wait till the next VS 2017 update or if there is a work around for this error. or post this error/issue in some other repo?

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada May 24, 2017

Contributor

@stanuku while copying sdk directory will make msbuild work from command line, is not enough for VS VF# extension, who need work for support the new project format (is a big change, but near completion).

See roadmap, need to wait until VS 2017 15.3 update at least (july timeframe)

Contributor

enricosada commented May 24, 2017

@stanuku while copying sdk directory will make msbuild work from command line, is not enough for VS VF# extension, who need work for support the new project format (is a big change, but near completion).

See roadmap, need to wait until VS 2017 15.3 update at least (july timeframe)

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jun 30, 2017

Collaborator

Closing this now, as these projects load with 15.3. The current way to use them:

(Yes, the .NET SDK is independent of VS. You will also need this to get .NET Core 2.0 support in VS 2017 Update 3 Previews).

There is a small amount of remaining work left in our own language service to no longer depend on IProjectSite. This the root cause behind #3260 and #3266. Work to support file ordering, and any other project system-specific F# issues is being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

Collaborator

cartermp commented Jun 30, 2017

Closing this now, as these projects load with 15.3. The current way to use them:

(Yes, the .NET SDK is independent of VS. You will also need this to get .NET Core 2.0 support in VS 2017 Update 3 Previews).

There is a small amount of remaining work left in our own language service to no longer depend on IProjectSite. This the root cause behind #3260 and #3266. Work to support file ordering, and any other project system-specific F# issues is being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

@cartermp cartermp closed this Jun 30, 2017

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri Jun 30, 2017

Should it be Preview 3 CLI?

xperiandri commented Jun 30, 2017

Should it be Preview 3 CLI?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jun 30, 2017

Collaborator

Nope, the one linked above is the one to use. There is no Preview 3 of the CLI (at the time of writing this). There is also no affinity between the VS version and CLI version. They have been designed so that you can update the .NET Core CLI and SDK out of band from VS.

Collaborator

cartermp commented Jun 30, 2017

Nope, the one linked above is the one to use. There is no Preview 3 of the CLI (at the time of writing this). There is also no affinity between the VS version and CLI version. They have been designed so that you can update the .NET Core CLI and SDK out of band from VS.

@xperiandri

This comment has been minimized.

Show comment
Hide comment
@xperiandri

xperiandri commented Jun 30, 2017

@cartermp, thanks. Here is an issue dotnet/project-system#2534

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Oct 16, 2017

Contributor

Should the files be in alphabetical order?
Also FSharp CoreApp 2.0 project's intellisense seems not to work with VS2017 and latest daily release of the tools.

Contributor

Thorium commented Oct 16, 2017

Should the files be in alphabetical order?
Also FSharp CoreApp 2.0 project's intellisense seems not to work with VS2017 and latest daily release of the tools.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 16, 2017

Collaborator

@Thorium Most issues are being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

If you're using 15.5, then I suspect your issues with IntelliSense are due to #3653, which enables project-to-project references and fixes a bug where adding files results in IntelliSense issues.

In 15.3, the projects will load but they're not fully supported at all.

Also, the alphabetical issue is tracked in this repo, along with a few other issues: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

Collaborator

cartermp commented Oct 16, 2017

@Thorium Most issues are being tracked here: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

If you're using 15.5, then I suspect your issues with IntelliSense are due to #3653, which enables project-to-project references and fixes a bug where adding files results in IntelliSense issues.

In 15.3, the projects will load but they're not fully supported at all.

Also, the alphabetical issue is tracked in this repo, along with a few other issues: https://github.com/dotnet/project-system/issues?q=is%3Aopen+is%3Aissue+label%3AArea-F%23

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Oct 18, 2017

Contributor

Thanks, I'm using 15.3 as there is no official 15.5 yet. Let's hope it won't vanish from the release version of 15.5 like F# features of Visual Studio often tend to.

Contributor

Thorium commented Oct 18, 2017

Thanks, I'm using 15.3 as there is no official 15.5 yet. Let's hope it won't vanish from the release version of 15.5 like F# features of Visual Studio often tend to.

@cartermp cartermp modified the milestones: VS 2017 Updates, 15.5 Jun 9, 2018

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