An Open Letter to the Community


Author’s Note:  Earlier today, I sent the attached note to each of the MVPs who signed the petition around VB6. Please let me know what you think.

 

I noticed that you signed the petition at http://classicvb.org/petition.  I’m mailing each of the MVPs who signed the petition directly in hopes of continuing this dialog and giving you some more insight into what’s going on with VB these days. 

 

There was a great deal of discussion around the issues raised in this petition back in 1999 and 2000 when Microsoft initially announced the design of Visual Basic .NET.  Some of the input that we received from the MVPs and the community changed this design significantly.   One debate was whether the Visual Basic language should evolve to target the .NET Framework.  Many of our VB customers felt they had reached the limits of what VB could do and were looking for more – better security, deeper access into the core Windows platform, easier leveraging of skills for building Web applications. After looking hard at the VB runtime, Microsoft made the decision that managed code based on the .NET Framework is the future strategic direction for development tools.

 

We took a lot of feedback when we made this decision and didn’t make it lightly. The MVPs have continued to give us a tremendous amount of feedback.  Much of the way that Visual Basic 2005 looks today is due to feedback that we got from MVPs about features like Edit and Continue, Design-time Expression Evaluation, and the overall simplification of the development environment.  The discussions on the MVP mailing list are sometimes heated, but this debate and feedback is what has led to the product that we are shipping later this year. 

 

We remain passionately committed to helping Visual Basic developers leverage their skills and solve new challenges using Visual Basic .NET and Visual Basic 2005.  Many MVPs have told us that migration is a difficult task for some types of code.  In response to that, we’ve concentrated on first helping developers to upgrade their skills.  Later this month, we’re introducing a “VB Upgrade Center” as a part of the developer center on MSDN.   We are also hosting a number of free training events worldwide and a pre-conference before TechEd focused on the Visual Basic 6 developer.  I welcome your input on how we can work together to continue to speak to Visual Basic developers.

 

There’s also been a great deal of debate around the end of mainstream support.  To clarify, this is a switch from free to paid support.  Many of the questions around support have been thoroughly addressed in the blogs and the current information is available at http://msdn.microsoft.com/vbasic/support/vb6.aspx.  Soma also addressed this in his blog at http://blogs.msdn.com/somasegar and linked to other comments on this. However, I want to highlight to you that Microsoft is still supporting Visual Basic 6 and will continue to for quite some time.  In fact, the Visual Basic 6 runtime is slated to ship as a part of Windows Longhorn, which means that it will be covered under Longhorn’s support lifecycle.

 

There are strong feelings on all sides of the issue that sparked this petition and I know that this note is not going to address all of these concerns.  However, I hope that we can continue to have an open dialog around this issue.  Some of these discussions will continue in the public forum, but please also feel free to contact me directly.

 

Best,
Jay

 


Comments (66)

  1. Hi Jay,

    Thanks for your email. I’d like to take the opportunity to respond publicly, if I may:

    As a commited developer of Office-based applications, I’d like to extend this discussion to include VBA, as the petition does.

    The issue is *not* about whether or not VBA is included in Office, or ‘supported’ in the sense of being able to contact Microsoft about it (I call this ‘passive support’). The term ‘support’ in the context of the petition is a much wider definition of ‘active support’, and means the ongoing improvement of the language and tools as well as supporting the users of those tools in adapting to new things.

    Nothing has happened to the VBA language or IDE since Office 2000, so I don’t think either VBA or VB6 has been *actively* supported for many years.

    The point is that only *now* is Office-based development on the cusp of a VBA->.NET transition and we are extremely fearful of how that is going to be handled by Microsoft.

    The VBA programmer base is radically different to either VB6 or .NET developers – they are typically not full-time programmers and do not think of learning a new language as something that’s tied to their careers.

    In my opinion, the attempt to migrate those VBA developers and their code to .NET is going to require a radically different approach than that used for VB6, and it’s the future sales of Office that is at stake.

    I think we all agree that it would be financial suicide for Microsoft to remove VBA from Office until the vast majority of the market has made the transition to .Net – without it, companies just wouldn’t buy the VBA-less version.

    So the question is how to get the existing VBA developers to use .NET, initially as well as, and ultimately instead of VBA?

    I believe that they will stick with what they know for as long as they can, so the only way to get them to change is to gently nudge them in the required direction in very small, incremental steps.

    If .NET is introduced to Office such that there are separate IDEs and VBA and .NET, all the existing developers will remain where their code is – in the VBA editor – and .NET will forever remain an irrelevance (just as much as the Microsoft Script Editor has been an irrelevance since Office 2000 – largely because it’s a separate IDE).

    The only way to get VBA developers to start using .NET is to introduce it to where they’re working – in the IDE they’re using for their VBA code. The only way to do that is to create a single IDE that supports VBA and .NET together. VBA developers will get comfortable with the IDE while working with their VBA code. It is then only a very small step for them to look at .NET and start creating hybrid VBA/.NET applications (particularly if all the interop issues are handled by the IDE). Over time, it’s reasonable to expect the percentages of VBA vs .NET code in an application to change in favour of .NET, until VBA dies a natural death through lack of use.

    Getting back to VB6, creating a combined VBA/.NET IDE is going to require overcoming a number of technical hurdles – but those are *exactly* the same hurdles that would need to be overcome in order to actively support VB6 as well (apart from the forms engine).

    I think even the most die-hard VB6 enthusiasts (Karl?) would agree that has this route been taken at .NETs inception, the adoption of .NET amongst the VB developer community would have been much, much higher.

    So that’s why I signed the petition. I’m emploring Microsoft to do it right for VBA and the future of Office sales. And once you’ve overcome all the technical hurdles to actively support VBA, follow Coca-Cola’s lead and go the extra mile to bring the millions of VB6 developers that have yet to adopt .NET back into the fold.

    Regards

    Stephen Bullen

  2. Jim Mack says:

    In continuing to focus on VB.NET, you’re side-stepping the issues that really matter.

    .NET, I think we can agree, is a fine platform and is, if MS decides it is, the future. Do the VB.NET team want reassurance that what they created is good and valuable in its own right? You have it — it is.

    But the petitioners are not talking about VB.NET, except peripherally. The main issue is the vast amount of VB6/VBA code — the valuable data assets of your customers — that MS is cavalierly declaring obsolete.

    It is generally considered — viz the posts by industry experts and the stated position by MS not to offer an improved conversion wizard — that ‘porting’ VB6 code to VB.NET is pointless, because in the end a rewrite is needed to take advantage of the radically different platform. So, given that .NET is the future, what the petition asks for is not outrageous.

    I would never ask that VB.NET be dropped, denigrated, deprecated or deloused. That isn’t necessary for a VB6 follow-on to succeed, and to be valuable in introducing — on their own terms and in their own time — legions of VB6/VBA programmers to the .NET future. It doesn’t have to be an either-or situation, and _that_ is the spirit of the petition.

    I again encourage all to read the actual petition, and the related FAQ, and ask yourself how Jay’s or Soma’s posts address the real concerns expressed there, here, and by many VB users in various forums. Ask what happens to your company when MS one day decides that the data you value, has no value. Don’t kid yourself — you have no protection and apparently no recourse.

    Well, unless you’re using FoxPro :-)

    http://vb.mvps.org/vfred/Trust.asp

  3. As far as I know, the MVPs were not even aware of the nature of VB.NET until the beta of it was released at PDC in 2000. After that date, the only design changes made in the 1999/2000 timeframe as a result of MVP input were the famous "beta 1 rollbacks". These consisted of the following

    1. Making And and Or bitwise instead of Boolean, and creating new Boolean operators with new names

    2. Making CInt(True) equal to -1 instead of 1

    3. Adding the Tag property to all Winforms controls.

    These in my view do not amount to a significant design change. It was also loudly pointed out to Microsoft at the time that these token changes (which is what they were) did not even approach being enough to make conversion of large VB6 projects to VB.NET a practical proposition.

    I have no problem with the idea that the VB6 runtime was getting frayed at the edges and that you wanted and needed a new platform. But what Microsoft forgot is that high-level languages exist to insulate source code from the effect of platform changes. Discussions with Paul Vick and others make it extremely clear to me that they do not understand this distinction, they treat the platform and language as an indivisible whole, and that changes to the platform both necessitate and justify further changes to the language. This means that even if I were to move any of my code to VB.NET, it appears extremely likely that I would be faced with yet another rewrite in the not-too-distant future. Your own documentation says as much. If I were (with significant effort) to use the migration wizard to port VB6 code to VB.NET, it would be making heavy use of the VB6 Compatibility library. But reading the VB.NET documentation, I find the following:

    "Caution Functions in the Visual Basic 6.0 Compatibility library are provided only for use by the upgrading tools. Although it is possible to use this library when writing new code, there is no guarantee that it will be supported in future versions of Visual Basic."

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconthevisualbasic60compatibilitylibrary.asp

    In that statement, you are telling me that even after I have ported and rewritten to get to VB.NET, I’m probably faced with another rewrite in the near future in order to eliminate dependency on the VB6 Compatibility library, which still contains features not duplicated elsewhere in VB.NET. Why should I bother?

    If you believe that "features like Edit and Continue, Design-time Expression Evaluation, and the overall simplification of the development environment" are what is most wanted, then you have only been hearing what you wanted to hear. The problem is not the complexity of .NET, and VB developers do not need to be talked down to as if their IQ is 20 points below the national average. The problem is how to get existing VB6 projects onto currently supported platforms and development tools. Until you have cracked that one, no other improvements in Visual Studio.NET are of the slightest interest.

    You have said "We remain passionately committed to helping Visual Basic developers leverage their skills and solve new challenges using Visual Basic .NET and Visual Basic 2005. Many MVPs have told us that migration is a difficult task for some types of code. In response to that, we’ve concentrated on first helping developers to upgrade their skills."

    So, on being told that migration of code is difficult, your immediate response to to talk about upgrading skills. Doesn’t that strike you as aiming for the wrong target? If you want to address the difficulty of migrating code, why not do something to make migrating code easier?

    The ending of support in terms of the two free phone calls is a red herring, and it is about time you stopped trying to find ways of avoiding listening to the real problem. The two free phone calls are way down the list of priorities. There are two reasons the petition is happening now

    1. We have tried and tried to get through to you in private about code migration, but nobody has been listening.

    2. The loss of support further increases concern that VB6 programs will be adversely affected by changes in key OS files. After all, that has already happened with Windows XP. You fixed it in a service pack, but once VB6 goes off support altogether, would you still bother?

    The Format() Function Gives Different Results in Windows XP Than in Windows 2000

    http://support.microsoft.com/?kbid=321047

    I’m afraid that your note has not yet started to address my concerns, because your note does not give me confidence that you have grasped the nature of those concerns. As far as I can tell, Microsoft has not been taking feedback from those who have expressed reluctance to move to VB.NET, has characterised all comments about the difficulty of migration as being anti-.NET, and has only been interested in comments from people who have already moved.

    Recent published surveys indicate that 4 years after it was superseded, VB6 is still more widely used than VB.NET. That suggests to me that you have comprehensively failed to understand the concerns of VB6 developers and application owners, and have not targeted your development efforts towards their needs. The petition was an attempt to bring this fact to your attention.

    The detailed proposal in the petition should be regarded as a short-term item. Extending support and bringing out another version of VB on COM would buy some time in which you could reconnect with the VB developer community, and work out a longer-term strategy for bring VB6 and VBA development to current platforms and development tools. If you are seriously interested in pursuing that long-term strategy, then I am sure that you will have all the co-operation you could wish for from the MVPs and the developer community.

    Just realise that in order to successfully interact with the developer community, you need to accept that they treat their own source code assets as being as valuable as you consider your own source code for Windows and Office written in C++. You will not regain the trust of the developer community unless and until you take actions that show them that you understand this and will remember it in future. Yes, doing this will be difficult and will take time, as Paul Vick mentions in his blog ruling out any possibility of it. But unless you make the effort and are seen to make the effort, you won’t regain that trust. You may have noticed that the MVPs who signed the petition include a number of MVPs for .NET products and languages. You can safely assume that they have signed in order to prompt you into understanding the need to preserve all customer code assets including .NET assets, and that unless you do something about reconnecting with VB6 they regard their own code as vulnerable.

  4. Paul Vick says:

    Jonathan,

    I find it it surprising that, given your usually elephantine powers of recall, you are suggesting that the compatibility namespace will be "going away." As you should remember, you asked me directly about this a little less than a year ago, and I replied, in part:

    ***BEGIN QUOTE***

    I tracked down who was directly responsible for this documentation and we worked on some edits. Although I haven’t seen the final text, the new note should read something like:

    "NOTE: Functions in the Microsoft.VisualBasic.Compatibility namespace are provided primarily for use by the upgrading tools. Although it is possible to use functions in this namespace when writing new code, their use are discouraged in favor of using functions in the Microsoft.VisualBasic or System namespaces."

    We’d discussed removing the note entirely, but we felt that it was worth retaining because the Compatibility namespace was explicitly designed as a bridge to get from VB6 into the Framework, not to replace the Framework itself. As such, when new functionality is added to the Framework, the Compatibility classes will likely only updated if that new functionality directly impacts conversion from VB6. Since the future development focus is going to be on the Framework, we feel it is best to encourage people to move off of the compatibility classes over time. However, what I just said seemed a bit wordy to put into the note.

    You also privately raised the issue of support. Libraries we ship are covered under a well-defined deprecation process. You can find more information about it at http://www.gotdotnet.com/team/changeinfo/v2.0/obsoletefaq.aspx.

    ***END QUOTE***

    So, the answer is, no, we are not "telling me that even after I have ported and rewritten to get to VB.NET, I’m probably faced with another rewrite in the near future in order to eliminate dependency on the VB6 Compatibility library, which still contains features not duplicated elsewhere in VB.NET."

    Hope this helps.

  5. Paul,

    That’s a very interesting set of comments. You might also recall that you promised to change the particular piece of documentation I referred to (you didn’t) and you promised a white paper on Microsoft policies for language stability (it never appeared).

    Now, if after those broken promises, and lack of public confirmation of private statements, even though you were occasionally reminded over a period of a year or so, would you like to explain to me why I should regard a page on gotdotnet as taking precedance over Microsoft’s official documentation in the product and on the MSDN website?

    I would also be most interested to hear your views publically stated about your understanding of the linkage between languages and platforms, and whether you regard a change of platform as justifying changes in language syntax that are not strictly necessary for platform compatibility. For instance, looking back, do you think that the additional changes you made to VB.NET were a good idea? When the next platform change comes round, would you like to take the opportunity to change the languages some more?

  6. RBL says:

    >>> and you promised a white paper on Microsoft policies for language stability (it never appeared) <<<

    I think developing, publishing, and maintaining a document such as this would be a responsible move on Microsoft’s part. It’s crucial information for developers, and is sorely needed.

    RBL

  7. BenB says:

    I understand the need for moving to .NET. I enjoy .NET and think it is a huge leep forward and I assert that it is nearly impossible to state that the .NET framework is not a leap forward from the days of Visual Basic 6.

    That said, I personally have spent years working with VB and spent many man years building not only business systems but also commercial products in VB. For anyone that has only a small view VB can be looked down upon, but for those of us that have actually used it, there is very little practical results that cannot be done. A look at Advanced Visual Basic 6 by Microsoft’s own Matt Curland proves this as well as work done on sites such as vbAccelerator and others.

    The real issue here is not keeping new platforms and means of achievement from coming forth, but rather the move to this and the choice to do so.

    I personally do not care about the so called support – as stated above, I consider that to be passive support. I rarely have needed to contact Microsoft about things for which I cannot find on the web somewhere or via finding work arounds.

    What Microsoft has done is FORCE its new platform onto us VB developers if we want to continue to use the language of VB. A primary issue I have with this is that I am also forced to bundle a 21 MB runtime with this and or worry about whether users have this… 21 MB even with the high speed internet today is no small amount. I remember when the 2 MB VB6 runtime was almost prohibitive… but 21 MB? No one can argue and say that it is on most machines, as it is not. In the real world, it is simply not. So now we are forced to put it out there, and also forced to hope we do not lose sales, drive up costs with downloads and that people are patient enough to wait.

    VB6 was primarily used as a client side system… That is not web based. Sure, you could use it to create DLLs to run on a server but I would argue that the primary usage of VB and its RAD nature was for the client. That is where VB really shined. That means people/ clients, not servers need the runtime.. and now we are back at that 21 MB download…

    I do not accept that we should wait for longhorn when it may or may not be included… or even an SP.. Then Microsoft should wait until that happens.

    I take one look at Delphi – which I have had to use on and off over the years – and how they have handled the upgrades and the needs of developers and I say, wow, wy can’t Microsoft handle it like this. That is, have all of the .NET functionality, but then also have the ability to compile to the plain old Win32. Am I to believe that Borland has better people or is simply smarter than Microsoft? Or do they not have some alterier motive? Or do they just get it and Microsoft doesn’t?

    The fact is, moving forward is a good thing. I like VB .NET as well as C#. But it HAS NOT BEEN READY for prime time on the client. On the server, great, it is easy to deploy a runtime, but on the client for which VB6 was great… we have been robbed. Controls we relied on are not there, the upgrade method is not there. Simple GUI methods have not been ready, such as much of XP themes or the ability to implement them. Oh sure, you can say off hand that VB6 did not have this, but almost any VB6 programmer worth his salt can do this – again look to vbAccelerator.com if you must see.

    .NET is great on servers and has been… on the client at least until 2005 arrives it has not been client friendly in any way from moving code to even simple GUI creation. We are still left then with distributing the runtime. What are we supposed to do about that??? Wait until Longhorn or 3 years until most people do have it? That is not feasible which is why people are looking to platforms that are already installed or out there, or things like Delphi or just staying with VB6.

    Microsoft has expoused the fact that .NET offers choice, choice of language and such. That is great… but what about our choice of when to be forced to move. We are forced to stick with something that is not actively supported wth new functionality or to use something that our users have to ship 21 MB runtime..

  8. Ananda Sim says:

    Doubtless, new tech takes over old tech. VB.NET is substantially more powerful and the .NET framework has more features than classic VB, VBA, VBScript.

    But there are gross business and human problems that have so far not been resolved successfully. This is hurting developers, businesses and consequently, Microsoft.

    1. VB.NET is not encapsulated in Office documents. And VBA has been left out in the cold.

    2. .NET deployment has not successfully penetrated all corporate and non corporate machines. We can’t use what is not there.

    3. VB.NET is really OPTION TIRESOME – there is so much tedious coding carrying out explicit variable type specification and conversion. It is not true that 80% of the users (as opposed to geeks) need that discipline. VB.NET culture is substantially different from VBA culture.

    We need a "big bang" to happen. Like another Alan Cooper to come up with a new Tripod/Ruby.

    http://www.johnsmiley.com/visualbasic/vbhistory.htm

  9. Monte Hansen says:

    My response to Jay’s message sent 3/17/2005

    Monte Hansen – Visual Basic MVP

    ——–

    Hi Jay,

    It’s great that you are trying to reach out to the MVP community directly (but I don’t think it’s going to help =).

    FWIW I think the VB.Net team did a fabulous job on the IDE and I especially love what they did with VB# as a language. I believe that it was the right thing to do for the (future) sake of the language (syntax, not so much for the managed VM). I dig OO as much as the next developer. But all that at the expense of huge masses of VB code in favor of VB# is a monster of a leap. It’s a slap in the face to developers and customers that have supported you over the years too. For that reason I’ll never use VB#, and also because I cannot trust that Microsoft will make the right choices concerning language stability. I get more warm fuzzies with C# in that regard, however it’s not much of a consolation prize for most VB developers/shops.

    I work for a company ranked #1 by Information Week for innovative uses of technology (not a gloat, but to give you an idea of it’s code assets). This company had volumes of VB/ASP code for their applications and business logic. Like Microsoft, they must plan the implementation of their strategies years in advance. Suddenly they are faced with making a choice of porting 10 years of code and adopting a risky unproven framework as its backbone. Or, they can move away from Microsoft driven technologies and tools altogether. Can you guess what they chose? Can you blame them?

    Honestly, I thought Soma’s March 16 response to the community was a joke. Public relations bull**** that does nothing but patronize and insult the intelligence of the developer community, your customers, and me, your Visual Basic MVP. You can try to help with all the little do-dads meant to "ease the migration" but most see them for what they are – a PR token for executives to throw around. It’s bad enough to sunset the language (which tells VB developers that their jobs are at risk), but to kill (free) support for it sends a “last call” message to your customers. The spirit of your actions say "See ‘ya, wouldn’t want to be ‘ya; but hey we support you". You can decorate it all you want, but that’s the message you send – and your message affect jobs, and job markets. It also affects the spirit of your MVP’s that unofficially represent you.

    I’m very disappointed.

    Respectfully submitted,

    Monte Hansen

  10. Responce to Jay’s message sent 3/18/05….

    >We took a lot of feedback when we made this decision and didnt make it lightly. The MVPs have

    >continued to give us a tremendous amount of feedback. Much of the way that Visual Basic 2005

    >looks today is due to feedback that we got from MVPs about features like Edit and Continue,

    >Design-time Expression Evaluation, and the overall simplification of the development environment.

    >The discussions on the MVP mailing list are sometimes heated, but this debate and feedback is

    >what has led to the product that we are shipping later this year.

    >

    >We remain passionately committed to helping Visual Basic developers leverage their skills and

    >solve new challenges using Visual Basic .NET and Visual Basic 2005. Many MVPs have told us

    >that migration is a difficult task for some types of code. In response to that, we’ve concentrated

    >on first helping developers to upgrade their skills. Later this month, we’re introducing a “VB

    >Upgrade Center” as a part of the developer center on MSDN. We are also hosting a number of

    >free training events worldwide and a pre-conference before TechEd focused on the Visual Basic

    >6 developer. I welcome your input on how we can work together to continue to speak to Visual

    >Basic developers.

    Jay,

    This whole thing about better features and upgrading skill sets is just a ruse to deflect attention from the key issue. The debate is now and has *always* been about migrating to the new platform the existing code base owned by the VB community rather than being about features and upgrading the skill sets of VB developers.

    Microsoft has left no *viable* avenue for migrating the existing VB code base that doesn’t require extensive human intervention into the process. When viewed practically, this "intervention" amounts to completely rewriting most of the existing code which, in terms of the time and expense that would be required, makes migration totally unfeasible for most owners of existing VB code. Given this, the current situation equates to the willful destruction by Microsoft of the precious data belonging to it’s VB customers.

    What is needed to solve the situation is a means by which the VB community can migrate their data to the new platform at an un-forced pace using fully supported and up-to-date development tools for the job. The avenue suggested in the petition would accomplish this goal by allowing the existing code base to be compiled "as is" from within the IDE of the new platform. From that point, the VB developer could migrate their code to the new platform in an orderly manner that makes sense for *their* business rather than the "from the ground up" rewrite that is currently being forced by Microsoft if one wants to get existing code into the new IDE.

    There have been a lot of arguments floating around that take the form of "VB6 isn’t going away so why not just keep your code in VB6?". There are a myriad of reasons why that argument doesn’t fly and rather than re-hash them all here, I’ll refer you to the "Myth Busting" section of the petition’s FAQ document (http://classicvb.org/Petition/faq.asp).

    I do appreciate your desire to continue the dialog about the situation and hope that you and the rest of the Microsoft representatives involved are sincere in this desire. All that will be required for a successful resolution for all involved (including Microsoft) is for Microsoft to acknowledge the fact that maintaining the value of existing data assets is *paramount* in the transition to the new platform and then produce the tools necessary to allow for the orderly migration of that data. One thing of which I can assure you is that supplying VB.NET and saying, "There it is, here’s how you use it, now go rewrite your code." will *not* be an acceptable solution.

    Sincerely,

    Bryan

  11. Piotrek says:

    Come on classic vb6 supporters… that’s at least 3 years I knew that VB6 would disapear, I’m not a MVP, I’m just (well I was) an average VB6 developper. I did not had a privileged access to new, articles, meetings, technologies as you did

    I did VBA, VB and ASP exclusively for 10 years. Last year I started to migrate to VB.Net

    I had the intuition that it will propose the improvements I was starving of: I know you are starving of innovation too

    I read the FAQ of the petition very carefully: that’s plenty of good sense… I begun to ask myself questions: why?

    You have plenty of code that’s running in vb6, me too: that’s not a good reason

    Migrating code is nonsense, I agree. But the idea is to re-think your code, improve it. It can be done, I did it.

    VB.Net is so powerful you can’t imagine how… wait… perhaps you had never experiment that power at all, because logically: if you experiment VB.Net correctely, you can’t go back: you love it

    Here is my analysis of the facts:

    *** Microsoft made a mistake when it tried to mimic a vb6 in a full-OOP backgroud

    – Wizards, Conceptors, datasets are good productivy tools I agree, but they where presented as basic features of the language: FALSE, the only base is OOP (just at least to understand how to use efficiently the productivity widgets)

    *** Vb6 developpers made a mistake as they began to code in a vb6 fashion in VB.Net

    – they begun to mimic that way (like "ah yes, I must put a NEW statement before that thing") without understanding what they where doing…

    – they are are still thinking in a procedural way

    – they are still starting their code from a form

    Consequently:

    – You code like in vb6, and at a moment you are lost

    – You find VB.Net totally different (that’s false, only organisation is different, code is the same)

    – You find it not intuitive (just because you haven’t seen the simple basis)

    => In my opinion that’s the only possible reason you are still for vb6. Is it exact?

    If yes, here is my proposal to a (constructive I hope) solution:

    *** To Microsoft:

    – You still have to keep a free suport for a while, you see, a lot of people haven’t migrate yet, it will take some time

    – You have to a migration "Marshall Plan" in coordination with people that have succeed their migration (who see everyday the same questions and who have an idea about why other haven’t migrated to VB.Net as expected)

    – You have to explain what is OOP in an intelligent and practical way. For instance: not "Interface is a contract between a…" but rather "implementing an interface in a class will allow you to easily switch between two different classes, or threat two diffent classes the same way"

    – garantee that vb.net and C# will have the same abilities for the future (who wants to code in a 2nd importance language? vb6 coders are not just ugly-imaginationless front end to databases: refresh your memory on http://www.planet-source-code.com/vb/default.asp?lngWId=1 )

    – you need to reoganize MSDN articles, sothat people can follow a learning path

    ***To vb6 supporters:

    – Give VB.Net one chance: Just try to understand how VB.Net works (after reading the first steps of the "Marshall Plan") Just feel its power, how you can easily improve what you have done for years, what are the new possibilities (that you can sold)… belive me as a former vb6 developper: it’s awesome, incredible, wunderbar, szwitne… words are missing

    – Forget to migrate to anything else, in all cases it’s much harder to learn concepts and syntax rather than concepts only, you will even be able to migrate to java very quickely after you will understand VB.Net (Mr Roxe: I’m kidding)

    – Your speed will rise exponentialy. "Quality", "Stability", "Flexibility", "Re-use" will have a meaning, trust me

  12. Lawrence Gatlin says:

    I to am a single VB Developer. Most of my work is done at home after work hours. Our ISD department did not consider our division worthy of any development for Applications. I have tried porting by apps to the .net world and found that it would be easier to rewrite the code. But I don’t have the time to try to relearn or learn the .net. I have been trying to learn when I can. What I have seen in the VB.net I really like. But when you are working with both languages, you tend to get confused on which syntac to I use here!

    I have been working in the VB express beta1 and also Vb 2003. I am getting a better understanding of the .net framework. I have to keep my vb6 apps going with constant updates and upgrades. Beside my computer I use at work has to be Win98SE because of Motorola Dos software Issues.

    Maybe most of this don’t make a lot of sense, but Microsoft needs to keep us small people in mind. I have not yet used any phone calls or the like for any of the MS products I have. But when they throw out the end of support, it sends a message to all us. Anyone remember MS Basic Professional, or Microsoft Basic of the Mid ’70’s? Got forced to Visual Basic.

    Just my three cents(Inflation) worth.

  13. Philip Thomas says:

    Shame on you, Microsoft! First you took away my Windows 95 and now my Visual Basic 6. Shame on you, Ford! You took away the Ford T Model.

    Shame on you! I can’t fly in a 14-BIS anymore!

    If VB6 is all you can do, get a job as a bricklayer – they haven’t had much progress over the last couple of centuries. Programming is for people who know they have to keep up with the Joneses constantly and not for crybabies.

  14. Piotrek says:

    :)

    The problem is that there are 3155 babies and still counting, and that babies represent the sucess of .Net (and not almost-retired java developpers, neither C# aristocracy)

    VB6 developpers are smart people (like me :]) that make smart applications with just a couple of controls (like I did), give them feeding-bottle plenty of simple explainations, of basics of OOP and then desing patterns (so they will be able to understand and use more evolved patterns like Microsoft Patterns, as they where using ActiveX controls)

    I totaly agree with you Lawrence Gatlin, I work in a small business too. that’s why it have to be explained not to change vb6 way of thinking, but only to adapt it

    It took me a while to understand evidence, nothing exists on the net that explain OOP fundamentals for procedural vb6 developpers. At the moment I am not enough confident in myself to write that kind of articles (that’s only my 3rd week with fundamental desing patters), it have to be done by a mixed team of senior OOP developpers and vb6 developpers that are migrating.

    I am sure that in one week, 1 hour a day, you can prove by practice that VB.Net is at the same time so much powerfull, so much more exiting and so few different

    I’m sure that if you transpose the minds of vb6 developpers to OOP, you will have some fresh minds that will go further than trying to copy java ideas (Spring, nxbre…)

  15. Kevin Johnson says:

    <VB6 developpers are smart people>

    So, and why did they fail to wake up during the past couple of years? Those who fear progress, and .NET is progress, are nothing more and nothing less than losers.

  16. Larry Blake says:

    There are many good points above and I won’t repeat them. I’ll just give you a personal anecdote that is probably not unique.

    At my office, we use VB6 and ASP. We attended some .NET training, expecting that we would move to Microsoft’s newer technology, but instead we came away convinced that an upgrade would be costly, and therefore difficult to justify to management.

    The result is that now we have to consider competing technologies. If a significant redesign is inevitable, why not do it in, say, Java? What would that do for us?

    If VB7 had come along, we would already be there, still dedicated to Microsoft. Now…?

    As many people have said here, .Net is a good technology. But that’s not the issue. When Microsoft says we must spend time (and therefore money) changing what we’ve done in the past, that makes us angry. The product is still called "Visual Basic", and that should imply a commitment to previously loyal customers.

    I’ll stop now.

    LB

  17. Paul Vick says:

    Jonathan,

    >>> That’s a very interesting set of comments. You might also recall that you promised to change the particular piece of documentation I referred to (you didn’t) and you promised a white paper on Microsoft policies for language stability (it never appeared).<<<

    I apologize if I didn’t make it clear that the updates will first appear in the VS 2005 beta documentation and then migrate to the official MSDN documentation when the VS 2005 documentation becomes the official documentation. The current Beta 1 documentation doesn’t have the edit, which is not surprising given the timeframe. It should show up in Beta 2 documentation and, if not, then we should report it to make sure it’s fixed.

    Also, as you should remember, I said that instead of issuing a separate whitepaper on language compatibility, I was going to fold the topic into the general language specification. That specification will be released in beta form once Beta2 ships, although we’re close enough now that I can post it over on my own weblog and will do so…

    I think my views on platform migration and language stability have stated publicly pretty consistently…

    Paul

  18. Bob Riemersma says:

    The issue isn’t about whether or not people can successfully move to .Net development so much as why they would want to. Many have remarked upon the parallels between .Net and Java, and further that people looking to leave VB (not .Net) face the same issues they did years ago when they chose not to go the Java route.

    Just like Java, .Net has turned out to be strongest on and near the web server and weak on the desktop. Someday we might see something close to the "VB everywhere" (VB/VBA/VBScript) that empowered Microsoft customers come out of .Net but that’s probably somewhere in the beyond-Longhorn timeframe. VB/VBA/VBScript were significant in helping keep the Linux wolf away from Microsoft’s door – they had no equal in that world.

    In the meantime the entrenchment gets deeper. By not updating Visual Basic (we ought to be looking at VB8 by now if not VB9), VBA, and VBScript Microsoft may actually have impeded its market’s ability to move with change.

    There is no reason why we shouldn’t expect things like native multithreading support, NT service project types, and web services client and server project types in a COM-based, native code VB by this date. An option to compile for a more fully sandboxed runtime environment and a compatible form of component and IPC technology that "looks like COM" at the VB source level seems just as likely.

    In a way it’s amazing that a 3rd party alternative hasn’t arisen. That could have been Delphi I suppose, but so far things haven’t worked out like that. The key thing working against 3rd parties is probably Office and its VBA integration.

    I’m amazed myself though at the resources being spent on FoxPro in the midst of all of this.

  19. Paul,

    Seeing as how you are comfortable about the consistency of your public statements about platform migration and language stability, I’m sure you won’t mind restating them one more time for the benefit of those who have not yet seen them elsewhere. To give a structure to them in the present context, I would be grateful if you would answer the following questions.

    1. Who did Microsoft regard as the primary target market for VB.NET? In other words, which language’s users did you regard as the largest group of people who would come to VB.NET?

    2. You have told me in the past that you accepted that many of the changes in syntax and behaviour made in the move from VB6 to VB.NET were not necessary for the purpose of compatibility with the platform. Given this, would you please summarize the reasons you think those changes were a good idea?

    3. When individual non-platform-related changes were being decided on, what consideration was given within Microsoft to the effect on the ability of VB.NET to import VB6 projects?

    4. Do you regard a change of platform as an opportune moment to include non-platform related changes in language syntax?

    5. Would you regard it as appropriate to make changes on a similar scale in the future, if you took the view that benefits of the same kind were available?

  20. BenB says:

    I see the same few responses of sarcasm (you took away my Win95! Ford you took away my Model-T) and of course the get over it, and move forward.

    First, to those writing those comments – to me it appears as though either they have not been involved in in depth projects or b) are looking at it from simply a technology standpoint. I personally do a lot of ASP .NET development in C# and VB.NET. I also have done smart client projects using both as well… so it is not a learning issue to move my mental assets. VB.NET and .NET as a whole is clearly a better platform overall and therein lies the true problem.

    What about client deployment? It is not about migrating to me, I can understand that sometimes code needs to simply interoperate. Why fix something that is not broken? BUT what about NEW CODE? Specifically what about making a new, what now is called, Smart Client? As stated before the .NET runtime is not out in a decent percentage of machines! Not at all!

    What were we as developers left with for creating NEW PROJECTS? Take out the learning the new language – what are our options? To me it is more times than not an absolute deal breaker to have to ship a 21 MB + runtime. If you are making a commercial app – which in the past could have been done using COM and VB – what can you now make? How will you distribute it?

    I would like someone to give me an answer, from Microsoft, about this: I want to create a new Client App that gathers RSS feeds and sell it (plug in any app type you want). My users download it, some try it as a demo and then they buy it. Now, how likely is it that a user will wait for a 21+ MB runtime to download? Simply making someone download and getting them to install something can be tricky. Microsoft completely overlooked this group of developers and people.

    It is not just commercial software, or shareware or online software either. Now take that concept and apply it to people that dial in remotely or even VPN over the Internet which needs an app.

    Microsoft provided no decent in between… No decent means or where to go on the client. We are left to choose between a language that has not changed in years and is no longer a live product and a framework that is great but is on less than 50% of machines, and with a distrib size that makes is prohibitive. What is the current installed base, percentage wise, of non server PCs that have the .NET Framework version 1.1?

    I would like someone at Microsoft to address this issue – with an answer. I do not want to hear that it will be splipped into Longhorn or something like this. Are we supposed to shut down until then? I want to hear What are we as developers that paid Microsoft for a product supposed to do in the meantime??? What is a VIABLE option?

  21. Paul Vick says:

    Jonathan,

    Like I said, your questions have been addressed publicly elsewhere, multiple times. Besides the fact that they’ve been rehashed enough times as it is, this isn’t the place to rehash them one more time. Sorry.

    Paul

  22. BenB says:

    Paul,

    How about answering the other questions then listed by others such as what is a viable option for smart client development? % of PCs (non server) with .NET runtime installed? See the post titled "what about smart clients? " and answer a few of those then.

  23. Paul Vick says:

    There are some good pointers about framework availability at http://blogs.msdn.com/scottwil/archive/2005/03/09/391199.aspx, Ben!

  24. BenB says:

    Paul,

    Thanks for the pointer.. Sadly though it points to the fact that the numbers are not reliable, available nor predictable. In my experience it is less than the 58% noted nor does that in any way indicate version 1.1 availability as noted in the blog – stating it is not possible to get that.

    We are still left with the questions regarding version 1.1 availability? We do not know. We can certainly assume it is less than 58% noted for business PCs with 1.0.

    So this again makes me ask, what did/ does Microsoft expect client side/ smart client ISVs to do regarding building NEW apps? What is/ was the thought regarding the platform being there. I again state that we have had the VB6 "platform" taken away as a live product and forced to use a platform for which there is very little penetration and very high cost (both in terms of lost sales, distribution charge via bandwidth etc) to us as ISVs. So, what are we expected to do? Can anyone at Microsoft just admit that we, client ISVs and client producing consultants were left out to dry with this?

    Again I say that I like .NET, I like the platform as a whole, but the practicality of the transition is the area I want to get corrected.

    Thanks,

    Ben

  25. Paul,

    Is there some other place on the web where there is a summary of your views on the topic? Your blog doesn’t have one, nor a link to one. It’s a bit strange to say that you have "stated publicly pretty consistently" your views, but you don’t provide the means for people to find out what those views are.

    I know pretty well what your views are from the numerous private conversations we have had, but it would be improper for me to post extracts from those conversations without first obtaining your permission.

    Also, please realise that I’m not after your views about VB.NET specifically, I’m after your views on whether and how it is appropriate to modify language syntax. VB.NET is only relevant to this in that it happens to be the language you have been working on lately.

    By the way, it’s also worth pointing out that I’m not anti-VB.NET or anti-.NET in general. To be anti-VB.NET would be to wish on VB.NET developers the same fate that has befallen the VB6 community, with the discontinuation of the language leaving their code assets stranded. I would not wish that on anyone. I’m also not anti-.NET, because I accept the need to update platforms from time to time with new features and capabilities. My sole interest is ensuring that there are ways forward for existing source code to be compiled onto current platforms using current tools. That is what the change from VB6 to VB.NET failed to do.

  26. Monte Hansen says:

    Good point Jonathan. It’s worth pointing out and re-pointing out that VB#, the migration to VB#, and the support of VB are three distinct issues, and it would help to address them as such. I believe that a large portion of the VB community have accepted .Net (C# and/or VB# as their language of choice within the framework), myself included. Although it has nothing to do with concerns over providing a higher level of support of systems built in VB, and the tidal wave of a message it sends to their customers.

    I just cannot believe that VB is even in this position while FoxPro gets beefed up. Did I miss something along the way? When did FoxPro even come close to the scale VB has reached? BTW, you can’t even post to Rob Copeland’s blog on this topic since it goes to the bit bucket, er I mean it’s moderated — couldn’t send clearer message ;-).

    Monte Hansen – Visual Basic MVP

  27. Paul,

    Is that the Foxtrot, Rumba or the Cha-cha-cha your doing around Jonathan’s questions? Step up and answer the questions or at the very least, provide some links to where you’ve already answered them! Or, is there something about your answers that you would rather not state publicly now?….

  28. Monte Hansen says:

    Bryan, I think all the players at MS have been prep’d on how to avoid the hard questions, and confuse the issues, while still constantly saying buzz phrases like "support isn’t going away", "we are giving you Edit and Go", "we’re keeping the lines of communication open" …

  29. Ananda Sim says:

    The devil’s in the details. The stats indicate that MS is trying hard to deploy .net framework to as many machines as possible.

    The stats do not indicate how many % of production machines (in the area that _putyourname here_ operate in) have the .NET installed.

    The stats do not indicate how many machines are *NOT* Windows XP, with or without SP2.

    The stats do not indicate how many machines are under corporate control with the IS team diligently blocking out Office 2003 (for example) until they have enough budget and resources to roll out and migrate Office 97

    And the list goes on an on….

    There are also paradigm shifts.

    Whilst end users may commission Access+Excel+VBA or VB6+Jet solutions, because an end user does not realise what VB.NET is and that VB.NET is not native in Office, the IT dept may be the commissioner. This means if your customer is end users, you’re dead in water.

    There is also the dependency problem. If you have ensured .NET is deployed corporate wise, you may find that Office 2000 or Office 97 so pervasive that Office 2002 and Office 2003 don’t get a go. And if you want to use VB.NET to manipulate Office 2002 or 2003, you are again, dead in water. Don’t forget, there are wrappers and shims for .NET and Office interop to be deployed as well.

    If you have a desktop app, on mobile notebooks, it may be that Access+Jet would be great. If you have a sparse, long distance app, then ASP.NET would be better. But the person who commissions the former is not the same as the one who commissions the latter. For example, setting up a standalon webserver in corporate environs is a no no, whilst getting VBA going may be quite "Just Do It" culture.

    Boils down to, VBA, VB6 are currently viable solutions – it does not make business sense to discard them in 2005.

    Finding a difference: An old Japanese beer story. Panel of tasters are asked to taste beer from different breweries. They conclude – "it’s the packaging that makes the difference, there is no superiority in taste". Later on they find out that there is a difference in taste. It’s just that after the first glass of beer, you don’t really care.

  30. BenB says:

    Paul or anyone with Microsoft,

    Again, someone from Microsoft answer the question: What is an ISV (including shareware and online distributions) that has used VB 6 to make Windows Applications supposed to do when making new applications? What does Microsoft believe is a feasible solution given the lack of .NET runtime penetration? (Please note the runtime difference of 2MB for VB6 to 23+ for 1.1)

    Please respond to this.

  31. Andrew Bradley says:

    we have an vb6 application (ERP like) with around 350.000 code lines. the team development time was about five years. the abs value of our codebase ist ~450.000,00 EUR.

    Theres no need for vb.net liked features. and so i dont get the point wheres the benefit to upgrade to vb.net?

  32. Barak Cohen (Microsoft) says:

    <body>

    <p><font face="Verdana" size="2">We recommend ISVs that know VB6 to use VB.NET

    for targeting new applications due to the following reasons:</font></p>

    <ul>

    <li><font face="Verdana" size="2">&nbsp;<b>Modern tool</b> – VB.NET is a

    modern tool that enables the best productivity for the skill set that ISV

    already has (in VS 2005 it is particularly true). The modern tool enables

    delivering modern applications that can use XML, Web Services and populate

    nice and modern UI using Windows Forms. VB.NET is also much better tool for

    developing localized applications than VB6. </font></li>

    <li><font face="Verdana" size="2"><b>Distribution </b>- The distribution of

    the .NET Framework is a lot deeper than most people realize. Within the

    population of Windows XP computers in the US, more than 60% of the PCs in

    home and consumer premises have the framework already installed. Considering

    that more than 50% of the internet connected users in the US have broadband

    connection, and that internet connected customers tend to be the potential

    customers of the ISVs, the potential target market should be big enough for

    any ISV to deliver applications to. The situation is improving by the day

    since more than 90% of new PCs sold by the big PC manufacturers to

    businesses and individuals have the .NET Framework preinstalled.</font></li>

    <li><font face="Verdana" size="2"><b>Reality of download </b>- 5 years ago

    it took 8 min to download the VB6 runtime on 33Kbit modem. Today it takes 3

    minutes do download the 23MB of the .NET Framework runtime on a 1.5MBs cable

    mode. These numbers are only going to get better and deployment techniques

    are going to improve.</font></li>

    </ul>

    <p><font face="Verdana" size="2">I hear the call to provide more details about

    the .NET Framework distribution and I plan to publish some articles on MSDN in

    the next two month to address that need. </font></p>

    <p><font face="Verdana" size="2">If you have direct questions and issues about

    adoption and deployment, feel free to email me directly:

    <a href="mailto:barakc@microsoft.com">barakc@microsoft.com</a></font></p>

    </body>

  33. Barak Cohen (Microsoft) says:

    We recommend ISVs that know VB6 to use VB.NET for targeting new applications due to the following reasons:

    Modern tool – VB.NET is a modern tool that enables the best productivity for the skill set that ISV already has (in VS 2005 it is particularly true). The modern tool enables delivering modern applications that can use XML, Web Services and populate nice and modern UI using Windows Forms. VB.NET is also much better tool for developing localized applications than VB6.

    Distribution – The distribution of the .NET Framework is a lot deeper than most people realize. Within the population of Windows XP computers in the US, more than 60% of the PCs in home and consumer premises have the framework already installed. Considering that more than 50% of the internet connected users in the US have broadband connection, and that internet connected customers tend to be the potential customers of the ISVs, the potential target market should be big enough for any ISV to deliver applications to. The situation is improving by the day since more than 90% of new PCs sold by the big PC manufacturers to businesses and individuals have the .NET Framework preinstalled.

    Reality of download – 5 years ago it took 8 min to download the VB6 runtime on 33Kbit modem. Today it takes 3 minutes do download the 23MB of the .NET Framework runtime on a 1.5MBs cable mode. These numbers are only going to get better and deployment techniques are going to improve.

    I hear the call to provide more details about the .NET Framework distribution and I plan to publish some articles on MSDN in the next two month to address that need.

    If you have direct questions and issues about adoption and deployment, feel free to email me directly: barakc@microsoft.com

  34. Barak Cohen (Microsoft) says:

    <html>

    <head>

    <meta http-equiv="Content-Language" content="en-us">

    <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

    <title>New Page 1</title>

    </head>

    <body>

    <p><font face="Verdana" size="2">We recommend ISVs that know VB6 to use VB.NET

    for targeting new applications due to the following reasons:</font></p>

    <ul>

    <li><font face="Verdana" size="2">&nbsp;<b>Modern tool</b> – VB.NET is a

    modern tool that enables the best productivity for the skill set that ISV

    already has (in VS 2005 it is particularly true). The modern tool enables

    delivering modern applications that can use XML, Web Services and populate

    nice and modern UI using Windows Forms. VB.NET is also much better tool for

    developing localized applications than VB6. </font></li>

    <li><font face="Verdana" size="2"><b>Distribution </b>- The distribution of

    the .NET Framework is a lot deeper than most people realize. Within the

    population of Windows XP computers in the US, more than 60% of the PCs in

    home and consumer premises have the framework already installed. Considering

    that more than 50% of the internet connected users in the US have broadband

    connection, and that internet connected customers tend to be the potential

    customers of the ISVs, the potential target market should be big enough for

    any ISV to deliver applications to. The situation is improving by the day

    since more than 90% of new PCs sold by the big PC manufacturers to

    businesses and individuals have the .NET Framework preinstalled.</font></li>

    <li><font face="Verdana" size="2"><b>Reality of download </b>- 5 years ago

    it took 8 min to download the VB6 runtime on 33Kbit modem. Today it takes 3

    minutes do download the 23MB of the .NET Framework runtime on a 1.5MBs cable

    mode. These numbers are only going to get better and deployment techniques

    are going to improve.</font></li>

    </ul>

    <p><font face="Verdana" size="2">I hear the call to provide more details about

    the .NET Framework distribution and I plan to publish some articles on MSDN in

    the next two month to address that need. </font></p>

    <p><font face="Verdana" size="2">If you have direct questions and issues about

    adoption and deployment, feel free to email me directly:

    <a href="mailto:barakc@microsoft.com">barakc@microsoft.com</a></font></p>

    </body>

    </html>

  35. Monte Hansen says:

    That’s great. However, none of the primary concerns pointed out here have _anything_ to do with adoption and deployment (and I’d argue the deployment thing with you too, in a different discussion perhaps).

    Monte Hansen – Visual Basic MVP

  36. BenB says:

    Monte,

    Actually, I do think it is discussed above and further it falls under objective 3 of the petition. That may not be an issue that is at the top of your mind, but it is one of the primary issues for many developers.

    Ben

  37. Monte Hansen says:

    Ben,

    While that may be a concern (and is one of mine too), it is also being used as a tactic to disguise the other primary concerns. The more we dwell on that concern, the more clouded the issues will be, and this is what the executives at MS would like (so the press doesn’t write about the other issues that make MS look bad).

  38. Rob Abbe says:

    It’s amusing to me that this article was entitled "An Open Letter to the Community" when it seems that Microsoft is anything but receptive to the needs of the community it claims to understand so well.

    Like many others here, we have an ENORMOUS investment in Visual Basic 6 and hence so do our customers. The lack of commitment shown by MS has forced us to rethink our direction for future products.

    The .Net community seems to consist of MS and anyone who agrees with MS. Where is the process at MS for community involvement? The quick answer is that there is none.

    Since .Net requires retraining and recoding efforts I encourage developers to use software based on open standards or software driven by the community. Standards driven software is good for developers and provides a reasonable secure investment for our customers. A great example of can be seen in the Java community process(JCP). Along with providing involvement in the creation of future Java standards, Java developers can now submit bug fixes to J2SE. That is community involvement! MS doesn’t have a clue about community and you need to figure it out fast, Slick Marketing isn’t going to help you this time.

  39. This is not an issue of support or not.

    The whole issue is that Microsoft has changed their way of reaching the market. We (the VB/VBA-people) helped them and opened the doors to get into the large accounts. Now they are there and they don’t need us anymore. It’s as simple as that.

    The people they meet today (their new customers) at the IT-apartments at the large accounts (CIO:s etc) haven’t got a clue about all the stuff used out in the apartments. And if they have seen anything they dislikes it and hopes it will die as soon as possible, that is what Microsoft is trying to help them to achieve. As always we are in the battle of if IT should be implemented top-down or bottom-up. And the sad story is that Microsoft has changed position the last years.

    I have always been the bottom-up guy who believed in the power and the engagement at the apartments where people work and find smarter ways of using computers. The top-down represented by IBM, Oracle etc and now also Microsoft has always been madness to me. Lots of wasted money trying to implement systems invented at HQ meetings by guys drawing silly schemas with boxes and arrows using three digit words who nobody understands. No it’s simply a question of dictatorship or democracy. It is not just Microsoft moving in that direction I think the whole nation, United States of America is going there…

  40. Msnyder says:

    As far as I’m concerned VB.net is already legacy. The majority of business apps will be browser based. Until Microsoft gets their framework into my Blackberry I’m not using it. Microsoft should stop wasting time on client side languages and worry about getting a runtime in every embedded browser out there. Microsoft should have two (2) products: .Net for the serious programmer and VB6 legacy ongoing development. Let US choose which one we want to use. Talk about the model “T” (any color you want as long as it’s black) I think Microsoft can afford to do both. I think you’d be surprised at how successful the latter product would be. As for being technologically advanced… Everything we use VB6 for is server side (the side nobody sees). All we use VB6 for is spitting out HTML pages. When we upgraded to VB.net all of our business logic was broken. It is going to cost me millions to debug and upgrade my code. Plus all of my 2000+ customers have to deal with bugs that will surely be overlooked in the conversion process. My customers have no patience for bugs. Anyone who has owned a business and paid programmers real money knows the upgrade process is difficult. And by setting the precedent it will happen over and over again. I say get a team together and re-release VB6 and let the Gurus and Ph.D. candidates play with .Net all day. I just want my code to work.

  41. DrMabuse says:

    @Rickard Osson

    And the dictator of your nation has a name?

  42. Sorry for upsetting you about my last sentence. I am not alone in Europe feeling worries when we see the news spread by Fox, but I agree that is a totally other story. US have got a lot of power and sometimes one could feel that it is not used in a humble way. I was on my way to Australia just changing flight in LA, and what happened – I got to have a visa into US, putting my fingerprint and photo into your databases, and after that I had to check out and check in my entire luggage…..

    And I agree I don’t know what that has to do with MSFT.

  43. Mike Thomas says:

    I think the main problem is not that it is .Net, but that it is not VB. VB.Net is Java with some Basic syntax slapped on top of it. I don’t care how the runtime implements my code. The idea behind a runtime is to protect the developers from changes in the environment. So if MS decides to change the way forms work in future versions of Windows I don’t have to worry because I am talking to a black box, the runtime, and it will handle those changes for me, otherwise why bother with the runtime at all?

  44. Bit Twiddler says:

    OK Microsoft… lets get to the heart of the situation and it always is:

    The money.

    If a classic/VB7 were offered at a reasonable market price, that actually fixed bugs and addressed common pet peeves, I think you’d see way more than enought revenue to cover any development costs to do so.

    Just sitting here twiddlin’ bits in VB6.

  45. BenB says:

    To me and hundreds – yes, I have discussed and listened to that many – of other people it is that Microsoft abandoned us (4.5+ million at one point) VB developers with NO PRACTICAL upgrade route or NEW PROJECT language. None. Microsoft practically invented/ discovered that it is not about what is best but rather what is practical. We have been left with a dead classic VB6 and nothing that is ready for prime time. VS 2005 is not out yet and to me and many others that is the only choice that is worth considering.

    In the end that means Microsoft left us with a dead product between 1998- whenever VS 2005 is released + 2 years as it will take at least that long to be implememented; and that is just for new projects, not old ones.

  46. Subrata Debnath says:

    The VB6 migration tool (included with VB.net 2003) is useless for any practical VB6 project except for very simple project created by student/ hobbyist. Whole rewrite of the code is needed. It is very hard to make Finance people (who sanctions money) agree to spend huge amounts of money on the projects which already work. Then rigorous testing is needed before deployment as these are new codes. All these are needed because Microsoft dropped future development of VB6. I don’t understand few basic steps of Microsoft (a financially successful IT company).

    1) Most developers (myself included) started programming with Basic/ Visual Basic becuase VB is so simple for novice. Still you can solve real problems with it, so they got glued to VB and later Microsoft Tools. If future generation of developer has to start with C, C++ or Java without absence real (old) VB, then Microsoft will be the loser. Try teaching VB.net to a school-kid of the same age, the age when you started to learn VB.

    2) Most of the establishments are still using MS office 97/ 2000 because lots of VBA codes they already have. Open source alternative (e.g. Openoffice) lacks replacement of VBA, the very simple tool which again solves real problems.

    3) Microsoft can afford to put developers to update foxpro, but they can not afford to update VB6.

    Microsoft has got a huge developer base because they offered simple tools which can solve real world problems. By killing VB6/VBA, they are losing the oppurtunity to present the very first tool to future generation of developers. Also, losing their defense against Linux, Java and other open source alternatives.

    I wish my comments are read by somebody at Microsoft who decides long term strategy but not by those Ph.D. development teams who are blind at .Net.

  47. mappin says:

    Well Isnt The . Net framework supposed to support any language???

    maybe someone will write a vb classic compiler for .NET

    The in the meantime for those of you that wrote code in VB6 and have been left hi and dry you shouldnt me surprised at all.

    When VB went from 16 bit to 32 bit the same thing happend and there was exactly the same problem … with backward compatbility…. or have you all forgotten the VBX -> OCX night mares

    Funny though, it was about that time that Delphi suddenly became hugely popular… because Delphi developers had no such upgrade issues….. (and it was way superior)

    Its pretty sad that MS managed to spread so much FUD that delphi began to fade away….

    Interestingly Borland has just released Delphi for .NET 2005 and with minute adjustments (mostly conditional compiler directives) all the delphi samples recompile in .net pretty much with out fuss….

    http://www.borland.com/delphi/demo/tutorial/tutorial1.html

    So those guys still smart enough to make their own choice and use delphi… can now

    compile to either

    Native win32

    .NET

    Native Linux (in many cases).

    All from the same source code

    All from the same IDE

    All from the same Components…(delphi components are written in delphi)

    Eat your heart out. :)