mikeg22 wrote:

simmotech wrote:

Otis wrote:

Simon: I implemented the stuff you suggested for this build except for the test for a remove tracker in the templates, as that would make it limited, because if you had other data, you then would run into hte same problem.

Thats excellent (and the template stuff was only really for mikeg and Barry anyway)

So, there is no test for collection serialization? Are all collections serialized regardless of their count?

Correct

Otis wrote:

mikeg22 wrote:

simmotech wrote:

Otis wrote:

Simon: I implemented the stuff you suggested for this build except for the test for a remove tracker in the templates, as that would make it limited, because if you had other data, you then would run into hte same problem.

Thats excellent (and the template stuff was only really for mikeg and Barry anyway)

So, there is no test for collection serialization? Are all collections serialized regardless of their count?

Correct

Wonderful

It's available. Please check my example how to serialize the removal tracker or another collection inside the collection.

I am trying to use this and I cannot get the test to work as is.

I have downloaded the most recent runtime updates and applied them. I have downloaded the most recent task & template updates and applied them.

I regenerated my code and pasted in the extension to EntityCollection<T> as is.

What I am seeing is that the test fails unless I leave at least 1 item in the original collection, then it passes.

When I debug and there are 0 items in the c.Orders collection I never hit a breakpoint in SerializeOwnedData for that collection.

Can anyone point me in the right direction to correct this?

Thanks!

After posting my last message I switched my reference of the runtime library file from the standard to the debug version in the hopes of stepping through and finding the issue myself.

The test now passes.

I switched back to the release runtime and the tests also pass.

The mistake must have been on my end.

Please ignore these 2 posts.

Thanks!

Ok. So I got this working in my unit tests. I am however not getting the RemovedEntitiesTracker when calling my service.

I'm passing an Entity as a parameter in this Service Contract method and when it reaches the service the RemovedEntitiesTracker is always null.

I'm calling my WCF Service via this method:

[OperationContract] void SaveEntity(IEntity2 entity);

What am I missing?

Thanks.

WCF means xml, not remoting. Removed entities tracker wasn't correctly serialized in xml. PLease use the latest runtime libs build (if you do that already, let us know)

I am using the latest runtime builds available in the download section. Build 11302007.

Is your service also using that latest runtime lib? As it works in your tests.

Could you post some code and describe exactly what's not working? (so do you get an exception, is there nothing serialized etc. ) with code: the service method and the client method.

The issue is on my end again!

The developer handling the wcf services was not doing a complete refresh when posting changes, so the version in the service was incorrect.

This has been fixed and all is working as it should.

Thanks!

Please help.

I had this working and now it is not.

My Fast Serialization test for this works. My XML Serializtion test does not.

The problem is when we send the entities over wcf they do not have the RemovedEntitiesTracker set at the other end.

I have made sure this time that I am using the same runtime libs as I downloaded for this problem the first time. Version 2.5.07.1129 released on 11302007

I have also tried the latest release runtime libs Version 2.5.08.0122 released on 01232008

I cannot get this to work.

Can you please help by pointing me in the right direction of where to look? What might be causing the issue?

Thanks!!!

Xml serialization is a different pipeline altogether. RemovedEntitiesTracker isn't serialized into XML, it's ignored. If you want to send it over, serialize it separately in XML situations. We can't enable it with a patch to v2.5, as it will break the XML format and it will also increase the XML size without proper packing.

So if you're using WCF, you always have to use XML anyway, so you should pass the trackers separately, as a workaround. Is this sufficient? (the interface for WCF is different from the remoting interface anyway)

We'll look into supporting this in the upcoming 2.6, as it's a breaking change.

Passing them seperate is what I was afraid of. Is there any "clean" way to override the xml write/read methods so that this is transparent?

If not I will need to shift gears and begin looking into a different approach for handling these items.

Thanks for the speedy response!

Ok. We may have a few different possible solutions at this point.

These of course have just raised more questions.

So, if would be so kind as to help explain some wcf stuff to me I would greatly appreciate it!!

You said:

So if you're using WCF, you always have to use XML anyway, so you should pass the trackers separately, as a workaround. Is this sufficient? (the interface for WCF is different from the remoting interface anyway)

My resident wcf lead says that we are using netcp and according to him that means we are sending binary messages. Now, if this is the case then I should be seeing the RemovedEntitiesTracker collections on the receiving end of the transmission. His question is: Does LLBL override some functionality in WCF to produce xml instaed of Binary for transport?

Next Question: Does LLBL provide a means to compress the xml before and decompress the xml after transmissions in wcf?

Thanks again!

Harry wrote:

Ok. We may have a few different possible solutions at this point.

These of course have just raised more questions.

So, if would be so kind as to help explain some wcf stuff to me I would greatly appreciate it!!

You said:

So if you're using WCF, you always have to use XML anyway, so you should pass the trackers separately, as a workaround. Is this sufficient? (the interface for WCF is different from the remoting interface anyway)

My resident wcf lead says that we are using netcp and according to him that means we are sending binary messages. Now, if this is the case then I should be seeing the RemovedEntitiesTracker collections on the receiving end of the transmission. His question is: Does LLBL override some functionality in WCF to produce xml instaed of Binary for transport?

All transport in WCF is xml based. That's also why there's an upgrade path from remoting to WCF: it will be XML. HOW it is send over the wire, that's up to the transport layer, but what is send is XML. Check the WCF remoting article in the MSDN by Ingo Rammer, it explains the details about it and that there's no remoting in WCF (though supported in .NET)

LLBLGen Pro doesn't override things to convert data to XML instead of binary: it implements IXmlSerializable, which is used by WCF to produce the XML from the objects, similar to the webservices code in .net to produce XML from the objects. Remoting uses different code, it's a completely different framework, however as both frameworks (wcf and remoting) use 'serialization' as the word for what they're doing with the data, it is confusing

Next Question: Does LLBL provide a means to compress the xml before and decompress the xml after transmissions in wcf? Thanks again!

No, you should do that through wcf. All LLBLGen Pro does is produce XML through IXmlSerializable by using the passed in xmlwriter. What happens with the XML, that's up to the platform used: if it's WCF, it will likely be threated differently than when it's a webservice, but nevertheless, it's XML.