I have an auto-generated WCF Client and I thought that I would be able to add Data Annotations by using a partial class and adding a Metedatatype attribute to it. Seemingly this will not work; as I have seen from other posts the MetadataType needs to be registered and I have tried this approach but with no success.
Validation works if I place a validation attribute directly on the field, and maybe I should do this and manually create the client DTOs, but I was wondering if anyone out there knew of a way to get this working.
I will happily post some code if people think it will help.
Thanks.
Create in your solution another project (let's call it "SolutionName.Infrastructure") responsible for storing DataContracts and ServiceContracts. Then in your service and client projects add reference to Infrastructure project. Such a solution declines the amount of code being created since now you store all code in one place depriving of auto-generated code. You can effortlessly leverage of DataAnnotations. The downside is that you need to adjust app.config file on client side manually.
Related
I have quite simple WCF service and its client - both reside in my application.
At the moment interface used for WCF contract consist of 3 methods, and according to MSDN I generated client code for it using svcutil.exe CLI.
But now I added one more method. And I wonder - is there a simpler way to regenerate client code (probably directly in VisualStudio) using doing less actions for this operation?
Right click on your Services References and select the service you'd like to regenerate code for. Then click Update Service Reference. Then you're done.
Update after re-reading the question I realized its possible you don't know how to import WCF Services.
Here is how its done:
Update as per comments:
There are two workarounds for this, The first is to run the application outside of your IDE and then go into your IDE to import it.
The second one is to create a proxy client that implements your service contract. When you are using the client proxy you can right click on the interface and select an option to implement the interface. Assuming that the set up is done correctly, if you make a change to the ServiceContract you can then go to your proxy class and just click implement interface which will update your proxy class. by doing this you bypass the svc utility completely; however, you have significantly more control over your development. You need to work with DLLs to accomplish this; however, it works like a charm. Here is an example though I doubt you need one I'll just leave it for the sake of completeness. Use this example for duplexes
Following the instructions to use the Reflection Provider (http://msdn.microsoft.com/en-us/library/dd728281.aspx) everything works well, until I move the classes Order and Item to a Class Library and reference the class library from the web project with the SVC file.
Move the POCO classes into the WCF project all goes well.
Move the POCO classes out of the WCF project into separate assembly, I get a 500 with no explanation.
I want to be able to keep my poco classes in a separate project and expose them with an OData endpoint. What am I doing wrong?
--UPDATE--
The scenario described above is meant to illustrate a problem I have found using the WCF OData Reflection Provider. It is not my real problem, but is easier to explain for illustrative purposes.
Try upgrading to the latest version of WCF Data Services (currently 5.3), if you aren't already on it. I reproduced your issue using the version of WCF Data Services that ships with .Net 4.5, but once I upgraded the references in both assemblies to the latest release of Microsoft.Data.Services using NuGet, the problem went away.
If you're already using the most up-to-date version of WCF Data Services, make sure that both assemblies are referencing the exact same version of WCF Data Services.
If neither of these fix your problem, add the following attribute to your DataService class to get a more detailed error message and stack trace:
[System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class YourService : DataService<...>
And then please update your question with the results of that (if the solution doesn't immediately jump out from the stack trace).
(disclaimer: I usually don't like answers of the kind that don't help you with your problem but rather explain why your problem isn't the correct problem, but I think it's justified in this case :))
If you think about it, you don't really want to do that:
The Order and Item classes aren't really POCOs at all; they're not 'plain' C# objects; they have data attributes on them, which make them data transfer objects (DTOs).
They belong to the interface between your service and its clients;
The domain entities (or POCOs) Item and Order will, most likely, be a bit more complex, and contain other things besides data, such as operations and business logic.
I believe the correct way to go is to have a rich domain model, in which Order and Item contain a full set of attributes and operations, and on top of that, a DTO layer, which contains only those attributes that your service client needs.
Sending your POCOs over the wire was termed 'the stripper pattern', and I believe it's best avoided.
I have made a complex solution using EF5 (Lets call it EF5), this solution works perfectly fine and has a Logic.cs file,lies at the app_code, which has multiple functions that access , control and modify this solution, So far so good.
I would like that my business' clients to access these function and I'd like to expose these functions by using WCF.
The steps I did are the following.
Adding WCF project to the solution where the EF5 project is.
Writing "OperationContract"s for each of the functions I'd like to expose to my client.
Try implementing each of the functions by calling the EF5 functions.
The problem lies at the implementation, VS fails to recognize the logic.cs file , and therefore I cannot call the functions and expose my EF5 project to my clients.
I am new with WCF, obviously I'm doing something wrong here.
My question is, how do I expose EF5 project's functions, that lies in a .cs class , to WCF?
I believe that the major mistake that I made was that I didn't make a WCF project and added EF5 item to it, but I'm not entirely sure.
Here are the screenshots that displays my steps to add the EF5 Reference to the WCF project.
Thanks
You need to add a reference to your EF5 project from your WCF project.
You also need to make sure all your function to be called in Logic.cs are public.
Also make sure you are 'using' the namespace in which those functions are declared.
When I add a Service Reference to my project in Visual Studio, it autogenerates a proxy to the service called ServiceNameClient. I really don't like that naming scheme. Is there a way to change it to something like ServiceNameProxy?
I can rename the class myself in the autogenerated code, but any time I add new features to the service, and go to UpdateServiceReference, it re-generates the code and changes it back to the old name.
My brief web search uncovered a way to create my own WCF Proxy Generator class, but I'm hoping there is some simple attribute that changes how the class name is calculated.
Like you, I have been dissatisfied with Visual Studio's code generation of the WCF service reference. I never have liked the naming scheme, and I also don't want to change it every time I update my service.
To answer your question, I don't know if there's a way to change it or not. But I had an epiphany after watching this video at dnrTV. Since then, I've been manually coding my WCF client proxies using a naming scheme that fits my project.
I'm still new to the ASP.NET world, so I could be way off base here, but so far this is to the best of my (limited) knowledge!
Let's say I have a standard business object "Contact" in the Business namespace. I write a Web Service to retrieve a Contact's info from a database and return it. I then write a client application to request said details.
Now, I also then create a utility method that takes a "Contact" and does some magic with it, like Utils.BuyContactNewHat() say. Which of course takes the Contact of type Business.Contact.
I then go back to my client application and want to utilise the BuyContactNewHat method, so I add a reference to my Utils namespace and there it is. However, a problem arises with:
Contact c = MyWebService.GetContact("Rob);
Utils.BuyContactNewHat(c); // << Error Here
Since the return type of GetContact is of MyWebService.Contact and not Business.Contact as expected. I understand why this is because when accessing a web service, you are actually programming against the proxy class generated by the WSDL.
So, is there an "easier" way to deal with this type of mismatch? I was considering perhaps trying to create a generic converter class that uses reflection to ensure two objects have the same structure than simply transferring the values across from one to the other.
You are on the right track. To get the data from the proxy object back into one of your own objects, you have to do left-hand-right-hand code. i.e. copy property values. I'll bet you that there is already a generic method out there that uses reflection.
Some people will use something other than a web service (.net remoting) if they just want to get a business object across the wire. Or they'll use binary serialization. I'm guessing you are using the web service for a reason, so you'll have to do property copying.
You don't actually have to use the generated class that the WSDL gives you. If you take a look at the code that it generates, it's just making calls into some .NET framework classes to submit SOAP requests. In the past I have copied that code into a normal .cs file and edited it. Although I haven't tried this specifically, I see no reason why you couldn't drop the proxy class definition and use the original class to receive the results of the SOAP call. It must already be doing reflection under the hood, it seems a shame to do it twice.
I would recommend that you look at writing a Schema Importer Extension, which you can use to control proxy code generation. This approach can be used to (gracefully) resolve your problem without kludges (such as copying around objects from one namespace to another, or modifying the proxy generated reference.cs class only to have it replaced the next time you update the web reference).
Here's a (very) good tutorial on the subject:
http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx