assemblies & references

  • Thread starter Thread starter A-PK
  • Start date Start date
A

A-PK

Anyone know how to breakdown every modules into different assemblies

and refernces. Hence, to repair problematic module, only that

particular module needed to be recompiled.


or any place can get more information about assemblies & references
 
just code it that way?! im kinda missing what you're not getting.. just code
all the modules as seperate projects and refrence them all together... it's
not that hard
 
If you want to take this approach, you'll need to create each module in its
own solution, which will compile it to its own assembly. For example, one
solution could be the module that describes data classes and another could
describe business classes.

Search MSDN.Microsoft.com, keyword "assemblies" for more.
 
Compile them just as you would any assembly. Reference them as you would
any assembly. Once they are referenced, you can instantiate the classes in
the modules.

Are you saying you don't know how to compile and make references? If so,
that is a completely different issue. If you are using VS.NET, "build" your
assembly (compile) from the Build menu. If not using VS.NET, use the
command line compilers.
 
so sorry.....
I right click the "references" under the solution explorer and choose Add
References.

then pop up one screen with Three Tab there
..NET \ COM \ Projects

i wonder which to choose ? I choose Project then anotehr screen poping up
i browse to the destination path and choose xxx.exe but can not add the
references.

this is where I stuck.

1- i dun know if my file compile correctly - acoording to scott, i did
compile them correcntly.
2- i dun know if my destination path is correct, but i have try every files
on that folder, but all can not

Is it only DLL or COM file can be references ?
I create a new project and try to compile and make it a reference ...can or
can not ?
 
A-PK said:
so sorry.....
I right click the "references" under the solution explorer and choose Add
References.

then pop up one screen with Three Tab there
.NET \ COM \ Projects

i wonder which to choose ? I choose Project then anotehr screen poping up
i browse to the destination path and choose xxx.exe but can not add the
references.
Click to expand...

You want to make a reference to a .NET Assembly, right? Then choose .NET
and hit browse. Browse to the .NET assembly in question and hit select.
Then click OK. It's really very simple.
 
ok..should i compile my project to .dll file then make references to my
project ?

i have compile my file to dll, and able to make references, i wonder if i
dun compile to dll (class), could I still make reference to my project ?

i am confused about dll now...i though dot net already face off dll.....but
how come i still need to compile dll in order to make references ?...pls
guide me....i am not clear in this issue
 
A-PK said:
ok..should i compile my project to .dll file then make references to my
project ?
Click to expand...

Whatever .dll you want to reference should already be compiled into its
final form (.dll or .exe) before you reference it. The project that needs
to use the referenced .dll need not be compiled to make the reference, but
certainly needs to be compiled in order for its code to run (and therefore
use the referenced assembly).
i have compile my file to dll, and able to make references, i wonder if i
dun compile to dll (class), could I still make reference to my project ?
Click to expand...

See above.
i am confused about dll now...i though dot net already face off dll.....but
how come i still need to compile dll in order to make references ?...pls
guide me....i am not clear in this issue
Click to expand...

As I stated, you need to have whatever you want to reference already
compiled, because the compiled assembly is what you make a reference to.
The project that is making the reference needs to be compiled to run, but
not to make a reference. An example of this is that a brand new project in
VS.NET will already have references to commonly used .NET assemblies
(system.dll, mscoree.dll, etc.) before you even begin.

I really would suggest an msdn.microsoft.com search on "Assemblies",
"Namespaces" and "references" as these are all basic tenants of .NET
programming.
 
I have a concern which follows on from this discussion.

I am building a .NET application made up of multiple assemblies
(projects) in a single solution. The projects are decoupled as much as
possible so that only a few interfaces are exposed between projects.

But....

Whenever I touch any code in a more fundamental project (say, Storage),
ALL files are recompiled in ALL projects that reference this changed
project.

This is unacceptable! At the moment the compile times are not large as
the project is still at POC stage but I expect the code space to
increase at least 100 to 1000 fold.

Am I missing something, or is this deliberate? Surely VS can determine
whether any exposed types have been changed rather than taking what
appears to be the most pessimistic approach.

Any information would be very much appreciated.
Whatever .dll you want to reference should already be compiled into its
final form (.dll or .exe) before you reference it. The project that needs
to use the referenced .dll need not be compiled to make the reference, but
certainly needs to be compiled in order for its code to run (and therefore
use the referenced assembly).




As I stated, you need to have whatever you want to reference already
compiled, because the compiled assembly is what you make a reference to.
The project that is making the reference needs to be compiled to run, but
not to make a reference. An example of this is that a brand new project in
VS.NET will already have references to commonly used .NET assemblies
(system.dll, mscoree.dll, etc.) before you even begin.
Click to expand...

---

If you whish to reply to me directly, my addres is spam proofed as:

pbromley at adi dot co dot nz

Or if you prefer - (e-mail address removed) :-)
 
When you make a reference to a .NET assembly, a COPY of that assembly is
placed in your application's /bin folder. If the assembly you are
referencing were to change AFTER you've made your reference to it, you will
not see those changes in your project UNLESS you recompile (which causes new
copies of referenced assemblies to be gotten).

This is the behavior that you are describing and it is by design. I
understand that if the public interface of an assembly doesn't change that
there shouldn't be the need to go get a new copy of it, but that is the
behavior.

However, if you are in production and you need to update one of the
satellite assemblies that your application uses and you know that the
interface for that assembly has not changed, you can simple replace the old
assembly with the new one and you would NOT have to recompile the main
application.
 
Hi Scott,

thank for guiding me the reference and assemblies.

i got one more question.

if my .dll path is not fixed, how could I add .dll files to be the
referecens.

In other word, how could I change the .dll path in run times. thank you
 
That's a tough one. Try looking into creating "Shared Assemblies" & the
"Global Assembly Cache". But I'm not sure if this will do it.
 
Back
Top