Reference DLL or project?

[Jon]

I'm wondering what people recommend. I used to have all my programs
reference another project that held general functions and classes I knew I
would want to reuse. Lately, I've switched to just referencing the dll that
comes from that project. However, when I do this, I often get the message
"No source code found at the current location" when debugging...it doesn't
always happen, but sometimes. So, I've been thinking of moving back to
referencing the actual project in the solution.

What do you do and why?

[Marina]

I typically only have one project per solution. So I reference the DLL, and
I've never had the issue you are describing.

"Jon" <ru******@msn.com> wrote in message
news:Ot**************@tk2msftngp13.phx.gbl...

I'm wondering what people recommend. I used to have all my programs
reference another project that held general functions and classes I knew I
would want to reuse. Lately, I've switched to just referencing the dll
that comes from that project. However, when I do this, I often get the
message "No source code found at the current location" when debugging...it
doesn't always happen, but sometimes. So, I've been thinking of moving
back to referencing the actual project in the solution.

What do you do and why?

[Dennis]

I seem to get erratic results when referencing my .dll's unless I make the
assembly version the same (replace the * with a number in the Assembly.vb
version attribute). When the .dll is changed, the version number also
changes unless it's fixed and I think this confuses the compiler.
--
Dennis in Houston
"Jon" wrote:

I'm wondering what people recommend. I used to have all my programs
reference another project that held general functions and classes I knew I
would want to reuse. Lately, I've switched to just referencing the dll that
comes from that project. However, when I do this, I often get the message
"No source code found at the current location" when debugging...it doesn't
always happen, but sometimes. So, I've been thinking of moving back to
referencing the actual project in the solution.

What do you do and why?

[Carlos J. Quintero [VB MVP]]

To debug the dll you need the .pdb file. If the .pdb file does not exist, or
it is out of synch, etc. you can get that error. In general, it is better to
use Project references.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

"Jon" <ru******@msn.com> escribió en el mensaje
news:Ot**************@tk2msftngp13.phx.gbl...

I'm wondering what people recommend. I used to have all my programs
reference another project that held general functions and classes I knew I
would want to reuse. Lately, I've switched to just referencing the dll
that comes from that project. However, when I do this, I often get the
message "No source code found at the current location" when debugging...it
doesn't always happen, but sometimes. So, I've been thinking of moving
back to referencing the actual project in the solution.

What do you do and why?

[Charles Law]

Hi Jon

In addition to other answers, Microsoft recommend referencing the project
when it is part of your solution. There are known issues when referencing
the DLL (at least up to V2003) that can cause the compiler to get confused,
and report erroneous errors.

HTH

Charles
"Jon" <ru******@msn.com> wrote in message
news:Ot**************@tk2msftngp13.phx.gbl...

I'm wondering what people recommend. I used to have all my programs
reference another project that held general functions and classes I knew I
would want to reuse. Lately, I've switched to just referencing the dll
that comes from that project. However, when I do this, I often get the
message "No source code found at the current location" when debugging...it
doesn't always happen, but sometimes. So, I've been thinking of moving
back to referencing the actual project in the solution.

What do you do and why?