I've been searching around and have not been able to find any concrete examples using gRPC without proto buffers in C#. Does anyone have a URL or example? I've found the "gRPC + JSON" blog post but that is for Java and not easily applicable to c#.
Thanks in advance
Was looking for the same thing and found MagicOnion (injected as service into existing ASP.NET app)
from README.md:
This framework is based on gRPC, which is a fast and compact binary
network transport for HTTP/2. However, unlike plain gRPC, it treats C#
interfaces as a protocol schema, enabling seamless code sharing
between C# projects without .proto (Protocol Buffers IDL).
Related
I am looking out for developing a C# application which posts message to a ebMS3 platform using AS4. I am new to this area. Could anyone please help? Is there any third party libraries to do this easily? If not, how we post messages using AS4 from a c# solution.
I have just implemented our own AS4 solution, and it is hard task to accomplish. Especially because .NET does not support SOAP with attachments out of the box. And there is a lot background knowledge you need to know about - all the different specifications AS4 is based on. I have not been able to find an AS4 API written in .NET without it being a standalone solution as well...
First thing is to understand AS4, and a good place to start is this blog:
https://www.codit.eu/blog/2016/02/03/as4-for-dummies-part-ii-messaging-overview/
And then you will have to understand most of the EBMS3 specification:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html
That being said - it is not impossible.
I have been looking at the AS4.NET framework as Sander talks about, and it is well-written and a very good starting point for exchanging AS4 messages. I have used it as a test-endpoint.
So unless you need to incorporate AS4 directly into an existing product (which we needed to), I can only recommend using AS4.NET.
AS4.NET is also open source (and e-SENS profile conformant), so you can have a look at their code-base and let you inspire by the hard parts in AS4.
For the MIME parts I can recommend Mimekit: https://github.com/jstedfast/MimeKit
And for some of the encryption/signing stuff Bouncycastle is great: http://www.bouncycastle.org/csharp/
Not sure whether it can be used as a library, but for a project within the European Commission an open source .NET based AS4 implementation was developed. You can find it here in the EC's code repository. I don't know if there is any support on this, so if that is important you should probably consider another implementation. A list of solutions tested by the EC for conformance with their own profile of AS4 is available here (or if that link doesn't work by searching for "as4 conformance tested implementations")
Note that most are standalone applications which you connect to for executing the AS4 message exchange. Most offer different integration options, so you should be able to integrate it into your solution.
I've found all kinds of information over the web, but none yet that can categorically answer the question.
This article on the MSDN is an argument against the RPC protocol, but doesn't specifically say it isn't supported.
This article demonstrates it is possible to extend the web service by hand. I'd prefer to avoid that, as it defeats the purpose of using a WSDL file.
There are sections of the MSDN with classes for dealing with RPC based SOAP messages in the framework, such as System.Web.Services.Protocols.SoapRpcMethodAttribute.
The service I need to connect to is using the RPC/literal protocol and there is no chance of changing that.
The Service Stub generating tool (wsdl.exe) will not accept RPC/literal WSDL files.
I really need to use RPC/literal in my .NET 2.0 application. Is it possible?
Yes, it`s possible. You can do RPC with .NET Remoting clickme. However, this is considered a legacy technology and it is not used anymore. Please take a look at .NET WCF if you want to do some SOAP RPC.
We currently using OpenFire as our XMPP server and using SoapBox C# library to implement XMPP client. But now we want to move to secure XMPP over HTTP (BOSH) so users can instant chat on different network. I've search for days but could not find any C# examples to implement XMPP over HTTP. Our application is in C# and so I need to find a C# or .NET solution, ideally keep SoapBox if possible. Anyone has any examples or pointers to share?
Just use an HTTPS URL for polling from any library that supports BOSH. Although why you'd use BOSH from a real programming language other than to cut through a particularly virulent firewall, I don't know.
SoapBox mentions that "SoapBox Server,BOSH implementation works well with JSJaC, the most popular XMPP BOSH JavaScript library" on their official website. Even though, they didn't mention anything about BOSH implementation using SoapBox library.
But, MatriX C# library supports http-bind(bosh) implementation. MatriX is a SDK/library for XMPP, written in managed C# dedicated to .NET and Silverlight technologies. But, MatriX is a commercial one.
I'm also looking the sample source for http-bind(bosh) implementation using SoapBox C# library. If anyone found please, share the link in here.
How to create Net.TCP WCF binding for\using SOAP 1.1? Is it posible?
If yes.
What do I need?
MSDN if there is any help on this.
Open Source Libs/wrappers.
Tutorials and blog articles on How to do it.
If no: I need know where did you get the information from (link to MSDN or other official WCF information resource).
SOAP is an XML format.
Net tcpbinding is a binary format.
They are two different things.
What you can do is to expose a service with 2 endpoints, one SOAP and one binary.
I think if you need a SOAP/TCP protocol (SOAP-based or XML Infoset-based) and you want to keep your solution open for interoperability like WCF - WSIT (Java) you need to use a tool like WCF-Xtensions from Noemax.
http://www.noemax.com/global/press_releases/september_24_2007.html
Oracle has a SOAP/TCP recommendation, but I don’t really see a lot of out of the box components, etc which implement it. It is a shame because it is pretty fast and works on both Java and .NET
http://java.sun.com/webservices/reference/apis-docs/soap-tcp-v1.0.pdf
I am not aware of free components. If you know any please comment on my post. I am working on a WCF - WSIT (Metro) integration project and WS-Http turned out to be very slow.
I think TCP binding also uses SOAP protocol, but within SOAP message it uses binary encoding instead of text. For more clarification please see this article:
http://forums.asp.net/t/1864812.aspx/1
MSDN:
Chapter 7: Message and Transport Security
We are trying to come up with our client and server standard and there is a big debate. One school of thought is C# client and java servers using some type of proprietary messsage library to share data objects (think XML like structure . .)
The issue with this model is that there is lots of code that needs to be duplicated (validation, parsing) that could simply be reused if you went with C# on the server as well. If there is a big push to use linux machine then wouldn't mono support your goal . .
anyone else have this dilemma?
There are frameworks for this. ICE (ZeroC), "protocol buffers", etc.
For example, my protocol buffers implementation (protobuf-net) works on mono, MS .NET, CF, Silverlight etc - and the binary format is compatible with a range of languages (java, etc). If you start from a .proto (a bespoke definition language), you can use it to generate the object layer in each language you need.
In any case I would use Protocol Buffers or something else defined in a language neutral form for the comms, to ensure that you aren't restricted in future.
Once you've done that you can start with C# on Mono. And then if that proves to be unworkable, you can switch to a different language.
I would suggest you use some old-but-good standard for transferring data between the two, SOAP and XML-RPC come to mind as examples for this. If either of these is possible or feasible, you may want to try JSON or writing your own XML format. Protocol buffers has been mentioned around lately quite a lot but I haven't looked into it so I really can't say anything about it.
I would try to keep the client and the server the same runtime (Java or CLR). We have had plenty of success using a mix of Mono and .Net client/Server.