I want to mock a ServiceContract. The problem is that Moq (and Castle Dynamic-Proxy) copies the attributes from the interface to the dynamic proxy which Wcf don't like. Wcf says: The ServiceContractAttribute should only be define on either the interface or the implementation, not both.
Exception is: InvalidOperationException - The service class of type Castle.Proxies.IWorkOrderRequestServiceProxy both defines a ServiceContract and inherits a ServiceContract from type IWorkOrderRequestService. Contract inheritance can only be used among interface types. If a class is marked with ServiceContractAttribute, it must be the only type in the hierarchy with ServiceContractAttribute. Consider moving the ServiceContractAttribute on type IWorkOrderRequestService to a separate interface that type IWorkOrderRequestService implements
Just experienced the same problem - so +1 for a solution! :-)
Update: http://code.google.com/p/moq/source/browse/trunk/Source/Proxy/CastleProxyFactory.cs contains a reference to a property (collection) called AttributesToAvoidReplicating, looks like a place to start looking in the Moq source code.
Update #2: Nailed it!
Add:
Castle.DynamicProxy.Generators.AttributesToAvoidReplicating.Add(typeof(ServiceContractAttribute));
before you wire up anything in your kernel.
Related
I have been doing laravel since 4 months. I don't find a clear difference between facades and contracts as they both are set of interfaces. Why would i use facades instead of contracts or contracts instead of facades?
The question whether to use Facade or Contract boils down how you want to resolve your classes and if you want to use interfaces.
Facade
A facade is a class and not an interface (here is an example facade).
A facade is only used to load a class from service container more convenient
The class that is going to be loaded is determent in the getFacadeAccessor() method of the facade class.
Example:
// Without facade - resolving from service container
app('some_service')->methodName();
// Do the same through facade:
someService::methodName();
Contract
A contract is an interface (here is an example)
A contract is used to load a class from service container more convenient AND as an interface
The class that is going to be loaded is determined in the service container, see Binding Interfaces To Implementations
Example: Assuming that class some_service implements interface Illuminate\Contracts\Config\Repository:
// resolving class directly from service container
app('some_service')->methodName();
// resolve through binding from contract
app('Illuminate\Contracts\Config\Repository')->methodName();
While looking at a variety of examples and how-tos for creating WCF services I notice that some people decorate the interface code with attributes and others decorate the implmentation code. I understand decorating the interface with [ServiceContract] but where is the proper place for things like [WebGet] or [WebInvoke] or [AspNetCompatibilityRequirements]?
Most attributes' proper location is not up the developer, but specified by the WCF documentation. See the examples in these pages for proper attribute usage.
WebGet - interface, operation contract:
http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webgetattribute.aspx
WebInvoke - interface, operation contract:
http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webinvokeattribute.aspx
AspNetCompatibilityRequirements - service implementation:
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.aspx
Since you are coding the class definition, it's best to place them in the same file as the class implementing them. Putting them on the interface makes it hard to remember how the method is to be used. With it right on the class and method implementations, you can't forget!
I am new to WCF; I have an abstract class that in my WCF service.
I am referencing that WCF service from another application that invokes it: I have it added as a Service Reference in my Visual Studio project.
I managed to serialize the derived classes using the ServiceKnownType attribute, but I cannot manage to make the base class automatically abstract in the service reference code.
Any ideas?
I'm not sure whether this is something that will work in your case, but you can't (with the normal Add Service Reference tool) directly generate abstract classes.
However, all generated classes are partial, so if you know the namespace, all that's required to make it abstract is a new file with;
namespace whatever.the.service.reference.namespace.is {
abstract partial class MyClass { }
}
...and the class will be marked abstract.
We are implementing IoC/DI in our application using NInject framework. We are having internal classes having internal methods. To implement IoC/DI, we have to extract interfaces. But if we are having only internal methods in an internal class, we can't extract interface for that class.
So is there a way to implement IoC/DI in such cases (internal class having only internal methods) or should we change our internal methods to public methods. Kindly suggest. Thanks
If your class is already internal then there is absolutely not difference between internal and public methods. public methods of internal classes are only internally visible.
If you stay with injecting concrete classes though you loose all the advantages of DI. So yes you should extract (internal) interfaces and inject the interfaces. This requires that the configuration code has access to the classes by either beeing in the same assembly of the assembly must be declased as friend assembly. Futhermore, you have to configure Ninject to allow none public classes. See NinjectSettings.
The only thing that you really need to make public is the interface (not the concrete implementation).
You can use an abstract factory or (easier) Ninject to map the public interface to the internal concrete; thus your client code just has to request an instance of "a thing" that implements the interface and your factory / container will return the implementation.
You should read up on Dependency Inversion Principle as well as it goes hand-in-hand with this.
You could use InternalsVisibleTo attribute in AssemblyInfo.cs file like this
[assembly: InternalsVisibleTo("Assembly_That_Should_Access_The_Internal_Class")]
I am fairly new to WCF and just have a question on how to correctly get MessageContract inheritance working. A simplified version of my setup is as follows - a "base" message type, and then another "test" message which inherits from it.
[MessageContract]
public abstract class BaseMessage
{ }
[MessageContract]
public class TestMessage : BaseMessage
{ }
I then have an asynchronous OperationContract on a ServiceContract defined as:
[OperationContract(AsyncPattern = true)]
IAsyncResult BeginFindRequest(BaseMessage request, AsyncCallback callback, object asyncState);
The problem that I am getting is when calling the BeginFindRequest method, and passing in a TestMessage instance for the request parameter, the WCF framework is deserialising the TestMessage instance to BaseMessage on the service/server side. As this is defined as an abstract class, it results in the following error:
"The message cannot be deserialized
into MessageContract type BaseMessage
since it does not have a default
(parameterless) constructor."
From the limited information that I can find on MessageContract inheritance, it seems that it should just work.
So my question is - what am I missing in order to get this to work; or should I perhaps rather define a seperate OperationContract on the ServiceContract specifically for that type - the downside being that I could end up with many additional OperationContracts?
In the end I found this blog post which hit the nail on the head -
Unfortunately the way that contracts
are expressed in WCF makes is very
easy to forget what their purpose is:
to define the messages send to the
operation and being sent back from the
operation. In reality you have to
think “how would I express this data
in XML?”. XML doesn’t support
inheritance so whatever you put in the
contract is going to have to have some
way of mapping to XML. The data
contracts used to define the messages
are simply a .NET typed convenience
for generating the XML for the data
you want to pass – if you view them
any other way you are destined for a
world of pain. So think about the data
you want to pass, not how it may
happen to be represented in your
business layer and design your
DataContracts accordingly.
http://www.dotnetconsult.co.uk/weblog2/PermaLink,guid,a3775eb1-b441-43ad-b9f1-e4aaba404235.aspx
So I will be refactoring to provide an additional method with an explicit contract type. This will also allow me to clean up the service implementation by removing all the type checking.
Thanks for the assistance.
OK, first question is: why are you really using Message contracts? Do you really have a need for that??
Typically, message contracts are only ever used when you need to tightly control the layout of your SOAP message, e.g. to satisfy a legacy system you need to call which requires specific headers and such.
A "normal" WCF call should hardly ever need to use a message contract.
You define your service calls (the methods on your service) using [ServiceContract], and the data structures being passed around as [DataContract]. If you have a DataContract, you have more options as to how to deal with inheritance / polymorphism in your service (more than with the message contract construct).
Marc
Is that possible to change BaseMessage so that it is concrete class with parameterless constructor?
The error message tells that there is no way to initialize the object of type BaseMessage because it is abstract.
The error simply wants you to have a default empty contructor that it can use. However, I agree with marc_s; in the projects I've worked on I've rarely used message contract, the only case I can remember was as part of a file transfer service where file chunks were passed in messasges.
Try decorating your [ServiceContract] with the KnownType attribute. Since TestMessage is not 'visible' from a public operation, this helps the plumbing know how to treat it when it sees it.
If this should allow the [DataContract] to be serialized as a TestMessage your still likely to need to handle multiple messages differently via 'is a' or some other casting.
Well I had declared this default (parameterless) constructor for sure, but that was not still working fine for me, for me the issue was, the access modifier was protected while it should be public:
public constructor() { }
^^^^