Building a single EXE file in VB 2005?

[ashley.ward]

We have been using VB6 to develop small custom apps that access an
Oracle database, in order to extend a larger product that is developed
by our colleagues in Germany (who use C++ and Java).

As each app is small and simple, we have been distributing each to the
customer in the form of a single EXE file.

I have been attempting to build another one of these small custom apps,
using VB 2005 Express Edition. It doesn't seem to be possible to
produce a single EXE file using this environment: for a start, there is
no File -> Make executable menu, only a more complex Build -> Publish
menu, which I think produces an MSI installer file. There are deeper
problems, however. Is there anything incorrect in my thinking below?

1) In order to write a program that takes the results of queries on an
Oracle database and places them in an Excel spreadsheet, in VB6, we can
use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the
data in a single (fairly quick) step. The database facilities in
VB.NET provide no equivalent: we must instead write (slow and possibly
buggy) code that copies one row at a time from the query result into
the spreadsheet (see
<http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>),
or use (COM) ADODB.

2) If our code uses COM objects (eg ADODB in the above case), it isn't
possible to compile the app into a single EXE file. It seems that
VB.NET needs to create an Interop.ADODB.dll file in this case.

I think if we want to continue to distribute single EXE files, it may
be best for us to stick with VB6.

Have I missed something?

Ashley.

[GhostInAK]

Hello ashley,

First, if you can't work the bugs out of a simple double loop perhaps you
should consider a different career path.
Second, the Express versions of the IDE are not for commercial use.
Third:

Set ExcelRowCounter
Set ExcelColumnCounter
Loop over each row
Loop over each column
Write Value to Excel Cell
Increment ExcelCellCounter
Next
Increment ExcelRowCounter
Next

-Boo

We have been using VB6 to develop small custom apps that access an
Oracle database, in order to extend a larger product that is developed
by our colleagues in Germany (who use C++ and Java).

As each app is small and simple, we have been distributing each to the
customer in the form of a single EXE file.

I have been attempting to build another one of these small custom
apps, using VB 2005 Express Edition. It doesn't seem to be possible
to produce a single EXE file using this environment: for a start,
there is no File -> Make executable menu, only a more complex Build ->
Publish menu, which I think produces an MSI installer file. There are
deeper problems, however. Is there anything incorrect in my thinking
below?

1) In order to write a program that takes the results of queries on an
Oracle database and places them in an Excel spreadsheet, in VB6, we
can
use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the
data in a single (fairly quick) step. The database facilities in
VB.NET provide no equivalent: we must instead write (slow and possibly
buggy) code that copies one row at a time from the query result into
the spreadsheet (see
<http://support.microsoft.com/?scid=k...=1249&sid=glob
al>),
or use (COM) ADODB.
2) If our code uses COM objects (eg ADODB in the above case), it isn't
possible to compile the app into a single EXE file. It seems that
VB.NET needs to create an Interop.ADODB.dll file in this case.

I think if we want to continue to distribute single EXE files, it may
be best for us to stick with VB6.

Have I missed something?

Ashley.

[ashley.ward]

Hello Boo...

Thanks for the reply. I don't see the need for your confrontational
tone -- although I realise that I didn't give any information about my
background, which hasn't helped. I did give a little detail recently
in another post here:
<http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/3f0bd46d9cf7ee1d?hl=en>.

I would prefer to avoid writing code to do this particular job in order
to minimise risk of bugs. I'm worried about typing issues, for
instance. If a well-tested library already exists to do this (which it
does in VB6), I'd prefer to use that.

I will check out the licensing limitations on the Express editions --
thank you.

There were other issues in my original posting. Does anyone have any
more feedback?

Ashley.

[Cor Ligthert [MVP]]

Ashley,

I think that most of us are not aware of a more suitable standard library
for your purpose in VB6.

Interop with Office has never been a simple job, all was it alone that the
development part of Office has showed in past in a way its own standards of
programming to the world.

But it is as well not so impossible to do as you show.

There is a special Office Net addition in Visual Studio which is standard in
more expensive versions.
See in this link what is included in the Express version.

http://msdn2.microsoft.com/en-us/library/b4z62wxz.aspx
However in this sample set is as well a sample how to automate office, I
have the idea that it will go in the Express version as well, because it are
older samples. (I don't guarantee that).

http://www.microsoft.com/downloads/d...displaylang=en

I hope this helps,

Cor
<as*********@gmail.com> schreef in bericht
news:11**********************@c74g2000cwc.googlegr oups.com...

Hello Boo...

Thanks for the reply. I don't see the need for your confrontational
tone -- although I realise that I didn't give any information about my
background, which hasn't helped. I did give a little detail recently
in another post here:
<http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/3f0bd46d9cf7ee1d?hl=en>.

I would prefer to avoid writing code to do this particular job in order
to minimise risk of bugs. I'm worried about typing issues, for
instance. If a well-tested library already exists to do this (which it
does in VB6), I'd prefer to use that.

I will check out the licensing limitations on the Express editions --
thank you.

There were other issues in my original posting. Does anyone have any
more feedback?

Ashley.

[ljh]

Ashley,

I make no bones about it.......in comparing VB.Net to Visual Basic 6, I
think VB.Net is a huge step backwards. It made the easy stuff easier and
the hard stuff harder. Not a great accomplishment if you ask me. VB.Net
was written for Microsoft - not for developers. It solves internal problems
for MS while creating problems for developers. It is the single, largest
screw-up in the history of programming languages.

You are not going to have a "small and simple" application using VB.Net. It
will not be small because you cannot depend on the end user having .Net 2.0
installed. That will add 25 MB to your installation. This significantly
increases bandwidth and distribution costs for you. (Don't even ask me why
MS can make BETA WGA - Windows Genuine Advantage - a critical security
download and not include the .Net runtime as a critical OS update...seeing
as how .Net is their strategy for the future.)

There is a way to make the installation simple and save some space while
including only the portions of .Net that your application needs. It is
called Thinstall.

Thinstall can wrap your entire project (including all needed portions of the
..Net framework) into a single, encrypted executable. Your customer does not
even need the .Net framework installed to use your Thinstall-wrapped app.
It has built-in licensing with the ability to distribute time-limited trials
of your software. It is a fantastic application for making no-install", but
Thinstall starts at $4,000 per application - so it will increase your
distribution costs.

There are similar (and much less expensive) applications that wrap VB6
applications into a single exe - just so you know.

As for what you are looking to do in .Net, I don't know if this will help -
but take a look at
http://www.xtremevbtalk.com/archive/.../t-239550.html. There is a
discussion of similar functionality there.

And, although we all know that VB6 was not perfect, VB.Net has more than its
share of problems. If you haven't already, subscribe to the free KB emails
at www.kbalertz.com. You can specify .Net 2.0 to limit the number of alerts
that you get and you can also search for all of the kb articles for .Net 2.0
right on the site.

IMHO, if what you have works, there is no reason to change to VB.Net. Don't
complicate something that is working. You won't gain any speed advantage.
Your distribution costs will increase. And, Microsoft is changing the
framework yet again with WinFX - now known as .Net 3.0 - and depending on
you to distribute it.

Jim Hubbard

<as*********@gmail.com> wrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...

We have been using VB6 to develop small custom apps that access an
Oracle database, in order to extend a larger product that is developed
by our colleagues in Germany (who use C++ and Java).

As each app is small and simple, we have been distributing each to the
customer in the form of a single EXE file.

I have been attempting to build another one of these small custom apps,
using VB 2005 Express Edition. It doesn't seem to be possible to
produce a single EXE file using this environment: for a start, there is
no File -> Make executable menu, only a more complex Build -> Publish
menu, which I think produces an MSI installer file. There are deeper
problems, however. Is there anything incorrect in my thinking below?

1) In order to write a program that takes the results of queries on an
Oracle database and places them in an Excel spreadsheet, in VB6, we can
use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the
data in a single (fairly quick) step. The database facilities in
VB.NET provide no equivalent: we must instead write (slow and possibly
buggy) code that copies one row at a time from the query result into
the spreadsheet (see
<http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>),
or use (COM) ADODB.

2) If our code uses COM objects (eg ADODB in the above case), it isn't
possible to compile the app into a single EXE file. It seems that
VB.NET needs to create an Interop.ADODB.dll file in this case.

I think if we want to continue to distribute single EXE files, it may
be best for us to stick with VB6.

Have I missed something?

Ashley.

[Claes Bergefall]

"GhostInAK" <gh*******@gmail.com> wrote in message
news:be*************************@news.microsoft.co m...

Second, the Express versions of the IDE are not for commercial use.

Not sure where you got that idea. From the FAQ for the express editions:

"4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using the
Express Editions"

Link: http://msdn.microsoft.com/vstudio/ex...t/faq/#general

/claes

[Mike Lowery]

"Claes Bergefall" <lo*****@nospam.nospam> wrote in message
news:Ou****************@TK2MSFTNGP02.phx.gbl...

"GhostInAK" <gh*******@gmail.com> wrote in message
news:be*************************@news.microsoft.co m...

Second, the Express versions of the IDE are not for commercial use.

Not sure where you got that idea. From the FAQ for the express editions:

"4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using the
Express Editions"

Link: http://msdn.microsoft.com/vstudio/ex...t/faq/#general

He probably meant "not for commercial use" as in XP Home is not (intended) for
commercial use, XP Pro is.

[Joseph Karpinski]

Hi Ashley,

I ran into the same Excel issue using adClipString with VB6.
It was so easy passing a recordset to Excel as a display interface for SQL
queries.

The work around I came up with for VB.Net was to issue a SQL query, parse
all field headings with VbTab, and then parse the returned fields for each
row.
The output is wrtten to a file, for which I then call Excel to display.
(It was only a couple of lines of code. See below)

Also, I've read that you can call old ADO recordset code from VB.Net by
setting a certain type of reference, so that you could use your current code
under VB.Net.
I just haven't tried it yet, because of the easy workaround listed below.

Something like:
sData = ""
strSQL = "select * from DBA_HIST_LibraryCache"
Get_Field_Values()
'oWrite = oFile.AppendText("C:\OracleAwrData.xls")
oWrite = oFile.("C:\OracleAwrData.xls")
oWrite.WriteLine(sData)
oWrite.Close()

Shell("C:\\Program Files\\Microsoft Office\\OFFICE11\\Excel.exe " & _
Chr(34) & "C:\OracleAwrData.xls" & Chr(34), vbMaximizedFocus)

Private Sub Get_Field_Values()

selectedDatabase = cmbServers.Items.Item(itemCountPointer)

Dim cnDBMS As New OleDbConnection
cnDBMS.ConnectionString = "Provider=msdaora;Data Source=" &
selectedDatabase & ";User Id=" & txtUserID.Text & ";Password=" &
txtPassword.Text & ";"

cnDBMS.Open()

Dim cmDBMS As New OleDbCommand(strSQL, cnDBMS)

Dim rdrDBMS As OleDbDataReader

rdrDBMS = cmDBMS.ExecuteReader(CommandBehavior.CloseConnecti on)

iFieldCount = rdrDBMS.FieldCount
sHeadingFlag = "N"

Do While rdrDBMS.Read()
If sHeadingFlag = "N" Then
sHeadingFlag = "Y"
For I = 0 To iFieldCount - 1
sData = sData & rdrDBMS.GetName(I) & vbTab
Next
sData = sData & vbCr
End If
For I = 0 To iFieldCount - 1
'sData = sData & selectedDatabase & vbTab &
CStr(Date.Now.ToShortDateString) & vbTab & CStr(Date.Now.ToShortTimeString) &
vbTab
sData = sData & CType(rdrDBMS.GetValue(I), String) & vbTab
Next
sData = sData & vbCr
Loop

cnDBMS.Close()

End Sub
--
Joseph Karpinski
"as*********@gmail.com" wrote:

We have been using VB6 to develop small custom apps that access an
Oracle database, in order to extend a larger product that is developed
by our colleagues in Germany (who use C++ and Java).

As each app is small and simple, we have been distributing each to the
customer in the form of a single EXE file.

I have been attempting to build another one of these small custom apps,
using VB 2005 Express Edition. It doesn't seem to be possible to
produce a single EXE file using this environment: for a start, there is
no File -Make executable menu, only a more complex Build -Publish
menu, which I think produces an MSI installer file. There are deeper
problems, however. Is there anything incorrect in my thinking below?

1) In order to write a program that takes the results of queries on an
Oracle database and places them in an Excel spreadsheet, in VB6, we can
use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the
data in a single (fairly quick) step. The database facilities in
VB.NET provide no equivalent: we must instead write (slow and possibly
buggy) code that copies one row at a time from the query result into
the spreadsheet (see
<http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>),
or use (COM) ADODB.

2) If our code uses COM objects (eg ADODB in the above case), it isn't
possible to compile the app into a single EXE file. It seems that
VB.NET needs to create an Interop.ADODB.dll file in this case.

I think if we want to continue to distribute single EXE files, it may
be best for us to stick with VB6.

Have I missed something?

Ashley.