SerializationException when using .NET Remoting

May 14, 2011 at 4:19 PM

Hi,

I need to use AlphaVSS in a 32-bit application which runs on 64-bit Windows. LoadImplementation() loads the x86 DLL (which is normal) so I have to do something else: have my app start a 64-bit process which loads the correct DLL. The communication between the application and the process is done via .NET Remoting. All works fine until I start accessing properties on method call results. Let me give you an example:

// init vss implementation
var vss = (IVssImplementation)Activator.GetObject(
  typeof(IVssImplementation),
  "tcp://127.0.0.1:2080/VssImplementation.rem");

var components = vss.CreateVssBackupComponents();

// other actions to set components in the right state

var properties = components.GetSnapshotProperties(id);

Accessing properties throws exception: "Type 'Alphaleonis.Win32.Vss.VssSnapshotProperties' in Assembly 'AlphaVSS.Common, Version=1.0.9156.0, Culture=neutral, PublicKeyToken=3033cf2dbd31cad3' is not marked as serializable."

I guess the fix for this is to add [Serializable] to VssSnapshotProperties and perhaps to all other types which are exposed. Do you guys think you could publish a build with this change?

Thank you

Coordinator
May 14, 2011 at 6:22 PM

Another solution is of course to create your own communication classes and use only those instead of the AlphaVSS ones to communicate between the processes, leaving the 64-bit process as the only one actually accessing the AlphaVSS api.

Depending on what you need to actually pass over to the 32-bit process I guess this may be either a good idea or a lot of work just wrapping the AlphaVSS classes.

If you post this as an issue I will have a look at what can be done in this regard.

Regards, Peter.

May 14, 2011 at 10:53 PM

I thought about this too... it is a lot of work. The application needs to work on both 32-bit and 64-bit Windows and remoting is only needed for 64-bit. If I use wrappers for 64-bit then the application will need to know how to work with both wrappers and VSS interfaces. I'd like to avoid it and stick only to VSS interfaces.

Also I could submit a SVN patch in which all VSS classes are decorated with [Serializable]. This can't do any harm, right? Just let me know if this is ok with you.

Coordinator
May 15, 2011 at 3:37 AM

Unfortunately just decorating them with [Serializable] does not mean that they will work correctly in a remoting scenario. Deriving from MarshalByRefObject would probably be a better bet, but since many of the VSS classes hold instances of unmanaged classes or interfaces I'm not sure it is that simple and I need to investigate this a bit further before I can give a correct answer (or implementation).

So please post a new issue and I will look in to it.

Regards, Peter.

May 15, 2011 at 6:20 PM

Thank you for your reply. I created a new issue in the issue tracker. Just to make sure there is no misunderstanding: the classes which I need to be serializable are only those from the Common assembly, the ones in the Classes folder (w/o the static ones of course). From what I've seen they are just simple POCOs and they certainly do not contain unmanaged stuff. My 32-bit process only uses the Common assembly. This is why I suggested the [Serializable] fix. But of course, I could be wrong.

Coordinator
Jun 3, 2011 at 12:28 PM

Version 1.1 and 1.2 just released should solve your problem. These classes are now marked as serializable. Let me know if I've missed any!