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.
Related
I generated the client code from a for OData V4 service (Dynamics 365 metadata) using the OData V4 Client Code Generator project template (https://marketplace.visualstudio.com/items?itemName=bingl.ODatav4ClientCodeGenerator).
The code was generated fine and it compiles. Now the problem is that I simply cannot find a way to make a connection (or context) that can be used when querying data (OData linq queries for example).
All the examples I've read basically just "start right away" with having a Context or a Resource available, but none of them actually specify why or how it's there.
For example https://blogs.msdn.microsoft.com/odatateam/2014/03/11/tutorial-sample-how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class/ shows how to generate the classes and then creates an instance of NorthwindEntities (or XxxxEntities) which, again, I don't have generated (I don't have anything named "Entities" in the generated code).
https://stoneridgesoftware.com/working-with-the-odata-endpoint-in-dynamics-365-for-operations/ just simply creates a new instance of Resources class, which I don't have (what is it?). I have nothing named Resources in the generated code.
Obviously it can't be this difficult so maybe I'm missing something.
EDIT: the generated class contains only classes Crmbaseentity, CrmbaseentitySingle, ExtensionMethods and then the entity classes themselves. There simply are no other classes.
Any ideas how to do this differently or any blog posts that I've missed?
The problem was that I used the code generation template from https://github.com/Microsoft/Dynamics-AX-Integration/tree/master/ServiceSamples/ODataUtility. When I added the OData service to the project as a "service refernce" and used the wizard, then the code was generated normally.
I still don't know the actual reason why the T4 template didn't work.
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 have 3 projects in my solution.
A common class library named ReportBuilderLib
A WPF application named ReportClient that contains a service reference to a 3rd project -
A WCF web service which contains web methods for my application to call upon.
Initially when setting up both the service and the application i added the common library to references on both projects so that i could use the classes i needed to in both.
It quickly cam clear that in the process of generating the code to use the web methods in my client application, it was automatically importing certain namespaces that i had used in service application.
This was throwing me conflicting reference warnings as they were effectively being imported from two separate resources.
I then removed the reference to the library in my report client, i could see that VS was only importing one out of the two namespaces my client requires. Both of which are returned by methods in my ServiceContract!
Having looked at the generated code for the client, it seems to be re-creating the classes i have included in the library and providing only the public properties for access.
Is it possible to use librarys like i am trying to with WCF. Or should i scrap the common library idea and simply create some data transfer classes on the service end?
You should be able to reference the common library on both ends, but it may be useful and less of a headache to implement data transfer classes like you suggested. Using special classes (or serialization like JSON) to send and receive data from the service would make it easier for you to re-use the service for multiple client projects.
Any time you decrease the coupling between layers of an application you make it easier to implement changes/upgrades in the future :)
I have a Silverlight app I've been working on. This app relies on a custom class called Customer. Instances of this class are returned from my web service. I've need to add a method called CalculateLoyalty() to this class definition. I want CalculateLoyalty to be available on both the server and client-side (my Silverlight app).
Currently, I can use CalculateLoyalty just fine on the server. Unfortunately, the method doesn't seem to get passed across the wire. I have a hunch its some serialization thing. How do I add a method to my class definition on the server-side and ensure that it is available on the client-side?
Thank you!
When you generate a service reference, it only copies public properties and fields. You can share classes between your server and client and avoid using a service reference. I'm not going to go into detail with how to do this, but here are some related questions that explain what needs to be done.
Create WCF Client without auto generated proxy
Call synchronous WCF operation contract methods asynchronously on silverlight
Even if you do this, I have to recommend against putting logic on your DTOs. I'd recommend creating a LoyaltyCalculator class and passing a Customer to this. In fact, you can do this even if you use generate your client through the Add Service Reference option.
Your defult Silverlight solution will have 2 projects.
MyApp - This is your Silverlight project.
MyApp.Web - This is the host web project.
You don't need to do this, but I recommend adding 2 new projects.
MyApp.Shared - A .NET Class Library
MyApp.Shared.Silverlight - A Silverlight Class Library.
At this point, you will want to add a project reference to the appropriate class library to both your Silverlight project and your Web project.
Add class LoyaltyCalculator to MpApp.Shared, or MyApp.Web if you don't want to make the shared libraries. Go ahead and implement this class here.
Now in MyApp.Shared.Silverlight, or MyApp if you don't want to make the shared libraries, select Add -> Existing Item. Browse to and select LoyaltyCalculator.cs. Do Not Double Click It!!! Instead, click the little down / more arrow on the Add button. Now select Add As Link.
LoyaltyCalculator is now available to both your server and client and you only have to maintain one copy.
Methods are not serialized, only data (property/field values) are, so you must be using a different version of the .cs file on the server than you are on the client. Are you sharing the source code between your web service and silverlight projects?
If you are on .NET 4.5/VS2012, you may be able to create a "Portable class library" with your class in it that can be referenced from both your .NET and Silverlight projects.
I'm working with an old windows app in visual studio 2005. A webserviced referenced in the original app has 2 functions and when i peak inside the auto-generated reference.cs file I notice a couple of other functions to allow async calls have been geenrated i.e. BeginWhateverFunctionNameIsCalled and EndWhateverFunctionNameIsCalled.
My problem is that I've created a new windows app and added the same web references but the Begin and End functions are not generated in my reference.cs proxy class. Anyone know whats going on?
It is VS2005, and isn't generating the async methods. OK; is it .NET 2.0 or .NET 3.0 (via the VS2005/WCF add-on)?. It looks like "wsdl.exe" (the original) will generate "FooAsync" methods, but WCF ("scvutil.exe") may generate the "BeginFoo" pattern. You might also look to see if you have used WSE*, for example, "wsewsdl2.exe" or "wsewsdl3.exe".
My bets would be of the WCF version. Note also that different frameworks (Silverlight etc) have their own proxy generation classes.
First step would be to check wsdl file returned by web service if those methods are still available on the server.