I have started to get my hands dirty on azure function. I am trying to implement this example in .net 7.0. In the azure function list, I was unable to find "Durable Functions Orchestration" option, but I went ahead and started copy-pasting from the link. Right now, I am stuck on the last piece of the code. Please help me out, what shall be done here. Screenshot attached
.NET 7 is not yet released and for .NET 7 Isolated, below are the available Function Triggers and Durable Functions did not come yet, still in beta:
Can you provide any link for your claim ?
I have found 3 references. One is the PlaygokidsTech's article given by Silent user where the article explains key changes in .NET 7 Isolated worker project in the context of Durable Functions.
And the second one is Azure Functions Tech Community Update Doc and the other is .NET 7 Azure Durable Functions Conference Link
Related
I've recently switched jobs from a AWS shop to an Azure shop, both using dotnet. AWS publishes Amazon.Lambda.AspNetCoreServer, which is a magic Nuget package that allows you to write a plain ol' ASP.NET core Web API and deploy it as into a lambda with only a few lines on config. I really loved this pattern because it allows developers to just write a normal web api without having the host runtime leak into their coding.
Does anything like this exist in Azure? Even something that is community supported? Or is there some any way to achieve something like this in Azure Functions?
Unfortunately there is no simple way to do that since Azure function format is a bit different.
[FunctionName(nameof(GetAll))]
public IActionResult GetAll([HttpTrigger("get", Route = "entity")]HttpRequest request)
Then it will generate json with meta data for AF.
If you wish to host pure .net core without any changes I would look into Containers option
PS0: Theoretically it would be possible to do it with little bit of reflection. For instance you create project with all your Asp.Net core apis, which you can use in asp.net core hosting. Then you write tool which grabs your dll and using reflection you find all actions in your controllers and generate code for AF
PS1: Have a look https://github.com/tntwist/NL.Serverless.AspNetCore
I am using SAP Cloud SDK (Java flavour) to create an extension application of SuccessFactors.
I sadly discovered that the Jenkins pipeline does not allow me to use any other service than the ones listed here: SCN Blog (scroll to the Appendix).
This does not make so much sense to me, as now the SDK can be used - and it is sponsored to be used by SAP - also with SaaS in its ecosystem, SuccessFactors being one of them.
Any hint? Can this check be somehow "bypassed"?
Thanks,
Roberto.
Please note that the blog post is quite old, have you verified your assumption that it does not work with SuccessFactors API?
Nonetheless, we recently introduced a configuration option which allows you to disable certain checks, cf https://github.com/SAP/cloud-s4-sdk-pipeline/blob/master/configuration.md#s4sdkqualitychecks
checkServices is what you would want to disable in your scenario.
As stated by Florian in the comment and following the Project Piper documentation, parameters "checkServices" and "customODataServices" can be used to customize the behavior of the pipeline when running upon a non-Business Hub API.
"checkServices: false" will completely deactivated the check, whereas "customODataServices: [ yourApiName ]" will skip the check just for the specified services.
I'm trying to wrap my head around how we're supposed to build Azure functions.
I love the idea of building serverless, compact, single-function apps that respond to events.
Here are the problems I'm running into:
I have nice class libraries built in .NET Standard 2 that handle all my "backend needs" namely handling CRUD ops with Cosmos Db, Azure Table Storage, Azure SQL, Redis, Azure Storage. No matter what I did, I couldn't integrate these class libraries into an Azure Functions project. More details below.
Also, getting dependency injection in Azure Functions project has proven to be quite a task -- especially with my class libraries mentioned above.
At this point, the only option I'm seeing is to "copy and paste" code into a new Azure Functions project and use it without any DI.
This seems to go against "best practices". So what's the solution other than either to create monolithic code or wait till Azure Functions support .NET Core and DI.
I thought I could use my .NET Standard class libraries from a regular Azure Functions project targeting .NET Framework. After all, the idea of .NET Standard is to "standardize" things. I opened a couple of posts here on SO. I'm providing the links so that you can see the issues I've run into:
Using .NET Core 2.0 Libraries in WebJob Targeting .NET Framework 4.7
No parameterless constructor error in WebJobs with .NET Core and Ninject
P.S. My previous posts are referring to WebJobs. That was plan B approach because WebJobs seem half a step ahead of Azure Functions when it comes to supporting things like .NET Core and DI. Ultimately, I'd like to build a few Azure Functions that can use my class libraries built in .NET Standard 2.
Also, my previous posts mention that my class libraries target .NET Core 2.0. Since then I converted them to .NET Standard 2 which didn't really take much at all. I did this so that I truly conform to .NET Standard 2.
One issue is that Visual Studio has an outdated version of the Functions Core tools. Until this is resolved, you can work around in the following way:
Install the latest via npm by running npm install -g azure-functions-core-tools
In your Function App in VS, go to the Properties
Go to Debug, and click New... under Profile
Name the new Profile something like FunctionsNpm
Set the executable to (replace [YourUserName]): C:\Users\[YourUserName]\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
Set the arguments to host start
Set the working directory to $(TargetDir)
In toolbar, look for the green triangle icon to change your current Profile to the one you just created:
Now when you run from VS, you'll be using the npm tools instead of the older one that come with the VS package.
.NET Standard 2 support is on its way, see this github issue.
I'm designing a new architecture in Azure. It's a multi-tenant SaaS application with an ASP.NET MVC front end and some application specific data in blob storage. I need to perform some background processing on this application data at certain points. This is currently only possible using some legacy C++ code (I can't realistically rewrite this in C#).
One thought I had was to push any background jobs onto a queue and use Azure functions to service the queue as and when a job gets pushed onto it. The sticking point is the native code. I can certainly expose methods in the native code that C# can p/invoke, but can Azure functions call onto native DLLs and if so is this a sensible approach?
The code does run in a sandbox, but this approach should work. (you may want to consider exposing the relevant API in a managed assembly that would in turn be consumed by your function).
Whether you'll run into limitations with the sandbox is dependent on what your code is doing, but you can learn more about the sandbox and its restrictions here: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
I hope this helps!
mfcu100.dll likely depends on some other DLL inside the VC++ 2010 Redist
Most probably msvcr100.dll and msvcp100.dll.
If you include all the dependency DLLs along with your native binary, it should work.
The Azure Storage client was recently updated to version 2.0, and I haven't found any API that returns Task.
How can I use TPL with Table Storage? .. Blob or Queue?
For your reference the new API has an example here for Table Storage.
Looking through some of the source under https://github.com/WindowsAzure/azure-sdk-for-net/ it appears that they haven't had a chance to add the Task versions yet (seems odd since it specifically mentions targeting .NET 4), but the operations appear to have the Begin* and End* versions available, so you could use the FromAsync method to wrap each pair in a task for easier consumption.
Does seem like an odd omission AFAICT, though.