I am trying to connect a C# .NET 4.7 application as a client to my Azure SignalR service. I am using the ASP.NET version of the SignalR client library, NOT the ASP.NET CORE version.
I have code set up like this:
var serviceUtils = new ServiceUtils(ConfigurationManager.ConnectionStrings["Azure:SignalR:ConnectionString"].ConnectionString);
var url = $"{utils.Endpoint}/client/";
_connection = new HubConnection(url, $"?hub={hubName}")
{
ConnectionToken = serviceUtils.GenerateAccessToken(url, userId)
};
IHubProxy proxy = _connection.CreateHubProxy(hubName);
await _connection.Start().ConfigureAwait(false);
However, this does not work. I get back a 'StatusCode: 401, ReasonPhrase: 'Unauthorized'' when _connection.Start() throws an exception.
The "ServiceUtils" token generation is pulled from the example here:
https://github.com/vavjeeva/AzureSignalRConsoleApp/blob/master/AzureSignalRConsoleApp.Utils/ServiceUtils.cs
Interestingly, I have implemented the same logic in a basic C# .Net Core console app, using the .Net Core version of the library, and it actually does work, using the same connection string. The difference is I am using the HubConnectionBuilder, which does not exist in the asp.net version of the library. My assumption is that the two are authenticating in different ways.
How do I get this sort of functionality working in this version of the library? I want my service application, as a client, to be able to invoke hubu methods via the Azure SignalR Service.
Related
Hi i am using TLSharp latest version is 0.1.0.574 and when i call var hash = await client.SendCodeRequestAsync("<my_phone>"); i got error System.InvalidOperationException: 'UPDATE_APP_TO_LOGIN' anyone know how to fix it
My code
TelegramClient client = new TelegramClient(appid, "apihash",null,"session",null,DataCenterIPVersion.OnlyIPv4);
await client.ConnectAsync();
var hash = await client.SendCodeRequestAsync("<my_phone>");
string code = "";
await client.SignUpAsync("<my_phone>", hash, code, "<fist_name>", "last_name");
The error "UPDATE_APP_TO_LOGIN" happens because your Telegram Client/Library uses an obsolete API layer.
As stated on its project page, TLSharp is no longer maintained and will not be updated to fix this.
You should switch to WTelegramClient which is:
offering up-to-date API (latest layer)
safer (latest MTProto v2 implementation and many security checks)
feature-complete (covers all API methods, handling of updates, multiple-DC connections)
easy-to-use (API calls are direct methods with fully documented parameters in VS)
designed for .NET 5.0+, but also available for .NET Standard 2.0 (.NET Framework 4.6.1+ & .NET Core 2.0+)
Available on Nuget. ReadMe/Github is here.
I need to migrate an application (that is consuming a Jira API) to .NET Core 3.1
var JiraClient = Atlassian.Jira.Jira.CreateRestClient("url", "username", "password");
var JiraLogs = JiraClient.Issues.GetChangeLogsAsync("key").Result;
The REST client works fine both on .NET Framework 4.8 and .NET Core 2.2, but raises an exception on .NET Core 3.1 ... is returning the whole PAC file instead of resolving for the proxy.
//////////////////////////////////////////////////////////////////////
// This PAC was web generated: 2020-05-23 10:50:39 AM
//////////////////////////////////////////////////////////////////////
var pacname = "hou9-hpx.pac";
var pacdate = "2020-05-23 10:50:39 AM";
function FindProxyForURL(url, host)
{
QNETPROXY = "PROXY proxy-ccy.company.net:8080; PROXY web-proxy.company.net:8080";
HPROXY1 = "PROXY proxy-ccy.company.net:8080";
}
Why does this happens?
How should I configure the proxy? (I tried setting up the proxy explicitly as shown below, but the result still fails)
RestClient.Settings.Proxy = new WebProxy("proxy-ccy.company.net", 8080);
Note: A colleage told me he vaguely remembers that .Net Core implementation of http stack is not based on windows on IE libraries and therefore javascript files are not supported (pac file), not sure if this is true, but it seems like the most reasonable option so far, still not sure how to fix it though.
According to the Azure DevOps Services REST API Reference, the request URI has the following format:
https://{instance}[/{team-project}]/_apis[/{area}]/{resource}?api-version={version}
Regarding the api-version:
Every API request should include an api-version to avoid having your app or service break as APIs evolve.
I started using the .NET client libraries for Azure DevOps Services (and TFS) to manage dashboards programmatically.
I am able to connect to Azure DevOps using a Personal Access Token:
var credential = new VssBasicCredential(string.Empty, "PersonalAccessToken");
using (VssConnection connection = new VssConnection(new Uri("...."), credential))
using (var client = connection.GetClient<DashboardHttpClient>())
{
// ...
}
How can I specify the API version? Does it still make sense to do it, when using the .NET client libraries?
The API version is decided by the client libraries. You can confirm this by disassembling them (e.g. using ILSpy).
For example, in the current stable release of Microsoft.TeamFoundationServer.Client, DashboardHttpClientBase has a CreateDashboardAsnc method that makes the following call:
this.SendAsync<Dashboard>(..., new ApiResourceVersion("4.1-preview.2"), ...);
I am working on an ASP.Net Core web app and I try to connect it via an Azure Mobile Backend.
The backend is working well with other Windows Desktop applications.
Also the backend was working well till now with ASP.Net Core v2.0.
Yesterday I installed the ASP.Net Core 2.1 SDK and I updated the Microsoft.AspNetCore.All nuget package from 2.0 to 2.1.2 and since then I am receiving the following exception:
MobileServiceInvalidOperationException - "The server did not provide a response with the expected content."
Can you tell me any solution to solve this issue?
Also the backend was working well till now with ASP.Net Core v2.0. Yesterday I installed the ASP.Net Core 2.1 SDK and I updated the Microsoft.AspNetCore.All nuget package from 2.0 to 2.1.2 and since then I am receiving the following exception: MobileServiceInvalidOperationException - "The server did not provide a response with the expected content."
According to your description, your Azure Mobile Backend could work as expected with ASP.Net Core v2.0. AFAIK, mobile backend just provides a simple way for you to expose your Table/API endpoints. Moreover, how did your web app connect with mobile backend, using HttpClient or Azure Mobile Client SDK?
For a simple way to troubleshoot this issue, you could Enable diagnostics logging for your Azure Mobile App to retrieve the detailed error message to narrow this issue, details you could follow here.
I have the same issue but no solution. I traced it down to the following line of code in MobileServiceHttpClient code in the SendRequestAsync(...) function.
// If there was supposed to be response content and there was not, throw
if (ensureResponseContent)
{
long? contentLength = null;
if (response.Content != null)
{
contentLength = response.Content.Headers.ContentLength;
}
if (contentLength == null || contentLength <= 0)
{
throw new MobileServiceInvalidOperationException("The server did not provide a response with the expected content.", request, response);
}
}
Looking at the response.Content.Headers.ContentLength it is null. Running the app as a 2.0 Core project, the value is filled in correctly. What is is strange is that the content is there.
If you drill into the private members some of them are set correctly.
catch (MobileServiceInvalidOperationException msioe)
{
//content will contain the correct json but the ContentLenth is null!?!
string content = await msioe.Response.Content.ReadAsStringAsync();
}
It is a 2.1 Core issue. Hopefully they fix it.
I'm developing my application on .net core framework which uses the following code to push messages to queue which is to be received by a webjob.
topicClient = new TopicClient(connection)
Message message = new Message(utf8encodedtext)
await topicClient.SendAsync(message);
BrokeredMessage support(Microsoft.ServiceBus namespace) is not yet there for .net core. I'm using the following code for Webjob
public static void ProcessQueueMessage([ServiceBusTrigger("topicgeneric","subscription")] BrokeredMessage message, TextWriter log)
{
log.WriteLine(message.Label);
}
}
With this setup I'm able to receive messages. However the web job doesn't support Microsoft.Azure.ServiceBus.Message. Is there any workaround to use Messages instead of BrokeredMessage are there any tradeoffs/compatibility issue/data loss. I want to re-write my webjob in .net core framework. Will it still work (currently its written in .net framework) as Microsoft.ServiceBus nuget is not supported in .net core
WebJobs SDK version 2.x is using the old service bus client with BrokeredMessage class.
WebJobs SDK version 3.x is using the new .NET Standard service bus client (Microsoft.Azure.ServiceBus with Message class). It's still in preview though, 3.0.0-beta4 is the last release is of today.
So, you'd have to pick the matching versions: either use all old or all new.
BrokeredMessage support(Microsoft.ServiceBus namespace) is not yet there for .net core
BrokeredMessage will never appear in the new SDK, it's been replaced by Message. They are not compatible to each other, so various issues are possible.