We Keep Coding

Changing the url in WSDL generated interface

To start off, i have never coded a SOAP web request before in my life so this has been a learning curve of note.
I am busy writing a service that will make a soap request to a SageX3 web interface in C#. Net (obviously using Visual Studio). We already have similar request on another service that is supposedly working and I am using that as a reference. So took the (supposedly) same wsdl file and created a connected service reference that generated the Reference.cs file which should be the interface I must use to this soap request. But this request url uses a default url that I do not seem to be able to change. I have looked through the class definition and the properties in the interface like "endpoint" and such all seem to be read only. So I looked in the other project how that Refenrence.cs file looks which is completely different. The first part of my generated reference.cs looks like this:
Newly created reference.cs header:
If you look at the original reference.cs file, it is vastly different:
Original created reference.cs header:
What I notice is that the original has public class that also inherits from SoapHttpClientProtocol that will allow the user of that class to setup the url as reqiured. I do not have that option as my generated code is straight up an interface.
This brings me to my question, could it be that I have an invalid wsdl file or working from a different file as the original code?
Was the code generated differently as there might be a different tool used in Visual Studio?
Did the original author make changes to the reference.cs after it was generated? I think this is a possible answer that I need to add a class definition in the reference.cs file.
Or am I on the completely wrong track here.

service reference proxy class renamed

I'm having my Web Application which hosts Webservices (svc) which are used in a Silverlight Webapplication. After a while I added some new stuff to my Service and now I tried to refresh my proxy classes in the Silverlight Application Project.
Unfortunately, Visual Studio now generates new class names.
Before I had this:
public SilverlightApplication.ServiceReferenceDoc.Document Document
but now I get a different class name (number one behind the name)
SilverlightApplication.ServiceReferenceDoc.Document1 Document
Which is really bad because my Silverlight Projects have a lot webservices and these have a lot of code which uses these proxy classes.
So far I found out it generates the proxy class 2 times.
Some ideas why this renaming is happening? I already tried VS2015, VS2013 and also I deleted the complete reference and add it again, but it's the same.

We had mixed EF classes with own classes. That caused the generation of two classes with the same name.

Adding Service Reference to WCF does not always create .datasource files

In some projects when I add a service reference to a WCF service, it creates datasource files for classes shared in a common class library, however in others the datasources are not created. The Reference.cs file is different where in the first case the types are from the class library and in the latter it's in the Reference.cs file it self. These are not compatible.
What is it that triggers the automatic generation of the datasource files in this case? Advanced options in Add Service Reference dialog are identical so something else must be playing tricks on me.
UPDATE: Turns out the datasource files are not needed. It's the code generated in the Reference.cs file that makes the whole difference. I can manually edit the parameters for the methods to point to the class-library, and it works. This is of course not a solution in the long run, since I have to do this every time I update the Service Reference. Hopefully someone will come along who knows the trigger of this problem.

The file is created by VS when you add a service reference. It's used to enable client UI components to bind to the models (data contracts). I don't know why they are not created for "all" services (but I guess it depends on how that service defines and uses data contracts (as in: no contract no data file)).
Here are some useful links:
https://msdn.microsoft.com/en-us/library/ee373840.aspx
What are the WCF Service Reference .datasource files?
UPDATE: You are right it should not depend on the consumed service. Here are two related links (that impliece that the files are included by VS):
http://objectmix.com/dotnet/797048-wcf-service-reference-datasource-file-name-length-problem.html
Disable automatic generation of datasources file when updating service references
So it looks like the file is created by VS, if you don't wan/need it you can exclude it by creating the proxy with svcutil.exe

Project structure for Schema First Service Development using WCF

I have WSDL and XSD as starting point. (WSDL is generated from XSD using WCSF Blue tool). From the WSDL, using a tool, the service code is generated. The project name is “Autogenerated_Service_Project”. Inside this project it will have [ServiceContract] and [DataContract] classes. It has a data contract named “EmployeeDataContract”. In the GetEmployee() service operation, this datacontract is returned to the client.
I have a business layer project named “Business_Project”. It has a method that returns “Employee” entity object.
At present, I am referring the “Business_Project” inside “Autogenerated_Service_Project”.
Business_Project.MyClass b = new Business_Project.MyClass();
EmployeeDataContract d = b.GetAssociate();
return EmployeeDataContract;
The challenge comes when there happens a change in WSDl. When the WSDL is the changed the “Autogenerated_Service_Project” will be recreated and the code mentioned above will be lost.
What is the solution to overcome this code lose?
Note: The “Autogenerated_Service_Project” is the top most project. Ideally, it cannot be referred by any other projects.

You may change the way calling Business layer(may your solution needs additional layer)
But in simple way, you can generate the proxy once, when changes happen to WSDL
handle the changes manually,Or use the tool only for new services.
If the services on WSDL are finely grained, the solution may be applicable.

This can be resolved by using Partial Classes in a different file. The code given in the question can be moved to this new partial class file. This file will persist even if the auto generated file is re-created.

Getting methods from web service and their parameters programmatically

I'm playing around with WCF and wondering about the following. I'd like to be able to get a list of all available service methods and parameters associated with these methods.
Now, I've tried to work with the ServiceDescription namespace, but it seems flawed. For one .svc it works, for another it doesn't.
What would be an okay way to approach this? Any tips?

You could just download the WSDL of the webservice and parse that (it is XML, see http://www.w3.org/TR/wsdl) since the WSDL contains all information like interfaces/methods/parameters etc.
Some helpful resources including source code for doing what you want:
http://webservicestudio.codeplex.com/
http://wizdl.codeplex.com/
http://soap-sec.sourceforge.net/