CallContext SerializationException
-
Hi all. I'm trying to pass some info from the client app to the remote singlecall object via Context, using CallContext.SetData / GetData. I've created the following ConxtextDataObject: [Serializable] public class CallContextData:ILogicalThreadAffinative { private string myData; public CallContextData() { } public string Data { get { return myData; } set { myData=value; } } public override string ToString() { return myData; } } In my AssemblyInfo file, the only security attribute I've included is: [assembly: PermissionSetAttribute(SecurityAction.RequestMinimum, Name="FullTrust")] I go ahead and set the context data, but when I make the remote object call, I always get the following expection: Error message would translate to "Due to security restrictions, the type Vigila.Objects.CallContextData cannot be accessed." {"Por restricciones de seguridad, no se puede obtener acceso al tipo Vigila.Objects.CallContextData." } [System.Runtime.Serialization.SerializationException]: {System.Runtime.Serialization.SerializationException} System.Object: {System.Runtime.Serialization.SerializationException} _className: "System.Runtime.Serialization.SerializationException" _COMPlusExceptionCode: -532459699 _exceptionMethod: _exceptionMethodString: "8\0GetSafeUninitializedObject\0mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\0System.Runtime.Serialization.FormatterServices\0System.Object GetSafeUninitializedObject(System.Type)" _helpURL: null _HResult: -2146233076 _innerException: {"Error de solicitud." } _message: "Por restricciones de seguridad, no se puede obtener acceso al tipo Vigila.Objects.CallContextData." _remoteStackIndex: 1 _remoteStackTraceString: "\nServer stack trace: \n at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type type)\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord pr)\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord pr)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandle
-
Hi all. I'm trying to pass some info from the client app to the remote singlecall object via Context, using CallContext.SetData / GetData. I've created the following ConxtextDataObject: [Serializable] public class CallContextData:ILogicalThreadAffinative { private string myData; public CallContextData() { } public string Data { get { return myData; } set { myData=value; } } public override string ToString() { return myData; } } In my AssemblyInfo file, the only security attribute I've included is: [assembly: PermissionSetAttribute(SecurityAction.RequestMinimum, Name="FullTrust")] I go ahead and set the context data, but when I make the remote object call, I always get the following expection: Error message would translate to "Due to security restrictions, the type Vigila.Objects.CallContextData cannot be accessed." {"Por restricciones de seguridad, no se puede obtener acceso al tipo Vigila.Objects.CallContextData." } [System.Runtime.Serialization.SerializationException]: {System.Runtime.Serialization.SerializationException} System.Object: {System.Runtime.Serialization.SerializationException} _className: "System.Runtime.Serialization.SerializationException" _COMPlusExceptionCode: -532459699 _exceptionMethod: _exceptionMethodString: "8\0GetSafeUninitializedObject\0mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\0System.Runtime.Serialization.FormatterServices\0System.Object GetSafeUninitializedObject(System.Type)" _helpURL: null _HResult: -2146233076 _innerException: {"Error de solicitud." } _message: "Por restricciones de seguridad, no se puede obtener acceso al tipo Vigila.Objects.CallContextData." _remoteStackIndex: 1 _remoteStackTraceString: "\nServer stack trace: \n at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type type)\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord pr)\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord pr)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)\r\n at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()\r\n at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandle
In which project's AssemblyInfo.cs file did you add that assembly-level declarative security attribute? The client or the server? If the code even runs at all, it's not a code access security problem. When the CLR loads your assembly it will demand for that permission set. If the demand fails, the assembly is not loaded. It'll never even get to your remoting code. To grant this permission set you'll need to run the client off your local machine (by default, local code runs with FullTrust permissions) or create a code group to grant your code (via whatever evidence seems suitable) the FullTrust permission set. So, have you tried debugging your code to make sure it's even loading? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
In which project's AssemblyInfo.cs file did you add that assembly-level declarative security attribute? The client or the server? If the code even runs at all, it's not a code access security problem. When the CLR loads your assembly it will demand for that permission set. If the demand fails, the assembly is not loaded. It'll never even get to your remoting code. To grant this permission set you'll need to run the client off your local machine (by default, local code runs with FullTrust permissions) or create a code group to grant your code (via whatever evidence seems suitable) the FullTrust permission set. So, have you tried debugging your code to make sure it's even loading? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
Hi Heath, thanks for the reply. Both Client and Server run on my machine and for sake of simplicity for the time being both assemblies and two other dlls (remote objects and general tools) are all linked to the same AssemblyInfo file so they all have the same set of permissions. My ContextData object is included in the 'general tools' dll. Code worked perfectly, and if I remove all CallContext code (the setter in the client app and getter in the remoteobject called method) everyting works perfectly again. The error seems to be when the remote call is made and before anything starts visibly 'moving' on the server side. A breakpoint in my remote object constructor (its a singlecall obj) is never reached. P.D. Both server and client app startup perfectly so the 'FullTrust' permission set is granted for both apps.
-
Hi Heath, thanks for the reply. Both Client and Server run on my machine and for sake of simplicity for the time being both assemblies and two other dlls (remote objects and general tools) are all linked to the same AssemblyInfo file so they all have the same set of permissions. My ContextData object is included in the 'general tools' dll. Code worked perfectly, and if I remove all CallContext code (the setter in the client app and getter in the remoteobject called method) everyting works perfectly again. The error seems to be when the remote call is made and before anything starts visibly 'moving' on the server side. A breakpoint in my remote object constructor (its a singlecall obj) is never reached. P.D. Both server and client app startup perfectly so the 'FullTrust' permission set is granted for both apps.
Skynyrd wrote: are all linked to the same AssemblyInfo file so they all have the same set of permissions. I'm sure you know this, but just in case and for future readers I note that using the same file won't grant any permissions. That happens at runtime. This approach just means they'll demand (or whatever action is appropriate) the same permissions. Could you post your remoting configuration (or, if programmatically, include the important details like the channel and connection string, the formatter you're using, etc.)? What hosts the remoting singleton? A Windows service, IIS, or just some app that blocks until you quit (like all those console examples in the remoting books)? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
Skynyrd wrote: are all linked to the same AssemblyInfo file so they all have the same set of permissions. I'm sure you know this, but just in case and for future readers I note that using the same file won't grant any permissions. That happens at runtime. This approach just means they'll demand (or whatever action is appropriate) the same permissions. Could you post your remoting configuration (or, if programmatically, include the important details like the channel and connection string, the formatter you're using, etc.)? What hosts the remoting singleton? A Windows service, IIS, or just some app that blocks until you quit (like all those console examples in the remoting books)? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
The server app is for debugging purposes a Console App at the moment. The remoting is done through an interface: relevant server code: ... TcpServerChannel myChannel=new TcpServerChannel(8086); ChannelServices.RegisterChannel(myChannel); RemotingConfiguration.RegisterWellKnownServiceType(typeof(DataLayerTool),"DataLayerTool.rem",WellKnownObjectMode.SingleCall); ... relevant client side app: ... private object GetProxy() { return Activator.GetObject(myType,myUrl); } public object RunMethod(string methodName, object[] arguments) { CallContextData cookie=new CallContextData(); cookie.Data=myUser.EncryptedUserName; CallContext.SetData("myUser",cookie); object proxy=GetProxy(); TypeDelegator delegator=new TypeDelegator(myType); return delegator.GetMethod(methodName).Invoke(proxy,arguments); } ... Client remoting config file:
-
The server app is for debugging purposes a Console App at the moment. The remoting is done through an interface: relevant server code: ... TcpServerChannel myChannel=new TcpServerChannel(8086); ChannelServices.RegisterChannel(myChannel); RemotingConfiguration.RegisterWellKnownServiceType(typeof(DataLayerTool),"DataLayerTool.rem",WellKnownObjectMode.SingleCall); ... relevant client side app: ... private object GetProxy() { return Activator.GetObject(myType,myUrl); } public object RunMethod(string methodName, object[] arguments) { CallContextData cookie=new CallContextData(); cookie.Data=myUser.EncryptedUserName; CallContext.SetData("myUser",cookie); object proxy=GetProxy(); TypeDelegator delegator=new TypeDelegator(myType); return delegator.GetMethod(methodName).Invoke(proxy,arguments); } ... Client remoting config file:
Duh...figured it out... kinda stupid of me :~ I was strong naming my assemblies (thought the code in the assemblyinfo file was commented out...) and I was getting the security exception possibly because I wasnt fully qualifying my assemblies in the client remoting configuration file. Commented out the strong naming and everything works fine.
-
Duh...figured it out... kinda stupid of me :~ I was strong naming my assemblies (thought the code in the assemblyinfo file was commented out...) and I was getting the security exception possibly because I wasnt fully qualifying my assemblies in the client remoting configuration file. Commented out the strong naming and everything works fine.
I wouldn't comment-out strong name attributes. Strong naming is your friend. Not only does it help you (and your clients) secure their machines and allow your code individually to have its own permissions, but it also helps you version and allows you to install into the GAC. If you get tired of the ever-changing version numbers, then don't use automatic versioning (I always use explicit versions, especially in multi-project solutions). Instead of using a version string like "1.0.*", be explicit with all 4 segments (from 0-65535; each segment is an unsigned short). This gives you control over versions. How does it help with versioning? Read about Publisher Policies[^]. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
I wouldn't comment-out strong name attributes. Strong naming is your friend. Not only does it help you (and your clients) secure their machines and allow your code individually to have its own permissions, but it also helps you version and allows you to install into the GAC. If you get tired of the ever-changing version numbers, then don't use automatic versioning (I always use explicit versions, especially in multi-project solutions). Instead of using a version string like "1.0.*", be explicit with all 4 segments (from 0-65535; each segment is an unsigned short). This gives you control over versions. How does it help with versioning? Read about Publisher Policies[^]. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
I wouldn't comment-out strong name attributes. Strong naming is your friend. Not only does it help you (and your clients) secure their machines and allow your code individually to have its own permissions, but it also helps you version and allows you to install into the GAC. If you get tired of the ever-changing version numbers, then don't use automatic versioning (I always use explicit versions, especially in multi-project solutions). Instead of using a version string like "1.0.*", be explicit with all 4 segments (from 0-65535; each segment is an unsigned short). This gives you control over versions. How does it help with versioning? Read about Publisher Policies[^]. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
I've tried out explicit versioning but I still get the same exception: These are the remoting config files I'm using: Server side: Client Side: If I try to include Version, culture and public key info of the Vigila.Objects assembly in the client config file: "Vigila.Objects.IDataLayerTool, Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a" , I get the follwoing RemotingException telling me that Client WellKnow entries dont admit full names (version, culture and key) !? dont know if this is normal. If u need details of exception I'll post them, but wont do it now because its too long. Anyhow, when I run the app, I'm getting exactly the same exception I posted in the first message: SecurityExpection due to the CallContexData object I'm using (see my first post please). Am I supposed to include info of this object in the client and server remoting config files somehow? and if so, how? Or what am I missing?..all examples I see of CallContext are without strongnaming, and I know my code works perfectly in that case, but I cant find any examples where StrnongNaming is used with CallContext.
-
I've tried out explicit versioning but I still get the same exception: These are the remoting config files I'm using: Server side: Client Side: If I try to include Version, culture and public key info of the Vigila.Objects assembly in the client config file: "Vigila.Objects.IDataLayerTool, Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a" , I get the follwoing RemotingException telling me that Client WellKnow entries dont admit full names (version, culture and key) !? dont know if this is normal. If u need details of exception I'll post them, but wont do it now because its too long. Anyhow, when I run the app, I'm getting exactly the same exception I posted in the first message: SecurityExpection due to the CallContexData object I'm using (see my first post please). Am I supposed to include info of this object in the client and server remoting config files somehow? and if so, how? Or what am I missing?..all examples I see of CallContext are without strongnaming, and I know my code works perfectly in that case, but I cant find any examples where StrnongNaming is used with CallContext.
Interesting. I've never actually had this problem and have always used strong naming. You might try this, though. Continue using the partial names (fully-qualified class name, followed by the assembly name) but define the following in your .config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="Vigila.Objects"
fullName="Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a" />
</assemblyBinding>
</runtime>
</configuration>Of course, do this for each assembly that needs qualifying. Without knowing more about your problem, it's possible that if you don't update your server and client versions (you might consider not changing the version every time you compile - figure out a scheme that works for you) at the same time and they use a separate copy of a shared assembly - and you don't update both copies at the same time, leading to different versions - you could end up with a serialization error since the types won't match (even if they're only off by a version number, they're still different types). I'm just speculating, however. In a typically deployment scenario, you can get around versioning problems (rather, so you can update some assemblies without updating others) with publisher policies (see the .NET Framework SDK for more details). To get around the incompatibilities in the serialization, you can use a
SerializationBinderand overridingBindToType(you can actually write generic code to handle any type thrown at it; it should be obvious but if you want, click "Search comments" to search for "BindToType" for a previous example I posted). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
Interesting. I've never actually had this problem and have always used strong naming. You might try this, though. Continue using the partial names (fully-qualified class name, followed by the assembly name) but define the following in your .config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="Vigila.Objects"
fullName="Vigila.Objects, Version=0.0.1.0, Culture=neutral, PublicKeyToken=caa4a15766f8ec1a" />
</assemblyBinding>
</runtime>
</configuration>Of course, do this for each assembly that needs qualifying. Without knowing more about your problem, it's possible that if you don't update your server and client versions (you might consider not changing the version every time you compile - figure out a scheme that works for you) at the same time and they use a separate copy of a shared assembly - and you don't update both copies at the same time, leading to different versions - you could end up with a serialization error since the types won't match (even if they're only off by a version number, they're still different types). I'm just speculating, however. In a typically deployment scenario, you can get around versioning problems (rather, so you can update some assemblies without updating others) with publisher policies (see the .NET Framework SDK for more details). To get around the incompatibilities in the serialization, you can use a
SerializationBinderand overridingBindToType(you can actually write generic code to handle any type thrown at it; it should be obvious but if you want, click "Search comments" to search for "BindToType" for a previous example I posted). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]Thnks for the advice. I tried the new config u posted but its not working either. Anyhow, I've been looking around in the net and I'm not the only one who's come up with this problem. It's apparently a Net v1.1 issue due to new security features in remoting not implemented in v1.0. After searching for a while I've come up with two solutions: First one isn't any good: its using the Assembly AllowPartiallyTrustedCallers attribute in my Objects.dll where the DataCallContext object is. The code works this way but it shouldnt be the solution to my problem unless there is absolutely nothing else I could do. Second one is most probably the correct way to solve the problem: explictly change the server formatter's FilterLevel to 'Full'. (defualts to 'Low'). ...so, in case anybody else has this problem and stumbles upon this post while searching the forum, the problem will be fixed if they configure the server remoting config file similar to the following: Thanks for all the help.