VbClassicMigrationConcerns is a page on getting VbClassic applications reimplemented to run on machines hosting MicrosoftWindows OS.

As most of the VbClassic applications are clientServer type applications, the information discuss here may not apply to situations where other uses of VbClassic was deployed in other ways (e.g. in ActiveServerPagesInVbClassic).

Another assumption of this page is not to use (often quite good) OpenSource tools. Quite often, SystemsIntegration complexities of a hybrid solution are a major concern.

''Assumptions for an EnterpriseApplication solution''

The "migrated" application should have a reasonable chance of being compatible with WindowsLonghorn, but it is not necessary to use any new WindowsApi.

If the application uses data (most do), an acceptable solution will probably have its data hosted in a SqlServer database.


'''''WorkInProgress'''''

----
'''MicrosoftWay approach to migration'''

MicrosoftWay is to use the most recent release of their product. At this writing, it meant the yet unreleased DotNetFramework WindowsForms using VbDotNet or CsharpLanguage.
* WebForms is actually favored by MS over WindowsForms. However, there will be a greater adjustment by endusers if WebForms are to be used.
* Please note there is a bias favoring use of CsharpLanguage in Microsoft material. However even in VisualStudioWhidbey there are cases where VbDotNet can be (perceived to be) a more suitable tool than CsharpLanguage.

An Apr05 application migration strategy can be found at http://msdn.microsoft.com/vbasic/default.aspx?pull=/library/en-us/dv_vstechart/html/appmigrationstrat.asp.

For simple cases, a MicrosoftExpress solution may suffice. If this applies, the applicable paper (2003 paper migrating to AspDotNet) is located at http://msdn.microsoft.com/asp.net/migration/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-movingvbtoaspnet.asp

----
'''Other ways that are Microsoft friendly'''

RichInternetApplication implementation using MicrosoftDotNet

----
'''Other ways MS (and your manager) don't want to know''' (conspiracy?)

* PythonLanguage 
* RealBasic

----

What is all this talk about future MS OS's busting VB6 applications? If a new OS cannot run VB6, likely it won't run a lot of other existing things also. With Linux eating into MS's market share, I don't think MS would really risk pissing off that many people. I think they are bluffing.
* Microsoft typically don't bluff about breaking compatibility. They did it more than once to their OS when it served their purposes. They may have put away an unreleased safety mechanism in case user resistance becomes too expensive to manage.
* In WindowsXp SP2 already there are new APIs introduced in the name of security. I am speculating one way to rid VbClassic apps is for InternetExplorer (7) to break the HTML component used by VbClassic 6, making it necessary for a rewrite once IE7 becomes widespread.

----

CategoryMicrosoft CategoryEnterpriseComputingConcerns