Afhalen na 1 uur in een winkel met voorraad
Gratis thuislevering in België vanaf € 30
Ruim aanbod met 7 miljoen producten

Afhalen na 1 uur in een winkel met voorraad
Gratis thuislevering in België vanaf € 30
Ruim aanbod met 7 miljoen producten

Winkels

Verlanglijstje

Winkels

Verlanglijstje

Zoeken

Volg ons op

Wist je dat er in Vlaanderen voor iedereen een Standaard Boekhandel is binnen een straal van 7 km?

Zoek een winkel

€ 67,45

+ 134 punten

Levering 2 à 3 weken

Eenvoudig bestellen

Veilig betalen

Gratis thuislevering vanaf € 30 (via bpost)

Gratis levering in je Standaard Boekhandel

Omschrijving

COM ON A WIRE, also known as DCOM, was a great boon to the distributed pro- grammer. Under the model ofDCOM, a client was able to interact with COM objects located literally anywhere, without requiring a change of code base. Using the indi- rection provided by AppiDs, stubs, proxies, and channels, our distributed endeavors involved little more than the use of declarative tools such as dcomcnfg.exe and the Component Services snap-in. However, all was not well in the world of DCOM (or COM for that matter). Although the clicking of check boxes made COM-based remoting appear quite simple on the surface, we suffered through numerous registry conflicts, a lifetime of passing interface pointers by reference, and the dreaded prospect of crossing firewalls. Just as ADO.NET has nothing to do with classic ADO, the .NET Remoting story has nothing to do with classic DCOM. The most obvious case in point is the fact that .NET assemblies are not registered with the system registry. Given this, we have no AppiD. Without an AppiD, we have no RemoteServerName value, which means no reference to oleaut32.dll and thus no more COM -based stub and proxies. In short, everything we knew about interacting with types across the wire has changed dramatically.