Publishing to Linux Function Apps from JetBrains Rider

David Buckell 11

I am attempting to publish my Azure Function Apps from JetBrains Rider running in my Ubuntu operating system.
If I attempt to create the function app within the publish profile I cannot specify the operating system & so it defaults to windows, which I do not want. But at least doing it this way I do see my functions within the function app.

If I attempt to create the function app within the azure portal first I can specify the linux operating system. However when I then publish to this existing resource from Rider the console suggests the publish was successful however my functions are not actually published.
When creating within the portal to I would like to specify my own app service plan when using the dynamic consumption pricing tier, but this does not appear possible?

I was previously able to create linux based function apps when publishing from Visual Studio.

David Buckell 191 Reputation points

2022-04-10T23:00:36.497+00:00

Just to point out too that my existing function app was built on the .net core 3.1 framework whereas my new one is .net core 6.0.
David Buckell 191 Reputation points

2022-04-11T17:53:40.063+00:00

Have ran some more tests.
It certainly appears to either be related to the framework version or the functions runtime.
I am having to create the function app within the portal first in order to host it within Linux regardless of the IDE that I use.

With Visual Studio 2019 I have managed to deploy a .NET 5 function app using the isolated worker (as I don't believe I had a choice) successfully. Despite having installed the .NET 6 SDK & Runtime Visual Studio will seemingly not allow me to create a .NET 6 function app.

With Rider I deploy my function app using the default worker & seemingly see a success, but the functions are never listed, so it hasn't actually deployed anything.
If I attempt to create an isolated worker within Rider I cannot even compile the project

The dependency packages differ like so:
Default Worker:

Isolated Worker:

This was running Rider from windows, I try again within my ubuntu operating system.
David Buckell 191 Reputation points

2022-04-11T20:32:53.847+00:00

It is certainly an issue with the functions runtime & Rider IDE.
I can compile a DefaultWorker project in Rider from both a Windows & Ubuntu O/S.
However with an IsolatedWorker the build initially fails with:
Microsoft.Azure.Functions.Worker.Sdk.targets(50, 7): Invalid combination of TargetFramework and AzureFunctionsVersion is set.

Which is down to an empty _ToolingSuffix property:
<Error Condition="'$(_ToolingSuffix)' == ''" Text="Invalid combination of TargetFramework and AzureFunctionsVersion is set."/>
<_ToolingSuffix></_ToolingSuffix>

If I set it as follows, which I believe is the value it is expecting: <_ToolingSuffix>net6-isolated</_ToolingSuffix>

The error becomes:
Microsoft.NET.Sdk.Functions.Build.targets(32, 5): It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.0' (x64) was not found.

So it would appear that Isolated Worker within Rider is expecting a .net core 3.1 runtime.
David Buckell 191 Reputation points

2022-04-11T20:33:04.63+00:00

So my current conclusion:
isolated workers support .NET 5 from VS but not Rider.
default worker not supported in VS & is in Rider.
When creating the function app from either IDE (VS=isolated worker & Rider=default worker) it publishes successfully but Rider always defaults to a windows hosted function app, Visual Studio allows you to decide.
When attempting to publish to existing Linux function app previously created within the portal the publish from Visual Studio is successful & the functions appear, but with Rider despite the publish stating to be successful no functions are listed post publish.
David Buckell 191 Reputation points

2022-04-12T18:54:32.023+00:00

Managed to at least get isolated worker approach compiling within Rider.
I edited the csproj from:
<AzureFunctionsVersion>V3</AzureFunctionsVersion>
to
<AzureFunctionsVersion>V4</AzureFunctionsVersion>

and upon adding a http trigger function I also had to install the Microsoft.Azure.Functions.Worker.Extensions.Http package.

But having then published to an existing linux function app I see the same behaviour as with default worker approach in that no functions are actually published.

Publishing the exact same code to a pre-created windows function app from rider is successful with the http trigger function being visible.

Same applies with default worker function apps. Publishing to existing windows function apps from rider works fine, but pubilshing to exist linux function apps does not publish the functions.

So this is probably not an IDE issue. It would appear that the Azure functions v4 simply is not supported within Linux yet?
David Buckell 191 Reputation points

2022-04-12T19:19:13.487+00:00

Correction: it appears that azure function apps v4 are not supported on Linux when built with .net 6
David Buckell 191 Reputation points

2022-04-13T17:40:28.743+00:00

Ok the reason I am unable to create a .NET 6 function app within Visual Studio is due to me running VS2019, whereas 2022 is required.
I opted to use the Azure CLI instead following this guide: https://learn.microsoft.com/en-gb/azure/azure-functions/create-first-function-cli-csharp?tabs=azure-cli%2Cin-process&pivots=programming-runtime-functions-v4
By creating the function app first and publishing via the CLI I was able to publish to both a default worker & isolated worker function app hosted in Linux.
So I assume I will be able to publish my function app created in Rider via the Azure CLI too.
Not ideal but it should act as a workaround. I intend on moving away from Visual Studio so that I can develop within Linux so won't be installing VS2022 in this case but I assume it would have worked from there.

I will attempt to publish my function app created in Rider using the Azure CLI & if that proves successful I guess I'll mark that as the answer given Rider & the Azure Toolkit for Rider aren't Microsoft products, so I guess there isn't much support you can offer here.

Hopefully a future Rider update addresses this.
David Buckell 191 Reputation points

2022-04-13T18:25:42.07+00:00

Somewhat closer.
Publishing my Rider function app using the Azure CLI does successfully publish the functions.
However there appears to be an issue executing them.
With a simple HttpTrigger example, testing the function app that I created using the Azure CLI within windows returns a successful response
https://<functionapp-name>.azurewebsites.net/api/<function-name>?name=dave

But testing this endpoint for my published Rider function app I receive a 401 status code instead.

Next I'll try creating & publishing the function app within Linux using the Azure CLI to isolate if it is a Linux or Rider issue & compare the file contents of both.
David Buckell 191 Reputation points

2022-04-13T22:39:29.92+00:00

I generated a function app in linux using the azure cli & added a http trigger function.
I then did the same with rider and compared the 2.

The csproj AzureFunctionsVersion property references v3 for the cli generated function app even though the package reference for Microsoft.NET.Sdk.Functions is set to 4.0.1.
The corresponding property within the csproj generated by rider was set to v4.

The only other difference was that the generated http trigger function was declared with an async signature for the cli generated function but was not async for the rider generated function.

But both of those are irrelevant as I updated the rider project to match the cli project files and the publish was still unsuccessful in the fact that the functions were not published despite the function app being published successfully.

I attempted to publish the cli generated function app via rider and that was unsuccessful.
I attempted to publish the rider generated function app via the cli and that was successful.

So it would appear the issue lies in the way that rider publishes function apps.

As a workaround I will either choose to generate my function apps via the cli or rider, but will only publish via the cli.

However regardless of the approach I take here both http triggers result in a 401 when tested in the cloud, which appears to be an issue when compared to windows hosted function apps.

I will raise the publish issues separately with jetbrains. But there appears to be an azure related issue here too with hosting .net 6 function apps v4 within linux.
David Buckell 191 Reputation points

2022-04-13T23:42:59.213+00:00

Ok so the 401 is simply down to the auth level of the http trigger. I assume in older versions the default was anonymous & it's now set to function so requires the API key included in the request.

So believe the overall conclusion is publishing function apps from rider as first anticipated.

Not sure what can be done about this if anything.

Would be good if someone from support/the community could confirm this behaviour.

1 answer

David Buckell 191 Reputation points

2022-04-20T21:20:14.713+00:00
Confirmed by JetBrains support to be an issue within Rider.
Being addressed via this pull request that missed the 2022.1 release but should be included in the subsequent one.
https://github.com/JetBrains/azure-tools-for-intellij/pull/587

Although having read through https://learn.microsoft.com/en-gb/azure/azure-functions/create-first-function-cli-csharp?tabs=azure-cli%2Cin-process&pivots=programming-runtime-functions-v4 and the linked articles I have decided to utilise the Azure CLI going forwards for creating & publishing Azure function apps.

Created my function app via:

az functionapp create --resource-group <RESOURCE-GROUP-NAME> --consumption-plan-location <REGION-NAME> --runtime dotnet --functions-version 4 --name <FUNCTION-APP-NAME> --storage-account <STORAGE-ACCOUNT-NAME> --os-type Linux

Published my function app via:

func azure functionapp publish <FUNCTION-APP-NAME>

Also blogged my approach here: https://www.davidbuckell.com/blogs/development/azure/function-apps/creating-linux-net-6-azure-function-apps-via-the-azure-cli/, which I'll tidy up soon.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment