I'm trying to return JArray object from Azure Function of HttpTrigger type:
JArray a = JArray.Parse("[{\"reportId\": \"1111\",\"reportName\": \"AAAA\"}]");
return req.CreateResponse(HttpStatusCode.OK, a);
However, for some reason, the response body returned as:
[{"reportId":[],"reportName":[]}]
What am I doing wrong?
I can repro the issue with Newtonsoft.Json version 10+. If downgrade is possible, please have a try to use Newtonsoft.Json version 9.0.1. Then it works correctly on my side. We also could rasie an issue to Azure function team.
Azure Functions requires that you use Newtonsoft.Json version 9.0.1, as we don't support binding redirects. Your code is running in the same process as the Functions host, which means you have the same binding redirects.
We're improving the Visual Studio experience so that it's clear that there's a strict upper bound on the dependency.
Related
I'm trying to use the Graph SDK and NuGet 5.0.0-preview16 and forwarding the example it says to use Request method in example
var users = await graphClient.Users.Request().GetAsync();
but I have an error in the code:
'UsersRequestBuilder' does not contain a definition for 'Request' and
no accessible extension method 'Request' accepting a first argument of
type 'UsersRequestBuilder' could be found (are you missing a using
directive or an assembly reference?
Since C# SDK V5 Request method is removed and you can call directly GetAsync method. But V5 is still in preview and it's better to use latest V4 version.
var users = await graphClient.Users.GetAsync();
Upgrade guide can be found here.
Fixed: I changed Microsoft.Graph on NuGet from 5.0.0-preview16 to 4.47.0
Getting Keyword not supported: 'authentication' error while trying to connect an azure DB through 'Active Directory Integrated' option in .NET core 2.1 project.
Note: I am using EF core to connect the Data source.
TL;DR
As called out by #Aamir Mulla in the comments, this has officially been added since Version 2.0.0
UPDATE - 16/08/2019
Active Directory Password Authentication has now been added for .NET Core in Microsoft.Data.SqlClient 1.0.19221.1-Preview
Unfortunately, the authentication keyword is not yet fully supported in .NET Core. Here is an issue which discusses this.
But .NET Core 2.2 has added some support for this use case as mentioned in this comment. The basic idea is to get the access token by any means (ADAL, REST, etc.) and set SqlConnection.AccessToken to it.
As for using this with EF Core, there's a good discussion about this in this github issue and in particular the comment by mgolois provides a simple implementation to the solution that cbriaball mentions in the thread.
Here is the same for reference
Note that this sample is using the Microsoft.Azure.Services.AppAuthentication library
// DB Context Class
public class SampleDbContext : DbContext
{
public SampleDbContext(DbContextOptions<TeamsDbContext> options) : base(options)
{
var conn = (System.Data.SqlClient.SqlConnection)this.Database.GetDbConnection();
conn.AccessToken = (new AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.windows.net/").Result;
}
}
// Startup.cs
services.AddDbContext<SampleDbContext>(options =>
{
options.UseSqlServer(<Connection String>);
});
The connection string would be something like this
Server=tcp:<server_name>.database.windows.net,1433;Database=<db_name>;
If you're still having the issue, make sure you have
Microsoft.Data.SqlClient package installed, not System.Data.SqlClient. They both contain SqlConnection class, switching the package for the first one fixed the issue for me.
As of today 7/18/2022 , I am still getting the issue from Azure when trying to use it through ManagedIdentity.
The microsoft doc at https://learn.microsoft.com/en-us/azure/app-service/tutorial-connect-msi-sql-database?tabs=windowsclient%2Cefcore%2Cdotnetcore
to use managed identity we need to use the connection string in this format!
"Server=tcp:.database.windows.net;Authentication=Active Directory Default; Database=;"
But looks like Azure is not liking it!
However, adding the access token helped!
var connectionString =
"Server=tcp:yourazuresqlservername.database.windows.net; Database=yourazuresqldbname;";
var con = new SqlConnection(connectionString);
//And then
con.AccessToken = (new AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.windows.net/").Result;
con.Open();
//Do sql tasks
con.Close();
I'm using the package azure-sb to send a message to an Azure Service Bus topic. My problem is that the constructor expects a key for a connection string for example
azuresb.createServiceBusService(KEY_NAME)
Is it possible to provide the connection string itself instead of a KEY_NAME?
Yes, you can. From the documentation of this package, you do need to pass the connection string.
var connStr = process.argv[2] || process.env.CONNECTION_STRING;
var sbService = azure.createServiceBusService(connStr);
Microsoft Azure SDK for Node.js - Gallery https://www.npmjs.com/package/azure-sb
Also, azuresb seems an older SDKs. If you use Azure SDK for Node.js, here is how you can pass the connection string (quite similar!)
var serviceBusService = azure.createServiceBusService(connectionString)
You might have found the answer already... adding it here if someone else visits your question in future. :)
As mentioned in the other answers, you can pass the connection string. Your code seems to be using the older azure-sb library.
I'd recommend using the latest #azure/service-bus library which is based on AMQP protocol and is more performant.
I know this is a late reply, but just in case someone is running into issues with the older service-bus node SDK and landed here, refer to the links below.
The latest version 7.0.0 of #azure/service-bus has been released recently.
#azure/service-bus - 7.0.0
Samples for 7.0.0
Guide to migrate from #azure/service-bus v1 to v7
Currently using RestSharp V106.1.0 as well a v2.1.8
While attempting to integrate docusign with our application I received an error off of the loginAPI:
string accountId = loginApi(username, password, integratorKey);
Receiving this error
{"Method not found: 'RestSharp.IRestRequest RestSharp.RestRequest.AddFile(System.String, System.Action`1, System.String, System.String)'."}
I have verified all of the parameters have the correct value and I was able to recreate a working API usage in a brand new project without prior packages installed. This leads me to think it is the version of RestSharp that is giving me this issue.Based on research about others having this issue it was an issue of the library change within updates.
Is there a specific version that is required as the dependancies for Docusign Package in visual studio doesn't mention a Restsharp version requirement?
Thank you in advance.
MyLibrary.dll
public class Person
{
[JsonProperty("name")]
public string Name { get; set; }
public static async Task Save(Person person)
{
DocumentClient client = CreateDocumentClient();
await client.OpenAsync();
await client.CreateDocumentAsync(CreateDocumentCollectionUri(), person);
}
}
MyFunctionApp.dll
public class SimpleHttpTrigger
{
public static async Task Run(HttpRequestMessage req)
{
Person bob = new Person() { Name = "Bob" };
await Person.Save(bob);
}
}
MyLibrary depends on:
Newtonsoft.Json 10.0.2
Microsoft.Azure.Documents.Client 1.13.1
And MyFunctionApp depends on MyLibrary.
The issue observed in this example is that the JsonProperty attribute is ignored when SimpleHttpTrigger.Run is called by the Azure Function CLI. SimpleHttpTrigger behaves as expected when called directly from a console app.
The issue can be resolved by changing MyLibrary's dependencies to match the versions currently used by the Azure Functions CLI:
Newtonsoft.Json 9.0.1
Microsoft.Azure.Documents.Client 1.11.4
It appears that Azure Function CLI ignores libraries in MyFunctionApp/bin when it has its own version of the library (found in node_modules/azure-functions-cli/bin). In this small example it's fine to match the dependencies but it isn't feasible when MyFunctionApp has a much larger dependency.
Is my understanding of this behaviour correct?
Is there any way to specify which version of these libraries to use in precompiled functions? I believe that one could get this behaviour in scripted functions by putting the dependencies inside the function's bin folder.
Update
My assumptions about the cause of this behaviour appear to be incorrect.
The newer versions of the Newtonsoft.Json and Microsoft.Azure.Documents.Client assemblies are in fact loaded alongside the Azure Function CLI's automatically loaded assemblies.
Which makes me even more confused as SimpleHttpTrigger.Run still behaves differently when called directly from a console app than it does when called by the Azure function host.
Any ideas what's going on? Possibly something stupid on my part.
Update 2
It looks like two different versions of the Newtonsoft.Json are used, whichever way the assemblies are loaded:
MyLibrary uses Newtonsoft.Json 10.0.2 as intended, but its dependency, Microsoft.Azure.Documents.Client 1.13.1, uses Newtonsoft.Json 9.0.1
Which might explain the incompatibility of the JsonProperty attribute.
Possibly? Please help, I'm very confused!
Basically, you are correct about the diagnosis of the problem.
This is an open issue with Azure Functions.
I stumbled on this myself and sympathize with your frustration.
Until the issue is solved, you must use the same major version of all the dependencies you happen to share with the implementation of Azure Functions.
Here is the list of Azure Functions dependencies : https://github.com/Azure/azure-webjobs-sdk-script/blob/dev/src/WebJobs.Script/packages.config
Open issues to track:
https://github.com/Azure/azure-webjobs-sdk-script/issues/573
https://github.com/Azure/azure-webjobs-sdk-script/issues/1311