![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 Icould 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 (AT) online (DOT) 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/subscripti...ult.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/subscripti...t/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights |
#3
| |||
| |||
|
#4
| |||
| |||
|
|
Hello Mathai, The development team has confirmed this behavior of .NET Remoting. How is your trial of AppDomain? By the way, if you search 'How to unregister a remote type in .NET remoting', you may see many community members suggest 'RemotingServices.Disconnect' in client side. But actually, Disconnect is a server side API to disconnect objects which are currently published via Remoting. You might have noticed an exception if Disconnect is called on a remoting proxy instead. Sincerely, Jialiang Ge (jialge (AT) online (DOT) microsoft.com, remove 'online.') Microsoft Online Community Support ================================================= When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================= This posting is provided "AS IS" with no warranties, and confers no rights. |
#5
| |||
| |||
|
#6
| |||
| |||
|
|
Hello Mathai, In fact, UnregisterChannel has removed the previous credentials. (If you register a new remote type in the new unauthorized channel, the call of that remote type object fails due to the incorrect user name or password.) The problem is, UnregisterChannel does not mean the remote type registered in this channel will also be unregistered. The remote type will still be active and valid in its life cycle which is determined by the app domain. Please let me know if you have any other concerns, or need anything else. Sincerely, Jialiang Ge (jialge (AT) online (DOT) microsoft.com, remove 'online.') Microsoft Online Community Support ================================================= When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================= This posting is provided "AS IS" with no warranties, and confers no rights. |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |