DAAB ExecuteReader method causes Exception

[Alec MacLean]

Hi all,

I'm trying to deploy an ASP.NET (1.1) app to our production webserver, but
having problems with the DAAB (from Ent Lib June 2005).
As you might guess, it works just fine and dandy on my dev PC (VS2003).

The error I'm getting on the production server is:
The type initializer for
"Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataConnectionFailedEvent"
threw an exception


Background info:
Using our own webserver, so I have direct folder access.
The application is for use on our Extranet and uses SSL for all comms.
Users access control is via Forms Auth (tried and tested methods used in all
our extranet apps).
I have used normal xcopy (cut & paste) deployment for the project folders
and aspx, dataconfiguration and dll files, then set up the virtual directory
on IIS, and enabled the required use of SSL on the new virtual directory.
I have other apps using the direct ADO.NET data methods, which all work
fine, so the folder structure and setup is not something I'm concerned
about.
I've converted one page of my new app to use the direct methods and these
work OK, so I believe the virtual directory config and SQL permissions can
be eliminated as a problem and it narrows the problem directly to the DAAB
methods.

So the folder structure is:
<myWebsite>
+--<myAppVDir>
+--Bin
+--images

With the files in my app's V-Dir being:
all the aspx files, globa.asax, styles.css
dataconfiguration.config
web.config

Content of /bin:
My project's dll
Microsoft.Practices.EnterpriseLibrary.Common.dll
Microsoft.Practices.EnterpriseLibrary.Configuration.dll
Microsoft.Practices.EnterpriseLibrary.Data.dll

I have set a project-level Imports for the
Microsoft.Practices.EnterpriseLibrary.Data
The production versions of web.config and dataconfiguration.config files
have been modified to use the production instance of the SQL dbo.

I've narrowed down my problem specifically to the db.ExecuteReader method
used to load the IDataReader.

In Page_Load, call is made to method for retrieving users email address:

Private Sub GetStaffEmail()
Dim db As Database = DatabaseFactory.CreateDatabase
Dim cmd As DBCommandWrapper =
db.GetStoredProcCommandWrapper("usp_OnLine_EmailAddr_for_Staff_SELECT")
Dim dataReader As IDataReader
'Add the required parameter:
cmd.AddInParameter("@ExtranetUSID", DbType.Int32, Me.intUSID)
Try
'Execute command and retrieve data:
dataReader = db.ExecuteReader(cmd) ' <--- Fails. Triggers exception
....
Catch
....
Finally
'Dispose of dataReader
....
End Try
End Sub

I have not installed or run any process specifically for the EntLib on the
server, other than copy the three DLL's as outlined above.
Should I run/install the EntLib MSI and then run the "Install Services"
batch file?
Being cautious, I avoid installing anything I don't have to on the
production server.

Is there anything else I should be aware of to implement the EntLib DAAB?

Thanks for any pointers.

Al

 

[Jose Rodriguez]

Alec, I would say yes...install and run the services...DAAB has some built
in dependencies to other components of the Enterprise library. Good luck,

-Jose

 

[Patrick.O.Ige]

Al try this:-
InstallUtil.exe against the Enterprise Library dll's in my project \bin\
directory.

The InstallUtil.exe is located in the Windows/Microsoft.NET framework
directory. Usually, this is located in:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
where the version is your latest version.

Open a DOS prompt, and navigate to the application's \bin\ directory, for
example:
C:\Inetpub\wwwroot\MyWebApp1\bin\

Run the InstallUtil.exe against the Enterprise Library dll's in that \bin\
directory. For example:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\InstallUtil.exe
D:\Inetpub\wwwroot\MyWebApp1\bin\Microsoft.Practices.EnterpriseLibrary.Data.dll

NOTE: It might be possible that the InstallUtil only needs to be run against
one of the dll's. Afterall, the problem is that the app can't write to the
registry, not that it can't find the dll's. But I don't know this for sure,
because I ran it for all three of my Enterprise Library dll's right off the
bat.

For more information on the InstallUtil.exe, obviously, MSDN has many
articles about it:
http://www.google.com/search?hl=en&q=site:msdn.microsoft.com+InstallUtil.exe
Hope that would solve your problem
** This did the trick on some PC's
Patrick

 

[sloan]

Check
http://blogs.msdn.com/tomholl/archive/2005/02/18/376187.aspx?Pending=true



//quote

If you are deploying to an environment where the instrumentation cannot be
used, it's pretty easy to disable it, but you will need to recompile the
code. Luckily all the instrumentation code is wrapped around conditional
compilation directives, so you won't need to edit any source files directly.
Just go into the Project Properties dialog for the Common project, and under
Configuration Properties\Build, find the Conditional Compilation Properties
property and remove ;USEWMI;USEEVENTLOG;USEPERFORMANCECOUNTER (or any
combination of these that you don't want). Once you recompile, the relevant
instrumentation code will be disabled. Of course, it is still possible to
configure the Logging & Instrumentation Application Block to use WMI or
Event Log, so make sure you also choose appropriate settings for your
environment if you are using that block.


I removed these conditionals when I built my release version of the
EnterpriseLibrary.

Also, you can't ~just use EntLib.Practices.Data .. you need to include
xxxxxxx.Config.dll
xxxxxxx.Common.dll
(if my memory serves me correctly).

...

 

[Alec MacLean]

Hmm - On examining the batch file behind the "Install Services", all this
does is copy the compiled DLL's from the EntLib /bin directory to the local
Visual Studio/ Common7/IDE folder.

It doesn't appear to make anything load into memory or register with GAC,
etc.

I was under the impression that the compiled DLL's should just be xcopied
along with the app's DLL and that should pretty much be it, just as I would
and have done for my other ASP.NET apps that are not using entlib.

I have looked into installing the EntLib package on my server, but to
compile it requires access to Visual Studio, because it uses a series of
solution files.

Why MS couldn't make the system compile directly from the Framework, I don't
know. I guess it's a fair assumption by them that if you're using the
EntLib, then you have VS, but that takes me back to my point above about
xcopy deployment - it's obviously not happening correctly in this particular
case.

We've all read about how all you need to get started in .NET is Notepad, the
Framework distributables and knowledge of the command-line compiler syntax
(I don't have this latter knowledge as I use and rely upon VS, but MS
certainly have people that do).

The only significant difference between the environments is that the
production version is using SSL, but my dev PC isn't. As far as I'm aware,
only my (solitary) cookie needs to be made aware of this difference by
setting it's .Secure property to true.

Has anyone else used the DAAB successfully with SSL?

Al

 

[Alec MacLean]

Thanks Patrick - I'll investigate this and let you know if it helps.

Al

 

[Alec MacLean]

Hi Sloan,

Already saw that, thanks. My project hasn't got any of the mentioned (or
any etra) directives set, so couldn't remove them...

I'm going to follow up on Patrick O. Ige's response, as this seems to hold
some promise.

Thanks

Al

 

[Alec MacLean]

Excellent Patrick! Using InstallUtil has done the trick - thank you.

Just to clarify for anyone else reading this thread, InstallUtil is run on
the server itself (using remote desktop terminal session) from the new
application's bin folder, _not_ from my dev PC against the server's
deployment location.



Al