| Groups | Blog | Home |
dotnet remoting : Version redirection
I'm trying to figure out how to handle versioning with remoting. I am using
RemotingServices.Marshal() to mashal my object and Activator.GetObject() to access it. I am using abstract classes to implement my remoting objects. Every works fine as long as the assembly version of my shared classes match between client and server. The moment that the client version is different than the server version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. I want to set up remoting to ignore the build number and update number for the shared assemblies. I think this is possible with application and publisher policy definitions in the configuration files, but I cannot figure out how to do this. Any help is appreciated. Regards, Bob Rundle
You should create your own binder and assign it to your serializer.
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); serializer.Binder = new Binder(Assembly.LoadFrom("....dll"); public class Binder : System.Runtime.Serialization.SerializationBinder { private System.Reflection.Assembly assembly; public Binder(System.Reflection.Assembly assembly) { this.assembly = assembly; } public override Type BindToType(string assemblyName, string typeName) { //Load from your assembly return this.assembly.GetType(typeName); } } Erick Sgarbi [quoted text, click to view] > I'm trying to figure out how to handle versioning with remoting. I am > using RemotingServices.Marshal() to mashal my object and > Activator.GetObject() to access it. I am using abstract classes to > implement my remoting objects. > > Every works fine as long as the assembly version of my shared classes > match between client and server. > > The moment that the client version is different than the server > version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. > > I want to set up remoting to ignore the build number and update number > for the shared assemblies. I think this is possible with application > and publisher policy definitions in the configuration files, but I > cannot figure out how to do this. > > Any help is appreciated. > > Regards, > Bob Rundle
This is an interesting idea.
The thing I figured out yesterday is that I can add entries to the app.config file to redirect the assembly versions. So I can do something like this... <dependentAssembly> <assemblyIdentity name="joaSimulationInterface" publicKeyToken="094f74ae6fceea7a" /> <bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" newVersion="1.0.0.0" /> </dependentAssembly> This works. I generally do not like adding stuff to app.config however. Would the serialization binder approach be superior to this approach. In what way? Bob Rundle [quoted text, click to view] <erick@csharpbox.com> wrote in message news:9de69f363348c761021dda03e0@msnews.microsoft.com... > You should create your own binder and assign it to your serializer. > > System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer > = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); > serializer.Binder = new Binder(Assembly.LoadFrom("....dll"); > > > public class Binder : System.Runtime.Serialization.SerializationBinder > { > > private System.Reflection.Assembly assembly; > > public Binder(System.Reflection.Assembly assembly) > { > this.assembly = assembly; } > > public override Type BindToType(string assemblyName, string typeName) > { > //Load from your assembly > return this.assembly.GetType(typeName); > } > } > > > Erick Sgarbi > >> I'm trying to figure out how to handle versioning with remoting. I am >> using RemotingServices.Marshal() to mashal my object and >> Activator.GetObject() to access it. I am using abstract classes to >> implement my remoting objects. >> >> Every works fine as long as the assembly version of my shared classes >> match between client and server. >> >> The moment that the client version is different than the server >> version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. >> >> I want to set up remoting to ignore the build number and update number >> for the shared assemblies. I think this is possible with application >> and publisher policy definitions in the configuration files, but I >> cannot figure out how to do this. >> >> Any help is appreciated. >> >> Regards, >> Bob Rundle > >
How can you attach a SerializationBinder in Remoting? I thought the
actual BinaryFormatter is pretty much hidden in the sink chains...
Yes, using using <assemblyBinding> will fix your problem, for some reason
I undertood that you needed to redirect some types and not the whole assembly. I usually prefer using config files since it allows very simple changes in a production scenario instead of recompiling all binaries again. Erick Sgarbi [quoted text, click to view] > This is an interesting idea. > > The thing I figured out yesterday is that I can add entries to the > app.config file to redirect the assembly versions. So I can do > something like this... > > <dependentAssembly> > > <assemblyIdentity name="joaSimulationInterface" > publicKeyToken="094f74ae6fceea7a" /> > > <bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" > newVersion="1.0.0.0" /> > > </dependentAssembly> > > This works. I generally do not like adding stuff to app.config > however. > > Would the serialization binder approach be superior to this approach. > In what way? > > Bob Rundle > > <erick@csharpbox.com> wrote in message > news:9de69f363348c761021dda03e0@msnews.microsoft.com... > >> You should create your own binder and assign it to your serializer. >> >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter >> serializer = new >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); >> serializer.Binder = new Binder(Assembly.LoadFrom("....dll"); >> >> public class Binder : >> System.Runtime.Serialization.SerializationBinder { >> >> private System.Reflection.Assembly assembly; >> >> public Binder(System.Reflection.Assembly assembly) >> { >> this.assembly = assembly; } >> public override Type BindToType(string assemblyName, string typeName) >> { >> //Load from your assembly >> return this.assembly.GetType(typeName); >> } >> } >> Erick Sgarbi >> >>> I'm trying to figure out how to handle versioning with remoting. I >>> am using RemotingServices.Marshal() to mashal my object and >>> Activator.GetObject() to access it. I am using abstract classes to >>> implement my remoting objects. >>> >>> Every works fine as long as the assembly version of my shared >>> classes match between client and server. >>> >>> The moment that the client version is different than the server >>> version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. >>> >>> I want to set up remoting to ignore the build number and update >>> number for the shared assemblies. I think this is possible with >>> application and publisher policy definitions in the configuration >>> files, but I cannot figure out how to do this. >>> >>> Any help is appreciated. >>> >>> Regards, >>> Bob Rundl
You are right, you need to create your own sink and throw it into the chain.
Erick Sgarbi [quoted text, click to view] > How can you attach a SerializationBinder in Remoting? I thought the > actual BinaryFormatter is pretty much hidden in the sink chains... >
Here is another idea.
There are two properties for the sink configuration that control versioning. includeVersions = true by default strictBindinging = false by default However the interesting fact is that the default settings should give proper behaviour in event of version mismatch. includeVersions = true/strictBinding = false will try to load the exact assembly, but then use only assembly name and type name. However this is not what I am seeing...If the versions of the shared assemblies are different in the smallest way, remoting fails. Is this a documentation error? BR [quoted text, click to view] <erick@csharpbox.com> wrote in message news:9de69f36ad78c761ce3534d57a@msnews.microsoft.com... > Yes, using using <assemblyBinding> will fix your problem, for some reason > I undertood that you needed to redirect some types and not the whole > assembly. I usually prefer using config files since it allows very simple > changes in a production scenario instead of recompiling all binaries > again. > > > > Erick Sgarbi > >> This is an interesting idea. >> >> The thing I figured out yesterday is that I can add entries to the >> app.config file to redirect the assembly versions. So I can do >> something like this... >> >> <dependentAssembly> >> >> <assemblyIdentity name="joaSimulationInterface" >> publicKeyToken="094f74ae6fceea7a" /> >> >> <bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" >> newVersion="1.0.0.0" /> >> >> </dependentAssembly> >> >> This works. I generally do not like adding stuff to app.config >> however. >> >> Would the serialization binder approach be superior to this approach. >> In what way? >> >> Bob Rundle >> >> <erick@csharpbox.com> wrote in message >> news:9de69f363348c761021dda03e0@msnews.microsoft.com... >> >>> You should create your own binder and assign it to your serializer. >>> >>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter >>> serializer = new >>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); >>> serializer.Binder = new Binder(Assembly.LoadFrom("....dll"); >>> >>> public class Binder : >>> System.Runtime.Serialization.SerializationBinder { >>> >>> private System.Reflection.Assembly assembly; >>> >>> public Binder(System.Reflection.Assembly assembly) >>> { >>> this.assembly = assembly; } >>> public override Type BindToType(string assemblyName, string typeName) >>> { >>> //Load from your assembly >>> return this.assembly.GetType(typeName); >>> } >>> } >>> Erick Sgarbi >>> >>>> I'm trying to figure out how to handle versioning with remoting. I >>>> am using RemotingServices.Marshal() to mashal my object and >>>> Activator.GetObject() to access it. I am using abstract classes to >>>> implement my remoting objects. >>>> >>>> Every works fine as long as the assembly version of my shared >>>> classes match between client and server. >>>> >>>> The moment that the client version is different than the server >>>> version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. >>>> >>>> I want to set up remoting to ignore the build number and update >>>> number for the shared assemblies. I think this is possible with >>>> application and publisher policy definitions in the configuration >>>> files, but I cannot figure out how to do this. >>>> >>>> Any help is appreciated. >>>> >>>> Regards, >>>> Bob Rundle > >
We need to make a distinction between the two differnt types of objects in
question being client activated or wellknown. While Wellknown objects versions are controlled by the server (because it is responsible in marshalling the instances because versions are always included in the TypeInfo in the ObjRef) the client-activated will be able too selectively choose which version can be loaded. From MSDN: "The server controls which version of a type is activated when a client connects to a server-activated (or <wellknown>) object. If no version information is provided when the service is configured, the most recent version of the assembly is used when the object is activated" Consequently in this case, you will not be able to choose or specify a version information on the client because it will not be allowed (a client could potentialy ask for a version that does not exist on the server... ). Furthermore, as far as Client-Activated goes .... MSDN: "When a client activates a client-activated (that is, an <activated>) object, a network call is immediately sent to the server where the requested object is activated and an object reference to the object is returned to the client. Because it directs the activation of the object, the client also chooses the version of the object to be activated" "It is important to note that you cannot specify the version number for activated types when configuring the service, and any versioning information provided for well-known types have no effect on client-activated objects, even if both types are in the same assembly" [quoted text, click to view] > However this is not what I am seeing...If the versions of the shared assemblies are different in the smallest way, remoting fails.It will fail if the client requests a version that doesnt exist on the server and objects are wellknown. The problem is related to serialization rather then versioning in this case... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/versremote.asp HTH Erick Sgarbi www.blog.csharpbox.com [quoted text, click to view] > Here is another idea. > > There are two properties for the sink configuration that control > versioning. > > includeVersions = true by default > strictBindinging = false by default > However the interesting fact is that the default settings should give > proper behaviour in event of version mismatch. includeVersions = > true/strictBinding = false will try to load the exact assembly, but > then use only assembly name and type name. > > However this is not what I am seeing...If the versions of the shared > assemblies are different in the smallest way, remoting fails. > > Is this a documentation error? > > BR > > <erick@csharpbox.com> wrote in message > news:9de69f36ad78c761ce3534d57a@msnews.microsoft.com... > >> Yes, using using <assemblyBinding> will fix your problem, for some >> reason I undertood that you needed to redirect some types and not the >> whole assembly. I usually prefer using config files since it allows >> very simple changes in a production scenario instead of recompiling >> all binaries again. >> >> Erick Sgarbi >> >>> This is an interesting idea. >>> >>> The thing I figured out yesterday is that I can add entries to the >>> app.config file to redirect the assembly versions. So I can do >>> something like this... >>> >>> <dependentAssembly> >>> >>> <assemblyIdentity name="joaSimulationInterface" >>> publicKeyToken="094f74ae6fceea7a" /> >>> <bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" >>> newVersion="1.0.0.0" /> >>> >>> </dependentAssembly> >>> >>> This works. I generally do not like adding stuff to app.config >>> however. >>> >>> Would the serialization binder approach be superior to this >>> approach. In what way? >>> >>> Bob Rundle >>> >>> <erick@csharpbox.com> wrote in message >>> news:9de69f363348c761021dda03e0@msnews.microsoft.com... >>>> You should create your own binder and assign it to your serializer. >>>> >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter >>>> serializer = new >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); >>>> serializer.Binder = new Binder(Assembly.LoadFrom("....dll"); >>>> >>>> public class Binder : >>>> System.Runtime.Serialization.SerializationBinder { >>>> private System.Reflection.Assembly assembly; >>>> >>>> public Binder(System.Reflection.Assembly assembly) >>>> { >>>> this.assembly = assembly; } >>>> public override Type BindToType(string assemblyName, string >>>> typeName) >>>> { >>>> //Load from your assembly >>>> return this.assembly.GetType(typeName); >>>> } >>>> } >>>> Erick Sgarbi >>>>> I'm trying to figure out how to handle versioning with remoting. >>>>> I am using RemotingServices.Marshal() to mashal my object and >>>>> Activator.GetObject() to access it. I am using abstract classes >>>>> to implement my remoting objects. >>>>> >>>>> Every works fine as long as the assembly version of my shared >>>>> classes match between client and server. >>>>> >>>>> The moment that the client version is different than the server >>>>> version (1.0.9.0 vs. 1.0.10.0, say) remoting fails. >>>>> >>>>> I want to set up remoting to ignore the build number and update >>>>> number for the shared assemblies. I think this is possible with >>>>> application and publisher policy definitions in the configuration >>>>> files, but I cannot figure out how to do this. >>>>> >>>>> Any help is appreciated. >>>>> >>>>> Regards, >>>>> Bob Rundle
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |