We’ve been humbled by the intense interest in Visual Studio tools for Azure Functions since we shipped our initial preview for Visual Studio 2015 last fall. Unfortunately, given other constraints, Visual Studio 2017 did not include Azure Functions when we shipped in March. So, we’d like to provide an update to our roadmap for Functions Tooling including Visual Studio 2017 support now.
Using the feedback we received from our first preview of the tools, we’ve decided that our next iteration of Azure Function tools will focus on creating precompiled Azure Function apps using .NET Standard 2.0 class libraries.
Why the pivot?
When we shipped the preview tools in Visual Studio 2015 last winter, two of the most common requests we received were for project to project references, and unit testing support (both locally and as part of a continuous integration pipeline). These feature requests along with many others made it clear that people desired a very standard Visual Studio experience for developing and working with Functions.
So rather than attempting to re-invent the wheel, we felt the right direction was to move to the standard C# artifact (class libraries) that has decades of investment and first class support for these capabilities. Additionally, as mentioned in the Publishing a .NET class library as a Function App blog post, precompiled functions also provide better cold start performance for Azure Functions.
What does this mean?
As with any change, there are both costs and benefits to the change. Overall we believe this will be a great thing for the future of Azure Functions for the following reasons:
- These will be C# class libraries, which means that the full tooling power of the Visual Studio eco-system will be available including project to project references, test support, code analysis tools, code coverage, 3rd party extensions, etc.
- NET Standard 2.0 is designed to work across the .NET Framework and .NET Core 2.0 (coming soon). This means .NET Standard 2.0 Azure Function projects will run with no code changes on both the current Azure Functions runtime, as well as on the planned .NET Core 2.0 Functions runtime. At that point, you can build .NET function apps on Windows, Mac, and Linux using the tools of your choice.
So, to ease the transition we recommend that you start new Azure Functions projects as C# class libraries, rather than using the 2015 preview tooling.
Conclusion
We hope that this helps to clarify what our current plans are, and why we think that it is the right thing to do for the long-term future of Azure Functions tooling. We’d also like to say that we’re working on on building this experience, and will have more details to share within the next month. As always, we would love your feedback, so let us know what comments and questions you have below, or via twitter at @AndrewBrianHall and @AzureFunctions.