I used the ServiceKnowType as you suggested but added it to the ServiceOperation rather than the ServiceContract (eitherway way worked, but I wanted to be more specific).

The reason why it wasn’t showing up because my Service Contract only had one method that returned a String type. As soon as I changed the return type to Object it showed up.

[Serializable]
public class Ping3Result
{
public String Name;
public String GID;
}

[ServiceContract]
public interface IMyPingTest
{
[OperationContract(ProtectionLevel = ProtectionLevel.Sign)]
[ServiceKnownType(typeof(Ping3Result))]
Object Ping(String str);
}

Also, I needed to use the [Serializable] rather than [DataContract]. Again, either would have worked. But in my context, i need to serialize the object using the XmlSerilaizer, sign and encrypt the final string (object).

And as stated before, it would have been queued into a database to be retrived by another application to decrypt, verify the signature then deseralize back to the correct object type. To make matters simpler, I could have just used XSD for that particular object as the real consumer of the object doesn’t care about web services or WCF

Thanks for you help!!! You lead me in the right direction.

Ross

BTW – I can’t use the ProtectionLevel attribute. When the caller recieves the result, they must put it on the queue and the object must remain encrypted. The problem with WCF’s ProtectionLevel is that it’s point-to-point, not end-to-end. Meaning that the message will be signed and encrypted across the wire but when the receiving WCF client recieves it, WCF will automatically decrypt and verify the signature. At least that’s how it seems to work.

I’ll back to you when I find a resolution. That might be a few days the way things are going I’ll retry the SeviceKnownType attribute one more time. but when I use the svcutil to generate the proxy, I don’t find any reference to it.

Thanks for your help thus far.

Ross

adding ServiceKnownType should work. If the type doesn’t show up in your wsdl take a look at imported shemas. There should be lines reading something like this:
<wsdl:import namespace=”MyServiceNamespace” location=”http://localhost/MyService?wsdl=wsdl0″/>
<xsd:import schemaLocation=”http://MyService/HelloWorld?xsd=xsd0″ namespace=”http://schemas.microsoft.com/2003/10/Serialization/”/>
…

If you need to deal with encryption/decryption and signing messages you may want to have a look at WCF’s security features. Here are some links that might be a good starting point:

http://www.code-magazine.com/Article.aspx?quickid=0611051

http://msdn.microsoft.com/en-us/library/aa347791.aspx

http://msdn.microsoft.com/en-us/library/aa347692.aspx

http://www.codeplex.com/WCFSecurityGuide

Btw: How does the caller know how to deserialize the string? You should consider changing your interface definiton!

How would I go about changing my interface definition to somehow state that I require the return string to be decrypted, verify the signature and deseralize the string to the MyResult type?

I really appreciate you help on this. It’s funny, I can do this in the old way be adding the type to the service interface, but in WCF I can’ seem to find the anwser yet. I know it’s possible. I might want to use the XmlSerializer in place of the DataContractSerializer and see if that works.

I’m not sure if I really understand what you want to accomplish.
Do you only want your type MyResult shown up in your WSDL without using the type in any of your methods?
If you do try adding the ServiceKnownType attribute to your interface like this:

[ServiceContract]
[ServiceKnownType(typeof(MyResult))]
public interface IMyService
{
// …
}

This will lead to the following definition beeing added to your wsdl:

<xs:schema elementFormDefault=”qualified” targetNamespace=”http://schemas.datacontract.org/2004/07/Contracts”>
<xs:complexType name=”MyResult”>
<xs:sequence>
<xs:element minOccurs=”0″ name=”SomeValue” nillable=”true” type=”xs:string”/>
</xs:sequence>
</xs:complexType>
<xs:element name=”MyResult” nillable=”true” type=”tns:MyResult”/>
</xs:schema>

Btw: How does the caller know how to deserialize the string? You should consider changing your interface definiton!

So my question is, how do I include this type in the WSDL without having to declare it being used as a type in the ServiceContract definition?

[DataContract]
pubic class MyResult
{
[DataMember]
public String SomeValue;
}

[ServiceContract]
public interface IMyService
{
[ServiceOperation]
public String MyMethod(); // return a serialized object of type MyResult
}

I need to ensure that the result remains encrypted and signed without having WCF involved.

Any help would be greatly apprieciated,

Thanks,

Ross

http://dkturner.blogspot.com/2008/02/shared-apis-part-1-of-4-why-and-how.html

That’s pretty much how I did it. Great minds think alike . I was already using a surrogate for other reasons, so it wasn’t too much code. Also, I didn’t use a special attribute on the operations, I just made the GetObjectToSerialize method do a little more work, using reflection to decide if the actual type was a known type and assuming it needed to slice otherwise. Oh, and I created a generic class called RefBase, which implemented the Slice() method (returning T). So my transport objects all follow a similar pattern:

[DataContract] class FooRef : RefBase { [DataMember] int id = 0; /* etc */ }
[DataContract] class FooHeader : FooRef { /* summary info goes here for those services that need summaries */ }
[DataContract] class Foo : FooHeader { /* adds the rest of the detail */ }

Some additional commentary (I’ll post more on my blog when I have the time):

1. The whole [KnownType] thing sucks. Yes, it’s handy when you need it, but I really haven’t run into that many contracts that use polymorphic messages. I’ve found that one tends to write multiple operations rather than implement a choice{ } data-type. That said, ASN.1 and most of the major protocols support choice-types, so I’m glad WCF does too. But it really should understand that if I don’t specify choice, then I probably want to slice! The one situation where I’ve found choice-types really useful is when passing changesets. But even then, it’s probably better to do it as (BeginChangeset(), AddXXXChange, AddYYYChange, …, CommitChangeset()).

2. On a slightly different point, when you really get into multi-tier programming, AOP starts to make a whole lot of sense. I really, really don’t want to re-implement my transport class on the server side and on the client side; and I’m equally opposed to putting client or server logic in the (shared) service API library. Another thing that I often want to do is aggregation (one UI facade representing multiple data objects). All these things are good’n'easy with AOP. Pity the CLR doesn’t support injection (except when you start playing with ContextBoundObject, which is interesting but bad design, too special-casey, and I really am getting carried away here…).

I’ve discussed (2) with my colleagues, and the best we’ve come up with is:

namespace API {
[DataContract] public class Customer {
[DataMember] protected string name = null;
}
}

namespace Server {
public class Customer : API.Customer {
public Customer(IDataRecord data) {
base.name = data["Name"] as string;
}
}
}

namespace Client {
public class Customer : API.Customer, INotifyPropertyChanged {
public string Name { get { return base.name; } set { base.name = value; OnPropertyChanged(“Name”); } }
}
/* etc… */
}

Alas, there are still many problems with this approach, which start to become apparent almost immediately.