Referencing assemblies and .config files.

  • Thread starter Thread starter Mark Broadbent
  • Start date Start date
M

Mark Broadbent

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 of its
associated classes of System.Runtime.Remoting are available, but certain
ones are not. A reference to System.Runtime.Remoting needs to be added to
make available all the unavailable ones. Now although I (think) understand
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 head
around why some classes of certain namespaces are available and others
arent -until a reference is made to this assembly. Is this simply a design
issue that certain parts of a namespace have been exposed in certain
assemblies. Could someone explain how this works and why it has been done?

The second part of my question relates to XML elements and attributes of
config files. Having looked at an example of storing certain predefined
elements for remoting config it has occurred to me that there must be some
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 that I
can look these things up?

thanks in advance!
--


Br,
Mark Broadbent
mcdba , mcse+i
=============
 
1)
A namespace can be distributed over several assemblies. A namespace doesn't really exist in an assembly - each type in the assembly just happen to have a fully qualified name that consists of several parts. Therefore, it's possible that you see some System.Runtime.Remoting types in one assembly and others in another assembly.

However, I would expect all System.Runtime.Remoting.* types to be located in System.Runtime.Remoting.dll assembly, i.e., I don't understand how you can see some of the types without a reference to System.Runtime.Remoting.dll. Try to run ildasm.exe on the assemblies that you do have references to - and see what types they contain.

2)
I don't know where the reference is. But in addition to the "standard" stuff, it's possible to add your own configuration information in that file and then read it at runtime.

Christian
 
1. I think the trade-off of having some namespaces in separate assemblies is
really down to the size of the assembly and the likelihood that it will be
referenced. Loading an assembly takes time, so they want to reduce the size
of the default assemblies as much as possible. Namespaces like Remoting and
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.
http://msdn.microsoft.com/library/en-us/dndotnet/html/remotingconfig.asp?frame=true
 
1. makes sense, thought that might be reason. Question is where am I picking
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 Im
right in saying is referenced automatically). Certainly if I look at it thru
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 for
this starting point.

--


Br,
Mark Broadbent
mcdba , mcse+i
=============
 
1. thx. You'll see though that if you create a project and remove all
references, you can still access part of the System.Runtime.Remoting
namespace in code (try intellisense to see that it does) -I think these
types are in the mscorlib.dll.


--


Br,
Mark Broadbent
mcdba , mcse+i
=============
Christian Heide Damm said:
1)
A namespace can be distributed over several assemblies. A namespace
Click to expand...
doesn't really exist in an assembly - each type in the assembly just happen
to have a fully qualified name that consists of several parts. Therefore,
it's possible that you see some System.Runtime.Remoting types in one
assembly and others in another assembly.
However, I would expect all System.Runtime.Remoting.* types to be located
Click to expand...
in System.Runtime.Remoting.dll assembly, i.e., I don't understand how you
can see some of the types without a reference to
System.Runtime.Remoting.dll. Try to run ildasm.exe on the assemblies that
you do have references to - and see what types they contain.
2)
I don't know where the reference is. But in addition to the "standard"
Click to expand...
stuff, it's possible to add your own configuration information in that file
and then read it at runtime.
 
I think you'll find the remoting namespaces are held in a separate DLL
called System.Runtime.Remoting.dll.
 
There is some file that defines the _default switches_ for csc.exe. MsCorLib is certainly referenced by default.

If you try to run "csc.exe /nostdlib ....", then you'll probably get lots of compile errors since you're missing the basic stuff (e.g., Console.WriteLine).

Christian

---
 
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
=============
 
will try that sometime when Im not so busy. Thanks fo that tip -will be
interesting to see the results.

--


Br,
Mark Broadbent
mcdba , mcse+i
=============
Christian Heide Damm said:
There is some file that defines the _default switches_ for csc.exe.
Click to expand...
MsCorLib is certainly referenced by default.
If you try to run "csc.exe /nostdlib ....", then you'll probably get lots
Click to expand...
of compile errors since you're missing the basic stuff (e.g.,
Console.WriteLine).
 
Hi,

I believe that the classes, defined in mscorlib.dll are those parts of
the remoting, which make use of the cross appdomain buildin memory
channels, used behind the scenes, when you just pass a reference of an
object between 2 appdomains in your process, or those one, used for com
interop.

The other classes, which are responsible for creating channels and all
other remoting stuff are located at their own assembly.

Sunny
 
Yep I agree. A lot of the remoting infrastructure is used for other things..
the real tcp channel management stuff is probably in the DLL.
That's the great thing about .net, the fact you can span one namespace over
multiple DLLs.
 
think that just about wraps that one up.

--


Br,
Mark Broadbent
mcdba , mcse+i
=============
 
Back
Top