Web programming and F# still a Far Cry?
Exploring F# web programming challenges in 2014: NuGet issues, dependency management, and Azure deployment hurdles.
F# is a wonderful language. And luckily or unluckily, I do Web Programming (nowadays mostly that). So, it is always a preference to use it wherever possible. But even at the end of 2014, it is still a pain in the ***.
I did make templates for Servicestack and I will continue to support that. But when it comes to real projects, they go far beyond templates.
I recently started experimenting on something and obviously I was gonna use templates created by me. I created a project and ran it. Luckily it ran without any issue. And then I fired up nuget update. Bang!!! Nuget update reverted with the error of object reference not found. I tried to find a solution but failed. Then I tried the same thing with Servicestack official templates. It worked once and then failed again.
I thought there was an issue with nuget or the updated F# tool chain. God only knows. So, I checked other ways of updating packages.
I knew about paket. Either due to some bug or feature, it just worked for a start. Then I added emberjs via a nuget package. And got a folder render error. Which is very typical for F# projects. I know how to solve it. I normally always keep the F# project file open in a different text editor for this kind of issue. So, I moved a few include lines here and there to keep the same folder in order and solved the issue. Then I added a few more JS libs and paket install gave the same issue again.
Now, all these issues were not enough—Azure deployment is not completed without a little hack I mentioned in my previous blog. For the last update, it should have solved this issue but it is not working. Maybe the feature is not completed or maybe it is just me.
And the whole exercise took more than 7 hours and I deleted and added the project more than 5 times just to make it work. Just to make the damn Hello World work. That is it. Nothing more and nothing less. I was exactly feeling like 
.
After that, I changed the project structure again and put a C# project as the front end and F# as the library project. Just to make nuget happy. And also to make Azure happy. As I don't want to mess around with project files and want to write some code. I guess that is more important than hacking around the tool chain.
I know F# is far ahead of its time. It is a next-generation language. But it is also old enough to have proper Visual Studio support. It should be supported and loved like any other language on the .NET framework. At least from the tool chain point of view. I can always have a workaround, but writing code in a pure project in a single language is always fun.
Please let me know if I missed anything or if I'm making a mistake on my side.
Things are improving fast and hopefully it will be at the same level where all languages can find common ground. Hoping and waiting for VNext support now.
Frequently Asked Questions
F# web programming faces several challenges including NuGet update failures with 'object reference not found' errors, F# project file management issues requiring manual editing, and Azure deployment complications that need workarounds. These issues persist despite F# being a mature language with Visual Studio support, making web development more time-consuming than necessary.
Paket is an alternative package manager for .NET projects that some developers have found more reliable than NuGet for F# projects. While Paket initially worked better for the author's use case, it also had limitations when managing JavaScript libraries through NuGet packages, indicating no single perfect solution exists for F# dependency management.
You can manually edit the F# project file in a text editor to reorganize include lines and folder structures when package managers create rendering errors. This workaround involves keeping the project file open in a separate editor and moving includes to maintain proper folder ordering, though this is a tedious process.
Some developers structure projects with C# front-end components and F# libraries to avoid continuous toolchain hacks and project file management issues. This hybrid approach allows developers to focus on writing actual code rather than spending hours troubleshooting package managers and deployment configurations.
F# projects require special workarounds for Azure deployment that weren't fully resolved in recent updates, requiring developers to manually configure their projects or modify deployment procedures. This adds complexity to getting even simple projects deployed to Azure production environments.