What is "mexHttpBinding" in WCF? When should this binding be used in preference to other bindings?
It is a binding that returns metadata so you can build a proxy at the client side. See here. More here as well.
mexHTTPBinding allows to use WS-MetadataExchange over HTTP. You don't need it unless you implemented policies which may change over time and you need to discover your service with UDDI for example
Many people says it's needed for creating client side proxies. This is not true. For client side proxies you need to publish WSDL. You can do that by specifying in your service behavior.
Shortly, you don't know it -> you don't need it.
mexHttpBinding is used while adding a new Service Reference in a Project in Visual Studio 2013 (DEBUG) that will consume your WebService (providing the mexHttpBinding). After you've added the Service Reference successfully you might disable the mexHttpBinding.
It is all described in the App.config when you're creating a WCF Service Library Project in the Visual Studio 2013 ( Solution >> Add New Project >> Visual C# >> WCF >> WCF Service Library)
Related
I'm new to WCF, so I opened up 2 projects: WCF class library and a host console application.
Now, both projects have app.config to store the WCF service configuration settings.
As it seems to me now, and correct me if I'm wrong, I have redundancy in configuring both projects with WCF settings.
How is it done in real world production software ? Does it use separate *.dll library for WCF services, or is it implemented withing the host project (and by that use a single place configuration of it) ?
Thank you .
EliorCohen's answer is correct, but I wanted to expand on a couple of points.
First, your building a WCF class library - library's don't use configuration files on their own. They use the configuration file of the calling application. This is something that I've seen cause a lot of confusion for developers, especially if they create a new class library and they see an App.config file in the project.
Second, with WCF 4 you can actually host a service without specifying anything in the configuration file. The runtime will add default endpoints based on the URI's supplied when you construct the service host.
You can also use set up default bindings and behaviors that will override the normal defaults - for example, if all of your services would be handling large requests, you might want to define a default binding with larger values (by ommitting the name attribute in the Binding configuration).
WCF is wonderful in that it has a lot of options - but that blessing is also a curse at times, especially when you first start working with it.
For more information on default endpoints and stuff, see A Developer's Introduction to Windows Communication Foundation 4.
Note that you'll still need a configuration file for any client apps.
the wcf project you are building represent an implementation of the service.
the configuration need to be on the host of the service (your host app).
In most examples of WCF services that use MSMQ transport it is always preferred to create a proxy manually using svcutil in Visual Studio command prompt rather than simply adding a Service Reference. When you can just reference the service by providing its endpoint address to the Add Service Reference dialog in visual studio why would you want to create a proxy with VS command prompt (since it is slightly more laborious)? I just came across this while reading WCF 4 Step by Step:
Note that you cannot easily use the Add Service Reference Wizard in
Visual Studio to add a reference to a WCF service that uses the MSMQ
transport.
Why exactly is it difficult? What exactly is the benefit (if any) of the former method of referncing a WCF service? It seems to me that creating a proxy manually is just unnecessarily complicating the task.
You don't need to pre-generate a proxy as long as you have a reference to the assemblies which define the service interface, operations, and data contracts. You can then create the proxy on the fly using ChannelFactory.
var factory = new ChannelFactory<IMyServiceInterface>("MyServiceNameInAppConfig");
var proxy = factory.CreateChannel();
This is far simpler than using svcutil. However, if the service is remote and you cannot get access to the type assemblies then you have no other choice but to generate a proxy.
Regarding your question about why it's easier to use svcutil instead of VS to generate the proxy code, without seeing the actual book it is hard to comment, but under the hood visual studio uses svcutil to generate the code anyway, so I can't see how it would be any better or worse. When you do this manually then you have more control over what gets generated I guess.
I have a visual studio 2008 solution with approximately 15 projects. Several of these projects have a WCF service reference to a WCF service project. Whenever I update the service project, I have to go to each of the other projects and right click the service reference and update it. Is there an easier way to do this, like a "Update All Service References In Solution" button, somewhere, somehow?
There's no such functionality, really - at least none that I'd be aware of.
You could do one of two things:
have svcutil.exe update your service references - it's a command line tool, which you can batch up, or have executed during a build process
or:
if you're controlling both ends of the communication channel, and both are .NET, you could put your service and data contracts into a separate assembly (or several), and then share those assemblies between server side and client side code. You'd have to change the way you build up your client side proxies a bit (instantiate a ChannelFactory<T> and create the channel from that factory for each service contract), but that would be a one-time effort.
Once done, any updates to the service and/or data contracts would be reflected in both the server side code, as well as your client proxy code.
The only drawback here is: it only works for .NET-to-.NET communication - if you have non-.NET clients, those are left out in the cold, obviously.....
I have a WCF test service and a test client in the same solution. The service is configured to run on localhost (Ie, "http://localhost:8731/Design_Time_Addresses/MyService/Service") I run the client app and it correctly invokes the service and gets back the correct answer. I've verified via logs that it's definitely running the service that's local to my machine.
However, I can't debug into the service when running the client. WCF is supposed to allow just stepping through, but no breakpoints on the service get hit, and stepping in to the service call doesn't work either. Has anyone ever seen this?
I've checked all the obvious stuff like "is the PDB file being generated?" -- yes, it is. If I run the service project by itself, then hit it with some test client, breakpoints get hit correctly. So debugging on the service works. I can even explicitly "attach to remote process" and debug the service that way. But WCF will not automatically step from the client to the service.
I've had this happen as well. Curiously it seems to happen after I make changes to the build configuration (from x64 to x86). Here's how I've been able to fix it:
Right-click the solution, select Properties.
Under "Startup Project" switch from "Single startup project" to "Multiple startup projects".
Set Action to "Start" for the WCF project.
Even though I'm hosting the project in the local IIS server (not the VS Development Server) this solves it, which is a little puzzling. I suspect that setting a project to "Start" also causes VS to attach to the process for debugging.
http://msdn.microsoft.com/en-us/library/bb157685.aspx
For Visual Studio multi-configurations:
In the Property Pages of your solution, ensure that the "Configuration" for your web-service is set for "Debug", not "Release".
Are you using the automatic WCF service hosting feature in Visual Studio? You can check this by opening the project properties of your WCF service project and navigating to the WCF Options tab. Is the Start WCF Service Host when debugging another project in the same solution checkbox checked? If it is, then this explains the problem.
What's happening is that when you run your client, a separate process is created to automatically host your WCF service. Because it is a separate process, you will not be able to "step into" it when debugging your client. You'll have to run two separate debug sessions, one for your service and one for your client.
An easy way to do this is to put a call to System.Diagnostics.Debugger.Break() in the startup logic for your service. When your service is automatically started by the WCF service host, you'll be prompted to debug it, allowing you to open a second instance of Visual Studio for its debug session.
Also when using VS debug and attaching it to the w3wp.exe process and you have specific port bindings other than http:80:* you must have the debug > web in VS set to the site and port http is running on.
Yes, I got the same problem, WCF uses another processs.
At last, I found a way, i start a new instance(debug->start a new instance) of WCF service first, then start the client side, the breakpoints in the WCF service hits!
One other reason for not stepping into WCF service may be the size of your data that is passed to the WCF methods.
For ex., I was passing an array of dobules of size 1000, and I was getting a bad request error (400) with seeing how the method is run. I made the size 500 and now it debugs the WCF.
In my case, I had published it using Release configuration. You need to select Debug here.
I had similar problem. WCF hosted by WCF Service Host, requests tested by WCF Test Client. My problem was caused by space in build configuration name. As soon as I used configuration name without spaces, debbuging worked.
I guess the real problem was the build output folder ending with folder named by the configuration name.
#msulis - yes, thanks, this remedied it for me. I had also changed recently, the target CPU from any to x86. I couldn't reply directly to you message for some reason so apologize if this comes up as an "answer".
I'm trying to figure out how to consume a WCF service in BizTalk 2006 R2 (sending a request and receiving a response).
I've gotten as far as going through the "Add Generated Items" wizard. Now I am trying to find out how to use the items it generated in an orchestration.
How should the request be made?
Below is a description of how to do this - I'm going to presume at least basic knowledge of things like BizTalk mapping, please let me know if you need any more detail and I'll update.
After generating the items in BizTalk you should have (at the least):
An orchestration file with Messages and Port Types created
A schema that describes the messages you send and receive from and to your WCF service
A .Binding.xml file that describes the service contract exposed by the WCF service and allows easy configuration in BizTalk
Open the orchestration file. This should be empty.
Drag a Port from the toolbox onto the orchestration designer surface.
Name the port appropriately.
Select "Use an existing Port Type" - one of the existing port types will be your WCF service (created by the Add Generated Items wizard)
Specify that you will be sending and receiving messages
Specify Bind Later
This port should have Request and Response operation messages and they should have been automatically configured to use the messages for your WCF service. If your service exposes multiple operations, you will see that reflected here.
Using standard BizTalk mapping methods, map the data you want to send to the WCF service into the request message for the WCf port. (you may want the change the message names in the orchestration designer to be something better than the default message_1, message_2...)
Drag Receive and Send shapes onto the orchestration designer and connect them to the right Port messages.
Wire up the rest of the BizTalk orchestration to take data from appropriate source systems (this is just basic BizTalk, not WCF)
Deploy the BizTalk application.
The application is now ready to go, you can deploy it to BizTalk.
Configure the BizTalk application
Open the BizTalk Server 2006 Administration Console and find the application containing the orchestration you just deployed.
The orchestraion will be unenlisted, you need to bind all of its ports
For most of the ports this is just like any other BizTalk application - only the ports that deal with the WCF service differ.
For the WCF ports you have (at least to begin with) two main options:
Import the bindings file made by the BizTalk Generate Items wizard (right click on the applicaiton and import - navigate to the .xml binding file) - Perhaps advisable until you have an idea of how Biztalk represents all the WCF binding options.
Configure your own WCF send port.
For this the port needs to be Solicit-Response to match the WCF service.
Choose one of the WCF Send Port types to match the binding type of your WCF service.
To begin with (for a basic Webservice) this will often be WCF-BasicHttp.
Once you have the basics working you might want to return here and experiment with the options available in the Custom binding - there is a LOT there!
Configure the send port.
In the general tab enter the url where the .svc file is specified
e.g. http://localhost/WCF/myservice.svc
Set the Action to match the action specified in the WCF service .wsdl file
e.g. http://tempuri.org/IMyContract/MyMethod
With your WCF port now created you can bind the orchestration ports to it.
Once all this is done, you should be able to start the BizTalk application and things should work.
One thing that may help - errors will be written to the event log, they may not be helpful, but you should also be able to see any soap fault messages returned from the service in the suspended message view.
Good luck!
BizTalk is overkill if you are just using it to orchestrate WCF services. You can use WCF services in .NET 3.5 inside of Windows Workflow Foundation a bit more easily.
That said, here is a screencast that should help:
http://www.pluralsight.com/community/blogs/aaron/archive/2007/11/15/49172.aspx
Its is very simple as other Service development in BizTalk. Let make it more simpler.
Just Develop you desire Work Flow (Orchestration) and Service.
Open WCF Web publishing Wizard and Check (a) Enable Metadata Endpoint , (b) Create BizTalk Receive Location in the in ur application.
Go to you BizTalk console and Enable the Receive location and Start your Application from Biztalk Console.
Then Browse it from IE or Fire Fox to check that either Service is running or Not.
Now Service has been Develop. Lets do something for its Client.
Go to the Patah "c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\" and Write SVCUTL and your url of your service i.e. c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\svcutil localhost:axix//axx.svx?wsdl, this will copy the two files, one is output.config and other is BizTalkServiceInstance. cut and paste both files to your ciletn and then See you service desp for its consumption.
I Think this is the most simplest which i tried to make.
Thanks
Abdul Aziz Farooqi.