Is anybody familiar with setting up WCF-nettcp adapters for BTS?
When I create a WCF-netTcp adapter for a Receive location, I am unsure how/when BTS will open up port 808 to listen on the address URI specified. It appears to only happen if I restart the entire BizTalk application. If it closes for some reason, I do not see any way of reconfiguring and reopening the port.
Furthermore, since that is only the net.tcp binding, there is no mex endpoint exposed. I believe client applications that wish to use that exposed WCF service needs mex metadata initially. Accessing that endpoint direct from a Visual Studio project would just yield
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.
Cannot tell for such how to properly expose a mex endpoint to the service. the BizTalk WCF Service Publishing Wizard is confusing me; I cannot get it to reference the WCF adapter/Receive location I setup. I find no document that teaches what one ought to do for netTcp services; it is all about Http.
Funny, it took the walkthrough about publshing Net-Msmq WCF service to nudge me thinking how the WCF Service Publishing Wizard really works.
The issue is this: When I manually created the WCF-netTcp Receive location, it has its endpoint URI e.g. net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. When selecting the option to publish just an mex endpoint in the WCF Service Publishing Wizard, it will eventually ask for the WCF Service Location, which i confused to be the actual service location. Since it would accept nothing but Http URLs, it appeared to only support Http-based WCF endpoints.
But for that textbox, one is supposed to place the Http URL that for just the mex endpoint, not the actual net.tcp WCF endpoint. That is the location in IIS where the wizard will create the necessary meta-data files. Once finished, that location, hosting a mex endpoint will inform clients of the real service located at the net.tcp endpoint.
Related
suppose i have developed a WCF service with one mex endpoint. now i like to know how can i secure the mex endpoint means that if anyone know my mex endpoint address then that user may not be able to add my mex endpoint address from their VS IDE to create proxy. if user try to do so then windows auth login dialog comes.
now the question is how then any out side user will be able to call my wcf service. i will distribute my service dll or proxy class related *.cs files or WSDL. so user can add that dll or add those proxy related .cs file or add wsdl to their project to create proxy just to call & consume my service. i am not advance developer so i am not being able to understand how to develop this kind of secure wcf service where user can not add my mex endpoint.
so just guide me with little wcf sample code & config example from where i can understand what i need to to meet my requirement. thanks
This topic looks helpful
https://msdn.microsoft.com/en-us/library/aa395212%28v=vs.110%29.aspx
Initially, one would think one would just change the HTTP to HTTPS but according to the article apparently you lose some degree of freedom in configuration
If you use the mexHttpsBinding your metadata endpoint will be secure, but there is no way to modify the binding settings.
I'm having an issue with a net.tcp WCF windows service int .NET 4.0 where it looks like my mex for a particular endpoint is too large. There is no problem at all connecting directly to the endpoint. I created a WCF RoutingService to allow someone outside our private network to connect to my internal WCF service. Getting the mex information through the RoutingService fails.
My WCF service has about 7 endpoints, and the WCF RoutingService is routing all of them, but only the large one (with 17 methods) is having the problem.
I found this link below which explains how to fix the problem when failing to connect directly to the mex endpoint
http://blogs.msdn.com/b/distributedservices/archive/2009/05/07/too-many-operations-or-methods-in-wcf-service-causes-the-metadataexchange-fail.aspx
But it talks about creating an endpoint in svcutil.exe.config with a contract of IMetadataExchange. The RoutingService endpoint I'm having a problem with is using the contract System.ServiceModel.Routing.IRequestReplyRouter, so I don't know if I need to configure the svcutil.exe.config file slightly differently. I've tried all sorts of combinations but couldn't get anything to work. I'm not even sure where I need to put the svcutil.exe.config file for the RoutingService WCF service to pick it up, or even if it needs one.
Does anybody know of a better solution, or a link which might provide help for when a RoutingService is involved?
I've been trying to have my Silverlight application work with a WCF net.tcp binding the whole day and couldn't make it, even though it seems to me I've done everything right, including after some googling...
I had a WCF service with a basicHttpBinding endpoint which worked perfectly, and as my WCF service and my Silverlight application are on the same network, told myself "why not trying something else than HTTP ?"
So I began googling to see what had to be done, and here's the list of what I did :
Server
Checked that Net.Tcp Listener Adapter service was running
IIS
Enabled net.tcp binding on my website, with binding information set to "4502:*"
Added net.tcp protocol to the Application that hosts my WCF service
Added a policy in the clientaccesspolicy.xml file to allow socket connection on ports 4502-4536
WCF Service
Added a net.tcp binding with Security set to None
Added an endpoint with this binding for my service, keeping the regular HTTP one
After doing all this, I can use my WCF service with WcfTestClient, it sees the two endpoints (HTPP and net.tcp), and both of them work like a charm.
In my Silverlight application, I can update my service reference (which I added with the HTTP address of my service, not the TCP one), and it also sees the two endpoints because it added the TCP endpoint in the ServiceReferences.ClientConfig. As I saw when googling, netTcpBinding is not supported in Silverlight, thus it describes the binding as a custom binding with a and a element.
I saw on the different tutorials I followed that, as for the HTTP binding, Silverlight asks for a socket policy file to check if the client has access to the WCF service. In SL4 Beta, this file was requested by TCP on port 943. As of SL4 RC and RTM, it's requested by HTTP on port 80, as it is for the HTTP bindings.
The thing is, when I launch my application with the proxy set to use the net.tcp binding, I checked with Fiddler, the clientaccesspolicy.xml is NOT requested at any time, and I get the classic error when the socket policy file is not present : TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions.
After googling, I found out that SL looks for this file with the IP address of the server, not its name, but trying http://IP_OF_MY_SERVER/clientaccesspolicy.xml in a browser on my client machine serves the file as expected...
So I'm a bit lost here, I would really like to have it working to see something else than HTTP with WCF...
Someone has any bit of a clue to guess what happens ???
As the service works as expected with WcfTestCLient with the net.tcp binding, I'm guessing this has something to do specifically with SL...
Thanks for reading :-)
I have found some basic information about hosting a WCF service in a Windows service, but not much. All of my experience thus far with WCF has been in Web projects. I have a few simple questions.
I have a project which creates a windows service application. I have done a right click -> add WCF Service. This creates Service1.cs and IService1.cs.
I'm wondering why no SVC file is created in this scenario? When I add services to Web projects i get an SVC file which I can navigate to and use to consume the service.
Adding the service adds some configurations to the app.config under the services element. I'm seeing a default base address of
http://localhost:8732/Design_Time_Addresses/WindowsServiceName.services/WCFServiceName/
What does this mean? It's sort of an odd looking address. Am I supposed to change it to whatever I want?
Navigating to this address in a browser results in an unable to connect message. Does the windows service itself have to be running to talk to the WCF service?
How do I go about consuming this service from another application without an svc file?
I'm taking a guess on this first one, but I'm thinking the .svc file when hosting in IIS is to tell IIS, "Hey I have a WCF service here, please handle accordingly".
The base address is as it should be and yes you can change it if I'm not mistaken.
You can't hit the WCF service unless the Windows service is running, which is one of the dangers of hosting in a Windows service, because if the service dies somehow your WCF service is offline until you get the Windows service running again.
You consume the service the same way you do any other WCF service, just using that base address to get at it.
I'm using IE8 and can't connect to my WCF service using net.tcp. I'm able to access the same service with http binding just fine. I got two binding enabled in app.config (net.tcp, http). Can anyone tell me if there is a settings that I need to set/play with for viewing service using net.tcp in IE.
You cannot connect to a WCF service using the netTcpBinding through IE.
What you need is a "real" WCF client app, or something like WCF Test Client which is shipped with WCF in the box - just find it and start using it!
Make sure you have a HTTP base address, for your service and a mexTcpBinding endpoint.