You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is the right forum, and I'm not sure if this has already been addressed elsewhere, but I wanted to bring up some known issues with the current VS F# tooling and try to get some insight into whether they are being addressed in the work for VS "15" F# tooling, and if not, try to provide some motivation for doing so.
Native Support for Web Project templates and Web Item templates
The F# Community Templates have been indispensable in my attempts to introduce F# at work. However, despite valiant efforts, the templates retain a certain brittleness stemming from things like having to reference a specific version of the MSBuild.Extension.Pack in a specific location and the use of registry "hacks" to allow use of Web Item templates to add items to the project. Both these workarounds have their issues as the reference to MSBuild.Extension.Pack will show up as an upgrade-able or outdated package in either NuGet or Paket and if upgraded will break the build, as will invoking MSBuild from a unexpected location which seems to break resolution of the path to MSBuild.Extension.Pack. As for the Web Item templates, they remain a constant source of problems as even with the registry hacks (whether done manually, or through scripts, or through the extension) the Web Item templates have a tendency to disappear at some point, perhaps due to VS config/option changes or extension installs/upgrades/uninstalls. It would be immensely empowering if more fundamental support for F# Web Project templates and Web Item templates could be arranged that obviate the need for the MSBuild.Extension.Pack and registry hack workarounds.
Native Support for File & Folder management, incl Add/Rename/Remove Folder, Drag n Drop, Copy/Paste, Show All Files and Include in Project
I can't begin to express how much I appreciate the work the community has done on the Visual F# Power Tools, however, one of the less stable features has to be Folder Organization. In fact, the maintainers themselves say the following
This feature is disabled by default. Because there are known issues with F# Project System in Visual F# Tools, folder organization may not work 100% correctly in all cases.
We do not advice you to introduce complicated folder structure within F# projects. You should keep number of folders within your project as low as possible.
I know that there are points to be made on how code organization in F# is different from more imperative languages but I think this is a bit of a red herring. This is basically like saying that limited file and folder management is a feature of the language tooling because it is more idiomatic to use less files and folders in the language. File and folder management is such a basic part of editing code, and while there are legitimate reasons why it has been challenging to sort this out, it really should be a top priority for the next version of VS F# tooling. Despite it being such a minor thing, it nonetheless becomes a constant sticking point anytime I show F# non-trivial apps to co-workers (in fact, it is precisely because it is a minor thing that I get particularly pitiable looks whenever I try to trivialize the need to my coworkers since they find it hard to accept that one should move on with coding as if file and folder management did not matter).
Manual rebuild necessary in order to detect changes from other files
This one is not as bad the other two, however, it does kinda get in the way of attaining flow. The usual response I see is that in F# you typically start with everything in a script file and then once you have it working correctly, then you break it up into files...but not into too many files. This also seems like a bit of a red herring. While I find the script workflow very productive, there is no reason why working with code across files cannot also be productive.
The text was updated successfully, but these errors were encountered:
I'm not sure if this is the right forum, and I'm not sure if this has already been addressed elsewhere, but I wanted to bring up some known issues with the current VS F# tooling and try to get some insight into whether they are being addressed in the work for VS "15" F# tooling, and if not, try to provide some motivation for doing so.
Native Support for Web Project templates and Web Item templates
The F# Community Templates have been indispensable in my attempts to introduce F# at work. However, despite valiant efforts, the templates retain a certain brittleness stemming from things like having to reference a specific version of the MSBuild.Extension.Pack in a specific location and the use of registry "hacks" to allow use of Web Item templates to add items to the project. Both these workarounds have their issues as the reference to MSBuild.Extension.Pack will show up as an upgrade-able or outdated package in either NuGet or Paket and if upgraded will break the build, as will invoking MSBuild from a unexpected location which seems to break resolution of the path to MSBuild.Extension.Pack. As for the Web Item templates, they remain a constant source of problems as even with the registry hacks (whether done manually, or through scripts, or through the extension) the Web Item templates have a tendency to disappear at some point, perhaps due to VS config/option changes or extension installs/upgrades/uninstalls. It would be immensely empowering if more fundamental support for F# Web Project templates and Web Item templates could be arranged that obviate the need for the MSBuild.Extension.Pack and registry hack workarounds.
supporting links
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2313421-more-f-project-types
fsprojects-archive/zzarchive-FSharpCommunityTemplates#51
fsprojects-archive/zzarchive-FSharpCommunityTemplates#100
Native Support for File & Folder management, incl Add/Rename/Remove Folder, Drag n Drop, Copy/Paste, Show All Files and Include in Project
I can't begin to express how much I appreciate the work the community has done on the Visual F# Power Tools, however, one of the less stable features has to be Folder Organization. In fact, the maintainers themselves say the following
I know that there are points to be made on how code organization in F# is different from more imperative languages but I think this is a bit of a red herring. This is basically like saying that limited file and folder management is a feature of the language tooling because it is more idiomatic to use less files and folders in the language. File and folder management is such a basic part of editing code, and while there are legitimate reasons why it has been challenging to sort this out, it really should be a top priority for the next version of VS F# tooling. Despite it being such a minor thing, it nonetheless becomes a constant sticking point anytime I show F# non-trivial apps to co-workers (in fact, it is precisely because it is a minor thing that I get particularly pitiable looks whenever I try to trivialize the need to my coworkers since they find it hard to accept that one should move on with coding as if file and folder management did not matter).
supporting links
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/6077963-add-folders-for-visual-f-projects
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/7031159-better-support-for-fsproj
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/11043387-enable-drag-and-drop-to-change-compilation-order-i
https://vfpt.uservoice.com/forums/247560-general/suggestions/8089230-add-existing-folder-to-project
https://fsprojects.github.io/VisualFSharpPowerTools/folderorganization.html
fsprojects-archive/zzarchive-VisualFSharpPowerTools#116
Manual rebuild necessary in order to detect changes from other files
This one is not as bad the other two, however, it does kinda get in the way of attaining flow. The usual response I see is that in F# you typically start with everything in a script file and then once you have it working correctly, then you break it up into files...but not into too many files. This also seems like a bit of a red herring. While I find the script workflow very productive, there is no reason why working with code across files cannot also be productive.
The text was updated successfully, but these errors were encountered: