Kompilator F # obsługuje foldery dobrze. Być może odwołujesz się do faktu, że Visual Studio, w domyślnej konfiguracji, nie pozwala na dodawanie folderów do projektów F # - to prawda. Ale jeśli w jakiś sposób uda się dodać foldery do pliku projektu (albo ręcznie edytując plik, czy też z F# Power Tools), kompilator F # nie będzie miał z nimi żadnych problemów.
Ale to wszystko nie ma znaczenia dla twojej sprawy, ponieważ skrypty (fsx
) to nie to samo co skompilowane moduły (fs
). Skrypty nie mają projektu wiążącego je ze sobą, a zamiast tego muszą się wzajemnie nawzajem łączyć, aby móc korzystać ze swoich kodów. I #load
można zrobić z dowolnej ścieżki.
Na przykład, możesz rozłożyć swój kod tak:
ProjectFolder
-> Common
-> Helpers.fsx
-> Function1
-> function.json
-> run.fsx
-> Function2
-> function.json
-> run.fsx
, a następnie w ciągu Function1/run.fsx
, załadować plik Helpers.fsx
za pomocą ścieżki względnej:
// Function1/run.fsx
#load "../Common/Helpers.fsx"
let x = Helpers.someFunction()
Jak wynika z powyższy przykład, skrypt załadowany w ten sposób pojawi się w skrypcie hosta jako moduł nazwany od pliku skryptu.
To działa, ale z biegiem czasu stanie się bardzo brudny. Zdecydowanie zalecam używanie prekompilowanego kodu. W ten sposób możesz umieścić wspólny kod we wspólnej bibliotece i odwoływać się do niego z obu funkcji.
Bardzo polecam this recent video from NDC Oslo. Mówi bardzo dobrze o tych rzeczach i nie tylko.
Zalecam używanie fsproj (wstępnie skompilowanego) dla Azure Functions zamiast skryptów. Zwłaszcza jeśli chcesz współdzielić kod między funkcjami. Wstępnie skompilowane są tylko zalety. Nie będzie można użyć projektu VS Azure Functions, ale nie jest on potrzebny. – TheQuickBrownFox