Vista - using .bas in C# or VB.Net

I have a couple of .bas files and i need to use them in C#. I read
Riquel_Dong reply that I need to compile them to COM dll files and use them.
How do I compile .bas to dll?
I saw another place:
fbc -dll myfile.bas
but its using freebasic and i could'nt understand it. Any other way.

Sorry didnt know in which group to post.

In Visual Studio Net there is a converter for Bas to VB but not to C#/

Be aware that probably the converter gives you a lot remarks to do as a
module written in the older VB dialects is often not very clean written or
have a lot of escapes to Win32 to do things which where in those days not
possible direct in VB code.

Cor

"amk_hawk" <amkhawk@xxxxxx> wrote in message
newsB7EA3CA-F0A5-4586-A5F9-A625A0CF764C@xxxxxx

Unless the older .bas file has a lot of file IO or Windows API calls in it,
I've had better luck simply making a copy of the .bas file and renaming that
copy to .VB. I then add the .vb file to my project and add the lines
"Option Strict On", "Option Explicit On", and "Option Compare Text". Then I
deal with the errors. My experience doing this type of conversion is that
far more of my code converts to VB2005/8 than the project converter and
without all the garbage comments that the converter inserts.

Mike.

"Cor Ligthert[MVP]" <Notmyfirstname@xxxxxx> wrote in message
news:%23yKzu6duJHA.4488@xxxxxx

My experience with both VB and VB.NET and VS is that you can easily get your
VB code to *work* in VB .NET, but that doesn't mean that the code is in any
way efficient or taking advantage of .NET's true power. Simply turning on
the extra compiler checks doesn't force you to abandon legacy VB functions
in favor of .NET framework objeccts and methods.

A perfect example is the VB C***() conversion functions, which are designed
to take in any data type (make that object in .NET) and return back the
desired data type (make that object in .NET).

When trying to go from a value type to another value type (like integer to
long integer), excessive boxing/unboxing occurs. This will *work*, but far
more efficient is the .NET convert class, which has many overloaded To***()
methods, each one written to accomodate a particular input type and avoid
these unneccessary boxing/unboxing operations.

In the end, if you really want an application to take advantage of all that
..NET has to offer, the brutal truth is that you shouldn't try to convert the
application, you should rewrite it. Of course, that is not always practical
and so, we wind up with a lot of poorly written VB.NET that started out its
life as VB 6.0.

I work with many companies that outsource the coversion of their VB 6.0
applications and when those applications come back (from India usually),
they run slower and have more bugs than before they were converted. This
leads many managers (who aren't programmers) to the incorrect conclusion
that .NET isn't worth the hype, when in fact, they're just dealing with
poorly written code, which you can write in any language for any platform!

-Scott


"Michael D. Ober" <obermd.@xxxxxx> wrote in message
news:-PednfdLapuBO33UnZ2dnUVZ_jednZ2d@xxxxxx

Scott,

Well put. If I have the time, I rewrite as it tends to generate more
efficient code.

Mike Ober.

"Scott M." <s-mar@xxxxxx> wrote in message
news:%23smom2ruJHA.5392@xxxxxx

Scott,

What you call legacy Visual Basic code?

You are talking about micro optimizing wich often don't make any sense.

It looks like you optimize in the 80% part of your code that is used 20% by
the program.

Beside that you tell to deoptimize by removing Functions like CDate and
ChrW, which are simply given optimized functions around the DateTime and
String classes.

By the way, boxing and unboxing is not that bad in .Net as it was in
history. Try to avoid refresh the screen and those things, that optimizes a
program. Not that micro optimizing that saves you a thousand of a pico
second.

If a VB6 program is poorly rewritten is not the fact of these functions.
Simply putting Option Strict in top of your program and get by that rid of
late binding makes the program much faster, as VB functions are used mostly
even faster.

On the other hand I see often people who want for whaterver reason use
Reflection. That is moslty simply using late binding. I seldom see comments
about using unnecessary Reflection then by a select part of the regulars in
these dotNet newsgroups.

Cor

"Scott M." <s-mar@xxxxxx> wrote in message
news:%23smom2ruJHA.5392@xxxxxx

I refer to any VB 6.0 function that still *works* in VB .NET, but does not
correlate to a .NET BCL object directly, a "legacy" function. That
includes just about all of the native VB 6.0 functions relating to data
types.

I'm using the Cxyz() functions as an example (and their use is discouraged
in general for the reasons I've stated). I disagree with your 80/20
assumption and, in fact would say that these legacy functions are used far
more than this.

There really is no reason to choose these functions. They offer no
improvement in performance and/or portability to other .NET languages (quite
the contrary). Also, their use does not follow with the Object Oriented
that VB .NET has.

It's true that boxing/unboxing can't be avoided in many circumstances, but
that's not a reason to allow it to happen when it can be avoided. The
ability to avoid boxing/unboxing operations is one of the great benefits of
the Generics collection types and is not a trivial.

This topic has been debated since the inception of .NET and I've heard the
argument that these functions are part of Microsoft.VisualBasic and
therefore they are first-class .NET language elements, but again they are
not needed - - not one of them. Each and every one of them have a .NET BCL
counterpart/mechanism and those counterparts are used in an OO way.

As an IT trainer, I know that in the Enterprise, there is no reason to learn
these legacy functions because nothing is gained by their use.

Lastly, there is no reason to think that Microsoft would support these
mechanisms forever. For example, at some point, it's not inconcievable that
MsgBox() would go away, in favor of MessageBox.Show().

-Scott


"Cor Ligthert[MVP]" <Notmyfirstname@xxxxxx> wrote in message
news:%23wrOLTwuJHA.5836@xxxxxx

Scott,

Are you using in English as well only the Anglo Saxon set of words. English
has a lot of synonyms because of the different tribes that have concoured
England in history.

So you eat flesh no meat because there is not any reason to call it flesh.

Poor English and so is Visual Basic as you avoid using the words which makes
it easier to describe things.

By the way, why you are always writing about "vb6 functions", those keywords
are and will be used in every version from vb even the scripting ones. vb6
has nothing to do with it.

It is something different as you are talking about the Com objects like
recordsets. Com can be used in every .Net language, however that is not
advisable because it is mainly dedicated to Win32.

jmo

Cor

"Scott M." <s-mar@xxxxxx> wrote in message
news:ORRo$DxuJHA.5764@xxxxxx

Correct me if I'm wrong, but I think the point you're trying to make is that
these functions are part of the language, so why not use them if they help
describe what is trying to be said. Correct?

Well, I've already answered that question. Because there are *better* ways
to describe the intent of your code than these outdated functions.

Even though, as you point out, these functions were created much earlier
than VB 6, I refer to them that way as a simple way of drawing a line
between classic VB and VB .NET - don't read anything else into it than that.

COM objects have nothing to do with this topic, in my opinion, because you
may *have* to use a COM object in a .NET application, but you *never* have
to use any of these legacy VB functions.

As I said in my last post, these functions:

- all have .NET counterparts
- don't follow OO syntax/programming style
- may not have continued supporte in the future
- can degrade application performance

These points can all be overcome by simply using the .NET framework. Given
that, saying that "they are part of the language" just isn't good argument
for their continued use.

Let me cite just one (of many) references about this:

From: Professional Visual Basic 2008 by Bill Evgen et al (page 45)

"The following set of conversion methods is based on the conversions
supported by Visual Basic. They coincide with the primitive data types
described earlier; however, continued use of these methods is not considered
a best practice. That bears repeating: Whil you may find the following
methods in existing code, you should strive to avoid and replace these
calls:"

Following that paragraph is a complete list of the Visual Basic Cxyz()
functions.

To sum up, just because you can do something, doesn't mean that you should.
There really isn't any complling reason to use these outdated and
inefficient function calls.

-Scott


"Cor Ligthert[MVP]" <Notmyfirstname@xxxxxx> wrote in message
news:uq54Q0xuJHA.4324@xxxxxx

Scott,

You should have seen that as somebody uses the term "best practise", I
always write that he tells most probably something he has heard, what fits
nice in what he thinks, but is not something he knows.

The term "considered best practise" should always be followed by: because
........................................

Now it is stated as if the writter has talked about this with some friends
in a bar and they decided that it was best practise.

It is however something which is often told by people who know C# and think
that they then can write a book about Visual Basic because the System
namespace is used in both.

Cor

"Scott M." <s-mar@xxxxxx> wrote in message
news:e5Ro2a3uJHA.4592@xxxxxx