This project has moved and is read-only. For the latest updates, please go here.

[en] Removing Unnecessary requisites (solved)

Topics: Technical Support
Dec 11, 2010 at 8:05 PM

Hi. I was just looking at the source code and trying to setup a simple server and noted a two things:

1) Zyan does not use any classes from the .NET 4.0 profile. I was able to compile Zyan using the .NET 3.5 Client Profile, which seems to be the real minimum. The only thing I had to do is change the target framework, and remove the unnecessary references to System.Dynamic and System.Threading.Tasks. I had to do this to be able to use Zyan in my 3.5 CP project.

I guess the best is not to require anything that is not really necessary, like the .NET Framework 4.0. The version 3.5 of the framework uses the 2.0 CLR, runs on more operating systems and has much lower system requirements for installation. Also, Mono 2.8 still hasn't full 4.0 support, but I think that doesn't mind as long as Zyan doesn't use the parts that are still not implemented in Mono 2.8.

2) Another unnecessary requisite seems to be an interface for registering components. I know it's cool to have an interface for an object that will be remotely exposed, but I think it's not completely necessary. For instance, if the client wants to remotely instantiate an object using the very same type exposed by the server.

My two cents.



Dec 13, 2010 at 5:35 AM
Edited Dec 13, 2010 at 5:36 AM

Hello Ernesto,

1) Thanks for your suggestion. I experimented with dynmics and tasks earlier,  but rejected to use them at the end. I forgot to change the framework to 3.5. I will test your suggestion soon an then lower the system requirements. The binaries will be also available for .NET version 3.5.

2) I think the client should not know the implementation of the server components. Otherwise the client can skip the application server und try to do things directly. That´s not, what I would call a good architecture. Even when automating a Windows.Forms Application from an other process on the same machine, there should be an explicit contract. Using the implementation types on the client might lead to deployment issues. Client and server have to be the same version. Otherwise only the shared interface assembly must be compatible.

I plan to add a dynamic call feature to Zyan. You might want to call runtime generated assemblies remotely. Their members ar not known in design time. Because of that, you have no interface for them. But also in this case, the implementation remains on the server and is not known by the client. So my dynamic call feature will use a kind of command pattern. A dynamic call might look like this:

DynamicProxy proxy = connection.CreateDynamicProxy();
string result = proxy.Invoke("SomeRemoteMethod","Param1","Param2");

Using that feature (when it´s finally available ;-) in the Zyan API) provides you with the ability to call remote components without knowing an interface of them.



Dec 14, 2010 at 3:14 PM

I understand. I didn't anticipate those deployment issues. I guess I'll have to write a couple of interfaces then.


Dec 19, 2010 at 1:55 PM
Edited Dec 19, 2010 at 1:56 PM

Zyan 1.0 is out now.

It runs under .NET 3.5 Client Profile (even on the server side). The dynamic call feature is not included, yet.