I really need a piece of advice...

I really need a piece of advice...

• Philip Mont

  degia wrote:

  only a little question. I have not well understood (my english is not perfect...): you mean that there are .NET features that are 50% more efficient than the correspondent in VB6, or that .NET has features that VB6 does not have Are there exampes or articles about these "power features" to help me to evaluate their impact on my application

  .NET has many, many more features that VB6 doesn't have. That's not to say that it couldn't be done in VB6, though; which brings out the '50%' comment. There is native functionality in .NET that required a lot of code to 'make happen' in VB6. Simple things like a form splitter bar, sensible form resizing can be done with zero lines of code (part of the new built-in controls).

  Other things like graphics which required heavy Win32 API calls in VB6 are all handled through the native .NET framework (and cause fewer problems - gosh I so hate going back to the old VB6 code and fixing a graphical glitch).

  As for evaluating the impact - only you can really assess that: the migration wizard will convert your code, but won't replace it with a .NET equivalent (a splitter bar, for example). Youre best bet is to take some time to play around in a structured fashion and see for yourself. There are some documents which help migration - the help files that are installed with .NET have a section regarding VB6 migration.

  
  
  

• Srey

  SJWhiteley
  
  only a little question. I have not well understood (my english is not perfect...): you mean that
  

  • there are .NET features that are 50% more efficient than the correspondent in VB6, or that
    
  • .NET has features that VB6 does not have

  Are there exampes or articles about these "power features" to help me to evaluate their impact on my application
  
  Thank you very much
  Degia
  
  
  
  

• Blaze_wardog

  The upgrade from VB6 to .Net is not painless. The damages can be mitigated if you make some changes to the VB6 before starting (not using late binding, avoiding default parameters, etc.) Some elements will eventually need to be re-written, particularly your ADO 2.x code to ADO.NET. Additionally, there are a number of areas where you won't see performance improvements until you switch over to the .NET way of doing things. One example would be switching from the FileSystemObject in the scripting runtime to System.IO. If you decide to migrate your solution to .Net, you should read the white paper at http://msdn.microsoft.com/vbasic/default.aspx pull=/library/en-us/dnpag2/html/VB6ToVBNetUpgrade.asp.

  Why would you want to migrate It depends on your solution. Contrary to the marketing message, .Net is much more than web services (you can use SOAP in VB6 with the SOAP Toolkit now). Some reasons would be:

  Vendor support, Including Microsoft and 3rd parties.
  Substantial additions need to be made to your code base.
  Wanting to take advantage of new controls/language features.

  I would not recommend the migration if there are no enhancements. An app that is simply in maintenance mode can be left there. If necessary, you can build COM wrappers for existing code and use it in .Net. This allows you to migrate your application in pieces rather than all at once.

  Jim Wooley
  http://devauthority.com/blogs/jwooley

  
  
  

• andryuha

   

  Degia, this is an age old question and professionals agree that if your current application is functioning well and meeting your current needs and appears that it is adequately scaleable to meet your projected needs, then there is no need to upgrade.

  However, lets say Access would no longer meet your needs and you saw a technical need to upgrade to vs2005, then I would do that. You say your old app "works good". "If it's not broke, don't fix it."

  On the other hand vs2005 supports multi-cultural issues much better than VB6 did. And I really support your plan to learn modern approachs.

  Few PCs have the V2.0 Framework and Microsoft has done something brilliant to address that. Deloyment involves automatic network installation of the framework on a per PC basis. I believe there is reduced support on win98 but it will run and I think things are OK on ME but that's just a guess. (It's not informed by much).

  When I said, "... better to actually migrate your older code into a new app framework" I meant, sometimes, depending on what you code presents....it's better to start a new VS2005 project and cut and past old code piece by piece into the all new app.

  Lastly, I've just gotten to the point that I just plain feel more comfortable with VB2005 code. But I also know that everytime I push the button on my vb2005 player, that it's going to do something quite supportive and rather nifty. :)

   

   

   

  
  
  

• The Undead

  "The damages can be mitigated if you make some changes to the VB6 before starting"

  I really have to agree with this. You can make things much better on your conversion by turning Explicit ON... and insuring that the application compiles and runs.

  I'm usually very good with declarations but some of my more painful vb6 conversion moments were the rare times when I did not declare a datatype.

  The is one of the more noticeable source of errors in conversion.

  
  
  

• coolbho3000

  Thank you ReneeC
  
  So. First question: what I am looking for....
  My old application in VB6 works good.
  The new application has to be quite similar to the old one, but this time I need to localize it in different languages, and the old application has not been developed using resources.
  So, I think that there will be some work to do also in VB6.
  And so I thought it could be the right chance to learn and use more modern tools.
  Also, in VB6 I use Access databases, and I think it could be good to use SQL server 2005 express instead. (...Even if I read an article about using SQL server 2005 express in VB6...)
  
  
  Second: my colleague also told me that a lot of PC do not have .NET framework, and that older PCs based on Windows 98 and ME do not support .NET. Is it true
  As my client application has to run on different PCs on a network, and I am not sure now if they are all based on Win2k or WinXP....
  
  
  Third point. What do you mean "...better to actually migrate your older code into a new app framework". What does it mean "to migrate"
  
  Last: if you think there are some good reason why I should use VB2005, please let me know them.
  
  Thank you
  Degia
  
  

• Ramesh Anna

  Degia,

  It's really hard to say without seeing your code.

  One question is always, why are you upgrading to begin with What do you hope to gain Is your current application functioning as you need it to function

  What is the nature of those errors The conversion process is "noisy", meaning is generates lots of warnings that are just warnings. There is VB6 syntax that is no longer legal and often it's just a matter of changing syntax.

  And you might do better to actually migrate your older code into a new app framework than to attempt a conversion. I believe but I'm not sure about this, if you convert, you're always going to need the VB6 runtime libraries. If you migrate, you'll only need to rely on the Common Language Runtime.

  Unfortunately, I can't be more specific than this.

  
  
  

• Craig22162

  I agree with Renee.

  I, also, have a lot of applications in VB6. If they need changing with feaures added, it'll be done in VB6. If it is a new component or program, it's done in VB2005. I use the conversion process to 'see how things are done' - but even so, there are .NET features which can 50% or more of some VB6 code (wohoo!).

  Develop a migration strategy.

  Keep VB6 around as you learn to be productive in VB2005.

  
  
  

• Chakri

  My folder structure is:

  D:\Projects

  With all the VB/VC projects

  and

  D:\Projects2005
  D:\Projects2005\Samples
  D:\Projects2005\Test

  The Test folder has 38 sub-folders (and counting!) for my test projects, for only 3 'real' projects .

  
  
  

• soum31995

  I follow SJ around and say, "I agree with SJ". He follows me around saying, "I agree with Renee."

  However I found your comments interesting SJ. I have tons of VB6 code. I wrote one VB6 mp3 players that I haven't converted because I didn't want another career. I do maintain that in vb6. This project was large enough that it began to illustrate how larger VB6 projects really can help you paint yourself into a corner.

  But other smaller utilities, I have migrated to Vs2005 and have been glad that I did.

  I've done pretty much what SJ has suggested. My migration strategy has been o convert "small" and to let "large" be.

  One nice thing is that I very rarely ever have to open up VB6 these days.

  This week I did something that was beyond symbolic importance

  My Original Directory structure was

  Code

  |

  |

  V

  All VB6 Code

  Then it was:

  Code (Main directory)

  aVS2005 (Subdirectory)

  |

  |

  V

  All VB6 Code

  This week it was

  Avs2005 (Main directory)

  Code (Main directory)

  And I never open the code directory anymore. :)

  
  
  

• JeffD-MDX

  Hehehe... your folder structure hmmm

  Mine is really complex. and very tidly.

  Yes, I have a samples directory full of sub folders and a Utilities folder.

  I too have one folder that has large projects. There are perhaps eight...with three very serious projects. That's hallowed ground.

  
  
  

• Waxdoll

  I really thank all of you.
  After this day I don't know if my ideas are more clear or not, but I have a lot of advices I can think of...
  I will evaluate all of them one by one, more slowly, and then I will decide what to do.
  
  I have also read in this forum a long messages exchange regarding Access Vs. SQL server 2005 Express, and this will also be a good thing to think on...
  
  My last ( ) question: is it possible to convert an Acces database to SQL server 2005 express
  
  
  Bye
  Degia
  
  
• I really need a piece of advice...