I have an Adapter-based EntityCollection hosted in a WCF ServiceHostBase. (HelloWorld complexity)

The service is hosted as InstanceContextMode.Single

Strings and ints in the ServiceHostBase keep their values during its lfetime, but the EntityCollection is always empty, but not null, after the next call to the service.

Is there a restriction on the life of items in a the EntityCollection hosted in the WCF service layer?

  [ServiceBehavior( InstanceContextMode = InstanceContextMode.Single)]
    public class CustomerService : ICustomer
    {

        public EntityCollection<CustomerEntity> GetCustomers()
        {

            if (OperationContext.Current.Host.Extensions.Find<MyServiceState>()==null)
                OperationContext.Current.Host.Extensions.Add(new MyServiceState());
            return OperationContext.Current.Host.Extensions.Find<MyServiceState>().ToReturn;
        }

    }


    class MyServiceState : IExtension<ServiceHostBase>
    {
        private string controlSample = "";
        private EntityCollection<CustomerEntity> toReturn;

        public void Attach(ServiceHostBase owner)
        {
            controlSample = "sdffffffffffffffffff";
            toReturn = new EntityCollection<CustomerEntity>(new CustomerEntityFactory());
            //FILL IT HERE
        }

        public void Detach(ServiceHostBase owner)
        {
            toReturn = null;
        }

        public EntityCollection<CustomerEntity> ToReturn
        {
            get { return toReturn; //controlSample here keeps its values }
            set { toReturn = value; }
        }
    }

I tried using a List<CustomerEntity> internally instead and it works fine.

For some reason a EntityCollection<CustomerEntity> in a ServiceHostBase doesn't maintain its items where as a List<CustomerEntity> does.

Ideas?

I have no idea why a generic EntityCollection doesn't work while an IList does.

Rule of thumb: don't use generic entitycollection objects in webservices. List<T> doesn't implement IXmlSerializable, so it's likely handled differently.

Attached is a netTcp remoting project that uses the Northwind DB.

Run it to see it work. (It will start up both the client and host projects)

Then change all the //TODO sections to EntityCollection and run again. You'll notice that once the EntityCollection goes into the WCF cache, it looses its entities.

Nothing is attached

I have emailed support AT llblgen DOT com a netTcp remoting project that uses the Northwind DB.

Change the connection string in the app.config of the Host project.

Run it to see it work. (It will start up both the client and host projects)

Then change all the //TODO sections to EntityCollection and run again. You'll notice that once the EntityCollection goes into the WCF cache, it looses its entities when it comes out.

The project was 307 k, just a little too big for the attachment limit.

Have you tried with the non-generic EntityCollection class instead? It's very likely a generics issue.

List<CustomerEntity> does work, EntityCollection<CustomerEntity> does not.

I'll try the non-genric EntityCollection.

Non-Generic EntityCollection didn't work unfortunately as a storage mechanism inside of a WCF IExtension<ServiceHostBase> as a member variable. Switching to List<CustomerEntity> does work though.

What I want to know if is the set of entities returned from the service is arriving correctly at the client in normal code, so not with caches or other stuff...

is that the case? If so, then I don't know why this fails, as all the runtime does is serialize and deserialize xml, so what happens with the collection after that is out of its reach and under control of WCF... (we're not experts in WCF, as that's not necessary if MS designed their framework properly).

Yes, the Entities do arrive correctly the first time in an EntityCollection<T>, but subsequent requests via the cache fail.

ianvink wrote:

Yes, the Entities do arrive correctly the first time in an EntityCollection<T>, but subsequent requests via the cache fail.

Please, understand: I want to know if subsequent requests WITHOUT the cache work.

That's what we can do for you: deliver the entities at the client in an entity collection. Whatever happens with the collection AFTER that, that's not something we can control. For example: it could be the subsequent requests WITH the cache are resulting in entities being fetched in a NEW collection though you're still looking at the OLD collection. (no idea if this is how this cache works, I don't have experience with the WCF cache)

Yes, if we just go to the DB and fetch the data every time it works fine.

Perhaps in version 2.0 of WCF......

Thanks, Ian

ianvink wrote:

Yes, if we just go to the DB and fetch the data every time it works fine.

Perhaps in version 2.0 of WCF......

Thanks, Ian

It's perhaps possible, I'm not sure, I just wished I or somebody else here at SD would knew deep WCF details so we could help here. .

Just thinking out loud, what I think could be the case is that the entities are fetched into a new collection object (which is always the case if you do: col = service.GetCustomers();, col is always a new instance!) but the cached version is a different one. I'm not sure how to determine this though...