I am converting a C++ MFC client-server application to C# dotNet and I
would like to switch my TCP/IP messages to use dotNet remoting
concepts.  I can successfully implement many remoting samples, for
example from Wrox Press Professional C#.  However all of these find
have trivial objects that are invoked on the server.  None has to
access any difficult data values to return to the client.  I need to
access data maintained by class instances within the server
application.  Yet the server object instantiated by the remote isn't
"connected" to the server application that I can tell.
Assembly.GetExecutingAssembly() indicates that the object is running
under the object's library dll and Assembly.GetCallingAssembly()
returns a windows system dll.

In MFC, all I would have to do from a server dll is call AfxGetApp()
and recast it to my CMainApp() derived class.  Is there an equivalent
in dotNet or is there another way I can access the instance of my
server?  As you may suspect, I am a newbie in C# and dotNet.    It
might be trivial.

If you're going from the ground up, I'd go straight to WCF.

See my sample here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry

Its not a super-simple example like (you and I both) find alot of times.

..

However, the objects that get sent across the wire are ... copies.

I'm not sure what you're getting at.  Do you want the code to execute on the 
server?
You want the objects to be connected to the server at all times?

Check this blog entry as well.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry

But I still recommend going to WCF.




"r norman"  wrote in message 
news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>I am converting a C++ MFC client-server application to C# dotNet and I
> would like to switch my TCP/IP messages to use dotNet remoting
> concepts.  I can successfully implement many remoting samples, for
> example from Wrox Press Professional C#.  However all of these find
> have trivial objects that are invoked on the server.  None has to
> access any difficult data values to return to the client.  I need to
> access data maintained by class instances within the server
> application.  Yet the server object instantiated by the remote isn't
> "connected" to the server application that I can tell.
> Assembly.GetExecutingAssembly() indicates that the object is running
> under the object's library dll and Assembly.GetCallingAssembly()
> returns a windows system dll.
>
> In MFC, all I would have to do from a server dll is call AfxGetApp()
> and recast it to my CMainApp() derived class.  Is there an equivalent
> in dotNet or is there another way I can access the instance of my
> server?  As you may suspect, I am a newbie in C# and dotNet.    It
> might be trivial.
>

On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:

>
>If you're going from the ground up, I'd go straight to WCF.
>
>See my sample here:
>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>
>Its not a super-simple example like (you and I both) find alot of times.
>
>..
>
>However, the objects that get sent across the wire are ... copies.
>
>I'm not sure what you're getting at.  Do you want the code to execute on the 
>server?
>You want the objects to be connected to the server at all times?
>
>Check this blog entry as well.
>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>
>But I still recommend going to WCF.
>
>
>
>
>"r norman"  wrote in message 
>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>I am converting a C++ MFC client-server application to C# dotNet and I
>> would like to switch my TCP/IP messages to use dotNet remoting
>> concepts.  I can successfully implement many remoting samples, for
>> example from Wrox Press Professional C#.  However all of these find
>> have trivial objects that are invoked on the server.  None has to
>> access any difficult data values to return to the client.  I need to
>> access data maintained by class instances within the server
>> application.  Yet the server object instantiated by the remote isn't
>> "connected" to the server application that I can tell.
>> Assembly.GetExecutingAssembly() indicates that the object is running
>> under the object's library dll and Assembly.GetCallingAssembly()
>> returns a windows system dll.
>>
>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>> and recast it to my CMainApp() derived class.  Is there an equivalent
>> in dotNet or is there another way I can access the instance of my
>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>> might be trivial.
>> 
>

Thanks for the pointer.  I did browse through this newsgroup
(ms.public.distributed_apps) before posting and saw references
(probably yours) to WCF but didn't find much reference to it
elsewhere.  But I'll take a look.

What I want to do is to have the client query the server for data
values that relate to various external equipment that the server is
communicating with.  So the client proxy class has to communicate with
the host real class which interrogates the real server app to find out
what the current state of that external equipment is.

The follow the link...that I have at my Remoting Post.
He discusses why.....and refers to a "super particle beam" thing in jest.
..

But .... you can do the same thing with WCF, via my "WCF Interfaced 
Development".


You're letting the "Host" do the data collecting, and then pushing the 
collected data to the client.




"r norman"  wrote in message 
news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>
>>
>>If you're going from the ground up, I'd go straight to WCF.
>>
>>See my sample here:
>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>
>>Its not a super-simple example like (you and I both) find alot of times.
>>
>>..
>>
>>However, the objects that get sent across the wire are ... copies.
>>
>>I'm not sure what you're getting at.  Do you want the code to execute on 
>>the
>>server?
>>You want the objects to be connected to the server at all times?
>>
>>Check this blog entry as well.
>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>
>>But I still recommend going to WCF.
>>
>>
>>
>>
>>"r norman"  wrote in message
>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>I am converting a C++ MFC client-server application to C# dotNet and I
>>> would like to switch my TCP/IP messages to use dotNet remoting
>>> concepts.  I can successfully implement many remoting samples, for
>>> example from Wrox Press Professional C#.  However all of these find
>>> have trivial objects that are invoked on the server.  None has to
>>> access any difficult data values to return to the client.  I need to
>>> access data maintained by class instances within the server
>>> application.  Yet the server object instantiated by the remote isn't
>>> "connected" to the server application that I can tell.
>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>> under the object's library dll and Assembly.GetCallingAssembly()
>>> returns a windows system dll.
>>>
>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>> and recast it to my CMainApp() derived class.  Is there an equivalent
>>> in dotNet or is there another way I can access the instance of my
>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>> might be trivial.
>>>
>>
>
> Thanks for the pointer.  I did browse through this newsgroup
> (ms.public.distributed_apps) before posting and saw references
> (probably yours) to WCF but didn't find much reference to it
> elsewhere.  But I'll take a look.
>
> What I want to do is to have the client query the server for data
> values that relate to various external equipment that the server is
> communicating with.  So the client proxy class has to communicate with
> the host real class which interrogates the real server app to find out
> what the current state of that external equipment is.
>

On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:

>The follow the link...that I have at my Remoting Post.
>He discusses why.....and refers to a "super particle beam" thing in jest.
>..
>
>But .... you can do the same thing with WCF, via my "WCF Interfaced 
>Development".
>
>
>You're letting the "Host" do the data collecting, and then pushing the 
>collected data to the client.
>

Thanks.  I've already downloaded the sample.  Now I have a lot of work
to do.

There is no choice about the data.  The host is hard-wired to the
external equipment and the clients are scattered around the city.

And I have a choice between the host pushing and the client polling.
One of the hosts has a slow, congested DSL link to the rest of the
network and traffic levels are an issue with my current data pushing
scheme.  There is an awful lot of data and the client only looks at a
small portion of it at any time. It is a lot easier for the client to
ask for what it wants than for the host to try to keep track of what
to send, different for each client.

You may recall that I did admit to being a newbie in dotNet.  Of
course WCF seems to be dotNet 3.0 and I am currently tied to Visual
Studio 2005 and dotNet 2 and don't feel like shelling out another
thousand bucks or so just to be that current.  My socket TCP/IP
messaging has worked well through Dos and C through Windows and C++
and translated easily into dotNet and C#.  There is a limit on just
how much I am willing to upgrade the infrastructure of the project if
it doesn't show up in the user interface where you can far more easily
justify the cost.  There is always the response "it works now, why
should I pay X thousand dollars extra to get the same thing?".  Yes,
the infrastructure is the most important part, but it is also the
hardest to sell.

On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:

>The follow the link...that I have at my Remoting Post.
>He discusses why.....and refers to a "super particle beam" thing in jest.
>..
>
>But .... you can do the same thing with WCF, via my "WCF Interfaced 
>Development".
>
>
>You're letting the "Host" do the data collecting, and then pushing the 
>collected data to the client.
>
>
>
>
>"r norman"  wrote in message 
>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>
>>>
>>>If you're going from the ground up, I'd go straight to WCF.
>>>
>>>See my sample here:
>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>
>>>Its not a super-simple example like (you and I both) find alot of times.
>>>
>>>..
>>>
>>>However, the objects that get sent across the wire are ... copies.
>>>
>>>I'm not sure what you're getting at.  Do you want the code to execute on 
>>>the
>>>server?
>>>You want the objects to be connected to the server at all times?
>>>
>>>Check this blog entry as well.
>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>
>>>But I still recommend going to WCF.
>>>
>>>
>>>
>>>
>>>"r norman"  wrote in message
>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>I am converting a C++ MFC client-server application to C# dotNet and I
>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>> concepts.  I can successfully implement many remoting samples, for
>>>> example from Wrox Press Professional C#.  However all of these find
>>>> have trivial objects that are invoked on the server.  None has to
>>>> access any difficult data values to return to the client.  I need to
>>>> access data maintained by class instances within the server
>>>> application.  Yet the server object instantiated by the remote isn't
>>>> "connected" to the server application that I can tell.
>>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>> returns a windows system dll.
>>>>
>>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>>> and recast it to my CMainApp() derived class.  Is there an equivalent
>>>> in dotNet or is there another way I can access the instance of my
>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>> might be trivial.
>>>>
>>>
>>
>> Thanks for the pointer.  I did browse through this newsgroup
>> (ms.public.distributed_apps) before posting and saw references
>> (probably yours) to WCF but didn't find much reference to it
>> elsewhere.  But I'll take a look.
>>
>> What I want to do is to have the client query the server for data
>> values that relate to various external equipment that the server is
>> communicating with.  So the client proxy class has to communicate with
>> the host real class which interrogates the real server app to find out
>> what the current state of that external equipment is.
>> 
>

3.0 is an "addon" to 2.0.  It does not require a new version of VS200x. It 
works with VS2005.

The framework is free.
The CTP is free.

So there is not a financial reason not to do it.


3.0 runs on XP, WinServer2003, Vista and WinServer2008.

.......



"r norman"  wrote in message 
news:5239j35ig21sncjgamomcdaa8tgc8k0q8c@4ax.com...
> You may recall that I did admit to being a newbie in dotNet.  Of
> course WCF seems to be dotNet 3.0 and I am currently tied to Visual
> Studio 2005 and dotNet 2 and don't feel like shelling out another
> thousand bucks or so just to be that current.  My socket TCP/IP
> messaging has worked well through Dos and C through Windows and C++
> and translated easily into dotNet and C#.  There is a limit on just
> how much I am willing to upgrade the infrastructure of the project if
> it doesn't show up in the user interface where you can far more easily
> justify the cost.  There is always the response "it works now, why
> should I pay X thousand dollars extra to get the same thing?".  Yes,
> the infrastructure is the most important part, but it is also the
> hardest to sell.
>
> On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:
>
>>The follow the link...that I have at my Remoting Post.
>>He discusses why.....and refers to a "super particle beam" thing in jest.
>>..
>>
>>But .... you can do the same thing with WCF, via my "WCF Interfaced
>>Development".
>>
>>
>>You're letting the "Host" do the data collecting, and then pushing the
>>collected data to the client.
>>
>>
>>
>>
>>"r norman"  wrote in message
>>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>>
>>>>
>>>>If you're going from the ground up, I'd go straight to WCF.
>>>>
>>>>See my sample here:
>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>>
>>>>Its not a super-simple example like (you and I both) find alot of times.
>>>>
>>>>..
>>>>
>>>>However, the objects that get sent across the wire are ... copies.
>>>>
>>>>I'm not sure what you're getting at.  Do you want the code to execute on
>>>>the
>>>>server?
>>>>You want the objects to be connected to the server at all times?
>>>>
>>>>Check this blog entry as well.
>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>>
>>>>But I still recommend going to WCF.
>>>>
>>>>
>>>>
>>>>
>>>>"r norman"  wrote in message
>>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>>I am converting a C++ MFC client-server application to C# dotNet and I
>>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>>> concepts.  I can successfully implement many remoting samples, for
>>>>> example from Wrox Press Professional C#.  However all of these find
>>>>> have trivial objects that are invoked on the server.  None has to
>>>>> access any difficult data values to return to the client.  I need to
>>>>> access data maintained by class instances within the server
>>>>> application.  Yet the server object instantiated by the remote isn't
>>>>> "connected" to the server application that I can tell.
>>>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>>> returns a windows system dll.
>>>>>
>>>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>>>> and recast it to my CMainApp() derived class.  Is there an equivalent
>>>>> in dotNet or is there another way I can access the instance of my
>>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>>> might be trivial.
>>>>>
>>>>
>>>
>>> Thanks for the pointer.  I did browse through this newsgroup
>>> (ms.public.distributed_apps) before posting and saw references
>>> (probably yours) to WCF but didn't find much reference to it
>>> elsewhere.  But I'll take a look.
>>>
>>> What I want to do is to have the client query the server for data
>>> values that relate to various external equipment that the server is
>>> communicating with.  So the client proxy class has to communicate with
>>> the host real class which interrogates the real server app to find out
>>> what the current state of that external equipment is.
>>>
>>

On Fri, 9 Nov 2007 13:54:43 -0500, "sloan"  wrote:

Does installing dotNet 3.0 on my system automatically give VS2005 the
ability to reference System.ServiceModel?  (You see how much I don't
know?)

>3.0 is an "addon" to 2.0.  It does not require a new version of VS200x. It 
>works with VS2005.
>
>The framework is free.
>The CTP is free.
>
>So there is not a financial reason not to do it.
>
>
>3.0 runs on XP, WinServer2003, Vista and WinServer2008.
>
>.......
>
>
>
>"r norman"  wrote in message 
>news:5239j35ig21sncjgamomcdaa8tgc8k0q8c@4ax.com...
>> You may recall that I did admit to being a newbie in dotNet.  Of
>> course WCF seems to be dotNet 3.0 and I am currently tied to Visual
>> Studio 2005 and dotNet 2 and don't feel like shelling out another
>> thousand bucks or so just to be that current.  My socket TCP/IP
>> messaging has worked well through Dos and C through Windows and C++
>> and translated easily into dotNet and C#.  There is a limit on just
>> how much I am willing to upgrade the infrastructure of the project if
>> it doesn't show up in the user interface where you can far more easily
>> justify the cost.  There is always the response "it works now, why
>> should I pay X thousand dollars extra to get the same thing?".  Yes,
>> the infrastructure is the most important part, but it is also the
>> hardest to sell.
>>
>> On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:
>>
>>>The follow the link...that I have at my Remoting Post.
>>>He discusses why.....and refers to a "super particle beam" thing in jest.
>>>..
>>>
>>>But .... you can do the same thing with WCF, via my "WCF Interfaced
>>>Development".
>>>
>>>
>>>You're letting the "Host" do the data collecting, and then pushing the
>>>collected data to the client.
>>>
>>>
>>>
>>>
>>>"r norman"  wrote in message
>>>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>>>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>>>
>>>>>
>>>>>If you're going from the ground up, I'd go straight to WCF.
>>>>>
>>>>>See my sample here:
>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>>>
>>>>>Its not a super-simple example like (you and I both) find alot of times.
>>>>>
>>>>>..
>>>>>
>>>>>However, the objects that get sent across the wire are ... copies.
>>>>>
>>>>>I'm not sure what you're getting at.  Do you want the code to execute on
>>>>>the
>>>>>server?
>>>>>You want the objects to be connected to the server at all times?
>>>>>
>>>>>Check this blog entry as well.
>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>>>
>>>>>But I still recommend going to WCF.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>"r norman"  wrote in message
>>>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>>>I am converting a C++ MFC client-server application to C# dotNet and I
>>>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>>>> concepts.  I can successfully implement many remoting samples, for
>>>>>> example from Wrox Press Professional C#.  However all of these find
>>>>>> have trivial objects that are invoked on the server.  None has to
>>>>>> access any difficult data values to return to the client.  I need to
>>>>>> access data maintained by class instances within the server
>>>>>> application.  Yet the server object instantiated by the remote isn't
>>>>>> "connected" to the server application that I can tell.
>>>>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>>>> returns a windows system dll.
>>>>>>
>>>>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>>>>> and recast it to my CMainApp() derived class.  Is there an equivalent
>>>>>> in dotNet or is there another way I can access the instance of my
>>>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>>>> might be trivial.
>>>>>>
>>>>>
>>>>
>>>> Thanks for the pointer.  I did browse through this newsgroup
>>>> (ms.public.distributed_apps) before posting and saw references
>>>> (probably yours) to WCF but didn't find much reference to it
>>>> elsewhere.  But I'll take a look.
>>>>
>>>> What I want to do is to have the client query the server for data
>>>> values that relate to various external equipment that the server is
>>>> communicating with.  So the client proxy class has to communicate with
>>>> the host real class which interrogates the real server app to find out
>>>> what the current state of that external equipment is.
>>>>
>>> 
>

I googled "WCF Getting Started".

Found this:
http://www.thoughtshapes.com/WCF/GettingStarted.htm


"r norman"  wrote in message 
news:ffb9j3d02iubaa6omiuhkl1q7i8ug6ao5l@4ax.com...
> On Fri, 9 Nov 2007 13:54:43 -0500, "sloan"  wrote:
>
> Does installing dotNet 3.0 on my system automatically give VS2005 the
> ability to reference System.ServiceModel?  (You see how much I don't
> know?)
>
>>3.0 is an "addon" to 2.0.  It does not require a new version of VS200x. It
>>works with VS2005.
>>
>>The framework is free.
>>The CTP is free.
>>
>>So there is not a financial reason not to do it.
>>
>>
>>3.0 runs on XP, WinServer2003, Vista and WinServer2008.
>>
>>.......
>>
>>
>>
>>"r norman"  wrote in message
>>news:5239j35ig21sncjgamomcdaa8tgc8k0q8c@4ax.com...
>>> You may recall that I did admit to being a newbie in dotNet.  Of
>>> course WCF seems to be dotNet 3.0 and I am currently tied to Visual
>>> Studio 2005 and dotNet 2 and don't feel like shelling out another
>>> thousand bucks or so just to be that current.  My socket TCP/IP
>>> messaging has worked well through Dos and C through Windows and C++
>>> and translated easily into dotNet and C#.  There is a limit on just
>>> how much I am willing to upgrade the infrastructure of the project if
>>> it doesn't show up in the user interface where you can far more easily
>>> justify the cost.  There is always the response "it works now, why
>>> should I pay X thousand dollars extra to get the same thing?".  Yes,
>>> the infrastructure is the most important part, but it is also the
>>> hardest to sell.
>>>
>>> On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:
>>>
>>>>The follow the link...that I have at my Remoting Post.
>>>>He discusses why.....and refers to a "super particle beam" thing in 
>>>>jest.
>>>>..
>>>>
>>>>But .... you can do the same thing with WCF, via my "WCF Interfaced
>>>>Development".
>>>>
>>>>
>>>>You're letting the "Host" do the data collecting, and then pushing the
>>>>collected data to the client.
>>>>
>>>>
>>>>
>>>>
>>>>"r norman"  wrote in message
>>>>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>>>>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>>>>
>>>>>>
>>>>>>If you're going from the ground up, I'd go straight to WCF.
>>>>>>
>>>>>>See my sample here:
>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>>>>
>>>>>>Its not a super-simple example like (you and I both) find alot of 
>>>>>>times.
>>>>>>
>>>>>>..
>>>>>>
>>>>>>However, the objects that get sent across the wire are ... copies.
>>>>>>
>>>>>>I'm not sure what you're getting at.  Do you want the code to execute 
>>>>>>on
>>>>>>the
>>>>>>server?
>>>>>>You want the objects to be connected to the server at all times?
>>>>>>
>>>>>>Check this blog entry as well.
>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>>>>
>>>>>>But I still recommend going to WCF.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>"r norman"  wrote in message
>>>>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>>>>I am converting a C++ MFC client-server application to C# dotNet and 
>>>>>>>I
>>>>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>>>>> concepts.  I can successfully implement many remoting samples, for
>>>>>>> example from Wrox Press Professional C#.  However all of these find
>>>>>>> have trivial objects that are invoked on the server.  None has to
>>>>>>> access any difficult data values to return to the client.  I need to
>>>>>>> access data maintained by class instances within the server
>>>>>>> application.  Yet the server object instantiated by the remote isn't
>>>>>>> "connected" to the server application that I can tell.
>>>>>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>>>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>>>>> returns a windows system dll.
>>>>>>>
>>>>>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>>>>>> and recast it to my CMainApp() derived class.  Is there an 
>>>>>>> equivalent
>>>>>>> in dotNet or is there another way I can access the instance of my
>>>>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>>>>> might be trivial.
>>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for the pointer.  I did browse through this newsgroup
>>>>> (ms.public.distributed_apps) before posting and saw references
>>>>> (probably yours) to WCF but didn't find much reference to it
>>>>> elsewhere.  But I'll take a look.
>>>>>
>>>>> What I want to do is to have the client query the server for data
>>>>> values that relate to various external equipment that the server is
>>>>> communicating with.  So the client proxy class has to communicate with
>>>>> the host real class which interrogates the real server app to find out
>>>>> what the current state of that external equipment is.
>>>>>
>>>>
>>

That should do it. As that site says, "like most new technologies it
might not be obvious how one goes about experimenting with it for the
first time".

I am using the time until they give me a P.O. for the new system to
upgrade my skills, and the farther I can get (with moderate but not
excessive stress on my part), the better the result will be.  WCF
sounds like the appropriate technology and I now have enough tutorial
information to go on my on.

Thanks a real big heap.  You have been an enormous help.


On Fri, 9 Nov 2007 14:09:33 -0500, "sloan"  wrote:

>
>I googled "WCF Getting Started".
>
>Found this:
>http://www.thoughtshapes.com/WCF/GettingStarted.htm
>
>
>"r norman"  wrote in message 
>news:ffb9j3d02iubaa6omiuhkl1q7i8ug6ao5l@4ax.com...
>> On Fri, 9 Nov 2007 13:54:43 -0500, "sloan"  wrote:
>>
>> Does installing dotNet 3.0 on my system automatically give VS2005 the
>> ability to reference System.ServiceModel?  (You see how much I don't
>> know?)
>>
>>>3.0 is an "addon" to 2.0.  It does not require a new version of VS200x. It
>>>works with VS2005.
>>>
>>>The framework is free.
>>>The CTP is free.
>>>
>>>So there is not a financial reason not to do it.
>>>
>>>
>>>3.0 runs on XP, WinServer2003, Vista and WinServer2008.
>>>
>>>.......
>>>
>>>
>>>
>>>"r norman"  wrote in message
>>>news:5239j35ig21sncjgamomcdaa8tgc8k0q8c@4ax.com...
>>>> You may recall that I did admit to being a newbie in dotNet.  Of
>>>> course WCF seems to be dotNet 3.0 and I am currently tied to Visual
>>>> Studio 2005 and dotNet 2 and don't feel like shelling out another
>>>> thousand bucks or so just to be that current.  My socket TCP/IP
>>>> messaging has worked well through Dos and C through Windows and C++
>>>> and translated easily into dotNet and C#.  There is a limit on just
>>>> how much I am willing to upgrade the infrastructure of the project if
>>>> it doesn't show up in the user interface where you can far more easily
>>>> justify the cost.  There is always the response "it works now, why
>>>> should I pay X thousand dollars extra to get the same thing?".  Yes,
>>>> the infrastructure is the most important part, but it is also the
>>>> hardest to sell.
>>>>
>>>> On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:
>>>>
>>>>>The follow the link...that I have at my Remoting Post.
>>>>>He discusses why.....and refers to a "super particle beam" thing in 
>>>>>jest.
>>>>>..
>>>>>
>>>>>But .... you can do the same thing with WCF, via my "WCF Interfaced
>>>>>Development".
>>>>>
>>>>>
>>>>>You're letting the "Host" do the data collecting, and then pushing the
>>>>>collected data to the client.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>"r norman"  wrote in message
>>>>>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>>>>>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>>>>>
>>>>>>>
>>>>>>>If you're going from the ground up, I'd go straight to WCF.
>>>>>>>
>>>>>>>See my sample here:
>>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>>>>>
>>>>>>>Its not a super-simple example like (you and I both) find alot of 
>>>>>>>times.
>>>>>>>
>>>>>>>..
>>>>>>>
>>>>>>>However, the objects that get sent across the wire are ... copies.
>>>>>>>
>>>>>>>I'm not sure what you're getting at.  Do you want the code to execute 
>>>>>>>on
>>>>>>>the
>>>>>>>server?
>>>>>>>You want the objects to be connected to the server at all times?
>>>>>>>
>>>>>>>Check this blog entry as well.
>>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>>>>>
>>>>>>>But I still recommend going to WCF.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>"r norman"  wrote in message
>>>>>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>>>>>I am converting a C++ MFC client-server application to C# dotNet and 
>>>>>>>>I
>>>>>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>>>>>> concepts.  I can successfully implement many remoting samples, for
>>>>>>>> example from Wrox Press Professional C#.  However all of these find
>>>>>>>> have trivial objects that are invoked on the server.  None has to
>>>>>>>> access any difficult data values to return to the client.  I need to
>>>>>>>> access data maintained by class instances within the server
>>>>>>>> application.  Yet the server object instantiated by the remote isn't
>>>>>>>> "connected" to the server application that I can tell.
>>>>>>>> Assembly.GetExecutingAssembly() indicates that the object is running
>>>>>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>>>>>> returns a windows system dll.
>>>>>>>>
>>>>>>>> In MFC, all I would have to do from a server dll is call AfxGetApp()
>>>>>>>> and recast it to my CMainApp() derived class.  Is there an 
>>>>>>>> equivalent
>>>>>>>> in dotNet or is there another way I can access the instance of my
>>>>>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>>>>>> might be trivial.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for the pointer.  I did browse through this newsgroup
>>>>>> (ms.public.distributed_apps) before posting and saw references
>>>>>> (probably yours) to WCF but didn't find much reference to it
>>>>>> elsewhere.  But I'll take a look.
>>>>>>
>>>>>> What I want to do is to have the client query the server for data
>>>>>> values that relate to various external equipment that the server is
>>>>>> communicating with.  So the client proxy class has to communicate with
>>>>>> the host real class which interrogates the real server app to find out
>>>>>> what the current state of that external equipment is.
>>>>>>
>>>>>
>>> 
>

Ok.

Please read my NOTE at my blog as well.

There is a slight tweak needed to get it to work without WF (WorkFlow).

..

"r norman"  wrote in message 
news:oje9j3lr66sp4hprldosvkm0foao50v7ls@4ax.com...
> That should do it. As that site says, "like most new technologies it
> might not be obvious how one goes about experimenting with it for the
> first time".
>
> I am using the time until they give me a P.O. for the new system to
> upgrade my skills, and the farther I can get (with moderate but not
> excessive stress on my part), the better the result will be.  WCF
> sounds like the appropriate technology and I now have enough tutorial
> information to go on my on.
>
> Thanks a real big heap.  You have been an enormous help.
>
>
> On Fri, 9 Nov 2007 14:09:33 -0500, "sloan"  wrote:
>
>>
>>I googled "WCF Getting Started".
>>
>>Found this:
>>http://www.thoughtshapes.com/WCF/GettingStarted.htm
>>
>>
>>"r norman"  wrote in message
>>news:ffb9j3d02iubaa6omiuhkl1q7i8ug6ao5l@4ax.com...
>>> On Fri, 9 Nov 2007 13:54:43 -0500, "sloan"  wrote:
>>>
>>> Does installing dotNet 3.0 on my system automatically give VS2005 the
>>> ability to reference System.ServiceModel?  (You see how much I don't
>>> know?)
>>>
>>>>3.0 is an "addon" to 2.0.  It does not require a new version of VS200x. 
>>>>It
>>>>works with VS2005.
>>>>
>>>>The framework is free.
>>>>The CTP is free.
>>>>
>>>>So there is not a financial reason not to do it.
>>>>
>>>>
>>>>3.0 runs on XP, WinServer2003, Vista and WinServer2008.
>>>>
>>>>.......
>>>>
>>>>
>>>>
>>>>"r norman"  wrote in message
>>>>news:5239j35ig21sncjgamomcdaa8tgc8k0q8c@4ax.com...
>>>>> You may recall that I did admit to being a newbie in dotNet.  Of
>>>>> course WCF seems to be dotNet 3.0 and I am currently tied to Visual
>>>>> Studio 2005 and dotNet 2 and don't feel like shelling out another
>>>>> thousand bucks or so just to be that current.  My socket TCP/IP
>>>>> messaging has worked well through Dos and C through Windows and C++
>>>>> and translated easily into dotNet and C#.  There is a limit on just
>>>>> how much I am willing to upgrade the infrastructure of the project if
>>>>> it doesn't show up in the user interface where you can far more easily
>>>>> justify the cost.  There is always the response "it works now, why
>>>>> should I pay X thousand dollars extra to get the same thing?".  Yes,
>>>>> the infrastructure is the most important part, but it is also the
>>>>> hardest to sell.
>>>>>
>>>>> On Thu, 8 Nov 2007 20:56:55 -0500, "sloan"  wrote:
>>>>>
>>>>>>The follow the link...that I have at my Remoting Post.
>>>>>>He discusses why.....and refers to a "super particle beam" thing in
>>>>>>jest.
>>>>>>..
>>>>>>
>>>>>>But .... you can do the same thing with WCF, via my "WCF Interfaced
>>>>>>Development".
>>>>>>
>>>>>>
>>>>>>You're letting the "Host" do the data collecting, and then pushing the
>>>>>>collected data to the client.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>"r norman"  wrote in message
>>>>>>news:o3a7j3p9tpbjsldt4mq22ainphcp08s3hm@4ax.com...
>>>>>>> On Thu, 8 Nov 2007 17:01:16 -0500, "sloan"  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>If you're going from the ground up, I'd go straight to WCF.
>>>>>>>>
>>>>>>>>See my sample here:
>>>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
>>>>>>>>
>>>>>>>>Its not a super-simple example like (you and I both) find alot of
>>>>>>>>times.
>>>>>>>>
>>>>>>>>..
>>>>>>>>
>>>>>>>>However, the objects that get sent across the wire are ... copies.
>>>>>>>>
>>>>>>>>I'm not sure what you're getting at.  Do you want the code to 
>>>>>>>>execute
>>>>>>>>on
>>>>>>>>the
>>>>>>>>server?
>>>>>>>>You want the objects to be connected to the server at all times?
>>>>>>>>
>>>>>>>>Check this blog entry as well.
>>>>>>>>http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!122.entry
>>>>>>>>
>>>>>>>>But I still recommend going to WCF.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>"r norman"  wrote in message
>>>>>>>>news:cl07j318asoergdptl23u6morui437ammc@4ax.com...
>>>>>>>>>I am converting a C++ MFC client-server application to C# dotNet 
>>>>>>>>>and
>>>>>>>>>I
>>>>>>>>> would like to switch my TCP/IP messages to use dotNet remoting
>>>>>>>>> concepts.  I can successfully implement many remoting samples, for
>>>>>>>>> example from Wrox Press Professional C#.  However all of these 
>>>>>>>>> find
>>>>>>>>> have trivial objects that are invoked on the server.  None has to
>>>>>>>>> access any difficult data values to return to the client.  I need 
>>>>>>>>> to
>>>>>>>>> access data maintained by class instances within the server
>>>>>>>>> application.  Yet the server object instantiated by the remote 
>>>>>>>>> isn't
>>>>>>>>> "connected" to the server application that I can tell.
>>>>>>>>> Assembly.GetExecutingAssembly() indicates that the object is 
>>>>>>>>> running
>>>>>>>>> under the object's library dll and Assembly.GetCallingAssembly()
>>>>>>>>> returns a windows system dll.
>>>>>>>>>
>>>>>>>>> In MFC, all I would have to do from a server dll is call 
>>>>>>>>> AfxGetApp()
>>>>>>>>> and recast it to my CMainApp() derived class.  Is there an
>>>>>>>>> equivalent
>>>>>>>>> in dotNet or is there another way I can access the instance of my
>>>>>>>>> server?  As you may suspect, I am a newbie in C# and dotNet.    It
>>>>>>>>> might be trivial.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for the pointer.  I did browse through this newsgroup
>>>>>>> (ms.public.distributed_apps) before posting and saw references
>>>>>>> (probably yours) to WCF but didn't find much reference to it
>>>>>>> elsewhere.  But I'll take a look.
>>>>>>>
>>>>>>> What I want to do is to have the client query the server for data
>>>>>>> values that relate to various external equipment that the server is
>>>>>>> communicating with.  So the client proxy class has to communicate 
>>>>>>> with
>>>>>>> the host real class which interrogates the real server app to find 
>>>>>>> out
>>>>>>> what the current state of that external equipment is.
>>>>>>>
>>>>>>
>>>>
>>