Convert proxy type to class type

[Joe]

I have a web service which returns many types (classes) to match the return
type. I want to cast the return type to the actual class type.

For example:

namespace Test
{
class MyClass
{
...
}
}

[WebMethod]
public MyClass Test();

the proxy will be a deserialized version of MyClass but under the namespace
of the generated proxy.

I would like to do something like this:

MyClass myClass = webService.Test();

This of course won't work because the cast fails.

Then I thought of creating another proxy in the lib were MyClass is defined
and add a constructor which takes the proxy MyClass. BUT, the new proxy now
falls under another namespace and again fails.

I than thought of using one proxy for both instances (the calling app and
the lib) but this isn't really practical.
I also thought of using the Convert.ToType but that means the generated
proxy needs to implement IConvertible.

Are there any suggestions on how to handle this?

Thanks,
Joe

 

[Robert May]

Joe,

Why not do an implicit cast? For example:

MyClass myClass=(MyClass) webService.Test();

Basically, you're telling the compiler that you KNOW that this object that's
being returned is of the type MyClass, even though it thinks it isn't. If
it really isn't of that type, this line will fail, however.

Also, this probably isn't the best design. You may want to re-evaluate why
this particular approach is being used. You may also want to overload your
Test() method for each return type.

Robert

 

[Joe]

The cast fails. I think this is because the compiler sees them as 2 separate
classes rather than based on signature.

How would overloading Test() help? The WebMethod is supposed to return an
instance of class MyClass which contains all the data needed by the calling
application.

I was playing with the idea of using reflection to copy all the members from
one type to the other but that's time consuming (plus I haven't done it
before).

The other idea is to modify the proxy that was created so both namespaces
and class names match. This will allow it to work but that means having to
make the change anytime I need to update the proxy due to a change in the
web service.

Joe,

Why not do an implicit cast? For example:

MyClass myClass=(MyClass) webService.Test();

Basically, you're telling the compiler that you KNOW that this object that's
being returned is of the type MyClass, even though it thinks it isn't. If
it really isn't of that type, this line will fail, however.

Also, this probably isn't the best design. You may want to re-evaluate why
this particular approach is being used. You may also want to overload your
Test() method for each return type.

Robert

I have a web service which returns many types (classes) to match the return
type. I want to cast the return type to the actual class type.

For example:

namespace Test
{
class MyClass
{
...
}
}

[WebMethod]
public MyClass Test();

the proxy will be a deserialized version of MyClass but under the
namespace
of the generated proxy.

I would like to do something like this:

MyClass myClass = webService.Test();

This of course won't work because the cast fails.

Then I thought of creating another proxy in the lib were MyClass is
defined
and add a constructor which takes the proxy MyClass. BUT, the new proxy
now
falls under another namespace and again fails.

I than thought of using one proxy for both instances (the calling app and
the lib) but this isn't really practical.
I also thought of using the Convert.ToType but that means the generated
proxy needs to implement IConvertible.

Are there any suggestions on how to handle this?

Thanks,
Joe

 

[Joe]

I think what I'll do is create another lib with one proxy in it and share
the proxy with both the application and the other lib.

 

[Scott Allen]

Joe:

If I understand your question it sounds as if you want to tightly
couple the web service and the client by sharing a common type. This
can cause difficulties down the road as one or the other starts to
version and change - you'll need to keep them in sync.

 

[Joe]

I thought about the sync issue but since the client needs all the data
produced by the web service method it seems this won't be too big of an
issue.

What is another way to do this?

I have a web service, class library (this class library is used in many
other places) and a winforms app. The app consumes the service and uses the
classes in the class library for data management. So, for simplicity and
clarity, I thought it would be best to either have a constructor of these
classes that will take the generated proxy class and create a new class from
it or over load the = to perform the same task.

I've been throwing this idea around for a while because I hate iterating
through the data (class) returned from web service and populating
(essentially the same class) with its data.

I way open to better suggestions

Thanks,
Joe

Joe:

If I understand your question it sounds as if you want to tightly
couple the web service and the client by sharing a common type. This
can cause difficulties down the road as one or the other starts to
version and change - you'll need to keep them in sync.

--
Scott
http://www.OdeToCode.com/

I have a web service which returns many types (classes) to match the return
type. I want to cast the return type to the actual class type.

For example:

namespace Test
{
class MyClass
{
...
}
}

[WebMethod]
public MyClass Test();

the proxy will be a deserialized version of MyClass but under the namespace
of the generated proxy.

I would like to do something like this:

MyClass myClass = webService.Test();

This of course won't work because the cast fails.

Then I thought of creating another proxy in the lib were MyClass is defined
and add a constructor which takes the proxy MyClass. BUT, the new proxy now
falls under another namespace and again fails.

I than thought of using one proxy for both instances (the calling app and
the lib) but this isn't really practical.
I also thought of using the Convert.ToType but that means the generated
proxy needs to implement IConvertible.

Are there any suggestions on how to handle this?

Thanks,
Joe

 

[Scott Allen]

Well, one approach would be to handcraft the proxy classes. You could
take a look at what the WSDL tool generates and work from there - it
is pretty much boilerplate code. I don't advise this appraoach of
course, but I can understand if you have a special circumstance.

--
Scott
http://www.OdeToCode.com/blogs/scott/

I thought about the sync issue but since the client needs all the data
produced by the web service method it seems this won't be too big of an
issue.

What is another way to do this?

I have a web service, class library (this class library is used in many
other places) and a winforms app. The app consumes the service and uses the
classes in the class library for data management. So, for simplicity and
clarity, I thought it would be best to either have a constructor of these
classes that will take the generated proxy class and create a new class from
it or over load the = to perform the same task.

I've been throwing this idea around for a while because I hate iterating
through the data (class) returned from web service and populating
(essentially the same class) with its data.

I way open to better suggestions

Thanks,
Joe

Joe:

If I understand your question it sounds as if you want to tightly
couple the web service and the client by sharing a common type. This
can cause difficulties down the road as one or the other starts to
version and change - you'll need to keep them in sync.

--
Scott
http://www.OdeToCode.com/

I have a web service which returns many types (classes) to match the return
type. I want to cast the return type to the actual class type.

For example:

namespace Test
{
class MyClass
{
...
}
}

[WebMethod]
public MyClass Test();

the proxy will be a deserialized version of MyClass but under the namespace
of the generated proxy.

I would like to do something like this:

MyClass myClass = webService.Test();

This of course won't work because the cast fails.

Then I thought of creating another proxy in the lib were MyClass is defined
and add a constructor which takes the proxy MyClass. BUT, the new proxy now
falls under another namespace and again fails.

I than thought of using one proxy for both instances (the calling app and
the lib) but this isn't really practical.
I also thought of using the Convert.ToType but that means the generated
proxy needs to implement IConvertible.

Are there any suggestions on how to handle this?

Thanks,
Joe

 

[Nicholas Paldino [.NET/C# MVP]]

Joe,

You are on the right track with defining the types in a separate
assembly, and then having the proxy code reference that assembly.

If you are using the classes generated by VS.NET, then you will have to
go to the IDE-generated code and remove all of the definitions for the
classes that are read from the WSDL which are used as return types and
parameter types. Then, you just have to make sure that the appropriate
namespaces are in scope (through a using statement), and it should work.

If you wanted to be really slick, you could use the WSDL tool and define
the namespace that the proxies are in. You would define it to be in the
same namespace as the rest of the types that are passed around. This way,
all you have to do is remove the definitions, and not worry about the fully
qualified type names (I'm not sure if the web service proxy generator does
this).

Hope this helps.

 

[Scott Allen]

Interestingly enough, Joe, this just turned up today:

http://pluralsight.com/wiki/default.aspx/Craig.RebuildingWsdlExe