Best practice on VS project layout regarding DLL references

[Stefan]

Hi,

I'm a VS/C# beginner and have a question on how I should structure my
C# projects.

I'm currently coding the basics for a larger project (base classes,
data access, business logic, UI stuff, main application). Up to now I
put each of these tiny bits in its own project that finally results in
a DLL, some consisting of only one .cs source file, some more (maybe
up to 10). In higher level projects I reference these DLLs (I do not
include the project). In the main app I just reference DLL's on form
window level maybe some business logic DLLs if needed.

Now I get into trouble because not all DLL's will get updated
automatically when I build the main application exe, only those that
are directly referenced. Also while developing I build all DLLs in
debug mode. Once a base DLL is fully tested, I want to switch to
release build. Which means I must update all references to this DLL
from the debug to the release directory.

Another problem is that some DLL's will get used in a MS-Office
application, which means that they must get "signed". And it is not
enough to just "sign" the top level DLLs I also must sign all
referenced lower level DLLs. Which leads to the questions why not sign
all DLL's?

Can somebody please advice me for a best practice with VS. Maybe there
is an MSDN article or book that shows which possibilities I have.
Maybe also regarding the fact that I must some day in the future
decide which DLL versions numbers are compatible (up to now I'm lazy
and just don't use other version numbers other than 1.0.0.0, this is
not a problem now, as the final version is not yet complete).

TIA,
Stefan

 

[Nicholas Paldino [.NET/C# MVP]]

Stefan,

I am not sure why you are not including the appropriate projects in the
solution. If you do this, and then set the reference to another project (on
the references dialog, there is a tab for "projects", do NOT set the
reference to the output of the other projects), when you build, it will
detect when changes have been made for ANY project in the solution, and
rebuild what has been changed, and what references what has been changed.

As for why not sign all DLLs? Do you mean why doesn't the compiler do
it by default, or why shouldn't you do it? For your solution, you have to
sign all of your DLLs, so I'm not sure what you mean by the question.

 

[sloan]

See my post here:

http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet/msg/6ff498b3ba370f3f


I've never seen a "best practice".

I think everybody figures out their own usually.

 

[Stefan]

Nicholas,

thanks for your feedback. I started a new form window project and now
included all needed base classes by including the
corresponding .csproj files. But I still have to include the
references to their DLL's because otherwise their functionality is not
available. Is this correct or am I still doing something wrong?

I also noted that sometimes even though the DLL is referenced I cannot
add the "using" clause to reference the namespace. Even fully
referencing the class including the namespace name did not help. After
fiddling arround with removing and adding the DLL it finally accepted
the using clause and I could reference the classes. Is this a know bug
(using VS2005/SP1)?

I'm still looking for a "best practice" in MSDN library.

Stefan

Stefan,

    I am not sure why you are not including the appropriate projects in the
solution.  If you do this, and then set the reference to another project(on
the references dialog, there is a tab for "projects", do NOT set the
reference to the output of the other projects), when you build, it will
detect when changes have been made for ANY project in the solution, and
rebuild what has been changed, and what references what has been changed.

    As for why not sign all DLLs?  Do you mean why doesn't the compiler do
it by default, or why shouldn't you do it?  For your solution, you have to
sign all of your DLLs, so I'm not sure what you mean by the question.

--
          - Nicholas Paldino [.NET/C# MVP]
          - (e-mail address removed)

Hi,

I'm a VS/C# beginner and have a question on how I should structure my
C# projects.

I'm currently coding the basics for a larger project (base classes,
data access, business logic, UI stuff, main application). Up to now I
put each of these tiny bits in its own project that finally results in
a DLL, some consisting of only one .cs source file, some more (maybe
up to 10). In higher level projects I reference these DLLs (I do not
include the project). In the main app I just reference DLL's on form
window level maybe some business logic DLLs if needed.

Now I get into trouble because not all DLL's will get updated
automatically when I build the main application exe, only those that
are directly referenced. Also while developing I build all DLLs in
debug mode. Once a base DLL is fully tested, I want to switch to
release build. Which means I must update all references to this DLL
from the debug to the release directory.

Another problem is that some DLL's will get used in a MS-Office
application, which means that they must get "signed".  And it is not
enough to just "sign" the top level DLLs I also must sign all
referenced lower level DLLs. Which leads to the questions why not sign
all DLL's?

Can somebody please advice me for a best practice with VS. Maybe there
is an MSDN article or book that shows which possibilities I have.
Maybe also regarding the fact that I must some day in the future
decide which DLL versions numbers are compatible (up to now I'm lazy
and just don't use other version numbers other than 1.0.0.0, this is
not a problem now, as the final version is not yet complete).

TIA,
Stefan- Hide quoted text -

- Show quoted text -