WCF Question

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

WCF Question

Hi guys,

I’m pretty new to WCF, and have a basic question about how it works. I’m
trying to use WCF to write an “SOA-system�, and am having a few problems.

The following analogy explains what I’m trying to do. I have a very simple
class:

[DataContract]
public class MyClass
{
private string data = "default data";

[DataMember]
public string Data
{
get
{
return data;
}
set
{
data = value;
}
}
}

This is exposed via a WCF Service:

[ServiceContract]
public interface IMyClassService
{
[OperationContract]
void Add(MyClass item);
}

public class MyClassService : IMyClassService
{
public void Add(MyClass item)
{
//Do something with the data...
Debug.WriteLine(item.Data);
}
}

As you can see, this is extremely simple. I’ve put the service in an ASP.NET
web application, created the correct web-config entries, included an svc file
with the correct tag, and the service does work. I’ve consumed the service
via a console application (by creating a service reference). I have the
following (very simple) code in the console application:

public static class Program
{
public static void Main(string[] args)
{
MyClassServiceClient client = new MyClassServiceClient();

MyClass myClass = new MyClass();

client.Add(myClass);
}
}

Obviously, the MyClass reference in the console application is a proxy class
generated automatically by WCF. It only knows about the properties marked
with [DataMember] attributes. This means that any “private� code within
MyClass is not executed by the console application. However, when the proxy
is passed to the service, I would expect an instance of the “real� or full
MyClass class to be instantiated on the WCF server, and I would expect the
private code to run on construction. It doesn’t! This can be proved by
looking at the value of the Data property on the server. It is still set as
null, despite giving it a value in the field declaration.

Hence, if MyClass has a constructor with code, this would not fire on the
server.

So, my questions is this: Is there a way to ensure that MyClass is
constructed fully on the server? It would be great if constructor code could
be fired. Can this behaviour be obtained by tweaking the attributes in the
service classes?

Thanks in advance,

Steve.

[sloan]

I don't know if this helps or not.

But this is a non-proxy-class approach, in a DotNet to DotNet world with
WCF.

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry

"Steve Barker" <st**********@nospam.nospamwrote in message
news:88**********************************@microsof t.com...

WCF Question

Hi guys,

I'm pretty new to WCF, and have a basic question about how it works. I'm
trying to use WCF to write an "SOA-system", and am having a few problems.

The following analogy explains what I'm trying to do. I have a very simple
class:

[DataContract]
public class MyClass
{
private string data = "default data";

[DataMember]
public string Data
{
get
{
return data;
}
set
{
data = value;
}
}
}

This is exposed via a WCF Service:

[ServiceContract]
public interface IMyClassService
{
[OperationContract]
void Add(MyClass item);
}

public class MyClassService : IMyClassService
{
public void Add(MyClass item)
{
//Do something with the data...
Debug.WriteLine(item.Data);
}
}

As you can see, this is extremely simple. I've put the service in an
ASP.NET
web application, created the correct web-config entries, included an svc
file
with the correct tag, and the service does work. I've consumed the service
via a console application (by creating a service reference). I have the
following (very simple) code in the console application:

public static class Program
{
public static void Main(string[] args)
{
MyClassServiceClient client = new MyClassServiceClient();

MyClass myClass = new MyClass();

client.Add(myClass);
}
}

Obviously, the MyClass reference in the console application is a proxy
class
generated automatically by WCF. It only knows about the properties marked
with [DataMember] attributes. This means that any "private" code within
MyClass is not executed by the console application. However, when the
proxy
is passed to the service, I would expect an instance of the "real" or full
MyClass class to be instantiated on the WCF server, and I would expect the
private code to run on construction. It doesn't! This can be proved by
looking at the value of the Data property on the server. It is still set
as
null, despite giving it a value in the field declaration.

Hence, if MyClass has a constructor with code, this would not fire on the
server.

So, my questions is this: Is there a way to ensure that MyClass is
constructed fully on the server? It would be great if constructor code
could
be fired. Can this behaviour be obtained by tweaking the attributes in the
service classes?

Thanks in advance,

Steve.

[Marc Gravell]

It looks like the problem here is that you did actually send a <nullup
the wire, because you instantiated with:

MyClass myClass = new MyClass();
client.Add(myClass);

Because the proxy MyClass doesn't know any better, all fields are
initialized to their defaults (null for string) and actively sent. This
(at the server) essentially does (for the real objects):

MyClass serverObj = new MyClass();
serverObj.Data = null;
// etc

You need to tell the class about defaults... in this case, you can do it
by (on the server object):

private string data = "default data";

[DataMember, DefaultValue("default data")]
public string Data {...}

(although you'll probably need to regenerate the client proxies to
update it).

This [DefaultValue] is part of the contract, so now the client proxy
will a: initialize as "default data", and b: not bother sending "default
data", as it can be assumed at the server (you can make it send default
values by tweaking the optional [DataMember] properties).

Marc

[Marc Gravell]

Well, you can't stop the client doing what it likes... and by definition
proxies don't have any logic. You also can't take away the default ctor,
or the serializer will break.

So you *could* have a New() method on the service, but it seems
overkill. What sort of logic did you have in mind?

Alternatively, you could create a method in a partial class at the
client (in a separate file for the service, but same types) that creates
a New() method. You could also check whether the WCF-generated proxy
exposes any partial methods that might help (if you are using C# 3).

If you are doing .NET-to-.NET, note that you don't have to limit
yourself to the proxies; you can also share the .cs (or the entire
assemlby containing your data-contracts / service-contracts) between the
client and the server; this allows you to run the same code at each, but
note that the server shouldn't assume that any such logic has occurred
(since a hostile client could be sending any old rubbish).

Note that in addition to [DefaultValue], DataContractSerializer also
supports the "bool ShouldSerialize{PropertyName}()" pattern for complex
optional values, but this won't work at the client if shallow proxies
are used.

Marc

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

That's a good point about not being able to stop the client from
instantiating an object. Hence, the New() method is not a good idea!

The sort of logic I'm talking about is stuff like checking business rules (a
la Rockford Lhotka). I want each class to maintain a set of which business
rules have been broken. (The class exposes an IsValid property.) For this, I
need certain code to run in the constructor of the class when it gets back to
the server, otherwise the rules structures are not instantiated.

It sounds as though I'm going to have to run the full class code in the
client as well as the server, which is a shame as standard WCF seems quite
elegant in that you don't have to have knowledge of the class at the client.

I don't understand what you mean by "bool ShouldSerialize{PropertyName}()".
Can you point me in the right direction of an article on this please?

Sloan mentions that it's possible to get WCF to serialise the entire class
and send it down the wire, rather than sending a proxy. I think it has
something to do with NetDataContractSerializer. I'm having trouble
understanding the articles I've read on this, so can you help me with this at
all?

Many thanks,

Steve.

"Marc Gravell" wrote:

Well, you can't stop the client doing what it likes... and by definition
proxies don't have any logic. You also can't take away the default ctor,
or the serializer will break.

So you *could* have a New() method on the service, but it seems
overkill. What sort of logic did you have in mind?

Alternatively, you could create a method in a partial class at the
client (in a separate file for the service, but same types) that creates
a New() method. You could also check whether the WCF-generated proxy
exposes any partial methods that might help (if you are using C# 3).

If you are doing .NET-to-.NET, note that you don't have to limit
yourself to the proxies; you can also share the .cs (or the entire
assemlby containing your data-contracts / service-contracts) between the
client and the server; this allows you to run the same code at each, but
note that the server shouldn't assume that any such logic has occurred
(since a hostile client could be sending any old rubbish).

Note that in addition to [DefaultValue], DataContractSerializer also
supports the "bool ShouldSerialize{PropertyName}()" pattern for complex
optional values, but this won't work at the client if shallow proxies
are used.

Marc

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

Actually, scratch that, the NetDataContractSerializer is actually really easy
to use, and completely solves the problem.

Sloan: Thanks very much for providing that solution!

"Steve Barker" wrote:

That's a good point about not being able to stop the client from
instantiating an object. Hence, the New() method is not a good idea!

The sort of logic I'm talking about is stuff like checking business rules (a
la Rockford Lhotka). I want each class to maintain a set of which business
rules have been broken. (The class exposes an IsValid property.) For this, I
need certain code to run in the constructor of the class when it gets back to
the server, otherwise the rules structures are not instantiated.

It sounds as though I'm going to have to run the full class code in the
client as well as the server, which is a shame as standard WCF seems quite
elegant in that you don't have to have knowledge of the class at the client.

I don't understand what you mean by "bool ShouldSerialize{PropertyName}()".
Can you point me in the right direction of an article on this please?

Sloan mentions that it's possible to get WCF to serialise the entire class
and send it down the wire, rather than sending a proxy. I think it has
something to do with NetDataContractSerializer. I'm having trouble
understanding the articles I've read on this, so can you help me with this at
all?

Many thanks,

Steve.

"Marc Gravell" wrote:

Well, you can't stop the client doing what it likes... and by definition
proxies don't have any logic. You also can't take away the default ctor,
or the serializer will break.

So you *could* have a New() method on the service, but it seems
overkill. What sort of logic did you have in mind?

Alternatively, you could create a method in a partial class at the
client (in a separate file for the service, but same types) that creates
a New() method. You could also check whether the WCF-generated proxy
exposes any partial methods that might help (if you are using C# 3).

If you are doing .NET-to-.NET, note that you don't have to limit
yourself to the proxies; you can also share the .cs (or the entire
assemlby containing your data-contracts / service-contracts) between the
client and the server; this allows you to run the same code at each, but
note that the server shouldn't assume that any such logic has occurred
(since a hostile client could be sending any old rubbish).

Note that in addition to [DefaultValue], DataContractSerializer also
supports the "bool ShouldSerialize{PropertyName}()" pattern for complex
optional values, but this won't work at the client if shallow proxies
are used.

Marc

[sloan]

//I think it has

something to do with NetDataContractSerializer. I'm having trouble
understanding the articles I've read on this, so can you help me with this
at
all?

//

My blog entry has a completely downloadable example of C# code.


"Steve Barker" <st**********@nospam.nospamwrote in message
news:EB**********************************@microsof t.com...

That's a good point about not being able to stop the client from
instantiating an object. Hence, the New() method is not a good idea!

The sort of logic I'm talking about is stuff like checking business rules
(a
la Rockford Lhotka). I want each class to maintain a set of which business
rules have been broken. (The class exposes an IsValid property.) For this,
I
need certain code to run in the constructor of the class when it gets back
to
the server, otherwise the rules structures are not instantiated.

It sounds as though I'm going to have to run the full class code in the
client as well as the server, which is a shame as standard WCF seems quite
elegant in that you don't have to have knowledge of the class at the
client.

I don't understand what you mean by "bool
ShouldSerialize{PropertyName}()".
Can you point me in the right direction of an article on this please?

Sloan mentions that it's possible to get WCF to serialise the entire class
and send it down the wire, rather than sending a proxy. I think it has
something to do with NetDataContractSerializer. I'm having trouble
understanding the articles I've read on this, so can you help me with this
at
all?

Many thanks,

Steve.

"Marc Gravell" wrote:

>Well, you can't stop the client doing what it likes... and by definition
proxies don't have any logic. You also can't take away the default ctor,
or the serializer will break.

So you *could* have a New() method on the service, but it seems
overkill. What sort of logic did you have in mind?

Alternatively, you could create a method in a partial class at the
client (in a separate file for the service, but same types) that creates
a New() method. You could also check whether the WCF-generated proxy
exposes any partial methods that might help (if you are using C# 3).

If you are doing .NET-to-.NET, note that you don't have to limit
yourself to the proxies; you can also share the .cs (or the entire
assemlby containing your data-contracts / service-contracts) between the
client and the server; this allows you to run the same code at each, but
note that the server shouldn't assume that any such logic has occurred
(since a hostile client could be sending any old rubbish).

Note that in addition to [DefaultValue], DataContractSerializer also
supports the "bool ShouldSerialize{PropertyName}()" pattern for complex
optional values, but this won't work at the client if shallow proxies
are used.

Marc

[sloan]

Well, these guys saved us both:
http://www.thoughtshapes.com/WCF/Usi...ametersTwo.htm
( I reference them in my post )

They're the ones to thank.

"Steve Barker" <st**********@nospam.nospamwrote in message
news:88**********************************@microsof t.com...

Actually, scratch that, the NetDataContractSerializer is actually really
easy
to use, and completely solves the problem.

Sloan: Thanks very much for providing that solution!

"Steve Barker" wrote:

>That's a good point about not being able to stop the client from
instantiating an object. Hence, the New() method is not a good idea!

The sort of logic I'm talking about is stuff like checking business rules
(a
la Rockford Lhotka). I want each class to maintain a set of which
business
rules have been broken. (The class exposes an IsValid property.) For
this, I
need certain code to run in the constructor of the class when it gets
back to
the server, otherwise the rules structures are not instantiated.

It sounds as though I'm going to have to run the full class code in the
client as well as the server, which is a shame as standard WCF seems
quite
elegant in that you don't have to have knowledge of the class at the
client.

I don't understand what you mean by "bool
ShouldSerialize{PropertyName}()".
Can you point me in the right direction of an article on this please?

Sloan mentions that it's possible to get WCF to serialise the entire
class
and send it down the wire, rather than sending a proxy. I think it has
something to do with NetDataContractSerializer. I'm having trouble
understanding the articles I've read on this, so can you help me with
this at
all?

Many thanks,

Steve.

"Marc Gravell" wrote:

Well, you can't stop the client doing what it likes... and by
definition
proxies don't have any logic. You also can't take away the default
ctor,
or the serializer will break.

So you *could* have a New() method on the service, but it seems
overkill. What sort of logic did you have in mind?

Alternatively, you could create a method in a partial class at the
client (in a separate file for the service, but same types) that
creates
a New() method. You could also check whether the WCF-generated proxy
exposes any partial methods that might help (if you are using C# 3).

If you are doing .NET-to-.NET, note that you don't have to limit
yourself to the proxies; you can also share the .cs (or the entire
assemlby containing your data-contracts / service-contracts) between
the
client and the server; this allows you to run the same code at each,
but
note that the server shouldn't assume that any such logic has occurred
(since a hostile client could be sending any old rubbish).

Note that in addition to [DefaultValue], DataContractSerializer also
supports the "bool ShouldSerialize{PropertyName}()" pattern for complex
optional values, but this won't work at the client if shallow proxies
are used.

Marc

[Marc Gravell]

Strictly speaking, the main difference here is that
NetDataContractSerializer simply *forces* you to have the same CLR
type at each end. You can get the same result with regular
DataContractSerializer (and hence retaining portability) simply by
*choosing* to have the same CLR type at each end, either by assembly
sharing or copying the class file(s). It doesn't actually transmit the
runnable type - just the metadata to resolve it at each end.

ShouldSerialize{foo} is just a more complex way of expressing things
like default values, but where the decision isn't just a comparison to
a constant; it doesn't sound like this is going to be hugely helpful
in this case (but depending on which problems you were trying to
solve, it might have been).

Marc

[Steven Cheng [MSFT]]

Hi Steve,

WCF use service description WSDL to expose its service interface and data
contract, it is reasonable that only those public parts(properties and
method signature) can be got by the client-side. The default
implemeation(such as the validation logic in method) is implemeation
specific which is not conpliant to service oritented or contract based
development.

For your scenario, if you do want to let the client-side also use the same
classes as the WCF service, I suggest you directly let the client side
proxy use the same classes as service(separate those reusable classes into
a single class library project). And when you create the client WCF proxy,
you can specify the assembly in which you want to reuse classes. You can
refer to the following articles and refernce for more ideas about sharing
and reusing types in WCF service and client proxy:
#Type sharing in WCF service reference
http://blogs.msdn.com/lifenglu/archi...-in-wcf-servic
e-reference.aspx

#What's New for WCF in Visual Studio 2008
http://msdn.microsoft.com/en-us/magazine/cc163289.aspx

#Sharing WCF Collection Types between Service and Client
http://www.codeproject.com/KB/WCF/WC...peSharing.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>From: =?Utf-8?B?U3RldmUgQmFya2Vy?= <st**********@nospam.nospam>
Subject: WCF Question
Date: Thu, 21 Aug 2008 06:12:00 -0700

>
WCF Question

Hi guys,

I’m pretty new to WCF, and have a basic question about how it works.

I’m

>trying to use WCF to write an “SOA-system� and am having a few

problems.

>
The following analogy explains what I’m trying to do. I have a very

simple

>class:

[DataContract]
public class MyClass
{
private string data = "default data";

[DataMember]
public string Data
{
get
{
return data;
}
set
{
data = value;
}
}
}

This is exposed via a WCF Service:

[ServiceContract]
public interface IMyClassService
{
[OperationContract]
void Add(MyClass item);
}

public class MyClassService : IMyClassService
{
public void Add(MyClass item)
{
//Do something with the data...
Debug.WriteLine(item.Data);
}
}

As you can see, this is extremely simple. I’ve put the service in an

ASP.NET

>web application, created the correct web-config entries, included an svc

file

>with the correct tag, and the service does work. I’ve consumed the

service

>via a console application (by creating a service reference). I have the
following (very simple) code in the console application:

public static class Program
{
public static void Main(string[] args)
{
MyClassServiceClient client = new MyClassServiceClient();

MyClass myClass = new MyClass();

client.Add(myClass);
}
}

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

Hi all,

Thanks for your replies.

Steven: I didn't realise that strict SOA involves passing only data. I guess
the right way to do things would be to write a validator class which the
domain class could be passed into once it has been received by the service.
Limiting the exchange to .NET isn't a great thing to do.

I think I might restructure the architecture a little then!

Thanks,

Steve.

"Steven Cheng [MSFT]" wrote:

Hi Steve,

WCF use service description WSDL to expose its service interface and data
contract, it is reasonable that only those public parts(properties and
method signature) can be got by the client-side. The default
implemeation(such as the validation logic in method) is implemeation
specific which is not conpliant to service oritented or contract based
development.

For your scenario, if you do want to let the client-side also use the same
classes as the WCF service, I suggest you directly let the client side
proxy use the same classes as service(separate those reusable classes into
a single class library project). And when you create the client WCF proxy,
you can specify the assembly in which you want to reuse classes. You can
refer to the following articles and refernce for more ideas about sharing
and reusing types in WCF service and client proxy:
#Type sharing in WCF service reference
http://blogs.msdn.com/lifenglu/archi...-in-wcf-servic
e-reference.aspx

#What's New for WCF in Visual Studio 2008
http://msdn.microsoft.com/en-us/magazine/cc163289.aspx

#Sharing WCF Collection Types between Service and Client
http://www.codeproject.com/KB/WCF/WC...peSharing.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

From: =?Utf-8?B?U3RldmUgQmFya2Vy?= <st**********@nospam.nospam>
Subject: WCF Question
Date: Thu, 21 Aug 2008 06:12:00 -0700

WCF Question

Hi guys,

I’m pretty new to WCF, and have a basic question about how it works.

I’m

trying to use WCF to write an “SOA-system� and am having a few

problems.

The following analogy explains what I’m trying to do. I have a very

simple

class:

[DataContract]
public class MyClass
{
private string data = "default data";

[DataMember]
public string Data
{
get
{
return data;
}
set
{
data = value;
}
}
}

This is exposed via a WCF Service:

[ServiceContract]
public interface IMyClassService
{
[OperationContract]
void Add(MyClass item);
}

public class MyClassService : IMyClassService
{
public void Add(MyClass item)
{
//Do something with the data...
Debug.WriteLine(item.Data);
}
}

As you can see, this is extremely simple. I’ve put the service in an

ASP.NET

web application, created the correct web-config entries, included an svc

file

with the correct tag, and the service does work. I’ve consumed the

service

via a console application (by creating a service reference). I have the
following (very simple) code in the console application:

public static class Program
{
public static void Main(string[] args)
{
MyClassServiceClient client = new MyClassServiceClient();

MyClass myClass = new MyClass();

client.Add(myClass);
}
}

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

Hi guys,

I’ve being playing around with the NetDataContract attribute and have
discovered something very strange.

The example code I wrote works perfectly one machine I own, but not on
another. The error I get on the machine that doesn’t work is as follows:

Type 'SoaTest.BusinessObjects.Person' cannot be serialized. Consider marking
it with the DataContractAttribute attribute, and marking all of its members
you want serialized with the DataMemberAttribute attribute.

Has anyone seen this before, and if so, what do you think is missing from
the machine and stopping it from working?

Many thanks,

Steve.

"Steven Cheng [MSFT]" wrote:

Hi Steve,

WCF use service description WSDL to expose its service interface and data
contract, it is reasonable that only those public parts(properties and
method signature) can be got by the client-side. The default
implemeation(such as the validation logic in method) is implemeation
specific which is not conpliant to service oritented or contract based
development.

For your scenario, if you do want to let the client-side also use the same
classes as the WCF service, I suggest you directly let the client side
proxy use the same classes as service(separate those reusable classes into
a single class library project). And when you create the client WCF proxy,
you can specify the assembly in which you want to reuse classes. You can
refer to the following articles and refernce for more ideas about sharing
and reusing types in WCF service and client proxy:
#Type sharing in WCF service reference
http://blogs.msdn.com/lifenglu/archi...-in-wcf-servic
e-reference.aspx

#What's New for WCF in Visual Studio 2008
http://msdn.microsoft.com/en-us/magazine/cc163289.aspx

#Sharing WCF Collection Types between Service and Client
http://www.codeproject.com/KB/WCF/WC...peSharing.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

From: =?Utf-8?B?U3RldmUgQmFya2Vy?= <st**********@nospam.nospam>
Subject: WCF Question
Date: Thu, 21 Aug 2008 06:12:00 -0700

WCF Question

Hi guys,

I’m pretty new to WCF, and have a basic question about how it works.

I’m

trying to use WCF to write an “SOA-system� and am having a few

problems.

The following analogy explains what I’m trying to do. I have a very

simple

class:

[DataContract]
public class MyClass
{
private string data = "default data";

[DataMember]
public string Data
{
get
{
return data;
}
set
{
data = value;
}
}
}

This is exposed via a WCF Service:

[ServiceContract]
public interface IMyClassService
{
[OperationContract]
void Add(MyClass item);
}

public class MyClassService : IMyClassService
{
public void Add(MyClass item)
{
//Do something with the data...
Debug.WriteLine(item.Data);
}
}

As you can see, this is extremely simple. I’ve put the service in an

ASP.NET

web application, created the correct web-config entries, included an svc

file

with the correct tag, and the service does work. I’ve consumed the

service

via a console application (by creating a service reference). I have the
following (very simple) code in the console application:

public static class Program
{
public static void Main(string[] args)
{
MyClassServiceClient client = new MyClassServiceClient();

MyClass myClass = new MyClass();

client.Add(myClass);
}
}

[Marc Gravell]

I think one of the .NET service packs made some minor tweaks to
serailization - try checking which .NET version/service-pack each has.

However, I'm pretty suer it still needs [Serializable] or [DataContract]
- check you have the same entity dll on both machines.

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

Thanks Marc!

I'm using exactly the same code on both machines, although the machines have
different OSs. The working machine is Windows Server 2003. The other is
Windows XP Professional.

The code doesn't need [Serializable] or [DataContract] on the Windows 2003
Server. Very strange!!!

I'll check versions etc... In the meantime, any other advice would be welcome.

"Marc Gravell" wrote:

I think one of the .NET service packs made some minor tweaks to
serailization - try checking which .NET version/service-pack each has.

However, I'm pretty suer it still needs [Serializable] or [DataContract]
- check you have the same entity dll on both machines.

[Steven Cheng [MSFT]]

Thanks for your reply Steve,

Yes, those SOA components like WCF ,webservice generally focus on contract
based interop. For such scenario that you need to share implementation
logic, it will be necessary to use some shared code/assembly which is used
at both side. Or maybe you can completely expose the validate method as a
WCF/webservice interface, but that'll be a bit overkill if it is frequently
used(especially in internet environment).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>Thread-Topic: WCF Question
Subject: RE: WCF Question
Date: Fri, 22 Aug 2008 02:05:01 -0700

>X-Tomcat-NG: microsoft.public.dotnet.languages.csharp

Hi all,

Thanks for your replies.

Steven: I didn't realise that strict SOA involves passing only data. I

guess

>the right way to do things would be to write a validator class which the
domain class could be passed into once it has been received by the

service.

>Limiting the exchange to .NET isn't a great thing to do.

I think I might restructure the architecture a little then!

Thanks,

Steve.

"Steven Cheng [MSFT]" wrote:

>Hi Steve,

WCF use service description WSDL to expose its service interface and

data

>contract, it is reasonable that only those public parts(properties and
method signature) can be got by the client-side. The default
implemeation(such as the validation logic in method) is implemeation
specific which is not conpliant to service oritented or contract based
development.

For your scenario, if you do want to let the client-side also use the

same

>classes as the WCF service, I suggest you directly let the client side
proxy use the same classes as service(separate those reusable classes

into

>a single class library project). And when you create the client WCF

proxy,

>you can specify the assembly in which you want to reuse classes. You

can

>refer to the following articles and refernce for more ideas about

sharing

>and reusing types in WCF service and client proxy:
#Type sharing in WCF service reference

http://blogs.msdn.com/lifenglu/archi...-in-wcf-servic

>e-reference.aspx

#What's New for WCF in Visual Studio 2008
http://msdn.microsoft.com/en-us/magazine/cc163289.aspx

#Sharing WCF Collection Types between Service and Client
http://www.codeproject.com/KB/WCF/WC...peSharing.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
D

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

This post seems to suggest there are some problems with the NetDataContract
implement that is commonly listed:

https://forums.microsoft.com/MSDN/Sh...44364&SiteID=1

I think a similar problem is causing the code to fail on XP but not on
Server 2003. Does anybody have the fix to make it work on XP Pro?

Thanks,

Steve.

"Steve Barker" wrote:

Thanks Marc!

I'm using exactly the same code on both machines, although the machines have
different OSs. The working machine is Windows Server 2003. The other is
Windows XP Professional.

The code doesn't need [Serializable] or [DataContract] on the Windows 2003
Server. Very strange!!!

I'll check versions etc... In the meantime, any other advice would be welcome.

"Marc Gravell" wrote:

I think one of the .NET service packs made some minor tweaks to
serailization - try checking which .NET version/service-pack each has.

However, I'm pretty suer it still needs [Serializable] or [DataContract]
- check you have the same entity dll on both machines.

[=?Utf-8?B?U3RldmUgQmFya2Vy?=]

Installing VSTS 2008 SP1 and running this tool:

devenv.exe /resetskippkgs

Has solved the problem. Very strange! (I can only guess that my .NET
Framework 3.0/3.5 was broken somehow?)

"Steve Barker" wrote:

This post seems to suggest there are some problems with the NetDataContract
implement that is commonly listed:

https://forums.microsoft.com/MSDN/Sh...44364&SiteID=1

I think a similar problem is causing the code to fail on XP but not on
Server 2003. Does anybody have the fix to make it work on XP Pro?

Thanks,

Steve.

"Steve Barker" wrote:

Thanks Marc!

I'm using exactly the same code on both machines, although the machines have
different OSs. The working machine is Windows Server 2003. The other is
Windows XP Professional.

The code doesn't need [Serializable] or [DataContract] on the Windows 2003
Server. Very strange!!!

I'll check versions etc... In the meantime, any other advice would be welcome.

"Marc Gravell" wrote:

I think one of the .NET service packs made some minor tweaks to
serailization - try checking which .NET version/service-pack each has.
>
However, I'm pretty suer it still needs [Serializable] or [DataContract]
- check you have the same entity dll on both machines.
>