Can a web service use other classes that I have in a project or should it be standalone and use only it's own methods?
Thanks !
Does a web service can use other classes that I have in the project ?
YES it can. You can also return your custom class object, after serialization. Its very unusual that you would see webservice interacting with primitive types only (internally).
You can create instances of other classes and use them to perform work.
Any class in the same project or a referenced project should be usable, subject to the usual access modifiers.
You'll either need to include a using statement. Following example assumes you want to use SomeClass which resides in MyAssembly.SomeLibrary:-
using MyAssembly.SomeLibrary;
// in code block somewhere
var thing = new SomeClass();
or fully qualify the name of the class.
var thing = new MyAssembly.SomeLibrary.SomeClass();
It sounds like you are asking in terms of best practice rather than "is this technically possible". The answer depends on the class you want to use I suppose, but in general it is acceptable to use any other classes or libraries you want in a web service as this will not affect the client being able to consume the service (i.e. using LibraryA on the service side does not mean client 1 has to also have LibraryA installed to use your service).
It is possible to reuse those classes service side (in Visual Studio this is done by ticking the "Reuse types in referenced assemblies" box when you configure a service reference and then adding a reference to the appropriate project / dll), but I would generally advise against it as it can confuse matters - not all clients will have access to those dlls when consuming your service.
Related
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.
A couple of very basic questions. I am new to WCF and I am building an application which has a Service Project, A Web Application project and a few Class library projects which I use for Business logic, etc.
I am hosting the WCF locally on my IIS and trying to add service references to the projects.
Question 1. When adding references, should I add a service reference to each project separately or is there a way I can share the same Service reference across the projects?
The reason I ask is because if I add separate references, each reference gets it own namespace, and when I have to pass the same object between the projects, I get an InvalidCastException because each ServiceClient has a different namespace.
Example -
Site.Business.XDataService.XDataServiceClient().GetItem()
is not the same as
Site.Web.XDataService.XDataServiceClient().GetItem()
Question 2. I specified the address of the local service in the class that implements the Service interface as below -
[ServiceBehavior(Namespace = "http://localhost:801/XDataService.svc", IncludeExceptionDetailInFaults = true)]
This doesn't seem right. If I move my code to a different/live environment, I would obviously have to change this part again and recompile. Where can I specify this (Web.Config?) so that I can change this address without having to rebuild my app?
Appreciate any kind of insight.
Thanks!
In answer to the first question, you can put the service reference in its own project and reference that project in all the other projects that need to access that service.
Basically all the service reference is is a lump of .NET code - namespace, class, etc.
Better yet (!) for a WCF service you also get an interface thrown in for free (more or less the same interface that you defined for your service) so you can do nice things in terms of dependency injection making testing etc easier.
First question - the service is just like any other code. For example, database access code. Should you put that in every project that needs to access your database? No - you should put it in a project which those other projects can reference.
As for your second question, you're specifying a namespace but I expect you think you're specifying a service endpoint address. The namespace is just like a C# code namespace - it essentially provides further identification and clarity in the event that you have multiple objects with the same name. Normally you'd use a namespace like http://mywebsite.com/MyService/VersionNumberIfRequired or similar.
The address itself is specified in configuration. The address will change depending on environment / deployment location - the namespace shouldn't.
Consider the following Visual Studio project structure
ProjectA.csproj
AClass.cs
ProjectB.csproj
References
ProjectA
Web References
AWebService
AWebService.csproj
References
ProjectA
ReturnAClassViaWebService.asmx
The issue occurs when ProjectB adds the web reference to AWebService and automatically generates all the proxy code for accessing AWebService including a new implementation of AClass. Since all of our other code needs to use the AClass defined in ProjectA, we're forced to convert the AWebService.AClass returned from the service into something we can use.
We're currently considering two solutions, neither of which are ideal.
Manually editing the generated Reference.cs to remove new definitions of AClass
Serializing AWebService.AClass to a stream then deserializing to ProjectA.AClass
Does anyone have any better solutions? This seems like something common enough for other developers to have experienced it.
Ideally we would like to have the proxy code generated in ProjectB to reference ProjectA.AClass rather than generating a whole new implementation.
Our environment is VS 2008 using .NET 2.0.
I have had the same problem that you are describing and I have tried both of the options you specify without being entirely happy about either of them.
The reason we both have this issue is at least partly because the shared-library-between-consumer-and-provider-of-a-web-service-solution is in violation of accepted patterns and practices for web service design. On the consumer side, it should be sufficient to know the interface published in the WSDL.
Still, if you are prepared to accept a tight coupling between your web service provider and web service consumer and you know for certain that your current client will never be replaced by a different client (which might not be capable of referencing the shared library), then I understand why the proposed solution seems like a neat way to structure your app. IMPORTANT NOTE: Can we really honestly answer yes to both of these questions? Probably not.
To recap:
The issue appears when you have classes (e.g. a strongly typed dataset) defined in some sort of shared library (used on both client and server).
Some of your shared classes are used in the interface defined by your web service.
When the web reference is added there are proxy classes defined (for your shared classes) within the web reference namespace.
Due to the different namespaces the proxy class and its actual counterpart in the shared library are incompatible.
Here are four solutions that can be tried if you want to go ahead with the shared library setup:
Don't. Use the proxy class on the client side. This is how it is intendend to be done. It works fine unless you simultaneously want to leverage aspects of the shared library that are not exposed by the web service WSDL.
Implement or use a provided copy/duplication feature of the class (e.g. you could try to Merge() one strongly typed dataset into another). A Cast is obviosuly not possible, and the copy option is usually not a very good solution either since it tends to have undesirable side-effects. E.g. When you Merge a dataset into another, all the rows in the target dataset will be labeled as 'changed'. This could be resurrected with AcceptChanges(), but what if a couple of the received rows were actually changed.
Serialize everything - except for elementary data types - into strings (and back again on the consumer side). Loss of type safety is one important weakness of this approach.
Remove the explicit declaration of the shared class in Reference.cs and strip the namespace from the shared class wherever it is mentioned within Reference.cs. This is probably the best option. You get what you really wanted. The shared class is returned by the web service. The only irritating drawback with this solution is that your modifications to the reference.cs file is lost whenever you update your web reference. Trust me: It can be seriously annoying.
Here is a link to a similar discussion:
You can reuse existing referenced types between the client and service by clicking on the 'Advanced' button on the 'Add Service Reference' form. Make sure the 'Reuse types in referenced assemblies' checkbox is checked and when the service client is generated it should reuse all types from project A.
In past versions this has not always worked correctly and I've had to explicitly select the shared type assemblies by selecting the 'Reuse types in specified referenced assemblies' option and then checking the appropriate assemblies in the list box. However, I just tested this with VS 2008 SP1 and it appears to work as expected. Obviously, you need to make sure that the types that are being used by the service and client projects are both from project A.
Hope that this helps.
We encountered a similar problem with one of our projects. Because we had several dependencies, we ended up creating a circular reference because project 1 required objects from project 2, but project 2 could not be build before project 3, which relied on project 1 to be build.
To solve this problem, we extracted all the public standalone classes from both projects and placed them inside a single librarie. In the end we created something like this:
Framework.Objects
Framework.Interface
Framework.Implementation
WebService
The WebService would be linked to all projects in our case, whereas external parties would only be linking to the objects and interface classes to work with. The actuall implementation was coupled at runtime through reflection.
Hope this helps
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.
In my client, I'm trying to declare an entity type from the service....
MyService.MyClass myClass = new MyService.MyClass();
....
MyClass isn't available.
The assembly MyClass is within is referenced by MyService. What am I missing?
Generally, to preserve the service boundary, you work with mex-generated proxy classes at the client; these are structure only, so don't have any methods etc (just properties), and may even have different names (and almost certainly a different namespace).
However; if this .NET to .NET, you can get WCF (via either svcutil or the IDE) to re-use types in existing assemblies. Via the IDE it does this automatically (by default - you can disable it) if you have a reference to a dll containing matching types. At the command line, you use /r IIRC.
From the client's perspective, the service is just the interface, the client doesn't have access to the guts of the server. The types you might need should be exposed as part of a contract externally (like in a seperate assembly).
You probably want to Add Service Reference. Note that the generated class will have a slightly differnt name/namespace to your server implementation.