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.
Related
In my project I have a class library that contains connections for WCF services.
In old ASP.NET MVC in order to use service methods I only needed to add bindings in my web.config and it would work properly.
The issue that I am having now is that when I call web service in ASP.NET5 I get this exception:
InvalidOperationException: Could not find default endpoint element that references contract 'xxx' 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.
Is there a way that I can add my binding in a similar way as I would do in old MVC apps?
I'm using the configuration below from an MVC app. When you add a reference to your WCF service using the add service ref dialog. A client section will get added to your System.ServiceModel section in your web.config. It should specify the endpoint which what seems to be missing based on the error you're getting.
Hope this helps
<client>
<endpoint address="http://address.to.your.service.com:8080/V3/ConfigService.svc"
binding="basicHttpBinding"
bindingConfiguration="ConfigService.V3.ConfigHttpServiceBinding"
contract="ConfigService.IConfigService"
name="ConfigService.V3.ConfigHttpService"/>
</client
I was able to run by programattically config bindings. thanks to #wiktor-zychla comment.
var documentService = new DocumentServiceClient(
new BasicHttpBinding(BasicHttpSecurityMode.None),
new EndpointAddress("http://localhost:60205/DocumentService.svc"));
i have few project that use the same wcf service, my asp.net and test project are working fine
with the wcf service i add.
my new project in mvc asp.net also added the wcf reference , all of those project reuse
the assemblies.
when there was compiler error with the types i saw difference in the reference.cs file and
the order that visual studio generate the code wasn't the same.
// CODEGEN: Parameter 'GetLookupTablesResult' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
this is the working one:
Runtime Version:4.0.30319.18063
this one not generate :
Runtime Version:4.0.30319.18444
why there is difference ? is it something in the solution settings?
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
Has anyone got any experience with Web Service Extensions? I spent time trying to make a web service extension from the MS examples.
I have an .net 3.5 web service client, built by adding a reference to the WSDL, via the VS IDE "Project > Add Service Reference". This built my web service client, and all works OK.
I need to intercept the request and response body for my web service client. I have found lots of references to Web Service Extensions, but am having an attack of the tired, and just can't get my extensions to fire.
I've used the MS example from here "How to implement a SOAP extension" ( http://msdn.microsoft.com/en-us/library/7w06t139.aspx) , which builds a logger for the request / response streams.
The related MS article "Soap Message Modification" (http://msdn.microsoft.com/en-us/library/esw638yk(VS.85).aspx) shows how to enable the SOAP extension for the web client:
Implementing the SOAP Extension
There are two ways to run a SOAP extension on either a client or server application. First, you can configure the application to run the extension. To configure your SOAP extension to run for all Web methods on all Web services, especially a vroot, edit the <soapExtensionTypes> Element section within the Web.config file. The following code shows that the type attribute value must be on one line and include the fully qualified name of the extension, plus the version, culture, and public key token of the signed assembly.
<configuration>
<system.web>
<webServices>
<soapExtensionTypes>
<add type="Contoso.MySoapExtension, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
priority="1" group="0"/>
</soapExtensionTypes>
</webServices>
</system.web>
</configuration>
I've compiled the traceextension into its own class library, and referenced it in the web.config of the web service project like so:
<add type="TraceExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ef8757fac167b8d8" priority="1" group="High"/>
No joy. Nothing is logged, no breakpoints are hit.
I then removed the referenced class, and dropped the source code into the web service project.
I tried to add a reference to it like so (my namespace is ServcieTest001):
<add type="ServiceTest001.TraceExtension" group="High" priority="1" />
I used the following thread as a guide as to enabling me extension "getting-raw-soap-data-from-a-web-reference-client-running-in-asp-net" (http://stackoverflow.com/questions/300674/getting-raw-soap-data-from-a-web-reference-client-running-in-asp-net).
Still no joy. I then copied the code from the above thread, and still cannot get the extension to fire when I make a SOAP request.
Can anyone point me to a functioning downloadable web service extension demo project, so I can disassemble it and work out what I'm missing?
John is right, you can intercept the messages on the client using a custom client behavior that implements IClientMessageInspector. See How To: Inspect or Modify Messages on the Client on MSDN.
The only thing 'tricky' about it is that if you plan on modifying the message body then you will need to create a copy of the original message first. See Using the Message Class for the gooey details.
Chances are you want to get some rest.
You don't ever want to use WSE. WSE is obsolete.
You don't want to be using ASMX Web Services - Microsoft now considers them to be "legacy" technology, and will not be fixing bugs. BTW, WSE is based on ASMX, so what's that make it?
You only want to work with Windows Communication Foundation. The WCF Development Center on MSDN is at http://msdn.microsoft.com/wcf/.
Have fun, and stay away from the nasty, ancient, obsolete stuff.
Yup - I was too tired.
I think the Web Service Extensions work with "Web references" (.net 2), not "Service references" (.net 3).
So I guess to alter my question - how do I intercept the request and response for a .net 3 "Service reference" connected to a legacy web service?
This is the command that gets your raw message:
OperationContext.Current.RequestContext.RequestMessage
I wasted 3 days trying with soap extention and it was way too simplier than I thought. You will find intersting reading the links Zach mentioned.
I'm pointing the .Net command line WSDL utility that ships with Visual Studio 2005 at a web service implemented in Java (which I have no control over) and it spits out the following error:
WSDL : error WSDL1: Unable to cast object of type 'System.Xml.XmlElement'
to type 'System.Web.Services.Description.ServiceDescriptionFormatExtension'.
Yet if I point Visual Studio 2005 itself at the service via the Add Web Reference dialog it generates a proxy class for me just fine.
I'm using the WSDL utility to generate all my other service proxies just fine (though an old one does emit a bunch of warnings).
Currently I'm pointing the WSDL utility at the URLs of deployed web services. All of which were developed in Java.
I want to use the WSDL command line utility in the build process to ensure I have the most up-to-date proxy code each time I compile.
Try specifying the option protocol SOAP12
/protocol:protocol (as show on MSDN)
Specifies the protocol to implement. You can specify SOAP (default), HttpGet, HttpPost, or a custom protocol specified in the configuration file. When using the /parameters option, this value is the element and contains a string.
If that does not help then.......
Visual Studio's "Add Web Reference" calls the WSDL.exe when adding a web reference. Basically there is no difference, other then the control you retain when running the WSDL.exe command from the command line. I would suspect that one of your arguments is incorrect or different then the one Visual Studio is setting.
To test this you would need to compare the output for from the 2 different XSD files that are generated, that will give you more of a clue of what is wrong(as Klathzazt has suggested).
Good Luck
Is this an XSD File? files have dependencies. Download the dependency files and place them side/by/side with the XSD you downloaded.
I would assume visual studio may fetch dependencies.
If this doesn't solve it, please provide more details.
I was able to get rid of the this error by decorating the (concrete)Service with the ServiceBehavior, and giving it a Namespace.
using System.ServiceModel;
[ServiceBehavior(Name = "MyConcreteServiceName", Namespace = "http://www.mycompany.com/services/")]
public class MyConcreteService: IMyService
{
}
NOTE:
Set via ServiceBehavior attribute on the service class (and not the contract (interface))
Instead of this:
<wsdl:definitions name="MyConcreteServiceName" targetNamespace="http://tempuri.org/">
I got this:
<wsdl:definitions name="MyConcreteServiceName" targetNamespace="http://www.mycompany.com/services/">