After reading some info about adding Dependency Injection (for use with Unity) i still have one issue: WcfTestClient.
At this point of development i really don't want to install my Windows Service each time i hit F5, i just simply want to keep using the WcfTestClient (i think, or are there better ways?).
But the document explaining the way to use Dependency Injection with WCF services all mention '.svc' file... my project type (WCF Service Library) does not have a '.svc' file.
Sample documents:
- How do I pass values to the constructor on my wcf service?
- http://www.i-avington.com/Posts/Post/usng-unity-with-a-wcf-service
- http://orand.blogspot.nl/2006/10/wcf-service-dependency-injection.html
How can i use Dependency Injection with Wcf Service Library working with WcfTestClient?
Related
I have a solution where I add a service reference for a service and the service shows up as a service reference and everything works great. Very Happy.
In a separate solution I have created the service. Within this solution I have a project for unit testing the service. When I add a service reference for the service to the unit test project, the reference shows up as a connected service rather than the expected service reference, and I do not have access to classes specified by [DataContract] .
This behavior is not the same as installing the service on a different project, and it is preventing me from testing the service.
To recap, I have one service, installing it in two separate solutions produces different results. One solution the install works as expected and I have access to classes specified by DataContract and the other solution Installs the service and I do not have access to classes specified by DataContract. Both installed services provide all the methods exposed in the interface.
What can I add to help figure this out? I am not terribly familiar with services so please ask me questions to help improve this question.
****UPDATE****
What is working if I add a new project, then the service provides the data contracts. Something is going sour when I am updating the service references on an existing project. Obviously creating a new unit test project and moving everything in is a pain.....
I solved this issue by a combination of restarting visual studio, restarting the computer, deleting the service reference, re-installing the service reference. I believe deleting the service reference then reinstalling using a different namespace ended up working. I also deleted the unit tester and rebuilt it, re-doing all references, installing the service under a new namespace, so that may have been the total fix.
****Update it broke again and this did not work*****
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.
We have an EPOS system that is built in VB6. A client is using Microsoft Dynamics AX as a CRM system. A 3rd party has created the AX implementation for our client and they've exposed a set of WCF web services that we need to consume to synchronise data between the EPOS and the AX CRM. Knowing VB6 would have issues calling WCF services, I created the following components to handle the communication between the EPOS and the AX CRM.
VB6 EPOS which calls -->
1) VB6 DLL wrapper which calls... -->
2) .NET(3.5) COM Callable Proxy DLL wrapper which calls... -->
3) .NET(3.5) Web Service Handler (Where the web servicesw actually get called) -->
Microsoft Dynamics AX CRM.
I built a test console app in Vb.NET to simulate calls from VB6 to help with debugging, so that test console app calls component 2.
Whilst doing this I was getting the following exception:-
"(could not find default endpoint element that references contract 'X' in the servicemodel client configuration section. this might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.)"
I googled around and found that I had to copy the bindings and endpoints section from Component 3's app.config to a new app.config for my Test Console app. I don't know WCF and haven't got the time at the moment, to really learn it to the point where I understand why this fixed this error.
Now though, I'm trying to call the services from the VB6 EPOS and this error is popping up again. So I added an app.config to Component 2, thinking that as Component 2 is the first .NET(3.5) component in the chain, that is where the endpoint declaration should go, but No. The error is still popping up.
Does anyone have any ideas? Any programming heroes out there that can shed some light on this for a simpleton please??? Please don't ask why we don't re-write the EPOS. We will. just not yet. Theres over 3 million lines of spaghetti code in there and I've only been working on it for 8 months!!!
As an aside, Doesn't this scenario break one of the golden rules of OOP, i.e. encapsulation. Why should my VB6 EPOS need to know what endpoints Component 3 uses to access the WCF service???
Great question here...
Your problem is essentially coming from all the required configuration data needed to work with a WCF Service.
When dealing with .NET Windows or Web Applications the configuration data on both the client and server sides of WCF Services reside in the application configuration file. For a windows application this file will be app.config, whereas it will be a web.config for a web application.
In your case, you would like to put the proxy logic in some form of a COM-visible .dll.
This is going to cause you some grief...in the .NET platform, the .config file for top-level host application (web or windows) is the place where all configuration data is read. Even if your application leverages dozens of .NET assemblies (each with custom configuration needs), the runtime is going to expect those configuration elements to all reside in the top-most application configuration file.
To resolve your issue, you are going to need to communicate to a service that VB6 does have access to (think ASMX web services) and have that service forward your call along to the appropriate WCF service.
The other alternative is to pass configuration variables directly from your VB6 application to your Com-visible assembly so you can use the extensibility model of WCF to create proxies (overriding the default behavior to read configuration data from a file) with your passed-in configuration.
I would say that the latter scenario could go both ways as far as being a violation of SOA/OOP..depending on the situation it may/may not be appropriate for the VB6 application to know about/store configuration details for communicating with the (eventual) WCF endpoint
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)