Q: Problem Deploying vb.net Application

[Guest]

I've created a small vb.net application which uses the Data Access Application Block to access a SQL Server 2000 database.

The application works fine on the machine with the development environment (Windows 2K) but I am unable to get it to work on two other machines (Windows XP machines). When I try running the application on these machines I get a message box, after some delay, that says "Application has generated an exception that could not be handled." I've done various searches for potential causes of this and haven't had any luck so far.

The file "Microsoft.ApplicationBlocks.Data.dll" is definitely being installed on the client machines. I've even tried registering it manually, to which the system says that I cannot do it.

The client machine has MDAC 2.8 and version 1.1 of the .NET Redistributable Framework installed. I've also tried using the .NET Wizards and set the trust level to Full for all the zones, and that didn't work.

I'm almost positive that it has to do with the data access. I installed the SQL Server client utilities on one of the client machines and I can browse to the database and see its objects using Enterprise Manager without any problems. I can even use Query Analyzer to log on with the specific user I created for the application. So, the client can obviously see the SQL Server database. Also, when I build a version of the application with the data access routines commented out it runs fine.

Any ideas as to what to do to solve this problem? Is there more something that I need to do to distribute an application that accesses SQL Server 2000?

Thanks a bunch!

 

[Greg Burns]

The file "Microsoft.ApplicationBlocks.Data.dll" is definitely being
installed on the client machines. I've even tried registering it manually,
to which the system says that I cannot do it.

You don't use regsvr32 with dotnet dll's. Just make sure the dll is in the
same directory as your executable.

I've also tried using the .NET Wizards and set the trust level to Full for

all the zones, and that didn't work.

You shouldn't need to mess with this wizard if your exe is running from a
local drive. If you want to run from a network drive you can push the local
intranet zone to full trust for testing.

When I try running the application on these machines I get a message box,

after some delay, that says "Application has generated an exception that
could not be handled."

If you are starting your app from a Sub Main (if not, switch it so that it
is). Then wrap your applicaiton.run method in a try-catch block, so that
you can see an error message.

Module Module1
'The main entry point for the application.
<STAThread()> Public Sub Main()
Try
Application.Run(New Form1)
Catch ex as Exception
MsgBox(ex.ToString)
End Try
End Sub
End Module


P.S. Do you have your connection string for the DB hard coded in the program
or are you using an app.config file? Your app.config needs to be renamed to
myprogramname.exe.config and placed in the same folder as the dll and exe.

HTH,
Greg

I've created a small vb.net application which uses the Data Access

Application Block to access a SQL Server 2000 database.

The application works fine on the machine with the development environment

(Windows 2K) but I am unable to get it to work on two other machines
(Windows XP machines). When I try running the application on these machines
I get a message box, after some delay, that says "Application has generated
an exception that could not be handled." I've done various searches for
potential causes of this and haven't had any luck so far.

The file "Microsoft.ApplicationBlocks.Data.dll" is definitely being

installed on the client machines. I've even tried registering it manually,
to which the system says that I cannot do it.

The client machine has MDAC 2.8 and version 1.1 of the .NET

Redistributable Framework installed. I've also tried using the .NET Wizards
and set the trust level to Full for all the zones, and that didn't work.

I'm almost positive that it has to do with the data access. I installed

the SQL Server client utilities on one of the client machines and I can
browse to the database and see its objects using Enterprise Manager without
any problems. I can even use Query Analyzer to log on with the specific
user I created for the application. So, the client can obviously see the
SQL Server database. Also, when I build a version of the application with
the data access routines commented out it runs fine.

Any ideas as to what to do to solve this problem? Is there more something

that I need to do to distribute an application that accesses SQL Server
2000?

 

[s2k888]

Thank you for your response.

installed on the client machines. I've even tried registering it manually,
to which the system says that I cannot do it.

You don't use regsvr32 with dotnet dll's. Just make sure the dll is in the
same directory as your executable.

It is definitely in the same directory as the executable.

after some delay, that says "Application has generated an exception that
could not be handled."

If you are starting your app from a Sub Main (if not, switch it so that it
is). Then wrap your applicaiton.run method in a try-catch block, so that
you can see an error message.

Module Module1
'The main entry point for the application.
<STAThread()> Public Sub Main()
Try
Application.Run(New Form1)
Catch ex as Exception
MsgBox(ex.ToString)
End Try
End Sub
End Module

The app does start from a Sub Main. Very simple stuff:

cnnGlobal.Open()
MyfrmMain.ShowDialog()
cnnGlobal.Close()

As you can already guess, it is failing on the cnnGlobal.Open() line of
code.

I put it in a try-catch block, as you suggested, and the error returned is:

System.Data.SqlClient.SqlException: SQL Server does not exist or access
denied.
at System.Data.SqlClient.ConnectionPool.GetConnection(Boolean&
isInTransaction)
at
System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnec
tionString options, Boolean& isInTransaction)
at System.Data.SqlClient.SqlConnection.Open()
at FormulaTracker.modGlobal.Main()

P.S. Do you have your connection string for the DB hard coded in the program
or are you using an app.config file? Your app.config needs to be renamed to
myprogramname.exe.config and placed in the same folder as the dll and exe.

The connection string is hard coded in the program, and it is:

"SERVER=Primary; DATABASE=FormulaTracker; USER ID=FormulaTrackerUser;
PASSWORD=xxxxx"

Security on the server is set to SQL Server and Windows, if that helps any.

Thanks.

 

[Greg Burns]

I've been playing with DAB. I can generate your error when I type in an
incorrect SQL server instance name. And you say you can use this same
connection info with Query Analyzer on these machines? Is "Primary" the
computername of your SQL server, or is that some sort of alias that only
your dev machine knows about?

I am stumped.

Greg

---------------------------
Application Error
---------------------------
System.Data.SqlClient.SqlException: SQL Server does not exist or access
denied.

at System.Data.SqlClient.ConnectionPool.GetConnection(Boolean&
isInTransaction)

at
System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnec
tionString options, Boolean& isInTransaction)

at System.Data.SqlClient.SqlConnection.Open()

at DataAccessQuickStartSamples.Form1.GetConnection(String
connectionString) in C:\Program Files\Microsoft Application Blocks for
..NET\Data Access v2\Code\VB\DataAccessQuickStartSamples\Form1.vb:line 239

at DataAccessQuickStartSamples.Form1.cmdSample1_Click(Object sender,
EventArgs e) in C:\Program Files\Microsoft Application Blocks for .NET\Data
Access v2\Code\VB\DataAccessQuickStartSamples\Form1.vb:line 254

 

[s2k888]

I've been playing with DAB. I can generate your error when I type in an
incorrect SQL server instance name. And you say you can use this same
connection info with Query Analyzer on these machines? Is "Primary" the
computername of your SQL server, or is that some sort of alias that only
your dev machine knows about?

Nope, it's definitely the name of the SQL Server machine. I just tried
changing it to an IP address and same results, works on development machine,
but not on deployment machine...

I am stumped.

You and me both...

 

[s2k888]

Just in case you were wondering, after taking some time off from this
problem, we resolved it by disabling the "Named Pipes" protocol from the
Server Network Utility, leaving only TCP/IP. It was above TCP/IP by
default.