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?
Related
I've created an ASP.Net core 3.1 project with Visual Studio 2019. I want to add a WSDL service as a web reference. But I can't. Why the Advanced button removed in this form.
Visual Studio 2019:
Old version:
I've read somewhere that, Web reference is deprecated.
How can I do it?
UPDATE1: The errors of documentation example code when I added it as a service reference
You just should use the new method. The old one is deprecated - see the question in your comment: Web Reference vs. Service Reference.
The last answers sums it like it is. In the end, the reference is just the creation of a client library to call the service. That's it.
Adding a service reference allows you to create a WCF client, which can be used to talk to a regular web service provided you use the appropriate binding. Adding a web reference will allow you to create only a web service (i.e., SOAP) reference.
If you are absolutely certain you are not ready for WCF (really don't know why) then you should create a regular web service reference.
(see: https://stackoverflow.com/a/2158137/2416958)
So, to "fix" your issue:
You need to include the namespace which you used to create the client on top of your file:
In my example:
using ServiceReference1;
But it can be different in your case. You can find it at the generated files, its called ServiceReference1 in my case:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
namespace ServiceReference1
{
[System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Tools.ServiceModel.Svcutil", "2.0.1")]
[System.ServiceModel.ServiceContractAttribute(Namespace="webservice.magfa.com", ConfigurationName="ServiceReference1.MagfaSoapServer")]
public interface MagfaSoapServer
{
You need to create a new one with this:
var client = new MagfaSoapServerClient();
client.ClientCredentials = ...
We have one service reference in one project of a solution. I am trying to move this service reference to new project in same solution. But adding the service reference in new project using URL present in the service reference of old project is throwing 404 error. I am not sure where is this service hence do not have it my IIS.
I tried to copy all the files and adding them to source control. like copy paste but then it has some auto generated code under reference.cs which generates all classes. They have old namespaces and might have to change it to new namespace manually. So, not sure if this can cause some other issue as I will be manually updating the auto generated code.
Is there a way to add this service reference in my new project?
option 1 - find the url by debugging the first project
Assuming that the first project accesses the WCF service correctly, you can debug it to the point where it makes the service call and look at the the remote address in the watch
var url = currentProxy.Endpoint.Address.Uri;
option 2 - add reference to the project thats already working
add a wrapper class that makes the WCF call in your original project and then add project reference of your original project to the new project. now you can you use the newly created wrapper to access the WCF service from the new project via the wrapper
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?
I am getting build failure due to warning in my web.config. Everything was fine before I added .net 2.0 Web service reference to the MVC project. I got warnings of Global element '{element name}' has already been declared for all the elements in my web.config. Searching has only turned up different issues than the one I am having.
Is there any way to fix this issue, perhaps by telling the configuration manager to ignore the config file in the referenced WS assembly?
I can not use the regular service reference as I am not able to call it via https. Or is there a way to reference the 2.0 web service as the regular service reference that can be invoked via https/ssl connection?
Edit: I also have a WCF service reference declared in the project, will that complicate the matter?
I figured out. I don't have to add .net 2.0 WS reference to the project. I can use in web.config to specify the transport protocol to be https.
However, it is wired that adding a web reference would invalidate the web.config elements. I would like to learn the cause of that and would appreciate your input.
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/">