[C#] Advanced remoting - foutmelding

[OZ-Gump]

Situatie
Momenteel probeer ik de volgende structuur te realiseren:
- Een interfaces project waarin een IProductFactory en een IProduct zitten.
- Een factory project waarin ProductFactory en Product geïmplementeerd worden.
- Een test project waarin via remoting een ProductFactory wordt aangemaakt.

Zowel het factory project als het test project refereren aan het interfaces project. De factory heeft een methode welke een object van het type product maakt, maar die methode heeft als returntype IProduct. Het factory project is een class library welke gehost wordt in IIS en dus middels een web.config zijn remoting objecten beschikbaar stelt.

Probleem
Het verbinding maken via remoting werkt naar behoren. Er wordt succesvol een object aangemaakt en gecast naar IProductFactory en hiervan zijn attributen en methoden met 'normale' returntypes goed aan te roepen. Wanneer er echter een object aangemaakt dient te worden van het type IProduct krijg ik de melding "No assembly associated with XML key". Verderop in de melding wordt de key genoemd, welke begint met "http://schemas.microsoft.com/clr/nsassem/". Product is (uiteraard) uitgerust met het Serializable attribuut.

Wat heb je al geprobeerd?
TypeFilterLevel op "full" gezet: dit mocht helaas niet baten.
Handmatige (de)serialisatie implementeren, daar ben ik nog niet aan begonnen, alhoewel dat wel een aantal malen aangedragen wordt als mogelijke oplossing.

Google en GoT hebben het op verschillende plaatsen over deze foutmelding, maar niet specifiek met betrekking tot remoting waarin (een interface van) een factory wordt teruggegeven, welke op zijn beurt weer een create-methode heeft met een interface als returntype. Bij Microsoft (MSDN) heb ik dit specifieke geval ook niet kunnen terugvinden.

Extra info

C#:

IProduct iProduct;
IProductFactory iProductFactory;

iProductFactory = (IProductFactory)Activator.GetObject(typeof(IProductFactory), URL);
iProduct = iProductFactory.CreateProduct();

Het gaat dus fout op regel 5 ...

Wat is de vraag?
Heeft iemand ervaring met dergelijke constructies? Weet iemand of ik misschien iets probeer wat niet kan of niet mag? En waarom dan niet? Of misschien zijn er andere constructies te bedenken die aan de client zijde een instantie van een server-object creëren?

[H!GHGuY]

de fout lijkt me betrekking te hebben op het feit dat de assembly van IProduct niet gekend is?
zitten je references goed ?
heb je al eens een breakpoint gezet in de CreateProduct() functie (server/implementatie-side) ?

[OZ-Gump]

De reference van de assembly van IProduct zou goed moeten zitten, omdat die in dezelfde assembly zit als de IProductFactory. De referenties worden binnen dezelfde solution op projecten gelegd, niet rechtstreeks naar assemblies. Ik heb nog geen breakpoint gehad in de CreateProduct() methode.

... please wait ...

Breakpoint gezet en CreateProduct lijkt correct te worden uitgevoerd. Ik denk zelf dat het ergens misgaat met deserialiseren van Product, maar ik ben er nog niet helemaal achter waarom...

[pjvandesande]

Ik denk dat het in je deserialisatie zit, hoewel dit ook weer niet zou moeten kunnen. Je kunt zelf even de serialisatie implementeren. Dit hoeft niet veel tijd te kosten als je even snel wat in elkaar flanst.
Kun je ook gelijk doen aan een binaire serialisatie ipv Xml.

[whoami]

Inherit je Product ook van MarshalByRefObject ?

[OZ-Gump]

Nope, Product inherit niet MarshalByRefObject. Het ding wordt volgens mij ook niet geremote, maar wordt geserialiseerd. Vandaar dat hij [Serializable()] is.

[whoami]

Ik geloof dat een object dat gecreeërd wordt door een remoted object, ook een remote object is/wordt/moet zijn.

Ik heb hier zelf een project, waarbij ik ongeveer eenzelfde opzet heb: een Factory die remoted is, en een bepaalde interface implementeert, en die een object creeërt die een bepaalde interface implementeert.
Zowel de factory als het object dat die factory creeërt, heb ik van MarshalByRefObj laten inheriten.

Op zich is het ook logisch dat je in jouw geval Product van MarshalByRefObject laat inheriten, want, op de client heb je enkel die IProduct interface.
Als je dat IProduct dus op de client aanspreekt, zal .NET 'm volgens mij toch op de server moeten gaan zoeken; je hebt nl. geen implementatie van Product op de client.

[OZ-Gump]

Sterker nog: ik heb het voor de zekerheid toch maar even uitgeprobeerd, en het lijkt potverdorie nog te werken ook! Hulde voor whoami...

Overigens maakt jouw verhaal me er wel op attent dat het probleem dat ik wilde oplossen waarschijnlijk dus nog niet opgelost is: ik wil de methodes van de server-side bekende class eigenlijk client-side uitvoeren, zonder call naar de server, om op die manier de classes maar op één plaats te hoeven definieren, maar dat ik ze vervolgens kan gebruiken op de client. Waarschijnlijk is daar geen oplossing voor, want dan moet je implementatie over gaan gooien en dat gaat niet goedkomen ...

In ieder geval bedankt voor je oplossing! Hij werkt naar behoren.

[whoami]

OZ-Gump schreef op dinsdag 06 september 2005 @ 09:03:

Overigens maakt jouw verhaal me er wel op attent dat het probleem dat ik wilde oplossen waarschijnlijk dus nog niet opgelost is: ik wil de methodes van de server-side bekende class eigenlijk client-side uitvoeren, zonder call naar de server, om op die manier de classes maar op één plaats te hoeven definieren, maar dat ik ze vervolgens kan gebruiken op de client. Waarschijnlijk is daar geen oplossing voor, want dan moet je implementatie over gaan gooien en dat gaat niet goedkomen ...

Daar is idd geen oplossing voor.
Ofwel werk je met je domein-objecten op de server, en stuur je data-transfer objects naar je client (die dus geen logica bevatten), ofwel werk je met domein-objecten op de server, en stuur je deze domein objecten ook naar je client, maar dan moet je client deze ook wel hebben. (Mbhv het updater-block of ClickOnce kan je er natuurlijk wel voor zorgen dat die domein-objecten automatisch op de client gedownloaded worden, als die op de server veranderd zijn).

In ieder geval bedankt voor je oplossing! Hij werkt naar behoren.

Wees er wel van bewust dat je nu, iedere keer je een property / method van je Product aanspreekt, er dus een server-call gebeurt. Op die manier kan je dus een 'chatty' interface hebben, en dat weegt op de performance.

[OZ-Gump]

Wees er wel van bewust dat je nu, iedere keer je een property / method van je Product aanspreekt, er dus een server-call gebeurt. Op die manier kan je dus een 'chatty' interface hebben, en dat weegt op de performance.

Daar ben ik me zeker van bewust. We zijn een proof-of-concept aan het maken om te kijken welke oplossing voor onze siuatie het beste voldoet. Waarschijnlijk gaan we inderdaad het updater block gebruiken om de business entities te synchroniseren tussen de server en de client. Mijn bedankt was dan ook vooral om aan te geven dat je mijn probleem goed had opgelost