References are "project properties" independent of the configuration
(Release/Debug) so they won´t change automatically. But you can add/remove
references programatically using the extensibility model, so you could build
a macro or add-in that switches references when executing it or clicking a
button. I think that even could be done automatically with some event that
notifies a change of configuration or a build. Let me know if you want to
follow that route, but it would be much better to use project references to
debug the library dlls. Also notice that in Release configuration you are
not debugging, so you can skip the IDE and run the app directly and at this
point the app will use as referenced dlls whatever the probing mechanism
finds first (dlls in the same folder, in subfolder, in GAC, etc.). In other
words, the Release configuration is used mostly to build the release version
and little else...

Signature
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
> Hi Carlos,
>
[quoted text clipped - 8 lines]
> TIA.
> Sek
Sek - 08 Nov 2005 02:00 GMT
Carlos,
Thanks for ur detailed reply.
One thing i am interested from your explanation is the purpose of
references.
I understand that, the references are basically for the compilation
phase to resolve the declarations. In this case, all that matters is
the type of assembly available during the execution/runtime phase,
rather than the compilation phase.
Presently, i am thinking of using Release config of assemblies in the
references and also set the "Copy Local" to false.
Thanks for all the help.
Sek
> References are "project properties" independent of the configuration
> (Release/Debug) so they won´t change automatically. But you can add/remove
[quoted text clipped - 33 lines]
> > TIA.
> > Sek
Carlos J. Quintero [VB MVP] - 08 Nov 2005 12:08 GMT
> In this case, all that matters is the type of assembly available
> during the execution/runtime phase rather than the compilation phase.
> Presently, i am thinking of using Release config of assemblies in the
> references and also set the "Copy Local" to false.
If you use "Release" versions as references during the debugging, you will
be unable to debug inside them if a problem arise...considering the some
people, including me, would love to debug inside the .NET Framework Dlls
provided by Microsoft to solve some problems, it would be a pity to impose
yourself the limitation of being unable to debug your own DLLs while
debugging their client application...

Signature
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