Development practices for Debug and Release builds...

  • Thread starter Thread starter jdwix
  • Start date Start date
J

jdwix

I have been developing in VB6 for several years and have become
accustomed to loading whatever VB projects I need to debug into a
group and having the ability to step through the code and make changes
on the fly. If the change happens to break compatibility, it currently
doesn't matter because the build process rebuilds every component in
the application. This has worked out for us because of the way we
deploy the application.

Now, finally, we are moving to Visual Studio.Net and I am sure things
have changed with how the developer loads and debugs his code. I am
looking for suggestions on what are the best practices for loading and
debugging several related projects into a solution and not having to
change references to suit whatever the situation is at the time. Is
changing references just something that has to be done now or is there
a better way?

Thanks in advance for any suggestions.
 
I'm not sure I understand. You can't run a project in VS2005 that won't
build. But you can rebuild all the components and run it in debug mode and
stop in the middle. You can add multiple projects to any solution, and
debug across the solution. It's much more robust than VB6 was, although the
Edit And Continue isn't quite as easy -- sometimes you can't edit and
continue, depending on the code involved.

I assume you're moving to vS2005 adn not VS2003. I don't think VS2003
supports edit&continue at all.

Robin S.
 
Back
Top