Home All Groups Group Topic Archive Search About

Building a single EXE file in VB 2005?

Author
26 Jun 2006 11:29 AM
ashley.ward@gmail.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.

Author
26 Jun 2006 6:43 PM
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

Show quoteHide quote
> 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=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.
>
Author
27 Jun 2006 9:45 AM
ashley.ward@gmail.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.
Author
27 Jun 2006 10:30 AM
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/details.aspx?FamilyId=08E3D5F8-033D-420B-A3B1-3074505C03F3&displaylang=en

I hope this helps,

Cor


<ashley.w***@gmail.com> schreef in bericht
Show quoteHide quote
news:1151401545.460368.172830@c74g2000cwc.googlegroups.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.
>
Author
27 Jun 2006 3:52 PM
Claes Bergefall
"GhostInAK" <ghosti***@gmail.com> wrote in message
news:be1391bfbde78c8672487163a5e@news.microsoft.com...
> 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/express/support/faq/#general

   /claes
Author
27 Jun 2006 5:22 PM
Mike Lowery
"Claes Bergefall" <louplou@nospam.nospam> wrote in message
news:Ou1I%23EgmGHA.3980@TK2MSFTNGP02.phx.gbl...
> "GhostInAK" <ghosti***@gmail.com> wrote in message
> news:be1391bfbde78c8672487163a5e@news.microsoft.com...
>> 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/express/support/faq/#general

He probably meant "not for commercial use" as in XP Home is not (intended) for
commercial use, XP Pro is.
Author
27 Jun 2006 3:21 PM
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/index.php/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

<ashley.w***@gmail.com> wrote in message
Show quoteHide quote
news:1151321366.708459.162500@p79g2000cwp.googlegroups.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.
>
Author
6 Jul 2006 6:02 PM
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.CloseConnection)

        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


Show quoteHide quote
"ashley.w***@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.
>
>