M
Mrinal
See the Comments In Line !!!
What u have seen is perfectly the way it behaves , until and unless first
call is not made , assembly is not loaded , that's what
dynamic loading is all about and it's always one time process , for any
future calls .
Also even for a given MSIL code , only and only when a given method is
called it gets jitted into native code , it doesan't happens at one time for
all the
assembly code .
I don't think there's any diff. between the two except tha former way of
"Project Tab" is easy for the developer , ultimately for dynamic referencing
it needs
to map to a physical path but one thing u can try :
-- Reference an assembly using project tab , then rebuild that dll project ,
with diff. target directory and delete the original .
-- Now only build the exe referring it and see it creates a diff.
As in case of browse button method -- mapping to a physical folder , i think
above one may fail , let me try it , i will give u exact results .
Finally, I've also noticed that "References Path" in the Project
Properties don't match "Path" for the individual Reference Properties.
What does that impact and how best to sync them so they are the same?
I am not very sure , will post back if i get some relevant answer .
db said:I have a few basic questions about references and assemblies.
I was under the impression that by adding a reference in a project to
another project within the same solution, the assembly for the
referenced project would be loaded automatically. However, in using
AppDomain.CurrentDomain.GetAssemblies it appears, that's not the case.
loads once some call is made to a class within the referenced project
(e.g. instantiating a form from the referenced project). Is this the
case?
What u have seen is perfectly the way it behaves , until and unless first
call is not made , assembly is not loaded , that's what
dynamic loading is all about and it's always one time process , for any
future calls .
Also even for a given MSIL code , only and only when a given method is
called it gets jitted into native code , it doesan't happens at one time for
all the
assembly code .
On a related note, when adding a reference to another project within
the same solution through the "Add Reference" dialog what's the
preferred approach? Does using the "Project" tab create a relatively
dynamic path to the referenced assembly file (.dll) such that it will
be able to find the referenced file regardless of the file structure of
the hosting PC? And conversely, by using the "Browse" button, is a
more static path to the .dll created, which could cause problems down
the road if you rearrange the internal file structure of your solution?
Can anyone give some good advice or rules of thumb for file and
reference organization within a multi-project solution?
I don't think there's any diff. between the two except tha former way of
"Project Tab" is easy for the developer , ultimately for dynamic referencing
it needs
to map to a physical path but one thing u can try :
-- Reference an assembly using project tab , then rebuild that dll project ,
with diff. target directory and delete the original .
-- Now only build the exe referring it and see it creates a diff.
As in case of browse button method -- mapping to a physical folder , i think
above one may fail , let me try it , i will give u exact results .
Finally, I've also noticed that "References Path" in the Project
Properties don't match "Path" for the individual Reference Properties.
What does that impact and how best to sync them so they are the same?
I am not very sure , will post back if i get some relevant answer .