I have a question about references to WCF Services. I have two apps:
Console app
--Library
----WCF Service
The console app and library are in the same solution. Because of the WCF service in the library, its app.config has info for the WCF Service.
The console app config has nothing about the WCF Service. The console app calls the WCF Service indirectly through the library. I'm guessing that is why the console app has no WCF info in its config (since it knows nothing about the web service). The console app does a call to a static method in the library, which handles the WCF call.
I'm getting this error on the above call:
Could not find default endpoint element that references contract 'MyServiceReference.IMyService' 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
Does the host (console app) need the WCF Service related info from the library? If so, why didn't VS2010 add it.
The library you created ("--Library", in your hierarchy) likely added a service reference to your WCF service. ("in the library" makes no sense, so I'm assuming that's what you meant). This means that a bunch of information about the WCF service was added to the app.config for the library. That information needs to be in the app.config of any exe that references the library in order for the library to correctly access the WCF Service that it references.
What I'd suggest is running the SVCUtil.exe. You can run it against the running service like this:
svcutil.exe http://localhost:Port/YourSvcClass/YourSvcMethod /language:c#
What that will do is build a client-side c# (or vb) stub class in c#, plus a .Config file with the exact client side configuration file you'd need to connect ... all the good stuff. You can also run svcutil against your WCF dll like this:
svcutil.exe c:\yourfolder\YourService.dll /language:c#
Whether you use the stub class or not, the .config file will be helpful in setting up the client.
Good luck
Related
I'm trying to develop a C# library that will be consumed in multiple C# based applications (e.g. WPF and ASP.NET projects), using the .NET framework.
My library depends on a specific web service (SOAP) which isn't necessarily in the consuming applications that will be using my library.
Is it any way possible for those applications to use my library without having to define the endpoints of the web services in my referenced library in its config file?
If not, how do "enterprise" type libraries solve this problem?...is this just a limitation of libraries?
Note, the error encountered when one doesn't define the matching endpoints in the consuming application is: "Could not find default endpoint element that references contract 'Web Service Contract Name' in the ServiceModel client configuration section. This might be because no configuaration file was found for your application or because no endpoint element matching this contract could be found in the client element."
I have created a class library - MyNS.MyClass. The Library has a Service Reference to a Webservice (added through Add Service Reference) - the Service Reference shows up as MyNS.VS in the Project. The class library is MyNS.dll. MyClass has a static method myStaticFunc which calls the Web Service
I have a separate C# console application where I add reference to this DLL. I have code there calling MyNS.MyClass.myStaticFunc. My project compiles fine. But when I run it, I get an exception
{"Could not find default endpoint element that references contract
'VS.MyObj' 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."}
To get rid of this exception, I have to also add a Service Reference in my Console Application & give it the same name (VS - however, here the namespace would obviously be my client app's namespace).
I don't understand why this needs to be done - it's the Library which is calling the WebService - the app is not calling it directly - and the Library does have the Service Reference. And why does the workaround work - in spite of the namespaces being different?
When I use the "Add Service Reference" utility in Visual Studio to connect to a WCF Data Service (OData), visual Studio doesn't generate an App.config file with the System.ServiceModel section for me. (The proxy class is generated fine). Is this normal?
Is there still a way to have this config generated automatically? The WCF service in question is secured and I therefore struggle with authentication issues if I try to to use the command line svcutil.exe with the /config option.
svcutil.exe cannot be used with WCF Data Services (OData), there's a datasvcutil.exe which is used instead.
The Add Service Reference for OData should not generate anything into your app.config as it doesn't need it. To use it, you just new up the generated context class and pass in the URI of the service.
If your OData endpoint required authentication though, the Add Service Reference doesn't support that though, so I'm surprised it works for you.
I have standard class library infrastructure assembly which i reference in my main application.
The infrastructure assembly uses a webservice internally and exposes functionality to my main application.
To get it to work i need to add a reference in my main app to the webservice otherwise i get a Endpointexeption. If i add it everything works fine. It seems to me that the infrastructure dll reads information in the main applications app.config so the entry has to be there. But it seems strange that i cant expose the web service throug an external dll as the main application does not call the webservie directly. Whats even stranger is that the webservice ignores the main applications security mode and reads it from the external dll's app.config.
If im correct in my assumptions, how do i expose a webservice in an external dll withot the main app knowing about the webservice.
in your class library project when you add the service reference you have to make sure the generated proxy is Internal.
for more info:
C#, WCF, Hide web service through dll
This will hide the WCF interface to the client.
if you don't want that the client that uses your class library project needs to add the WCF configuration key in its app/web.config your library has to configure the EndPoint/address/binding in the code (hard coded) but I won't recommend you to go down this road as if something changes on the WCF side your class library won't work anymore
You don't need to add the service reference to your main app, but you must copy the relevant configurations to the main app.config
I tried to use separate assemblies for the implementation, contract and WCF service library but starting the service in debug produced an error because it couldn't find the service/contract. If I move them into the same assembly it works. What is needed to wire up the WCF when it's in different assemblies?
Shouldn't be anything special to do - we've got hundreds of services running with contracts and impls in separate assemblies, and it works just fine. Are you self-hosting with ServiceHost or using IIS? If you're using IIS, make sure the host project has references to both assemblies so they all show up in the bin directory together. You may need to at least partially assembly-qualify the type name in the ServiceHost directive's Service attribute (ie, MyImplNamespace.MyImplTypeName,MyAssemblyName).