Upgrade\Migrate VB 2003 App to 2005 or 2008?

  • Thread starter Thread starter dotnetme
  • Start date Start date
D

dotnetme

My Company is thinking of moving an Application that was written in VB.Net
2003 to 2005... I'm pushing for 2008.... it is a Very large application and
it may take 6 months to convert everything and by then it will be 2009 and we
just brought our in house system up in a 2005 product which will be 4 years
old.... I'm looking for some convincing reasons why go to 2008 instead of
2005... I'm aware you can compile it in different frameworks versions and I
will need to read up more on LINQ... but that is SQL Server thing... If
anyone has some comments I would like to hear from you please!!! I guess the
reason they never upgraded originally was because the Serialization in 2005
was different then in 2003 so it was a bigger task... Our middle tier was
developed in 2003 so any project that talked to the middle tier had to be
written in 2003. I currently use 2005, and love it, for my projects which
are not affiliated with the middle tier application... I also test drove
2008 and liked what I saw but I do not know enough to be effectively
persuasive...

the project that is in 2003
uses remoting for the middle tier
and uses Oracle a DB

Thanks in advance

Dotnetme
 
Simple statement is you need to build in the latest version, but rollout and
support backwards.

A big jump in VS 2003 to VS 2008(that took place at VS2005) Is the design
surface environment support at the Data Acces layer. The move from
dataadapter/dataset to tableadapter/dataset can be profound as the codegen
is different. Continued support of the VS 2003 projects may require those
coders to find the path through this at a level of urgency that can be
scary. If most of the code was handwritten it is less of a problem but in
specific instances the data access designer no longer supports familiar data
components. There aren' many examples of this so you may need initial
knowledge sharing session within the DAL group
to exploit the transition to best advantage. It is worth doing, as it
represents good skill development as opposed to DAL code rewrite that can
take place over time
at a much lower billed cost.

By example:
a VS2003 DAL component set that contains Direct SQLCommand objects,
DataTable objects, SqlConnection objects. Is no longer visually editable or
has graphical designer support in the same way it did at build time on
VS2003. This can lead to a duality within the DAL component layer projects
with truncated design support along the VS2003 code as opposed to New code
base that utilizes the (VS2005/08) "Dataset Designer".


It's a big topic especially across multiple datasources or integration
across multiple programming domains. Hopefully the below links will
demonstrate
some of the concerns...But that being said there is way too much good in
VS2008 to ignore. With dedicated SQL programmers and admin the DLinq (Linq
to SQL) is the true path to bridging the communication gap between OO
practitioners and Relational Persistance folks.
There are lots of religious type debates on this but from a root problem
solving approach this is pretty important, it is "pay it forward" however
which as you stated
is a tough sell. Especially since it demands a command of how all this stuff
works together and grows up, accountants or CIO don't know even a portion of
what is involved.

Ajax, Jquery library will be a great Christmas present for your programmers.
Depending on your environment an evaluation of Windows 2000 Server IIS5
may come into play. But even the most conservative Server administrators (in
tough financial times) are now going to Server 2008 training now. The
Application Server layer (WCF, webservices, IIS7) placed on Server 2008
today has been tested well, (back to member Servers with NT4 domain).
This is the other sell that may need to be done depending on you programming
vision..
Since that VS2008 Server is a straight CAPEX expense it is acutally an
easier buyin than the pitch for VS2008
and the indeterminant manhours involved in the needed transition.

If I was to give one example of a single convicing arguement for VS2008 over
VS2005 it would be the AJAX Autocomplete textbox as demonstrated on Google.
This is trivial to impliment on VS2008 but in DHTML is a whole diffrent
skill set. This functionality is a small codebase, enabled by 3.5 and VS2008
and covers many enduser Interface options, that effectiuvely destructure an
enterprise system and delivers layers huge. i demonstrated how this overcame
one of the big limitations in a specific shopping cart example. I don't know
if you've gotten into Popup search or auto search datastructures but they
are implimentions that have never inspired me. They often exist as
disjointed, poor temporary/persistance layers that just don't work at the
application level. I hold out hope for the OS level but Vista Search is a
perfect example of the shortfall (and the promise).

By example:
Imaging a Universal Purchase Requisition online form. The parts that are
ordered by the masses are generics (paper towels). The average user does not
know the Item Master naming of those parts within the ERP system, The ERP
system does not cotain a hierachical item goruping like Amazon.
Housewares->Cleaning->Dispoasables becasue internally non retail businesses
do not have a value stearm that relates to consumable presentation. But if
the internal user presented to the Purchasing queue with actual part numbers
on the Universal Purchase Requisition to the purchasing dept
"SS-papertowel-hd-200sheet" That indicator can "know" the last pricing from
prefered vendor. The purchasing department now has a substantially lower
work load. It puts the various Actors talking a similar dialect without
human interpretation. The Universal Purchase Requisition now exists only as
a completed form that needs to be passed around a queue for approval and
checking rather than edits into actual values all without full time
categorization effort. Layers of beaucracy is removed. It's a big deal. This
BOM, item master, PO problem has been a big problem for decades. The most
indepth investigation has been within the ship building and ship
commisioning industry such as Northrup Gumman. That involves a cross
reference condition as well but the basic problem is still very simple.
Unique naming within disparate systems or "verbalization". It is funny how
such a simple single item such as AJAX autocomplete can be exploited to
address a substantial portion of solving the problem scope.


calling StoredProcedures from .NET using TableAdapters in the online
documentation
http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework.adonet/topic36472.aspx

queriestableadapter is....

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3099911&SiteID=1

queriestableadapter Methods give unexpected results...

http://www.msusenet.com/archive/topic.php/t-1874902315.html

yeah that is a problem description...

http://groups.google.ca/group/micro...c?lnk=st&q="dataset+designer"+sql+error&fwc=1

manually add...

http://www.vbdotnetforums.com/ado-net/18833-data-source-stored-proc-vs-query.html

http://visualbasic.ittoolbox.com/gr...-l/vbnet-2008-sending-values-to-store-2324529

EVIL

http://scruffylookingcatherder.com/archive/2007/05/30/ms-daab-is-eeeeviiiiil.aspx



return value..

http://www.developersdex.com/vb/[email protected]>

http://msdn.microsoft.com/en-us/library/ms171918.aspx
 
Back
Top