Azure WebJobs ServiceBus returns Exception: found 2 DNS claims in authorization context - azure

I'm trying to read a message from an Azure ServiceBus queue using an Azure WebJob but it's throwing and exception:
Unhandled Exception: System.InvalidOperationException: Found 2 DNS claims in authorization context.
I've set the correct connection strings named "AzureWebJobsServiceBus", "AzureWebJobsDashboard" and "AzureWebJobsStorage"
The WebJob Program code has been updated to use JobHostConfiguration:
class Program
{
static void Main()
{
var config = new JobHostConfiguration();
config.UseServiceBus();
var host = new JobHost(config);
host.RunAndBlock();
}
}
And the actual Job method
public class Functions
{
public async static Task ServiceBusResizeRequest(
[ServiceBusTrigger("blah")] string message,
TextWriter log
)
{
await log.WriteLineAsync("got message " + message);
}
}
I can successfully create and write to the queue via a separate console application.
But when I run the webjob application, it throws that exception.
Any ideas?
EDIT: Using .net 4.6.1

The answer marked as solution, is not the solution, it is a botched job.
The solution to use it in .Net Framework 4.6.1 is to add in the rutime block in App.config:
<AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableMultipleDNSEntriesInSANCertificate=true" />
Read this article Mitigation: X509CertificiateClaimSet.FindClaims Method
Very IMPORTANT for now Azure WebApps / WebJob etc, doesn't support 4.6.1 I will note here when (said at jan 21, 2016).
It means, that you can develop a web job application with 4.6.1, but when you push it to Azure, you can see exceptions like Job failed due to exit code -2146232576

January 29th Microsoft released version 3.1.3 of the NuGet package WindowsAzure.ServiceBus.
From the release notes:
• General: .Net 4.6.1+ compatibility fix. Fixing custom DNS IdentityVerifier so that we honor multiple DNS claims returned by WIF
Upgrading the package solved the problem for us.

As outlined in this answer above, the snippet below does the trick
<runtime>
...
<AppContextSwitchOverrides value="Switch.System.DisableMultipleDNSEntriesInSANCertificate=true" />
...
<runtime>
BUT be carefull to add it to the correct project in your solution! Add it to the project containing the Azure code and Azure references.

Microsoft released a new package (under a new name) to fix this issue. So ...
remove the Microsoft.AspNet.SignalR.ServiceBus package,
install the Microsoft.AspNet.SignalR.ServiceBus3 package instead, and
upgrade the WindowsAzure.ServiceBus package.
More info here: https://github.com/SignalR/SignalR/issues/3548#issuecomment-296326048

Downgrading from .net 4.6.1 to 4.6 seems to prevent the issue from occurring.

Today, I ran into this issue and had no idea about it. Finally, I decided to upgrade all the Azure nuget packages that I am using (including webjobs, servicebus ...) and BOOM! it WORKS. Hopefully, it will help if anyone runs into this issue in the future

For me it started failing after I updated .NET Framework from 4.5.2 to 4.7
All I did to fix it was update the Nuget Package WindowsAzure.ServiceBus to 5.2.0

Related

EventSourceException while processing event "LogVerbose"

While using EventHubTrigger Azurefunction such a ugly exception received (As below) in telemetry traces of ApplicationInsights.
AI (Internal): [Microsoft-ApplicationInsights-Core] EventSourceException while processing event "LogVerbose": System.NullReferenceException:Object reference not set to an instance of an object.
Details :
timestamp [UTC] : 2019-01-24T04:10:02.5700507Z
message : AI (Internal): [Microsoft-ApplicationInsights-Core] EventSourceException while processing event "LogVerbose": System.NullReferenceException:Object reference not set to an instance of an object.
sdkVersion: dotnet:2.8.1-22898
https://github.com/Microsoft/ApplicationInsights-dotnet/issues/973
The recommended workaround is to use 2.7.2 of Application Insights dependency.
For now, the options are:
use the same version of AppInsihgts that Functions use (or lower)
Filter out internal SDK messages. You can do this by creating and configuring telemetry processor. You can have a filter that checks if telemetry is TraceTelemetry and traceTelemetry.Context.Operation.SyntheticSource is SDKTelemetry
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.7.2" />
Otherwise there is pretty much nothing except to wait and hope that version 2.9 will contain a bugfix for this.
As I have mentioned the link in comment regarding open GitHub issue: https://github.com/Microsoft/ApplicationInsights-dotnet/issues/1029
And #Alex AIT shared a link which is an open issue related the same problem :
https://github.com/Microsoft/ApplicationInsights-dotnet/issues/973
However, I found a concrete answer with the reference of Microsoft Docs:
Application Insights for Azure Functions supported features
In summary:
According to the reference by Microsoft Docs on Supported feature on azure function V2 with Application Insight, If you want to use Application Insight then set an Application Insights version 2.7.2 rather than 2.8.0 and 2.8.1.
Some issues are responsible due to the Application Insights version: 2.8.0 and 2.8.1.
So, we should use Application Insight version 2.7.2 till the new update is not coming from Microsoft/stable version for V2.
https://learn.microsoft.com/en-us/azure/azure-monitor/app/azure-functions-supported-features
Other Exceptions faced with Application Insights 2.8.1 such as
AI (Internal): ERROR: Exception in Command Processing for EventSource Microsoft-ApplicationInsights-Core: An instance of EventSource with Guid 74af9f20-af6a-5582-9382-f21f674fb271 already exists
AI (Internal): EventSourceException while processing event "DiagnosticsEventThrottlingHasBeenResetForTheEvent": System.NullReferenceException:Object reference not set to an instance of an object.
Now, which is resolved via to degrade the Application Insights version as 2.7.2 which is actually supported to Azure function V2.

OpenIdConnectOptions Missing from .net core sample application on linux

I am trying to follow this tutorial for Azure AD authentication in a .NET core web app:
https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/aspnetcore2-2
and I get this error:
The type or namespace name 'OpenIdConnectOptions' could not be found (are you missing a using directive or an assembly reference?)
I am using Linux and have no issue getting the basic templates to generate and build, the issue appears to arise where the tutorial says to add this line:
services.Configure<OpenIdConnectOptions>(AzureADDefaults.OpenIdScheme, options =>
{
options.Authority = options.Authority + "/v2.0/";
options.TokenValidationParameters.ValidateIssuer = false;
});
I have tried adding packages (semi randomly) e.g.:
Microsoft.IdentityModel.Protocols.OpenIdConnect
Microsoft.Owin.Security.OpenIdConnect
to no avail as the error persists and I get new issues like:
Error: Package 'Microsoft.Owin 4.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project.
I am not sure if I am missing some basics with authentication and running .net core on linux, I am new to this and just trying to get the ball rolling with a working demo that actually does something :)
I have not checked on linux yet, but the nuget package you are missing should be produced by ASP.NET Core from the following project: https://github.com/aspnet/AADIntegration. Did you try to update the latest nuget package of ASP.NET Core ?
As a workaround you might want to have a look at the following branch of the sample (which still has the code which was now moved to ASP.NET Core AADIntegration) : https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master
ran into the same issue. After installing these modules, it compiled.

Azure Function fails to bind ILogger

My function is referencing an assembly that references Microsoft.Extensions.Logging.Abstractions 2.0.0. If I add a nuget reference to that version to the function's assembly, function execution fails with:
[1/25/2018 11:14:46 PM] Microsoft.Azure.WebJobs.Host: Error indexing
method 'TrainingFunction.Run'. Microsoft.Azure.WebJobs.Host: Cannot
bind parameter 'log' to type ILogger. Make sure the parameter Type is
supported by the binding. If you're using binding extensions (e.g.
ServiceBus, Timers, etc.) make sure you've called the registration
method for the extension(s) in your startup code (e.g.
config.UseServiceBus(), config.UseTimers(), etc.).
Is it possible to use the newer logger in Azure functions ?
(SDK 1.0.7)
What is probably happening is that the SDK is binding to version X of the ILogger assembly and your user code is binding to version Y. The binding engine then doesn't recognize your parameter's type as being the same since they're from different assemblies. (this can happen with any other type too).
Generally the fix is to:
See the nugget references used by the SDK
Use those existing references and don't add the same dll with a different version.
I was somehow also having the same error, but it was the package version for Microsoft.EntityFrameworkCore.SqlServer what is causing the issue.
Downgrading Microsoft.EntityFrameworkCore.SqlServer v2.2.0 to v2.1.4 did the trick.
I assume that there is a version mismatch between logging.abstractions libraries for this package.
For me, the problem was that I needed to explicitly declare the Azure Functions Version in my .csproj file.
I added <AzureFunctionsVersion>v2</AzureFunctionsVersion> after the <TargetFramework> element:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
Hope that helps someone :-)
Also binding-order could cause this failure.
Changing from parameter order ...
[FunctionName("SomeFunction")]
public static async Task Run([BlobTrigger("path", Connection = "conn")]
ILogger logger, ExecutionContext context, Stream stream, string name) {}
... to ...
[FunctionName("SomeFunction")]
public static async Task Run([BlobTrigger("path", Connection = "conn")]
Stream stream, string name, ILogger logger, ExecutionContext context) {}
... fixed my problem. (Microsoft.NET.Sdk.Functions v1.0.24)
For me, I was using NuGet package Microsoft.Extensions.Logging on a project referenced by my Azure function. Uninstalled this package and my error (this exact error) went away.
I didn't actually need the NuGet package to use ILogger in my Azure function.
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
ILogger log)
Edit: Also downgrading to Microsoft.Extensions.Http 2.1.0 worked on another occurrence of this error. If you still need the Extensions package (for IHttpClientFactory for example) it's possible to get this logging error because of an SDK version conflict with 3.1.1.
As stated by one of MS employees the cause could be:
we don't quite yet support .NET Core 2.2, but we have the work underway and should ship in January.
https://github.com/Azure/azure-functions-host/issues/3854#issuecomment-449034719
Another reason for the same error...
Somehow I ended up with a using statement referencing Microsoft.Build.Framework which has its own version of ILogger the fix is just to replace this with Microsoft.Extensions.Logging which the functions app is expecting
This will also happen when updating Azure Functions/Durable Functions from v2 to v3. You need to manually edit .csproj to resolve the ILogger reference problem.
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
...
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.2" />
</ItemGroup>
The function will continue to report a run-time module error. Then you have to try to create new Azure Function v3 project in Visual Studio to download the templates for run-time modules. More information on the procedure is provided in the official documentation: Azure Functions runtime versions overview
I had to uninstall Microsoft.Extensions.Logging nuget package from the solution.
I suddenly started getting the ILogger binding error after auto-updating my Nuget packages.
I couldn't find any explict references to ILogger extensions in my solution files. It turned out the culprit was a different extension Microsoft.Extensions.Caching.Memory that updated to v5.00 (.NET 5?). Downgrading that package to the prior version 3.1.15 fixed the error (I was originally at v3.1.4). I wonder if any v5.x extension package would trigger this issue.
What worked for me was downgrading "Microsoft.Extensions.Http" from version 5.x.x.x to "3.1.20", which implicitly downgrades "Microsoft.Extensions.Logging" to "3.1.20"
It looks like there is an implicit dependency with the version 5.x of Http library and "Microsoft.Extensions.Logging" version 5.x , and that version of logging has some issue with it.

Method not found: 'Void Lucene.Net.Store.Azure.AzureDirectory..ctor(Microsoft.WindowsAzure.Storage.CloudStorageAccount, System.String)'

I have the following solution deployed to Azure. It basically is a website to add and edit user information. It uses a Azure table storage for data access.
Recently I started adding search functionality using Lucene.net and more specifcally Lucene.Net.Store.Azure.
<package id="Lucene.Net.Store.Azure" version="3.0.5553.21100" targetFramework="net451" />
I have developed it locally against an existing Azure storage container and it works. I'm able to build the index and can query it.
I just published the new version to Azure, and it behaves differently from the local code. I now get a runtime error that it can't find a method, more specifically the constructor.
Method not found: 'Void Lucene.Net.Store.Azure.AzureDirectory..ctor(Microsoft.WindowsAzure.Storage.CloudStorageAccount, System.String)'
It is addressed (some code omitted for brevity), like this.
private AzureDirectory _azureDirectory;
CloudStorageAccount cloudAccount = CloudStorageAccount.Parse(settings.Endpoint);
_azureDirectory = new AzureDirectory(cloudAccount, "storagename");
it's from this nuget https://azuredirectory.codeplex.com/
Maybe someone can pinpoint me in the right direction.
Basically what is happening is that the version of Lucene.net.Store.Azure used by Azure is a different version than I'm using locally? Is this assumption correct, and how can I check the Azure version?
Is this because of the difference in .Net framework of the Azure server and my local development?
How can this be fixed?
any help appreciated

Missing Functions and Changes in Azure Storage SDK 7.2.1

Recently we have started upgrading our projects from ASP.NET 4.5 to ASP.NET Core and we are targeting the .NET Standard 1.6 framework. Most of the projects have been migrated but we are particularly facing issues with projects which have reference to Azure Storage SDK. Initially we were using SDK version 7.0.0, but since it was not supported in .NET Standard 1.6, we had to upgrade SDk to 7.2.1. But it seems that a lot of functions have been removed from the new version, for e.g. CloudTable.CreateQuery(). And also it seems that all the functions have been made async.
Is it an expected thing, or am I missing something here? Is there are a change or a upgrade document for all the changes that has been done? I could not find any document for all these changes.
Is it an expected thing, or am I missing something here?
Yes, this is an expected thing. We could check the CloudTable class in this article. And we could find CreateQuery function in that article. However we could not use CreateQuery function and we only could use async method. I think it is caused by the following, and this is a default behavior:
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
},
As we know that, we only could use Azure storage async method in portable library and win8. In asp.net core it imports "portable-net45+win8". So I think this is a reason. If you update your application to Asp.net core. I think you need to rewrite the Azure Storage code.

Resources