I'm new in .NET Core. I have implemented MTOM in .NET framework by adding bindings of MTOM, now I need to implement WcfCoreMtomEncoder in my .NET Core project.
I'm little bit confused as there is no web.config in .NET Core, so where can I implement MTOM? and how?
Thanks in advance.
The MtomMessageEncoderBindingElement allows .NET Core applications to communicate with WCF endpoints which support MTOM encoding.
Note: This is not a complete implementation of MTOM. It is meant as a workaround for calling existing MTOM encoded SOAP services. It consumes MTOM encoded messages, but does not perform MTOMEncoding on outbound messages. However this should be sufficent for interoperating with existing services.
You need to install the WcfCoreMtomEncoder Nuget Package: Install-Package WcfCoreMtomEncoder.
And then create a custom binding:
var encoding = new MtomMessageEncoderBindingElement(new TextMessageEncodingBindingElement());
var transport = new HttpTransportBindingElement();
var customBinding = new CustomBinding(encoding, transport);
var client = new MtomEnabledServiceClient(customBinding);
For specific steps, you can refer to this link.
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 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.
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"), ...);
Since today, I am receiving the following error message when sending a package:
Error calling Login: The request was aborted: Could not create SSL/TLS secure channel.
My code
StringBuilder authHeader = new StringBuilder(
$"{{\"Username\":\"{userId}\", \"Password\":\"" +
$"{password}\", \"IntegratorKey\":\"{IntegratorKey}\"");
authHeader.Append(
string.IsNullOrEmpty(senderEmail)
? "}}"
: $",\"SendOnBehalfOf\": \"{senderEmail}\"}}");
Configuration.Default.AddDefaultHeader(
"X-DocuSign-Authentication",
authHeader.ToString());
AuthenticationApi api = new AuthenticationApi();
return api.Login();
Coincidently, today is THE day where TLS1.0 was disables on the demo site of DocuSign. (source)
While I was aware of that, my application uses the .NET 4.7 framework which will uses TLS1.2 by default. Hence, it should not be a problem
As I use the DocuSign NuGet package found here, I looked in the source code and it uses .NET 4.5 (which uses TLS1.0 unless told otherwise)
I understand that I could implement this solution but, shouldn't it work since my application uses .NET 4.7 ?
TLS 1.1 or above is required for all DocuSign APIs and endpoints.
All our libraries now support TLS 1.2 including the the DocuSign eSign C# Nuget package.
See here - https://support.docusign.com/en/articles/End-of-TLS-1-0-and-weak-cipher-support
I'm trying to send an email using SendGrid API with an API Key I already have.
The problem is: I have to do this from an old .net application, whose asp.net framework version is 3.5 (and changing framework version is not an option)
I'm failing to find useful information on how to achieve it. The only code I found makes use of SendGrid csharp libraries, and these do not support asp.net framework 3.5
This is the code sample I found here, but I cannot make this work from my .net 3.5 web app:
// using SendGrid's C# Library - https://github.com/sendgrid/sendgrid-csharp
using System.Net.Http;
using System.Net.Mail;
var myMessage = new SendGrid.SendGridMessage();
myMessage.AddTo("test#sendgrid.com");
myMessage.From = new MailAddress("you#youremail.com", "First Last");
myMessage.Subject = "Sending with SendGrid is Fun";
myMessage.Text = "and easy to do anywhere, even with C#";
var transportWeb = new SendGrid.Web("SENDGRID_APIKEY");
transportWeb.DeliverAsync(myMessage);
// NOTE: If you're developing a Console Application, use the following so that the API call has time to complete
// transportWeb.DeliverAsync(myMessage).Wait();
Any ideas?
You have a couple of options. The SendGrid API uses the HttpClient class to make the requests and this requires the .NET 4+ dependency.
You could try implementing your own implementation using RestSharp, this is compatible with .NET 3.5 and the SendGrid API uses an interface you can implement. It would just need to be adjusted from the source code on github.
Use the .Net SMTP classes to send your emails and configure as per the guidelines in the SendGrid documentation.
Proxy the requests via another WebAPI that is running .NET 4+ and simplify what is required to make these calls by implementing your own API. Use something like the WebClient class or RestSharp to make the calls.
** Scrap that, option 1 is harder than it looked **
That the ISendGridClient is a bit of a weird example. It used the implementation inside of the interface for some parameters. Looks like 2 and 3 are good options!