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.
Related
I am having problems in working with the Namespaces in the WCF. I have never done it before. I have tried a lot to find solution on the google. But still I am not able to find a solution for it.
I have written a WCF service which is divided in 3 projects and additionally i have created a models project:
Contracts (ServiceContract)
Service (Codebehind)
Host (ServiceHost)
Models (DataContract classes)
When I am hosting the service in IIS, it is generating the WSDL fine but there are namespaces which I have not defined as below:
http://schemas.microsoft.com/2003/10/Serialization/
http://schemas.datacontract.org/2004/07/My.Models
The problem is that I want to access all my service contracts and data contracts through same namespace only.
Because when the DataContract classes are generated in the proxy class, it is being duplicated. Mean if I have a class ClassA in my Models projects, then it is giving me 2 classes as ClassA and ClassA1.
I saw that in proxy class that these are there in the different namespace. So, I want to avoid that.
I also want to avoid ChannelFactory method, because there are a lot of OperationContract functions. So, don't want to code that much with hand but would like it to be auto generated in right fashion.
Any help is greatly appreciated. Thanks in advance.
I also want to avoid ChannelFactory method, because there are a lot of
OperationContract functions. So, don't want to code that much with
hand but would like it to be auto generated in right fashion.
This makes no sense at all. The ChannelFactory<T>.CreateInstance() method is much lighter than a wsdl-generated service proxy, and the amount of code you will have to write is comparible.
Service references are designed for when you're calling third party services which you have no control over or internal visability of.
There is aboslutely no situation I can think of where using a generated service reference is preferable to using ChannelFactory if you have access to the service definition assemblies.
This is especially the case for your requirement to manipulate the service wsdl in order to control code generation on the client side.
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
I've built a service and corresponding data model in c#. A third party wants to integrate with service. I'm required to provide xsd-schema.
The "xsd" tool in VS does the job but somehow namespaces is lost in the process. Is it possible to include the namespaces I've defined on my classes(using the DataContract tag) using the xsd-tool? Is there other tools out there to convert a .cs model to xsd?
Update:
The service is rest api based on json used by serveral client. This issue arrised when I wanted to integrate biztalk with this api. I could manuanly add namespace but this is tedious as it's a huge service contract that change alot.
Based on the suggestions from #dbc svcutil turned out to be the solution. Using the datacontract only flag I was able to generate service model containing correct namespace references.
I am working with integrating an MVC4 application with WCF services. At present, I generate a service reference from the WCF services endpoint using svcutil.
I have a number of services eg. a BooksServiceReference and CarsServiceReference. An issue I have is that both service references share the same entities but my code treats them differently as they have different namespaces. For example, both references have a Price entity which is the same, only a different namespace.
What I want to do but unsure in doing is the follows. Use T4 mapping to take each class in the service reference file and generate a DTO object for it. So at this point, I have my own DTO object for all classes in the service reference.
Next step, exclude the common entities via a T4 configuration file that are common to both service references. I believe this will be manual and I am fine with this.
For the common entities to, I create a separate T4 configuration file which generates these in to one DTO file.
I have only done some brief work with T4 generation so would appreciate any assistance with the above?
I've worked on a few C# projects over the years, and generally the rules are consistent from project type to project type. But having started a WCF Webservice project, I'm finding things a bit different. I have to validate incoming XML to a schema. I've created a folder off the project root, XSDs, for storing the schemas. In previous projects, when referencing an XSD in a folder, I've used something like this:
XmlTextReader textReader = null;
XmlSchemaCollection xSchemaCollection = null;
XmlValidatingReader valReader = null;
string uri = string.Format(#"{0}\{1}", Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), XSDPath);
// text reader object
textReader = new XmlTextReader(uri);
xSchemaCollection = new XmlSchemaCollection();
xSchemaCollection.Add(null, textReader);
// XML validator object
valReader = new XmlValidatingReader(strXMLDoc, XmlNodeType.Document, null);
The properties for the XSD files are set to Copy Always to target folder. Normally, I get a valid path to the XSD, and things proceed just fine. But in this WCF Webservice project, the path that the XSD files get copied to is a temporary directory, and I don't get a valid path. The xSchemaCollection.Add method fails.
BTW, the XSD folder isn't in the WCF project at this point. I added a class library project (in which the above code currently resides), and that's where the folder and files are. I expected this to eliminate the temp-directory problem, but it didn't.
Any ideas what I'm doing wrong? Thanks in advance.
WCF is a very powerful framework, but one of the core concepts of WCF is that the service definition is abstracted away from the implementation details of the communication channel. This means that a WCF service has no knowledge of what XSD files are used to describe its content, or even if XSD files are used at all (a service binding doesn't necessarily use SOAP).
WCF works really well if you're trying to follow an existing protocol, or if you're trying to customize one aspect of a complex protocol in which every other aspect of the protocol conforms to web standards. However, it sounds like what you're doing is more down and dirty than that.
If you find that you must process SOAP messages directly in a way that is non-standard, WCF may not be the best tool for the job. I would recommend that you consider using other service implementation strategies, such as an HttpHandler or a good old asmx file. Asmx based web services are nowhere near as sophisticated as WCF, but it is this very lack of sophistication that makes them more flexible for non-standard protocols.
I think that if, for some reason, you have an issue to access the XSDs via the file system, then I would most likely embed them as resources within an assembly. All you have to do then is to use a custom resolver (from the sound of it, these XSDs don't seem to make use of includes/imports; it they do, the custom resolver is definitely the way to go)...