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.
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?
My application is trying to consume a WebService for which i have a WSDL file. So, i generated an interface from that using SvcUtil.exe. I am using that in my class as below :
namespace ApplicationUsage
{
public class Usage
{
private readonly IExportService _exportServiceProxyClient;
public Usage(IExportToNavisionService _exportServiceProxyClient)
{
_exportServiceProxyClient= exportServiceProxyClient;
}
}
I am injecting the "IExportService" as :
Component.For<IExportService >() .AsWcfClient(DefaultClientModel.On(WcfEndpoint.FromConfiguration("exportServiceProxyClient")));
My issue is that i am forced to use the Endpoint name in the app.config same as the property name ("exportServiceProxyClient") in the class constructor ("Usage") where the instance to be injected. I dont think that it is a good idea. If i dont do this, i get an exception :
**Could not find endpoint element with name 'exportServiceProxyClient' and contract 'IExportService ' 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 name could be found in the client element.**
I dont know how to get around this issue. Why Windsor wants that the endpoint name should be same the variable name in the constructor for the class where it is being injected.
Can anybody help?
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 have a plugin that I will instantiate at runtime and I want to pass it a WCF service from the application host. The application host is responsible for creating the connection to the service. The reason for this is that a single service can be used by multiple plugins, but the plugins should only know about its interface since there may be several implementation of IMyPluginServices. For instance, the Run method of the plugin instance would be:
public void Run(IMyPluginServices services)
{
services.DoSomething();
}
The problem I am running into is that I don't know how to create a service of type IMyPluginServices and pass it to the Run function. The service reference generated by VS 2010 doesn't seem to create an object of type IMyPluginServices that I can pass to it. Any help would be greatly appreciated. Thanks.
When you add a service reference in VS 2010 for a service it generates an interface named IMyService which contains methods for each OperationContract in your service. It also generates a concrete class named MyServiceClient, which can be constructed and then used to invoke your service.
Now, the problem that you're running into, I believe, is that MyServiceClient is a subclass of ClientBase<IMyService>, and does not implement the generated IMyService interface (which is a real pain).
To get around this problem I ended up making a new interface:
public interface IMyServiceClient : IMyService, IDisposable, ICommunicationObject
{
}
(Note: IDisposable and ICommunicationObject are only required if you want your module to be able to detect/react to faulted channels and other such things).
I then extend MyServiceClient with a partial class (in the assembly that contains my WCF Service reference):
public partial class MyServiceClient : IMyServiceClient
{
}
Now in my modules I can accept an IMyServiceClient instead of an IMyService, and still execute all of the methods that I need to. The application in control of the modules can still create instances of MyServiceClient as it always did.
The beauty of this is that your new interface and partial class don't need any actual code - the definitions suffice to get the job done.
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