Hello,
in my remoting client, i am first registering a TcpChannel after creating it 
with the following properties

secure = "True"
userName = "U1"
password="P1"

i connect to the server and invoke methods and everything works fine because 
'U1' and 'P1' are valid credentials.

Now i call StopListening on the channel, unregister the channel and then 
register a new channel with different credentials userName="U2" and 
password="P2". These i know are invalid. however if i connect to the server 
and invoke methods, it still works even though the credentials are invalid. 
it seems that even if i unregister a channel, its setting are still effective 
and not replaced by the second set of the newly registered channel. can 
anyone please tell me a solution
-- 
mathai

Hello Mathai,

From your post, my understanding on this issue is: you wondered why the 
security settings were kept when you unregistered the TcpChannel to a .net 
remoting server and register the channel again with an incorrect password 
and username. If I'm off base, please feel free to let me know.

I reproduced your issue in the attached test project. (The attachment can 
be downloaded with Outlook Express or Windows Mail).
In that test project, there are two remote types: RemoteObject and 
RemoteLife. In the client side code, I first registered a TcpChannel with 
correct user name and password, then registered the remote type: 
RemoteObject and create an instance of RemoteObject to call its method: 
GetCount. All these operations were ok. 

Then I unregistered the TcpChannel 
(ChannelServices.UnregisterChannel(clientChannel)) and registered a new 
TcpChannel with incorrect password. When I tried to register the remote 
type: RemoteObject again 
(RemotingConfiguration.RegisterWellKnownClientType(remoteType);), I found I 
could not do that because RemoteObject has already been registered during 
the first TcpChannel connection. Thus I commented that line and started to 
register another remote type: RemoteLife. Finally, I created an instance of 
RemoteObject and called its function successfully as you said. But when I 
called the function of an instance of RemoteLife, it failed because of the 
unauthorized connection. Therefore, my conclusion is that the call the 
RemoteObject is actually still using the authorized registered type in the 
first phase. We need to unregister the remote type after the channel is 
unregistered, and register the remote type again in the new channel.

Thus, the current problem is how to unregister a remote type. 

There is no 'unregister' methods available in RemoteingConfiguration. 
RemotingConfiguration.Configure() won't help as well. According to the MSDN 
article: http://msdn2.microsoft.com/en-us/library/ms973857.aspx, Channels 
are registered per application domain. There can be multiple application 
domains in a single process. When a process dies, all channels that it 
registers are automatically destroyed. Therefore, the workaround is to 
create a secondary AppDomain in your application and call 
RemotingConfiguration.Configure() from this newly created AppDomain. When 
you are done with your first channel connection, you can unload the 
AppDomain and start with a new domain instead. Hope it helps.

Besides, I have sent emails to our development team to confirm this 
behavior of Remoting. I will also do further researches for other 
workarounds.

Please let me know if you have any other concerns, or need anything else.

Sincerely,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
For MSDN subscribers whose posts are left unanswered, please check this 
document: http://blogs.msdn.com/msdnts/pages/postingAlias.aspx

Get notification to my posts through email? Please refer to 
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express/Windows Mail, please make sure 
you clear the check box "Tools/Options/Read: Get 300 headers at a time" to 
see your reply promptly.

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://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Jialiang,
Thanks for your prompt reply. you have hit the problem on the dot. I will 
try the appdomain method you have suggested. Please keep me posted if there 
are any further developments.
Regards Mathai
-- 
mathai


"Jialiang Ge [MSFT]" wrote:


> Hello Mathai,
> 
> From your post, my understanding on this issue is: you wondered why the 
> security settings were kept when you unregistered the TcpChannel to a .net 
> remoting server and register the channel again with an incorrect password 
> and username. If I'm off base, please feel free to let me know.
> 
> I reproduced your issue in the attached test project. (The attachment can 
> be downloaded with Outlook Express or Windows Mail).
> In that test project, there are two remote types: RemoteObject and 
> RemoteLife. In the client side code, I first registered a TcpChannel with 
> correct user name and password, then registered the remote type: 
> RemoteObject and create an instance of RemoteObject to call its method: 
> GetCount. All these operations were ok. 
> 
> Then I unregistered the TcpChannel 
> (ChannelServices.UnregisterChannel(clientChannel)) and registered a new 
> TcpChannel with incorrect password. When I tried to register the remote 
> type: RemoteObject again 
> (RemotingConfiguration.RegisterWellKnownClientType(remoteType);), I found I 
> could not do that because RemoteObject has already been registered during 
> the first TcpChannel connection. Thus I commented that line and started to 
> register another remote type: RemoteLife. Finally, I created an instance of 
> RemoteObject and called its function successfully as you said. But when I 
> called the function of an instance of RemoteLife, it failed because of the 
> unauthorized connection. Therefore, my conclusion is that the call the 
> RemoteObject is actually still using the authorized registered type in the 
> first phase. We need to unregister the remote type after the channel is 
> unregistered, and register the remote type again in the new channel.
> 
> Thus, the current problem is how to unregister a remote type. 
> 
> There is no 'unregister' methods available in RemoteingConfiguration. 
> RemotingConfiguration.Configure() won't help as well. According to the MSDN 
> article: http://msdn2.microsoft.com/en-us/library/ms973857.aspx, Channels 
> are registered per application domain. There can be multiple application 
> domains in a single process. When a process dies, all channels that it 
> registers are automatically destroyed. Therefore, the workaround is to 
> create a secondary AppDomain in your application and call 
> RemotingConfiguration.Configure() from this newly created AppDomain. When 
> you are done with your first channel connection, you can unload the 
> AppDomain and start with a new domain instead. Hope it helps.
> 
> Besides, I have sent emails to our development team to confirm this 
> behavior of Remoting. I will also do further researches for other 
> workarounds.
> 
> Please let me know if you have any other concerns, or need anything else.
> 
> Sincerely,
> Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
> 
> ==================================================
> For MSDN subscribers whose posts are left unanswered, please check this 
> document: http://blogs.msdn.com/msdnts/pages/postingAlias.aspx
> 
> Get notification to my posts through email? Please refer to 
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications. If you are using Outlook Express/Windows Mail, please make sure 
> you clear the check box "Tools/Options/Read: Get 300 headers at a time" to 
> see your reply promptly.
> 
> 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://msdn.microsoft.com/subscriptions/support/default.aspx.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights