Unable to access classes via WCF - c#

I have two projects in the same solution, a service and a consumer app. In the service I have many classes that can be instantiated by the consumer app but some classes are not accessible. There's no difference apart from name. All classes are all Public so they should all be seen. Is there any buffering problems or anything else that could cause the problem to behave like this?

Consumer does not get access to Server classes when you use WCF or any other Web Services/Removing technology. Proxy classes are created instead. Think about them as set of Interfaces that are able to call method over app boundaries. You can instantiate proxy classes but when you call method proxy class will go to Service and call corresponding method of class hosted by service.
You need to use Class Library and move move your shared classes there (and deploy dll with Service and Consumer) if both parties use them.
Update (thanks razlebe):
Business logic should not be shared in DLLs. It should be hosted by server. But it will make sense to share supporting classes (for example class that do data formatting) to avoid code duplication.

When you update service class and change interface by:
Adding a method (Your case)
Removing a method
Changing signature
Your consumer needs to learn about the change. You have to update service reference (http://msdn.microsoft.com/en-us/library/bb628652.aspx) to rebuild proxy.
How to update it?
Check here to see how: http://msdn.microsoft.com/en-us/library/bb628652.aspx)
But one image is better than thousand words:

My guess is that the classes that "are not accessible" were created after the last generation of the proxy (classes of the service, client-side). Check if REgenerating the proxy helps.

Related

web service pointing to 2 classes

I could have sworn I saw this done somewhere, but I guess maybe it was a DLL, not a web service. I was originally doing this as a DLL, but now need to use a web service.
I have a service file (DataService.svc). I have class Foo and class Bar. Both have the same methods (Load, LoadAll, Insert, Update). I know that a web service doesn't support overloading, but I thought that since these were in separate classes it might be possible. Is there a way to configure this so that in my client, I could do this:
DataService.Foo.Load();
or
DataService.Bar.Load();
Thanks,
Andrew

WCF - regenerate client code from interface contract

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

WCF another best practice?

Ok so I have built my WCF service and its functioning great! However, I am starting to implement it into our pre-existing piece of software now and I am instantly running into the question, do I only use the proxy generated code and get rid of the dll that I used initially? Or do I keep both, and make distinctions between the two very obvious?
What I mean by keeping distinctions is, having a ServerUser and a LocalUser property that represent the same user object. However, my LocalUser property would be filled via the dll that the app initally ran with, if the application service is unavailable.
My main reasoning for this thought pattern is that if I remove my dll, I have a single point of failure. If for some reason my ServiceHost is just not up and running, but the DB server is, I would want my users to still be able to do their job. The features that the new WCF implementation utilize are not dependant for employees to do their job. It is more of a convenience in what the WCF service provides. Also, building in this kind of logic to the Service would allow service modifications more readily available in a non IIS hosted environment.
Also, is there a way to build in logic on the service so that when I pull down the proxy code for the client that it just knows to access the DB manually if the ServiceHost is unavailable? If this was a possibility, I think about 90% of all my problems would disappear.
Thank you in advance!
From what you describe it sounds like keeping your existing DLL, i.e. direct access to the DB, would best suit your needs. Having a WCF service adds nothing if, when it fails, you'll just use the DLL anyway.
Ideally you would go with the WCF service completly and offer some kind of redundency to deal with any potenial service issues. Plus, using a service will mean you won't have to deal with any DLL upgrades/deployments.
But, from your question, it sounds like there would be some real issues to deal with should the service not be available, so just do with the DLL.
EDIT: Just read the last part of your question and I don't think that is possible. The proxy code for accessing services is generated when you add the reference to your project. The kind of "dynamic" information you're after would actually require a service.
EDIT: As a follow up to my comment below you could test this by creating a DLL and class, lets call it Class1. Then create a WCF service with a method that will return Class1. Create a client application and add a reference to the service. If you look at the proxy-generated code you should see (hopefully...I'm thinking of this as I type :)) that the method returns Class1, but when you compile it won't be able to find Class1. This is because Class1 does not have the DataContractAttribute which would auto-generate Class1 on the client. So, you have to distribute the shared DLL to the client. Now when the method returns and WCF tries to re-create Class1 it will use the local version in the shared DLL. Your other DLL, which will already be on the client, would use the same shared DLL.

Portable class library for shared [DataContract] class

This is probably a real simple one. I wished to create some code inside a [DataContract] class which is used to communicate information between a WCF service and consuming application.
I created a new Portable Class Library project and created inside it my [DataContract] class. It's really simple - it has a few easy attributes (strings mostly). I added a reference to the DLL in my WCF service and republished it. I then deleted the service reference from my consumer project and re-added it. It adds fine, no problems there.
The problem comes when I want to actually use it. See, the type is called 'Eval'. Some of the WCF methods return this 'Eval' type. So I have this serialized version of 'Eval' in the Reference.cs file within my service reference. Obviously this doesn't contain the method I'm looking for since it's just the serialized version. I can add the dll to the client project as well, but then I have two different Eval objects in two namespaces, and only the one from reference.cs is valid to be returned from the service calls.
So how do I ... erm... merge the two? So as the Eval objects that come back from the WCF service calls also have access to the method in question?
Thanks for reading, and stay safe on those roads.
When generating service reference you can specify what classes should be reused and what classes should be generated from service

Using a webservice type directly through the DLL

I have a webservice with a function that returns a type (foo). If I consume this webservice in .NET through the 2.0 generated proxies, it creates a class called foo in the generated proxy. If I have the DLL that contains that class (foo) that is the DLL being used by the webservice, is there any way to have it use that class instead of creating a custom proxy class? I'm looking for something similar to what remoting does... but not remoting.
I've seen 3 ways of doing this:
Let Visual Studio generate the proxy and then change the classes in the proxy to the full class names of the dll, by hand. Works, but you would have to do this again everytime you update your proxy. Plus it's really dirty, isn't it?
Use a generic class/method that
creates deep copies of your proxy
objects into the "real" objects by
reflection. Works, but of course
with a little performance offtrade
Use WCF, where you can reference the
dll with the data contracts (your
data classes) and use them instead
of creating any proxy by code
generation.
I think the key issue here is in generating the proxies. I've generally used two different approaches to web services:
1) Traditional services, where you expose methods and a client generates the proxy in Visual Studio to consume the methods.
2) Request/Response services, where the exposed "service" is more of a pass-through and the "actions" being performed are encapsulated in the objects being sent to and received from the service. These actions would be in that shared library that both the server and the client have.
In the former I often run into this same problem and I don't really think there's a solution, at least not one that Visual Studio is going to like at all. You could perhaps manually modify the generated proxies to use the other classes, but then you'll have to repeat that step any time you re-generate. Conversely, you can generate outside of Visual Studio in something like CodeSmith (the older version is free, but depends on .NET 1.1), which will require some work to create a template for the proxies and to step outside the IDE to re-generate any time you need to update them.
I can recommend a good tool for the latter, however, and that would be the Agatha project. It takes the approach of separating the "service" from the "actions" that are being performed, and makes the approach of the shared library very easy. Such a re-architecture may very well be out of the question for the project you're working on depending on your schedule, but it's definitely something to explore for future projects.
You could write your own proxy class, or you could implement a constructor on your Foo class that takes an instance of the generated Foo class and copies over the data as appropriate.

Categories

Resources