How to split up Durable Functions in multiple class projects

Cosmin Vladutu
3 min readNov 7, 2022

Problem

You have a big function project that it’s hard to handle; for some reason, you have multiple processes inside the same function project. You want to separate them into different projects, from the sln structure but you want all of them to be run in the same way (as they were in the same project).

Solution

You can split them in different csproj, based on types, or on some business logic you have in there. In the image below I split them based on type:

sln structure

I have my App, which is a function project, but all my triggers, orchestrators, activities and logic, in general, are split based on type in two different class libraries projects.
Now the fun part starts: When you click run:

Functions not found on runtime

To make this work, and make the triggers/functions visible by the function project (since they are “invisible” being in another csproj which is not marked as being a function one), is pretty simple, but almost not documented at all: You just need to add this code in the function csproj, in the property group section

<FunctionsInDependencies>true</FunctionsInDependencies>

It will look like this:

After that, you can just hit the run button, and your listeners will start listing, but even here it’s a catch: you need the function to have a reference to your class library project, and use something for it. If you don’t have anything that it’s used, the compiler will optimize your code and remove the dependency since he will say it’s useless and you added it by mistake.

Conclusion

It’s easy to split the functions using class library csproj, but in my opinion, your function project shouldn’t do much; you should always keep the SRP principle in your mind, and if you don’t really do that, at least think about the limitation of durable functions. In the consumption plan, things go side-ways if you have more than 100 functions in your function project (and it’s pretty easy to have this if you’re using durable functions and you have pretty big orchestrations); my suggestion would be to have one function project per process, but if you think it’s too much, or can’t do it, at least try as a first step to split them on separate projects, like I just presented. It can be the first step in making your life easier.

--

--

Cosmin Vladutu

Software Engineer | Azure & .NET Full Stack Developer | Leader