THE INS AND OUTS OF VERSIONING in VB.NET

Printer QR Code 2d barcode in VB.NET THE INS AND OUTS OF VERSIONING

Very Important The concepts I am introducing in this chapter should only be used if they are really necessary this means a situation like the one described previously can potentially become reality. In any other cases, avoid the additional effort of implementing versioning in this way. Furthermore, in such situations, Web Services might be more appropriate than .NET Remoting solutions. My primary intention with this chapter is to show you that versioning of serializable types is not easy and needs to be kept in mind from the very first moment of the application design and development process! Note The next generation of messaging runtime, codename IIndigo, has such concepts built into the infrastructure through data contracts. This means with Indigo you really can concentrate on your data contract design and not as is happening here digging into some details of runtime serialization.

In the next example, you ll see how to implement a similar situation to the one described in Figure 8-19. Your starting position will be the first version of the client and the server from the previous example. This time you ll add an intermediary remoting server, and the client will communicate with this server instead of the original server. As you know that you are going to version your message sent across the wire the Person object introduced in the shared library in Listing 8-11 of the first version of your interface versioning sample you are going to change this class a little bit. Modify the Person object to support custom serialization as follows: [Serializable] public class Person : ISerializable { public int Age; public string Firstname; public string Lastname; public Person(string first, string last, int age) { this.Age = age; this.Firstname = first; this.Lastname = last; } public Person(SerializationInfo info, StreamingContext context) { Age = info.GetInt32("Age"); Firstname = info.GetString("Firstname"); Lastname = info.GetString("Lastname"); } public void GetObjectData(SerializationInfo info, StreamingContext context) { info.AddValue("Age", Age);

info.AddValue("Firstname", Firstname); info.AddValue("Lastname", Lastname); } } This will be the first version of your Person object. You ll see later on that this kind of serialization will not be sufficient for scenarios described at the beginning of this chapter. But for the moment, you will leave it to see what the problem is. Next, create your intermediary server. For simplicity, the intermediary implements the same interface as your final back-end server and just routes messages from the client to the server. The complete code for the intermediary server can be seen in Listing 8-17. Listing 8-17. The Intermediary Server using using using using System; System.Runtime.Remoting; System.Reflection; System.Runtime.CompilerServices;

using General; using General.Client; [assembly: AssemblyTitle("Intermediary Server Assembly")] [assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyKeyFile("")] namespace IntermedServer { public class IntermedImpl : MarshalByRefObject, IRemoteFactory { private IRemoteFactory _server; public IntermedImpl() { _server = (IRemoteFactory)RemotingHelper.CreateProxy( typeof(IRemoteFactory)); } public int GetAge() { Console.WriteLine(">> Routing GetAge()..."); int ret = _server.GetAge(); Console.WriteLine(">>>> GetAge() returned {0}", ret); return ret; } public Person GetPerson() { Console.WriteLine(">> Routing GetPerson()...");

Person p = _server.GetPerson(); Console.WriteLine(">>>> GetPerson() returned {0} {1} {2}", p.Firstname, p.Lastname, p.Age); return p; } public void UploadPerson(Person p) { Console.WriteLine(">> Routing UploadPerson()..."); _server.UploadPerson(p); Console.WriteLine(">>>> UploadPerson() routed successfully"); } } class IntermedApp { [STAThread] static void Main(string[] args) { Console.WriteLine("Starting intermediary..."); RemotingConfiguration.Configure("IntermedServer.exe.config"); Console.WriteLine("Intermediary configured, waiting for requests!"); System.Console.ReadLine(); } } } The intermediary is configured to listen on port 1235 for the object URI MyIntermed.rem, as you can see in the following configuration code. Furthermore, the intermediary is configured as a client for your original server. <configuration> <system.runtime.remoting> <application> <channels> <channel ref="tcp" port="1235"> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> <service> <wellknown type="IntermedServer.IntermedImpl, IntermedServer" objectUri="MyIntermed.rem" mode="Singleton" /> </service> <client>

<wellknown type="General.IRemoteFactory, General" url="tcp://localhost:1234/MyServer.rem" /> </client> </application> </system.runtime.remoting> </configuration> On the client you don t need to change any code. All you have to do is change the well-known client configuration to use the intermediary instead of the back-end server as you see in the following snippet: <wellknown type="General.IRemoteFactory, General" url="tcp://localhost:1235/MyIntermed.rem" /> If you now run all three programs, starting the server first, then the intermediary, and last but not least the client, the output of the client and the server will not change, while the output of the intermediary does, as can be seen in Figure 8-20.