That was partly my point that you will notice that you can declaratively
access part of the System.Runtime.Remoting namespace *without* adding a
reference to the remoting.dll. However some classes of the namespace was
missing which I could only make available by referencing this dll. This
really is the basis for my question because (like your assumption) you would
have thought that everything that belongs to remoting would be accessible
through the remoting.dll; wheras you will find that alot is accessible
without referencing this. Hence I believe that this namespace spans several
dlls ... and the bit that is being exposed to me I think can be found in the
mscorlib.dll.
Please have a try with intellisense (or view mscorlib via object browser)
and you will see what I mean.
I can only assume that things have been designed like this to reduce file
library sizes, and to only expose essential classes in namespaces for design
reasons.
P.S. I am pretty sure that remoting is not the only namespace that spans
dlls like this.
I hope I made more sense.
--
Br,
Mark Broadbent
mcdba , mcse+i
=============
"John Wood" <j@ro.com> wrote in message
news:%23Zadt$dXEHA.1000@TK2MSFTNGP12.phx.gbl...[color=blue]
> I think you'll find the remoting namespaces are held in a separate DLL
> called System.Runtime.Remoting.dll.
>
> --
> John Wood
> EMail: first name, dot, last name, at priorganize.com
> "Mark Broadbent" <no-spam-please@no-spam-please.com> wrote in message
> news:%23oBaS7dXEHA.3292@TK2MSFTNGP09.phx.gbl...[color=green]
> > 1. makes sense, thought that might be reason. Question is where am I[/color]
> picking[color=green]
> > up the initial remoting classes from? -At a guess I'd say there is a
> > System.Runtime.Remoting namespace defined in mscorlib.dll (which I think[/color]
> Im[color=green]
> > right in saying is referenced automatically). Certainly if I look at it[/color]
> thru[color=green]
> > object browser it certainly seems that way.
> >
> > 2. Thx for this link. I was kind of hoping the documentation for all
> > namespaces/ classes config in Xml docs would be in one place but I guess
> > I'll have to see what I can find on a class by class basis. Still thx[/color][/color]
for[color=blue][color=green]
> > this starting point.
> >
> > --
> >
> >
> > Br,
> > Mark Broadbent
> > mcdba , mcse+i
> > =============
> > "John Wood" <j@ro.com> wrote in message
> > news:uSly0pdXEHA.2716@tk2msftngp13.phx.gbl...[color=darkred]
> > > 1. I think the trade-off of having some namespaces in separate[/color][/color]
> assemblies[color=green]
> > is[color=darkred]
> > > really down to the size of the assembly and the likelihood that it[/color][/color][/color]
will[color=blue]
> be[color=green][color=darkred]
> > > referenced. Loading an assembly takes time, so they want to reduce the[/color]
> > size[color=darkred]
> > > of the default assemblies as much as possible. Namespaces like[/color][/color][/color]
Remoting[color=blue][color=green]
> > and[color=darkred]
> > > Windows.Forms are great candidates for splitting off into separate
> > > assemblies because they are large namespaces and used only in specific
> > > circumstances.
> > >
> > > 2. The remoting configuration file format is all documented in MSDN.
> > >[/color]
> >[/color]
>[/color]
http://msdn.microsoft.com/library/en...asp?frame=true[color=blue][color=green][color=darkred]
> > >
> > > --
> > > John Wood
> > > EMail: first name, dot, last name, at priorganize.com
> > > "Mark Broadbent" <no-spam-please@no-spam-please.com> wrote in message
> > > news:OvHJUTdXEHA.1152@TK2MSFTNGP09.phx.gbl...
> > > > Hi guys, just going through remoting at the moment and a couple of
> > > questions
> > > > relating to .net in general has surfaced.
> > > > Firstly I have seen in the designer that for the namespace and many[/color][/color][/color]
of[color=blue][color=green]
> > its[color=darkred]
> > > > associated classes of System.Runtime.Remoting are available, but[/color][/color]
> certain[color=green][color=darkred]
> > > > ones are not. A reference to System.Runtime.Remoting needs to be[/color][/color][/color]
added[color=blue][color=green]
> > to[color=darkred]
> > > > make available all the unavailable ones. Now although I (think)[/color]
> > understand[color=darkred]
> > > > the concept that an assembly needs to be referenced in order for its
> > > classes
> > > > and other members to be exposed to the designer, I cant quite get my[/color]
> > head[color=darkred]
> > > > around why some classes of certain namespaces are available and[/color][/color][/color]
others[color=blue][color=green][color=darkred]
> > > > arent -until a reference is made to this assembly. Is this simply a[/color]
> > design[color=darkred]
> > > > issue that certain parts of a namespace have been exposed in certain
> > > > assemblies. Could someone explain how this works and why it has been[/color]
> > done?[color=darkred]
> > > >
> > > > The second part of my question relates to XML elements and[/color][/color][/color]
attributes[color=blue]
> of[color=green][color=darkred]
> > > > config files. Having looked at an example of storing certain[/color][/color]
> predefined[color=green][color=darkred]
> > > > elements for remoting config it has occurred to me that there must[/color][/color][/color]
be[color=blue][color=green]
> > some[color=darkred]
> > > > kind of reference for this XML based language to configure things at
> > > > runtime. For instance I might have known how to register a client
> > > activated
> > > > channel in c# code, but how would I have known that...
> > > > {snippet!!}
> > > > <channels>
> > > > <channel ref="http" port="1234" />
> > > > </channels>
> > > > ..would have done the same thing. Therefore there must be somewhere[/color][/color]
> that[color=green]
> > I[color=darkred]
> > > > can look these things up?
> > > >
> > > > thanks in advance!
> > > > --
> > > >
> > > >
> > > > Br,
> > > > Mark Broadbent
> > > > mcdba , mcse+i
> > > > =============
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
