VB .net - A question for Microsoft Moderators...

[Andrew The Marginalised Accountant]

VBA was invented to automate the functions of Microsoft office. It was made
available to all users who were willing to get their hands dirty and learn it.

The latest incarnation of office solutions can be written using VB .net. but
to write with the solutions you need visual studio .net.

Many non "IT" people are programmers but a reality of the modern business
world is that it is the IT department that gets the programming tools. This
leaves many business programmers in a very difficult position. Their skills
and jobs are programming based but they have had to survive on the VBA ide
provided in office because often business itself does not understand their
function and role.

Microsoft has developed .net based office solutions but has not made the
development environment for office automation freely available to those
business based programmers (as opposed to IT programmers) that need to update
their skillsets as well. Updating skills is a long process that is best
achieved slowly, day to day and using the tools in the course of a job.

Very few companies will purchase Visual Studio for their System and
managment accountants and other accounting/business users and this makes it
very difficult to update the skills for these people - who may not
necessarily wish to stay with vba forever. Microsoft seems to commit to
retaining VBA in the medium term but this does not mean users who rely on the
vba ide should have to put up with being marginalised and shut-out from
platform advances in the .Net area.

Please respond Microsoft....

 

[Jonathan West]

Hi Andrew,

You aren't alone, I have been expressing similar concerns for years, and
wrote an article about it some time ago.

Office and .NET: Better Together?
http://www.ftponline.com/vsm/2002_08/magazine/departments/guestop/

It is unlikely that anyone from Microsoft will respond here as they have an
official policy of not commenting on unannounced products. But you can be
quite sure that they have been made thoroughly aware of your concerns.

Most VBA programming is concerned with manipulating the Office object
models, and has relatively little need for access to operating system
functions, either through the .NET framework or otherwise. This means that
Office is already good enough for most of the purposes to which it is being
put. Ultimately, if VBA does not continue to be supported and/or extended,
then users like you will probably decide not to upgrade to future versions
of Office because the gains in doing so will be outweighed by the costs of
rewriting your VBA code. You won't be alone, as large companies with major
investments in VBA code (particularly in Excel for mathematical models) may
be unwilling to upgrade, refusing to accept that they will have to pay
Microsoft for the privilege of being forced to rewrite all their code.

I suspect that Microsoft has given some throught to the issue. After all,
two releases of Office have come & gone since .NET was introduced, and VBA
is still there as the only integrated method for doing Office programming.
Visual Studio Tools for Office is not a practical method for making .NET
available to Office programmers, it is more a means of making Office more
accessible to .NET programmers, who have Visual Studio.NET already.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup

"Andrew The Marginalised Accountant" <Andrew The Marginalised
(e-mail address removed)> wrote in message

 

[Andrew The Marginalised Accountant]

Hello Jonathan,

Thanks for the charitable reply and apologies for the multiple post. It's
actually the first time I have managed to find any forums that might be
monitored by Microsoft moderators in which I can vent my frustration and
possibly get a meaningful two way exchange.

Every few months or so, I do some basic searches to see if any progress has
been made on this particular issue but for some reason I find that obtaining
concrete information on the direction of VBA and of any VSA successor is
really hard to get. I've never been happy with placations from Microsoft that
say that VBA will still be supported for a while yet as that is fine for
business reassurance but not for developers who wish to feel that they are
being left behind.

From my perspective, I have to wade through reams of semi-relevent MSDN
Visual Studio white papers and scan through Visual Studio Express Beta's only
to find that nothing has really happened (ie. C# and vb .net still requires
the full Visual Studio Suite). I have been learning a little C# via the SDK
and SharpDevelop (at home) and have tried playing with MS Office interops -
but it's not nearly as easy as just having Visual Studio. It's certainly not
practical to play with that at work.

I feel very nervous that my skills are becoming slowly redundant and hybrid
programmer accountants like myself are an endangered species since office
solutions using managed C# and vb .net are now available for IT based
developers but not to business developers. Also in a sense it is the business
developers like myself that would arguably need the biggest head start in
learning the new paradigm wheras the IT developers have been given the
opportunity to get a jump on us.

Cheers

Andrew

 

[Jonathan West]

"Andrew The Marginalised Accountant"

Hello Jonathan,

Thanks for the charitable reply and apologies for the multiple post. It's
actually the first time I have managed to find any forums that might be
monitored by Microsoft moderators in which I can vent my frustration and
possibly get a meaningful two way exchange.

I'm not from Microsoft, but I am in touch from time to time, and yes, they
are aware of the issue. You are not alone. Whether that means we will
ultimately get the result we want is more debateable. We will have to see!

Every few months or so, I do some basic searches to see if any progress
has
been made on this particular issue but for some reason I find that
obtaining
concrete information on the direction of VBA and of any VSA successor is
really hard to get. I've never been happy with placations from Microsoft
that
say that VBA will still be supported for a while yet as that is fine for
business reassurance but not for developers who wish to feel that they are
being left behind.

There are two reasons why the information you are looking for is hard to
come by. First is the simple matter of Microsoft generally not commenting on
unannounced products.

Second is that there was a huge rumpus in the developer community over the
extent to which VB.NET was different from VB6. You might be interested in
taking a look at this site for more information on this topic.
http://vb.mvps.org/vfred/Trust.asp. This rumpus might have resulted in some
genuine uncertainty within Microsoft as to what direction to take. I alluded
to this in the article I mentioned before.

From my point of view, I find that the great majority of my customers are 1
to 3 versions behind the current Office version (probably half or more are
on Office 2000 still). If this lag remains, VBA is going to remain relevant
for a good long time after it is dropped from a future version of Office (if
that ever happens). I suspect that if VBA is dropped, many of my customers
will be very hesitant to move on, because of the cost & effort involved in
rewriting or paying me to rewrite all the VBA code they have now. That will
cost Microsoft a lot of money in lost upgrade sales.

From my perspective, I have to wade through reams of semi-relevent MSDN
Visual Studio white papers and scan through Visual Studio Express Beta's
only
to find that nothing has really happened (ie. C# and vb .net still
requires
the full Visual Studio Suite). I have been learning a little C# via the
SDK
and SharpDevelop (at home) and have tried playing with MS Office
interops -
but it's not nearly as easy as just having Visual Studio. It's certainly
not
practical to play with that at work.

The MSDN magazine & website are hardly likely to provide many VBA articles,
since that would imply there are useful things that can be done without
using Microsoft's flagship developer product.

I feel very nervous that my skills are becoming slowly redundant and
hybrid
programmer accountants like myself are an endangered species since office
solutions using managed C# and vb .net are now available for IT based
developers but not to business developers. Also in a sense it is the
business
developers like myself that would arguably need the biggest head start in
learning the new paradigm wheras the IT developers have been given the
opportunity to get a jump on us.

You still have skills that the IT developers lack, in that you have detailed
knowledge of accounting practices which I guess is most useful for the kind
of work you do. That knowledge won't be lost just because you have to learn
a new language.

The owners of major custom applications have just as much reason to complain
as you do. If they want to move their VB &/or VBA apps to .NET, they are
going to have to do a near-complete rewrite, paying all those IT developers
to repeat the work they have already been paid to do. I know of at least one
significant vendor of vertical-market apps in the banking sector who has
decided that moving to Delphi is a better bet than moving from VB6 to
VB.NET, not just because there is less effort involved, but also because he
mistrusts Microsoft's ability and intention to keep the .NET languages
stable enough to avoid the need for another rewrite in a few years time.

 

[Jim Vierra]

My guess is that VBA will be available in teh next version of office. After
all VBA is just another add-in. I would guess and hope that in the future
C# and J# would be added to Office in their scripting versions. The CScript
engine that is used from the command line is possibley a good model. Access
to the OS will probably be further isolated in Office for security reasons.
dotNET in VS.NET is really more for add-ins, control customization and more
advanced solutions requiring the skills of a developer. VBA was targeted at
users and Office super-users. It allows users to do a tremendous amount of
customization without hbecoming a systems guru.

I don't see VBA going away soon, but, MS has proven me wrong before - so
who knows.

 

[jay]

When MS introduced VBA, the previous automation still worked, right?
Even now, you can run Wordbasic programs in WordXP (and maybe later?)

So, probably no need for alarm. Surely the VBA automation will continue
to work for several versions to come.
I assume (ass/u/me ?) that MS will include the either the VBA
environment or something of similar functionality in new versions of
the product.
But, maybe not- they may decide to make the automation programming
features "additional at extra cost"...
In that case, need to keep older version around for the VBA programing
environment.
cheers
Jay

 

[Jonathan West]

When MS introduced VBA, the previous automation still worked, right?
Even now, you can run Wordbasic programs in WordXP (and maybe later?)

What is supposed to happen is that the WordBasic code is automatucally
converted to VBA when you first open a template in version of Word later
than Word 95. The conversion actually happens. The resulting code is horrid
to look at. It's also a bit of a lottery whether it will continue to run.

A 10-line macro will probably be OK. A 100-line macro is distinctly iffy.
For a 1000-line application, you can bet your bottom dollar that something
has broken.

That said, the quality of the conversion was a great deal better than
Microsoft managed with the Migration Wizard between VB6 and VB.NET, which
were supposedly consecutive versions of the same language.

So, probably no need for alarm. Surely the VBA automation will continue
to work for several versions to come.

Logically that would be the sensible course for Microsoft. But having seen
what they did to VB.NET, and continued to do even after they were told in no
uncertain terms by a lot of VB developers what a disaster it would be, I can
no longer assume that logic is always a factor in Microsoft's
decision-making process.

I assume (ass/u/me ?) that MS will include the either the VBA
environment or something of similar functionality in new versions of
the product.
But, maybe not- they may decide to make the automation programming
features "additional at extra cost"...
In that case, need to keep older version around for the VBA programing
environment.

If you need to keep the older version around in order to be able to run VBA,
effectively that means in a corporate environment that your organization
will never upgrade to the new version.

It might be that Microsot has had its fingers burnt, and they have decided
to pull back on taking Office full speed into the .NET world. There is no
sign that the Visual Studio group are learning from the VB.NET experience, I
understand that new incompatibilities have been introduced into the new
"Whidbey" version of VB.NET out on beta test. But it might be that the
Office group (who are after all responsible for about a third of all
Microsoft revenue) have decided they need to take a more conservative line.
Nobody wants to be the executive who killed Office.

 

[Jim Vierra]

The current truth is, from attending VBUG meetings, most VB programmers are
more than satisified with VB.NET. They may be more excited by it than
anyone else.

I do know of one VB programmer who still complains al of the time and
declares he will stop programming if VB6 goes out of support. Privateluy he
has admitted that he is just to lazy to learn dotNET but is beginning t
oplay with it.

 

[Jonathan West]

The current truth is, from attending VBUG meetings, most VB programmers
are more than satisified with VB.NET. They may be more excited by it than
anyone else.

I do know of one VB programmer who still complains al of the time and
declares he will stop programming if VB6 goes out of support. Privateluy
he has admitted that he is just to lazy to learn dotNET but is beginning t
oplay with it.

VBUG meetings will tend mainly to have sessions on features of the latest
version, so the people attending are by definition those interested in the
latest stuff. In essence you have a self-selecting group.

The problem with VB.NET is not learning the new language. Any programmer
worth his salt should have little problem with that, provided that he has
some time available to play around with it for a while.

The problem is carrying forward existing VB6 code, which for anything much
more sophisticated than "Hello World" means a substantial rewrite. That
takes time & money which would be better spent on new features and is likely
to introduce new bugs to the application.

Even so, VB programmers are generally not going to complain - they will be
getting paid to do their apps all over again! The people who will complain
are the application owners - those tho paid the programmers to create the VB
apps in the first place.

And what assurance is there that Microsoft won't decide in a few years time
to improve VB.NET in the way it "improved" VB6, and leave the poor
application owners with yet another rewrite on their hands?

 

[Karl E. Peterson]

The current truth is, from attending VBUG meetings, most VB
programmers are more than satisified with VB.NET. They may be more
excited by it than anyone else.

Read what Jonathan said, over and over if necessary, until you understand that the
issue is application *owners* much more so than *coders*. If you say, "well, that
doesn't apply to me!", then consider exactly who it is that's paying for your time.
You very well may fool her/him into paying you to do your own work over again once,
but do you really think they'll fall for that again? That is the history that is now
firmly established with Microsoft BASIC. You are on notice.

 

[Jim Vierra]

I would say it's a design issue. Do you re-write older code or just extend
it with NET. I'm a big fan of objects. COde ported from VB4 to VB6 will
not have much Class so will not be easy to port. That code is truly due for
complete re-engineering as the world, windows, companies and users have
changed dramatically since the old Cobol days. Most code I have worked with
ported quite quickly as much of it is unnecessary in NET. Forms do more by
themselves and data binding is smooth and reliable.

The hardest programs to port are the ones that are badly layered. The
warning with VB6 was - use classes! Much VB code is riddled with API calls
embeds all data acces in the program procedures. Yes. This is very
difficult code to port.

To test VB.NEt I took an old utility I had laying around and ran it through.
What a mess. It would have taken me all day to read the fix list. I looked
at what the routines were doing and realized that most of them were not
needed as the functions already existed in VB.NET. It was angly test that I
ran just to see.

Luckily I am not goinf to have to port any old code but I like doing it as a
challenge. If anyone is willing to pay I will port ANYTHING. Right now I'm
working on a FoxPro 2.6 100,000 line disaaster. I throw out 9 of every 10
lines and that's just on the first pass. 10 years ago I ported over 250,000
lines of dBase IV code to Clpper. Same thing. The final program was only
about 35,000 lines. The first pass took 2 weeks - long days. Iused a
version control system to delta all of the similar modules and looked at the
diff reports. Convertd th most generic module and paramaterized the
differences. The same technique works for VB.NET and Foxro to VS.NET.
Believe me. NET is a tremendous help to program development.

 

[Jim Vierra]

As a consultant I get to pick my employer. I act as a consultant and
advise. I will not do something that makes no sense and I will not maintain
code that should be replaced. I will however go in and fix simple things
when the business need is clear and can justify my price. I very often tell
clients to move to off-the-shelf solutions when it will clearly improve
their operation and reduce costs. Outside of large corporate environments
there is usually little need for highly customized solutions. My experience
in large corps is that projects grow as big as the staff. As soon as
somebody does a headcount the demand for customization all but disappears.
The better corps. have good architecture and infrastructure engineering
teams that are now improving the IT efficiency. For highly specialized
deployments high level consultants are brought in to work with the internal
teams. In thes environment VB, more and more, has become a utility and
maintenance tool. Web Services and modern databases are doing more of the
business work along with many middle tier comopnents. Microsofts InfoPath
was probably built to address this. It decouples the data entry layer from
the busines and data layers with an MS Office based tool that, if properly
deployed, can eliminate error.

There will always be a need for us old timers as this environment will not
shrtly be able to solve all problems. VB6 will be arounf for about another
5 years. Hell - If I have it installed on an old machine in 10 years I
might still use it. It's a great little scripting engine. Good editor too.
And it doesn't completely clog up the disk drive of a laptop. VB.NET won't
fit on my old laptop. Well - it fits but it maxes memory.

 

[Jonathan West]

I would say it's a design issue. Do you re-write older code or just
extend it with NET.

You do one or the other according to circumstances. It shouldn't be forced
on you as part of the price for taking up the next version of the language.

To test VB.NEt I took an old utility I had laying around and ran it
through. What a mess. It would have taken me all day to read the fix
list. I looked at what the routines were doing and realized that most of
them were not needed as the functions already existed in VB.NET. It was
angly test that I ran just to see.

There are two parts to this.

1. The fact that the code was a mess. If the language had been done
properly, this shouldn't have happened.

2. I accept that many of the features of the utility would be replicated in
the framework. But they *worked* in the utility before, they had been coded
tested and debugged. You are now dependent on code that is new, which you
have not had the opportunity to test, and which, while it provides the same
features, probably provides them is ways that are different, leaving you to
trip up over subtle things you were not previously aware of. The fastest RAD
is reusing debugged code you already have.

Luckily I am not goinf to have to port any old code but I like doing it as
a challenge. If anyone is willing to pay I will port ANYTHING.

There you hit my point. How many people will be willing to pay you to rework
code that was previously working well. I hope you see that there is a
significant difference in outlook here between you (and me for that matter),
people who will code for money, and those who have to pay us.

Right now I'm

working on a FoxPro 2.6 100,000 line disaaster. I throw out 9 of every 10
lines and that's just on the first pass. 10 years ago I ported over
250,000 lines of dBase IV code to Clpper. Same thing. The final program
was only about 35,000 lines. The first pass took 2 weeks - long days.
Iused a version control system to delta all of the similar modules and
looked at the diff reports. Convertd th most generic module and
paramaterized the differences. The same technique works for VB.NET and
Foxro to VS.NET. Believe me. NET is a tremendous help to program
development.

I don't doubt that, but if they had not made so many unnecessary changes to
the language, then it could have been so much easier still.

 

[Karl E. Peterson]

As a consultant I get to pick my employer.

I act as a consultant and advise. I will not do something that
makes no sense

Like writing disposable code for a "new legacy" application?

and I will not maintain code that should be replaced.

That's the choice open to hired guns, of course.

VB6 will be arounf for about another 5 years.

I'd have to bet it will be damn common for probably twice that long, and in rather
widespread use for probably 4-6x longer. Unless Microsoft does the Right Thing and
updates it with another, newer, forward-compatible COM-based release, of course.

Later... Karl

 

[Jim Vierra]

Now that's a new concept "forward-compatible" Is that like write-once and
forget-it coding.

 

[Andrew The Marginalised Accountant]

Agree with most of what everyone has said but it doesn't address the problem
that not all VB6/VBA programmers have the luxury of Visual studio proper.
Some System Accountants like myself have huge amounts of legacy database and
spreadsheet applications to maintain using any combination ADO, DAO, SQL and
VBA written by successive people who have been in the role. Sometimes some
accounting applications are very lacking in reports and are managed using MS
Access.

Despite all the above, people like me aren't given Visual Studio we have to
survive with IDE of MS office Apps. So my initial gripe was that even if I
wanted to learn VB.net I can't because it isn't made available to me. My
other gripe is a lot of people seem to think that all programmers are members
of the IT department. Not true either. This is obviously why Microsoft
peddles .Net office programming as a Visual Studio Add-on - but it's plain
ignorant to think MS office programmers are all strict IT people.

I want to learn .Net and I don't care if VBA is around for 5 or 10 years. I
still have 20 years before my retirement so I have to keep up to date for the
time being. Microsoft is abandonning those VBA programmers who only have the
office IDE as their staple programming tools and insulting them as if they
were lower class citizens to my way of thinking.

I'd be happy to fork out for .Net privately but I'm not the person I need to
convince - it's the employers who dictate what tools are given to their
programmers in the work environment.

That's enough of a screed from me for now

As a consultant I get to pick my employer. I act as a consultant and
advise. I will not do something that makes no sense and I will not maintain
code that should be replaced. I will however go in and fix simple things
when the business need is clear and can justify my price. I very often tell
clients to move to off-the-shelf solutions when it will clearly improve
their operation and reduce costs. Outside of large corporate environments
there is usually little need for highly customized solutions. My experience
in large corps is that projects grow as big as the staff. As soon as
somebody does a headcount the demand for customization all but disappears.
The better corps. have good architecture and infrastructure engineering
teams that are now improving the IT efficiency. For highly specialized
deployments high level consultants are brought in to work with the internal
teams. In thes environment VB, more and more, has become a utility and
maintenance tool. Web Services and modern databases are doing more of the
business work along with many middle tier comopnents. Microsofts InfoPath
was probably built to address this. It decouples the data entry layer from
the busines and data layers with an MS Office based tool that, if properly
deployed, can eliminate error.

There will always be a need for us old timers as this environment will not
shrtly be able to solve all problems. VB6 will be arounf for about another
5 years. Hell - If I have it installed on an old machine in 10 years I
might still use it. It's a great little scripting engine. Good editor too.
And it doesn't completely clog up the disk drive of a laptop. VB.NET won't
fit on my old laptop. Well - it fits but it maxes memory.

 

[Jonathan West]

Hi Andrew

"Andrew The Marginalised Accountant"

Agree with most of what everyone has said but it doesn't address the
problem
that not all VB6/VBA programmers have the luxury of Visual studio proper.
Some System Accountants like myself have huge amounts of legacy database
and
spreadsheet applications to maintain using any combination ADO, DAO, SQL
and
VBA written by successive people who have been in the role. Sometimes some
accounting applications are very lacking in reports and are managed using
MS
Access.

Despite all the above, people like me aren't given Visual Studio we have
to
survive with IDE of MS office Apps. So my initial gripe was that even if I
wanted to learn VB.net I can't because it isn't made available to me. My
other gripe is a lot of people seem to think that all programmers are
members
of the IT department. Not true either. This is obviously why Microsoft
peddles .Net office programming as a Visual Studio Add-on - but it's plain
ignorant to think MS office programmers are all strict IT people.

I agree with you on that point, and it is something which Microsoft seems to
have forgotten. I also think that it has been a significant reason for the
success of Office, in that it put programming tools into the hands of
subject-matter experts like yourself, who were then able to produce
workgroup and departmental applications without bothering the IT department.

Of course, if those applications are successful, as sometimes happens, and
they need to be scaled up, the scaling process sometimes exposes design
flaws which are then fixed by professional programmers who come in and make
a more solid job of it. Professional programmers are often very scathing
about what they regard as the design-free messes they are called on to
untangle. While their comments are valid on one level, they also miss the
point that without the unofficial activity of a subject-matter expert, the
application would never have justified the time & budget from IT. The
professional programmer would therefore never have had the opportunity to
design the application properly from the start.

I want to learn .Net and I don't care if VBA is around for 5 or 10 years.
I
still have 20 years before my retirement so I have to keep up to date for
the
time being. Microsoft is abandonning those VBA programmers who only have
the
office IDE as their staple programming tools and insulting them as if they
were lower class citizens to my way of thinking.

Well, since VBA is still available as part of current supported products and
it's the only thing available for people like yourself, I'm not sure how you
can say that it (and you) have been abandoned by Microsoft. If Microsoft
were to come out with a new version of Office that included an embedded
VB.NET, dropped VBA and provided no effective means of bringing your ADO,
DAO, SQL and VBA code to the new version, then you would have a much more
significant cause for complaint. That hasn't happened to us (yet) though
that is what happened to VB6.

I'd be happy to fork out for .Net privately but I'm not the person I need
to
convince - it's the employers who dictate what tools are given to their
programmers in the work environment.

That is a more significant statement than perhaps you realised when you
wrote it. If your employers decide that they will not get good value from a
future version of Office with VB.NET, then they won't buy it, you won't need
to learn it, and Microsoft won't get the upgrade license fees for it.

 

[Karl E. Peterson]

Now that's a new concept "forward-compatible".

..Not at all!

MSBasic offered forward-compatability for a quarter-century! With the near-singular
exception of platform-specific i/o methods, GW/QB code loaded/ran just fine in VB6,
ugly line numbers and all. That's what happens when the vendor partners with the
customer, to insure the soundness of the customer's investment.

Is that like write-once and forget-it coding.

Well, no, but it is sort of the antithesis of nocturnal aviation, er, consulting. <g>

Of course code benefited from being revisited as it was brought forward. But the
point remains, it *ran*, so you could immediately get to work on improving it rather
than wasting time debugging it all over again, and again, and again. Working *is* a
feature!

Later... Karl

 

[Jim Vierra]

This is great fun but...somebody should satr a blog for it. I think we may
be clogging up a developer support forum with our kibitzing.

 

[Jonathan West]

This is great fun but...somebody should satr a blog for it. I think we
may be clogging up a developer support forum with our kibitzing.

So long as the conversation is in response to a genuine question from
somebody, is conducted in a civil manner and remains generally related to
the subject of the group, I see no problem.

Since all those three conditions have been met and continue to be met, I
don't see why we shouldn't continue for as long as there is something useful
for us to say to each other.

What will happen to VBA as a reasonable question for this group, and
discussing what happened to a closely related language (VB6) is relevant to
the discussion.