WCF issue when using Callback contracts in external DLLs

Like most of the other postee's here, we are new to WCF development. We have
run into a strange situation whereby the same exact code will not run
properly if the code sits in an external DLL, but does run as expected if the
code sits directly in our exececuting assembly. Allow me to explain ....

Step 1 - We have a Publish & Subscribe application .... our client sends in
subscriptions to our server to be notified when specific events happen.

Step 2 - Our server takes the incoming call from the client and stores the
Topic the client wishes to be notified about, along with a reference to the
callback channel for the client using
"OperationContext.Current.GetCallbackChannel<T>()". This information gets
stored into a list (SubscriptionList) for later use.

Step 3 - When our server receives an incoming event, we check our
Subscription list from Step 2 to see if anyone has subscribed to that topic?
If "yes" then we grab those callback objects and call the "notify" method on
those clients.

All of this works perfectly fine when the WCF objects are part of the Server
application. We moved the WCF code out to an external library, that our
Server now references and uses, and the client are able to subscribe and
cancel subscriptions as before, but the Server is no longer able to notify
the client using the callback channel.

Does anyone know why?????

Server Background facts:
1) - The "ServiceContract" attribute for the Contract has the SessionMode
set to "SessionMode.Required" and the CallbackContract =
typeof(IPublisherCallback) ... which are the correct settings.

2) - The "ABC's" apparently are correct by the fact that this works as long
as the WCF code is located directly in the Server project. Obviously we do
change the contract value to reflect the different fully qualified WCF
objects when we use the version that sits in an external library. These must
be correct also, because of the fact that the client is still able to find
the ServiceType and correctly subscribe and unsubscribe as before.

Client Background facts:
1) - Our ABC appear to be correct here to by the fact that the client is
able to subscribe and cancel subscriptions correctly to the Server
(regardless of the Server using embedded WCF objects or using the version
where the WCF code is in an external library).

2) - Our callback interface .... IPublisherCallback ... has a single method
called "Notify()". The OperationContract attribute has the IsOneWay value
set to "true" ... as it should be. And, our implementing class - a Windows
form - does implement this method (all it does it place some XXXXXXXX's into
a text box to sow that communication just came in from the Server).

3) - The Proxy that the client uses (PublisherClient) does correctly
implement the DuplexClientBase<T>, T and show the Subscribe and
CancelSubscription methods. It also correctly shows the PublisherCallback
interface and the Nofiy method ... and correctly shows the IsOneWay = true,
Action = "http://tempuri.org/PublisherCallback/Notify" values too.

The bottom line is the same exect code runs perfect fine as long as it's
embedded into the Server code, but if we use an external library we can no
longer use the callback functionality.

We do not throw any exceptions that give any clue, other than the fact that
when we use the external library version of this you are able to make a first
attempted call to the client.Notify method .... nothings gets placed into our
client's TextBox, though ... which shows us the client never received the
callback from the Server.

And, if you try to send a second attempted call from the Server back to the
client you will get an "ObjectDisposedException" on the statement where we
call Notify() on the client callback object.

We assume the callback object was disposed of from the first attempt, after
it was unable to successfully communicate with the client. And, when we
attempt a 2nd try that object is no longer there. This was the other item
that tipped us off that the WCF runtime seems to treat the external
components differently that the embedded version.

Any suggestions, thoughts, or ideas are TRULY appreicated. If we can't get
this to work we'll have to abandon WCF and go back to using older
technologies.

Thank you.


--
Stay Mobile

Well, the plot thickens ...

After enabling tracing in our app.config file on the Server we ran the test
under both scenarios: 1) using the embedded code from the Server, and 2)
using the same code, but from an external library DLL file.

Interesting results ......................

We used the Microsoft ServiceTraceView tool to step through the flow of our
WCF execution and noticed something I find strange (to say the least). When
we run the test using the library version of the WCF object the runtime is
calling a method that does not exist.

The desktop client - using the library project - implements the callback
interface that the Server is supposed to use to call Notify(). The file is
IPublisherCallback, and it holds the Notify() method. For some strange
reason when we run our test using the library code for our WCF the server
tries to call IPublisher.Notify() instead. The point here is this doesn't
exist!!! There is no Notify() method defined in the IPublisher interface.
Nor, does any class which implments IPublisher have a Notify method either.

But, if we take that same exact source code and move it from the library
project and place it directly into our Server project (as you would expect we
also have to change the name spaces for those classes and change the
app.config file to reflect the adjusted full-qualified Contracts) .... all of
a sudden the Server does correctly call the IPublisherCallback.Notify()
method instead.

DOES ANYONE HAVE ANY IDEA WHY THIS IS????

--
Stay Mobile


"MobileMan" wrote:

> Like most of the other postee's here, we are new to WCF development. We have
> run into a strange situation whereby the same exact code will not run
> properly if the code sits in an external DLL, but does run as expected if the
> code sits directly in our exececuting assembly. Allow me to explain ....
>
> Step 1 - We have a Publish & Subscribe application .... our client sends in
> subscriptions to our server to be notified when specific events happen.
>
> Step 2 - Our server takes the incoming call from the client and stores the
> Topic the client wishes to be notified about, along with a reference to the
> callback channel for the client using
> "OperationContext.Current.GetCallbackChannel<T>()". This information gets
> stored into a list (SubscriptionList) for later use.
>
> Step 3 - When our server receives an incoming event, we check our
> Subscription list from Step 2 to see if anyone has subscribed to that topic?
> If "yes" then we grab those callback objects and call the "notify" method on
> those clients.
>
> All of this works perfectly fine when the WCF objects are part of the Server
> application. We moved the WCF code out to an external library, that our
> Server now references and uses, and the client are able to subscribe and
> cancel subscriptions as before, but the Server is no longer able to notify
> the client using the callback channel.
>
> Does anyone know why?????
>
> Server Background facts:
> 1) - The "ServiceContract" attribute for the Contract has the SessionMode
> set to "SessionMode.Required" and the CallbackContract =
> typeof(IPublisherCallback) ... which are the correct settings.
>
> 2) - The "ABC's" apparently are correct by the fact that this works as long
> as the WCF code is located directly in the Server project. Obviously we do
> change the contract value to reflect the different fully qualified WCF
> objects when we use the version that sits in an external library. These must
> be correct also, because of the fact that the client is still able to find
> the ServiceType and correctly subscribe and unsubscribe as before.
>
> Client Background facts:
> 1) - Our ABC appear to be correct here to by the fact that the client is
> able to subscribe and cancel subscriptions correctly to the Server
> (regardless of the Server using embedded WCF objects or using the version
> where the WCF code is in an external library).
>
> 2) - Our callback interface .... IPublisherCallback ... has a single method
> called "Notify()". The OperationContract attribute has the IsOneWay value
> set to "true" ... as it should be. And, our implementing class - a Windows
> form - does implement this method (all it does it place some XXXXXXXX's into
> a text box to sow that communication just came in from the Server).
>
> 3) - The Proxy that the client uses (PublisherClient) does correctly
> implement the DuplexClientBase<T>, T and show the Subscribe and
> CancelSubscription methods. It also correctly shows the PublisherCallback
> interface and the Nofiy method ... and correctly shows the IsOneWay = true,
> Action = "http://tempuri.org/PublisherCallback/Notify" values too.
>
> The bottom line is the same exect code runs perfect fine as long as it's
> embedded into the Server code, but if we use an external library we can no
> longer use the callback functionality.
>
> We do not throw any exceptions that give any clue, other than the fact that
> when we use the external library version of this you are able to make a first
> attempted call to the client.Notify method .... nothings gets placed into our
> client's TextBox, though ... which shows us the client never received the
> callback from the Server.
>
> And, if you try to send a second attempted call from the Server back to the
> client you will get an "ObjectDisposedException" on the statement where we
> call Notify() on the client callback object.
>
> We assume the callback object was disposed of from the first attempt, after
> it was unable to successfully communicate with the client. And, when we
> attempt a 2nd try that object is no longer there. This was the other item
> that tipped us off that the WCF runtime seems to treat the external
> components differently that the embedded version.
>
> Any suggestions, thoughts, or ideas are TRULY appreicated. If we can't get
> this to work we'll have to abandon WCF and go back to using older
> technologies.
>
> Thank you.
>
>
> --
> Stay Mobile

Just to let everyone know .... found the fix:

When we were calling the code from our server ... i.e., the code was
embedded into our server project ... everything worked perfectly fine.

But, when we moved the WCF code out to an external DLL it quit working. In
this setup the WCF was calling the wrong class / method. Seriously! For
reason my friend at MS cannot even explain, the runtime was calling a method
(whch does exist, but not in the class it was trying to invoke) in the wrong
class.

The fix: simply decorate your the OperationContract attribute withe the
correct "Action" element. For reason I cannot explain, the runtime was able
to correctly determine this on its own when the code was embedded, but when
the code was moved to a library it lost its mind!!! By setting
Action="http://tempuri.org/[interface name]/[method name]" it instantly
worked again.

Hope you guys on the WCF team read this.

--
Stay Mobile


"MobileMan" wrote:

> Well, the plot thickens ...
>
> After enabling tracing in our app.config file on the Server we ran the test
> under both scenarios: 1) using the embedded code from the Server, and 2)
> using the same code, but from an external library DLL file.
>
> Interesting results ......................
>
> We used the Microsoft ServiceTraceView tool to step through the flow of our
> WCF execution and noticed something I find strange (to say the least). When
> we run the test using the library version of the WCF object the runtime is
> calling a method that does not exist.
>
> The desktop client - using the library project - implements the callback
> interface that the Server is supposed to use to call Notify(). The file is
> IPublisherCallback, and it holds the Notify() method. For some strange
> reason when we run our test using the library code for our WCF the server
> tries to call IPublisher.Notify() instead. The point here is this doesn't
> exist!!! There is no Notify() method defined in the IPublisher interface.
> Nor, does any class which implments IPublisher have a Notify method either.
>
> But, if we take that same exact source code and move it from the library
> project and place it directly into our Server project (as you would expect we
> also have to change the name spaces for those classes and change the
> app.config file to reflect the adjusted full-qualified Contracts) .... all of
> a sudden the Server does correctly call the IPublisherCallback.Notify()
> method instead.
>
> DOES ANYONE HAVE ANY IDEA WHY THIS IS????
>
> --
> Stay Mobile
>
>
> "MobileMan" wrote:
>
> > Like most of the other postee's here, we are new to WCF development. We have
> > run into a strange situation whereby the same exact code will not run
> > properly if the code sits in an external DLL, but does run as expected if the
> > code sits directly in our exececuting assembly. Allow me to explain ....
> >
> > Step 1 - We have a Publish & Subscribe application .... our client sends in
> > subscriptions to our server to be notified when specific events happen.
> >
> > Step 2 - Our server takes the incoming call from the client and stores the
> > Topic the client wishes to be notified about, along with a reference to the
> > callback channel for the client using
> > "OperationContext.Current.GetCallbackChannel<T>()". This information gets
> > stored into a list (SubscriptionList) for later use.
> >
> > Step 3 - When our server receives an incoming event, we check our
> > Subscription list from Step 2 to see if anyone has subscribed to that topic?
> > If "yes" then we grab those callback objects and call the "notify" method on
> > those clients.
> >
> > All of this works perfectly fine when the WCF objects are part of the Server
> > application. We moved the WCF code out to an external library, that our
> > Server now references and uses, and the client are able to subscribe and
> > cancel subscriptions as before, but the Server is no longer able to notify
> > the client using the callback channel.
> >
> > Does anyone know why?????
> >
> > Server Background facts:
> > 1) - The "ServiceContract" attribute for the Contract has the SessionMode
> > set to "SessionMode.Required" and the CallbackContract =
> > typeof(IPublisherCallback) ... which are the correct settings.
> >
> > 2) - The "ABC's" apparently are correct by the fact that this works as long
> > as the WCF code is located directly in the Server project. Obviously we do
> > change the contract value to reflect the different fully qualified WCF
> > objects when we use the version that sits in an external library. These must
> > be correct also, because of the fact that the client is still able to find
> > the ServiceType and correctly subscribe and unsubscribe as before.
> >
> > Client Background facts:
> > 1) - Our ABC appear to be correct here to by the fact that the client is
> > able to subscribe and cancel subscriptions correctly to the Server
> > (regardless of the Server using embedded WCF objects or using the version
> > where the WCF code is in an external library).
> >
> > 2) - Our callback interface .... IPublisherCallback ... has a single method
> > called "Notify()". The OperationContract attribute has the IsOneWay value
> > set to "true" ... as it should be. And, our implementing class - a Windows
> > form - does implement this method (all it does it place some XXXXXXXX's into
> > a text box to sow that communication just came in from the Server).
> >
> > 3) - The Proxy that the client uses (PublisherClient) does correctly
> > implement the DuplexClientBase<T>, T and show the Subscribe and
> > CancelSubscription methods. It also correctly shows the PublisherCallback
> > interface and the Nofiy method ... and correctly shows the IsOneWay = true,
> > Action = "http://tempuri.org/PublisherCallback/Notify" values too.
> >
> > The bottom line is the same exect code runs perfect fine as long as it's
> > embedded into the Server code, but if we use an external library we can no
> > longer use the callback functionality.
> >
> > We do not throw any exceptions that give any clue, other than the fact that
> > when we use the external library version of this you are able to make a first
> > attempted call to the client.Notify method .... nothings gets placed into our
> > client's TextBox, though ... which shows us the client never received the
> > callback from the Server.
> >
> > And, if you try to send a second attempted call from the Server back to the
> > client you will get an "ObjectDisposedException" on the statement where we
> > call Notify() on the client callback object.
> >
> > We assume the callback object was disposed of from the first attempt, after
> > it was unable to successfully communicate with the client. And, when we
> > attempt a 2nd try that object is no longer there. This was the other item
> > that tipped us off that the WCF runtime seems to treat the external
> > components differently that the embedded version.
> >
> > Any suggestions, thoughts, or ideas are TRULY appreicated. If we can't get
> > this to work we'll have to abandon WCF and go back to using older
> > technologies.
> >
> > Thank you.
> >
> >
> > --
> > Stay Mobile