Reference Project or Assembly

[Just Me]

I have a solution containing many usercontrol projects.
When I wish to reference a usercontrol in another project I can select
either the project or the assembly.

Does it make a difference which one I select?



Thanks

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,
I normally reference the project, allowing VS.NET to work out compile &
setup dependencies for me.

If you reference the assembly, then you need to manually work out the
compile & setup dependencies. You can use "Project - Project Dependencies"
to set the compile dependencies, I believe you need to manually add the
respective assemblies to setup projects.

I've never had any real problems with referencing the project, however I
have seen reports on developers having problems with both methods.

Hope this helps
Jay

 

[solex]

Yes it does. When you select project it is simply for debugging. When you
do a final compile you should first compile the child project and then
reference the compiled assembly in the parent project.

Dan

 

[Just Me]

Thanks, but can you tell me why?
I mean if I select the project for the final compile, what bad thing
happens?

Thanks again

 

[Just Me]

You mean, if I reference an assembly, I have to also reference all its
dependencies?

thanks

 

[Jay B. Harlow [MVP - Outlook]]

Dan,
I only reference projects, when I do my final compiles (release builds),
using Build Solution, the child project is compiled first then the parent
project is compiled.

Do you have a documented case where the above does not work? I would be
curious to see it.

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Just Me,

You mean, if I reference an assembly, I have to also reference all its
dependencies?

No that is not what my statement is saying!

If you have 2 or more projects in your solution, an executable and one or
more class libraries. And you reference the class library assembly from your
executable. The executable may be built before the class library, causing
build errors. However ever if you use "Project - Project Dependencies" you
can indicate that the executable depends on (requires) the class library,
VS.NET will then build the class library first, then it will build the
executable.

As I stated I normally reference projects, then VS.NET takes care of every
thing (dependencies) for me. In both debug & release (final) builds.

You mean, if I reference an assembly, I have to also reference all its
dependencies?

There are cases where you need to reference dependent assemblies/projects.
For example:
- Library1 has BaseClass
- Library2 has DerivedClass that inherits from BaseClass
- Executable3 references Library2 & uses DerivedClass, Exectuable3 also
needs to reference Library1 as VB.NET needs the "definition" for the
BaseClass also. Here Exectuable3 can either reference both assemblies or the
projects.

However this dependent referencing has nothing to do with build order, which
is what my initial comments about Build/Project Dependencies are referring
to.

Hope this helps
Jay

 

[Just Me]

Thanks a lot.
I've got it now.

Just Me,
No that is not what my statement is saying!

If you have 2 or more projects in your solution, an executable and one or
more class libraries. And you reference the class library assembly from
your executable. The executable may be built before the class library,
causing build errors. However ever if you use "Project - Project
Dependencies" you can indicate that the executable depends on (requires)
the class library, VS.NET will then build the class library first, then it
will build the executable.

As I stated I normally reference projects, then VS.NET takes care of every
thing (dependencies) for me. In both debug & release (final) builds.

There are cases where you need to reference dependent assemblies/projects.
For example:
- Library1 has BaseClass
- Library2 has DerivedClass that inherits from BaseClass
- Executable3 references Library2 & uses DerivedClass, Exectuable3 also
needs to reference Library1 as VB.NET needs the "definition" for the
BaseClass also. Here Exectuable3 can either reference both assemblies or
the projects.

However this dependent referencing has nothing to do with build order,
which is what my initial comments about Build/Project Dependencies are
referring to.

Hope this helps
Jay

 

[solex]

Jay,

I do not have documentation. It was my understanding that this was an
accepted method. I generally compile my components outside of the solution
and therefore need to reference the assembly. This way I do not inadverntly
recompile the component if there are no changes, which can cause problems if
there are other projects that depend on the component.

In short my posting was just my convention and apologize for any
misunderstanding.

Regards,
Dan

 

[Jay B. Harlow [MVP - Outlook]]

Dan,
For projects that are shared across solutions, that may be a good
convention.

I currently do not share projects across solutions, so I have not "crossed
that bridge yet".

I can see potential problems for projects destined for the GAC where this
may be an issue, however for shared projects that are destined for side by
side deployment I don't know if I would worry about it. As I stated above, I
have not "crossed that bridge yet".

Thanks for the additional info!

Jay

 

[solex]

Jay,

The problem I have is that I have shared projects and I do not want to use
the GAC because that will change my deployment stragedy. I really like the
convience of using NTD but your projects must be XCOPY deployable.

Dan

 

[Jay B. Harlow [MVP - Outlook]]

Dan,
I normally use a Setup project to deploy my apps.

When you deploy your apps are you going to a single folder for all EXEs or
does each folder get its own EXE? If each EXE gets its own folder then each
folder will have its own copy of the DLL, so I don't see a versioning issue
per se.

If the DLL goes in the GAC or all the EXEs are in a single folder, then I
can see a versioning issue.

As I stated, I have not "crossed that bridge" yet, never the less, I do
appreciate the info for when I do reach that bridge.

Thanks again
Jay