By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,649 Members | 696 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,649 IT Pros & Developers. It's quick & easy.

Development practices for Debug and Release builds...

P: n/a
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.

Apr 26 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
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.
----------------------------
<jd***@yahoo.comwrote in message
news:11*********************@u32g2000prd.googlegro ups.com...
>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.

Apr 27 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.