I am creating a service reference to a WCF service using VS2008 but the generated reference file has 2 classes defined representing the same object. Any ideas why this would be? See result below - THView and THView1 were generated while I'm expecting only THView.
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="THView", Namespace="http://schemas.datacontract.org/2004/07/CH.BusinessServices.Model")]
[System.SerializableAttribute()]
public partial class THView : object, System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged {
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="THView", Namespace="http://tempuri.org/")]
[System.SerializableAttribute()]
public partial class THView1 : object, System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged {
Service files are generated based on the service's metadata (WSDL), and this particular service's metadata apparantly defines two different THView types.
They may look similar (they have the same name), but they are actually different because they live in two different namespaces (notice the Namespace property of the DataContractAttribute), respectively
http://schemas.datacontract.org/2004/07/CH.BusinessServices.Model
http://tempuri.org/
Because the namespaces are different, the types are considered different. That's simply how XML works.
It looks as though the developer who defined the original service forgot to change the default XML namespace on one or more of the types exposed by the service - at least, http://tempuri.org/ is the default namespace in WCF.
It's strongly recommended that the default namespace is changed to a namespace 'owned' by the service owner.
The issue is that you are refreshing the reference when you already have information in the app.config, to fix this, delete the app.config information before refreshing the proxy, or recreate the proxy to a different file
Thanks,
Sebastian
Related
I've looked around - can't find the answer to this, even in lots of sample code.
I'm trying to compile a WCF Service Application that uses [datacontract] classes as parameters on the interface members, which are from a global C# class library... This is on the server side. When I import the service reference into the client, it's re-namespace-based the global class library classes, and generated a bunch of serialization code!
I cannot add a reference to the global class library in the client project and use the classes freely. this seems clunky. I've checked the button when importing the service reference "reuse types", but I don't know what that does, but it's not the right thing.
During the import of the service library, it allows me to specify the namespace for the about-to-be-generated proxy classes. I'm pretty sure this isn't supposed to be the same namespace as the classes used on the server side!
example:
GLOBAL CLASS LIBRARY
namespace SquallGlobal
[datacontract] class ProcessStartInfo{ }
WCF SERVICE
namespace Squall
[servicecontract] interface IJob{
[OperationContract] StartJob( SquallGlobal.ProcessStartInfo psi );
}
END USER PROJECT
WCF Service imported under namespace 'Squall_Imported'
using SquallGlobal;
if I want to call proxy.StartJob( ), I need to pass in a Squall_Imported.ProcessStartInfo, not SquallGlobal.ProcessStartInfo!
Thus, the final question: How do I keep the proxy-generation code from re-basing the namespace on global classes used in interface methods?
I have a WCF Project named EmployeeGateway this WCF Project has been added as a WCF service reference to another WCF Project named CompanyService
EmployeeGateway has an Object named EmployeeView
In CompanyService I have an object with the same name 'EmployeeView' which inherits from EmployeeGateway.EmployeeView
[DataContract]
public class EmployeeView : EmployeeGateway::EmployeeView { additionalfields }
Now, I have a third project named CompanyUI (MVC) which has a service reference to CompanyService.
The problem is that the generated code in the reference.cs file has a:
public partial class EmployeeView :
and a
public partial class EmployeeView1 : {Namespace}.EmployeeView { fields }
Is it possible for this file to be generated without the 1 at the end of the name? Can it somehow be fully qualified? For example: The reference file contains {Namespace}.EmployeeGateway.EmployeeView and {Namespace}.CompanyService.EmployeeView (which would inherit from the EmployeeGateway?
If not, I wonder if it possible to not even expose the EmployeeGateway.Employee view at all within the CompanyUI project?
Really though, I don't like that the method that i'm calling has the number 1 at the end of it and am looking for options on how to properly fix it.
Thanks for any assistance.
Steven.
I have defined the following type in a class library project.
[CollectionDataContract()]
public class OperationException:System.Collections.Generic.Dictionary<string,ExceptionData>
{
[DataMember()]
public bool ExceptionExists { get; set; }
}
[DataContract()]
public class ExceptionData {[DataMember()] public string Msg;}
On my WCF service end, I am returning an object which contains the above class as a child member variable like this.
[DataContract()]
public class SaveClient
{
[DataMember()]
public string Id;
[DataMember()]
public OperationException ExceptionCollection;
}
I have the OperationException class library referenced on the client side. The problem is when I generate the proxy using Add Service Reference, a new definition of OperationException of type dictionary is generated. I do have the Reuse Types option set to true. I like to have Actual 'OperationException' type being used since I have to pass this object to other methods.
Thanks in Advance..!
Iftikhar.
I had the same issue and like you I had applied the CollectionDataContract attribute and told the proxy generator to reuse types from my shared assembly.
The fix was not obvious, you need to supply a hook in the Reference.svcmap file on your client to tell the generator to use your custom collection type.
In Reference.svcmap edit the CollectionMappings element as follows and then update the service reference:
<CollectionMappings>
<CollectionMapping TypeName="YourSharedAssemblyNamespace.OperationException" Category="List" />
</CollectionMappings>
I think the same objective can be achieved if you are using svcutil from the command line by supplying the collection type argument.
/collectionType:YourSharedAssemblyNamespace.OperationException
See these posts for more info:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/09eefbbc-bf63-4aa3-a0cb-01a9dbd7f496/
http://www.codeproject.com/KB/WCF/WCFCollectionTypeSharing.aspx
I am not sure why the WCF proxy generator doesn't just use it's common sense to find the shared collection types but there you go, chalk it up as another funny from the WCF tool design.
Does your client proxy assembly have a project reference to the class library where the type is added?
If the proxies generated by svcutil are not what you want, it's also very easy to write them by hand. Just create your own ClientBase-derived class and implement your service interface on it. Then you have control over which assembly types you want to reuse.
I'm trying to write a WCF Web service that will return my data as JSON so I can call it from some client script.
I know I need to decorate any classes I want to return from the Web Methods in a [DataContract] attribute and then any Members in a [DataMember]. That in mind I want to return entity types so I went to the Entity ObjectContext classes.
However when I look at the .edmx file I can see that the classes have been decorated like so...
[EdmEntityTypeAttribute(NamespaceName="PteDotNetModel", Name="AssocFile")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class AssocFile : EntityObject
When I then try and add [DataContract] I get an error saying I can't have duplicated attributes. I'm confused whilst they are similar they are clearly different no?
The second part of my question is how I return entity types over a WCF service?
The two attributes are the same; the trailing "Attribute" can be excluded. From MSDN:
By convention, all attribute names end with the word "Attribute" to distinguish them from other items in the .NET Framework. However, you do not need to specify the attribute suffix when using attributes in code.
I have a datacontract as part of my WCF Interface that inherits from IIdentity:
[DataContract]
public class AuthenticationIdentity : IIdentity
{
//implements IIdentity...
}
The service returns my AuthenticationIdentity objects just fine. However, when I try and do the obvious cast on the client:
AuthenticationIdentity aId = client.GetID();
IIdentity id = aId;
I get a complaint that AuthenticationIdentity cannot be cast to IIdentity. I've tried adding the ServiceKnownTypes to the interface:
[ServiceKnownType(typeof(AuthenticationIdentity))]
[ServiceKnownType(typeof(IIdentity))]
but still no luck. Any ideas?
If you control both sides of the wire (which it looks like you do since you want to cast to IIdentity), you can reference your DataContract from a shared assembly. Then you can use svcutil to share the DataContracts between the service and the consumer. Or, if you wanted to cut out svcutil altogether, you could write your own proxy to use the shared assembly.