Mike Feingold's Adventures in programming

I was not sure it is possible, but it is. I managed to implement the approach I described here, found a workaround to (almost) every problem I ran into along the way and packaged all of it into one little Visual Studio extension package which allows you to organize your f# project like this.

You can download it here.
Using the package is really simple. Once you open an F# project after installing the package, the context menu on the project in the Solution Explorer will give you one new item:

Clicking on the item will enable the Project Extender for your project. From this moment on the behavior of the solution explorer will change in a number of ways.

First of all the order of items in the solution explorer will no longer reflect the compilation order. All files will be listed in the alphabetical order within their directories, right after the subdirectories listed also in the alphabetical order.

Context menus on the project node as well as subdirectories now also provide a way to create new (sub)directories. Renaming items changes the position of the item in the solution explorer if it is necessary to keep the alphabetical order of items.

All of the features listed above and a few more which are not listed are self - explanatory and very similar to the way the Solution Explorer works for C# project among others.

The file compilation order is not affected by any changes to the files performed through solution explorer. Compilation order is controlled by a new project property page:

Pressing Move Up and Move Down buttons changes the compilation order by moving the selected file up or down in the compilation order list.

As explained in the previous post ability to support compilation order across multiple directories involves some cheating. In practical terms it means that every time a project is loaded, the project file will be modified. When the project is closed it is modified back. It works ok with subversion, because the final state of the project file does not change, but with other source control systems it may force you to checkout the project file even though you have no intention of modifying it. This is one of the things I found no way around. I hope you can live with it as I plan to.

One more thing worthy mentioning is that once you enable the Project Extender you will get two more buttons on the solution explorer: Show All Files and Refresh:

Pressing the Show All Files button makes all files and/or subdirectories in the project directory visible in the solution explorer. Pressing this button again removes the elemens displaying such files from the solution explorer. Refresh button refreshes the list of files to bring it up to date. Again this functionality is similar to how it is done in other project systems, including ability to re-add previously excluded files back to the project.

And finally one last note: when you get really annoyed with the Project Extender you can easily disable it by using Disable F# project extender item on project context menu in the solution explorer.

I hope you will never use this command. Enjoy.

P.S. At this time the only platform supported is Visual Studio 2008/F# CTP 1.9.9.9. I am working on implementing it for Visual Studio 2010.

As of version 0.9.1.0 both VS2008 and VS 2010 are fully supported

Cheating is bad - right? But what if this is the only option available? As you may or may not know the project system shipped with F# compiler imposes limits on theВ  compilation orderВ  for the files in non-flat directory structure. Look here for the explanation.

I was looking for a way to squeeze by this limitation and here is what I found out: all this strictness is only enforced when

• The project is being loaded.
• project elements are added or renamed.

In particular these rules are not validated or enforced when the project is compiled. So the solution I came up with is to give the F# project manager something it can live with and when it is happy with what's provided and looks the other way rearrange the elements in the project file in the order I want them to be. If I do that I can use my custom compile order dialog to arrange the compilation order any way I want - for as long as the F# project manager looks the other way.

When the project is saved it has to be brought back to the state compatible with the F# project manager, otherwise it will refuse to load it next time around. So I intercept the onAfterProject close event and reorder project elements to comply with the F# project manager demands. While doing so I decorate the elements I move with custom XML elements to preserve the information how should I move them back to restore the (non-compliant) order of the files.

I also have to be on the lookout for F# project manager turning its attention to the build file element order. When it is about to happen I will have to adjust the element order in the build file to F# project manager liking, and it turns its back on me again I will have to move the items back.

That's the plan at the moment, let's see how far it's gonna take us.