New Project & Design Environment

  • Thread starter Thread starter Matthew Hood
  • Start date Start date
M

Matthew Hood

My company is just starting development of a new project using VB.NET.
The question I have is, since the release of VS 2005 and the 2.0 Framework
comming out soon, should we start developing with the Beta version? Or
should we stick to 2003 & the 1.1 framework. 2005 will be released before
we are even halfway done with the project, and I am anxious to take
advantage of some of the new features.

Any thoughts?

Thanks,
-Matt
 
Matthew,
I would use it expecting to take time to update & test my code for each
interim build (beta release) of VS.NET, plus the final build.

Also I would take the unknown release date of VS.NET 2005 into account...

The cool thing about building it for 2005, is you can release you project
when 2005 is released & say "Look this is 2005, cool huh!"...

I should have added a word of caution, remember that this is beta code,
methods show up, methods disappear, even on new 2005 Types I've noticed a
handful of Obsolete members.

Plus some classes/concepts are dropped in favor of new ones (WinBar was
renamed MenuStrip...) Based on a thread in
microsoft.private.whidbey.windowsforms.databinding DataContainer was dropped
in favor of DataConnector.

Depending on how heavily you "invested" in some of the new items you may
have some time to update on an interim release...

Also Beta code is Beta code, things may just not work, be certain to report
bugs!

Good luck & have fun!

Hope this helps
Jay
 
Personally, I would take the opposite approach from Jay.
In Beta products, methods/objects come and go, things change.
You may be constantly reworking your code to keep it working in each
release.
Then you might have a major re-work or at least a long debug cycle when the
official 2.0 Framework is released.
Additionally, no matter how hard they try, there will be bugs in the initial
2.0 release. The Framework is massive and some bugs will slip through.

If you write it on the 1.1 Framework, you could just keep going and make
sure everything works.
When the 2.0 Framework is released, you can upgrade known good code to take
advantage of the improvements you actually need. This is far easier than
trying to upgrade questionable beta code that may rely on things that are
not in or substantially different than the official release.
Worst case, you release your app on 1.1 Framework. Then very quickly
re-release your app on the 2.0 Framework. You customers might perceive this
as a good upgrade. This is much better than an extended debug schedule and
trying to explain to your customers why something doesn't work. It might be
due to a bug or something missing in the final 2.0 Framework and might
require you to "downgrade" your software. Customers don't like that.

Gerald
 
Gerald.
Personally, I would take the opposite approach from Jay.
In Beta products, methods/objects come and go, things change.
You may be constantly reworking your code to keep it working in each
release.

In my opinion is that what Jay wrote?

Cor
 
Gerald,
As Cor suggests, I'm not sure you are taking the opposite approach. It
sounds like you reiterated what I stated.

Most of my projects I am leaving on 1.1 for the reasons you and I stated.

I have one project I am doing in 2.0 as 2.0 is a better fit (it uses Master
Pages, and possible themes). My customer understands the risks associated
with using 2.0.

Hope this helps
Jay
 
Hmm... I guess we said the same thing.
My interpretation of the following led me to believe you encourage using 2.0
from the beginning.
"[I would use it] expecting to take time to update & test my code for each
interim build (beta release) of VS.NET, plus the final build."

However, we are in agreement with everything else.
IMHO, I would suggest not starting the project in 2.0 beta, but rather
target 1.1.
Then when appropriate, upgrade the working code to 2.0 release and
incorporate desired changes.
Just "seems" like a more rational development scheme to me.

Now in the case where specific core functionality is needed that exists in
2.0 and not 1.1, then there is a strong case to go ahead and use the 2.0
beta and deal with the inevitable problems. I have one project that does fit
that profile. But generally speaking, I would not recommend a beta for
actual production development.

Gerald
 
Gerald,
My interpretation of the following led me to believe you encourage using
2.0
from the beginning.
"[I would use it] expecting to take time to update & test my code for each
interim build (beta release) of VS.NET, plus the final build."

Doh! I can see now how one could read my opening comment that way.

Thanks for helping clarify it.

Jay

Gerald Hernandez said:
Hmm... I guess we said the same thing.
My interpretation of the following led me to believe you encourage using
2.0
from the beginning.
"[I would use it] expecting to take time to update & test my code for each
interim build (beta release) of VS.NET, plus the final build."

However, we are in agreement with everything else.
IMHO, I would suggest not starting the project in 2.0 beta, but rather
target 1.1.
Then when appropriate, upgrade the working code to 2.0 release and
incorporate desired changes.
Just "seems" like a more rational development scheme to me.

Now in the case where specific core functionality is needed that exists in
2.0 and not 1.1, then there is a strong case to go ahead and use the 2.0
beta and deal with the inevitable problems. I have one project that does
fit
that profile. But generally speaking, I would not recommend a beta for
actual production development.

Gerald

Jay B. Harlow said:
Gerald,
As Cor suggests, I'm not sure you are taking the opposite approach. It
sounds like you reiterated what I stated.

Most of my projects I am leaving on 1.1 for the reasons you and I stated.

I have one project I am doing in 2.0 as 2.0 is a better fit (it uses Master
Pages, and possible themes). My customer understands the risks
associated
with using 2.0.

Hope this helps
Jay
 
Jay,
Doh! I can see now how one could read my opening comment that way.

That is why I saw it that fast from Gerald, however reading it more times, I
think you wrote that part as well right.

:-)

Cor
 
Gerald,

Although this is slippery ground for me, is the only part that we agree
about these words, (which did cost me the most time).

"I should have added a word of caution,"

Conform the text I readed it as

I have to add a word of caution,

:-)

Cor
 
Thanks for the replies. I guess for the moment then we'll continue using
the current release and work in an update when 2.0 comes out.

Appreciate the info.
-Matt
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top