Background
I have a BLL DLL that uses NHibernate. I share the same BLL between a client application and the WCF service (even though the client runs on another machine).
I can successfully use either SqlServerCe or SqlServer driver with the BLL with the client application but can only use the SqlServer driver for the WCF.
If I change the hibernate.cfg.xml to use SQL Server I am able to use the service as required with no exceptions being thrown.
The Error
The exact error from the log4net output is:
2421, 5, DEBUG, NHibernate.Connection.DriverConnectionProvider, (null),Obtaining IDbConnection from Driver
2483, 5, DEBUG, NHibernate.Connection.DriverConnectionProvider, (null),Exception thrown obtaining connection: Exception has been thrown by the target of an invocation.
I also have the following code in my WCF code behind file:
AppDomain.CurrentDomain.SetData("SQLServerCompactEditionUnderWebHosting", true);
NOTES
WCF bin directory contains all required DLL's for NHibernate and SqlServerCe
Does not matter if System.Data.SqlServerCe.dll is in the GAC
Does not matter if System.Data.SqlServerCe.dll is added to the web.config file under assemblies
Operating Systems is Windows Server 2003 R2 SP2
.NET Framework 3.5SP1 installed
Visual Studio 2008 installed
Just incase, I uninstalled anything to do with compact edition but this still did not resolve the issue
The Question
How would you try and determine why NHibernate cannot load the SqlServerCe framework?
What forensic analysis would you perform to try and accurately determine the problem so that you can then find ways of resolving it?
Update 1
Incase it was my code I just created a simple website and am able to successfully use the ORM to insert and retrieve records using a hard-coded path to the SDF database. If I use the same hibernate configuration file for the webservice then exception is generated. This does narrow down the problem to the WCF implementation.
Well, clearing the ASP.NET temp cache did not do anything and deleting and republishing my site did nothing, but reverting to an VM Snapshot on the Windows 2003 R2 SP2 O/S did!
An update or myself must have done something to the OS that caused the problems.
I have a different problem now as the SQL is not successfully running under the environment but at least the NHibernate driver is loading and running to which this question was asking.
Update: Yes, I can only get NHibernate talking to SQL Server still and this is fine for the webservice endpoint. We will investigate the issues at a later stage. Marking this answer as the correct one as no other comments have been added.
Related
I am getting this error in a WCF web service when the program attempts to use a method that employs the entity framework. However, we know that the server has the entity framework (correct version) installed because it is hosting another WCF web service and an intranet site that use it successfully.
I've tried to set copy local to true, however this simply compiles the Entity Framework dll into the debug/release folder of the project that uses it, not the web service project that gets deployed (the project that gets deployed contains a references the project that uses the entity framework).
Has anyone run into this kind of issue before and know a work-around either with or without using copy local?
The solution to this problem was to simply place the EntityFramework.dll and .xml file generated in the bin of the project that uses the Entity Framework and place that in the bin of the service project that was being deployed.
Check to see that the Application Pool for the IIS Site in question is set to use to correct .NET Framework version. In the case of EF 4.1, the Application Pool should be running on .NET Framework version 4 or higher.
To identify the version of .NET being used by the site, first find out the Application pool in use (in IIS, click on Basic Settings for the site), then identify the appropriate pool under the Application Pools node. The .NET Framework version should be listed.
Check whether bit versions are compatible between entity framework and server. If the server is 64 bit and you are using 32 bit entity framework dll you can get this error. Then change app pool setting to enable 32 bit applications.
I am trying to run simple application (e.g. generated from template by VS.NET 2010) on IIS6.
I changed it to run with .NET 4.0 (its application pool) and checked with regiis (this pool has 4.0). I also changed all possible httpHandlers (svc etc), to run with NET4.0. All possible rights are checked (i think so).
Almost every request results in "Server Application Unavailable" (sometimes it is empty page with -2146232576 (0x80131700) value) and "...Please review this log entry to discover what caused this error to occur." but EventViewer and IIS Log are empty.
Any ideas? Where to find error details?
Do you run any 2.0 apps on the same server? If yes it could be the issue in case they bot use the same application pool. The application tool itself doesn't have any .NET version setting, it's per virtual directory (application). But you can't use the same application pool to run applications with different versions of .NET Framework apps.
Create two seperate app pools one for your CLR 2.0 and CLR 4.0, the older clr can not host both CLRs, there was a similar issue with 1.1 and 2.0.
cheers
A little bit old question, but still could help someone...
If you installed the higher .NET f/w recently, check, if your apps written for lower versions of .NET f/w were not (automatically) moved to new app pool for the higher f/w.
Many years ago something similar happenned to me after f/w 3.5 installation. Then my 3.5 application worked fine, but after any of the 2.0 apps was firstly called, the app pool crashed.
Needed to move every app to corresponding app pool.
I'm dev'ing an MVC 2 website targeting .NET 4.0 and using Ninject 2.0 (dev box running Win 7 64 pro). All is going well on the dev side, I really enjoyed using Ninject and it works a charm.
Until I deploy it to the server. Once I deploy the app to the server (a virtual machine running Win Server 2008 R2 x64, IIS 7.5) the ninject binding appear to simply not happen. I was first getting a null reference exception on the Logger that I was calling in OnApplicationStarted, I manually bound that and I got another null reference exception the very next time the code called for an injected component. Manually changing that one pushes the problem down the line.
I'm not getting any errors at all locally, and I'm not getting errors in the event log other than the null reference exceptions on injected components.
I have already verified that the server has .Net 4.0, MVC 2's dll, both Ninject DLLs and the DLLs of all my components. I was compiling against "any cpu" as well, in release mode.
Any ideas or known bugs w/ the platform I've described?
I'd post source code except that I figured it's not relevant since it's working locally unchanged.
Ninject works fine on Server 2008 R2. If you are experiencing a difference in functionality between your machine and the server, then something is different in your setup. There is no way to help you with the information you have provided so far. Please create a sample project that exhibits the issue and it will be a lot easier to help you.
-Ian
Some months ago, a colleague of mine installed ODAC 11.106.21 in a server using XCOPY and then he developed many applications that use this client without problems (in test and production windows servers).
Past week, I developed an application under ODAC 11.1.07.20. When I asked him to install these new ODAC version using XCOPY in a different folder and then include my application in the test server, he answered me that I should use ODAC 11.106.21 because he could have troubles with his applications.
So I would like to know:
1) If it is really possible to have two different ODAC versions in one server.
2) If the answer is positive, how can I firmly ensure to my colleague that he will not have troubles with his applications?
3) If the answer is positive, is this necessary to do some kind of configuration in the server?
Thanks!!
You can have multiple versions of ODAC on the same machine, but there are several things to be aware of with regards to which version will be used by each application. This actually applies to all assemblies.
in Visual Studio, if you set Specific Version = True on Oracle.DataAccess.dll, then that application will not use any other version and must be able to find the version it was built against.
whether you deploy the DLL with your application or expect it to be in a certain place or in the GAC.
there is a specific search order for finding dependent DLLs, and it's quite involved, so read this MSDN topic.
The short answer is that there are two easy ways to make sure your application uses the exact version of Oracle.DataAccess.dll you want it to (this applies in most cases where everything else is default):
Set Specific Version to True;
Deploy the DLL with your application and have it reside in the application directory, OR ensure that the DLL is in the GAC.
In your specific case, your colleague may have a valid concern: If his applications which are currently installed are getting Oracle.DataAccess.dll from the GAC, and he didn't set Specific Version to True, then when you install the new ODAC, his applications will start using it (I'm assuming the new Oracle.DataAccess.dll will be installed in the GAC too),
The problem here is not .NET dlls but unmanaged dlls.
I trying to make to work two ASP.NET applications on one server. One is older using ODP.NET 9.x and the new one using the latest ODP.NET. I deployed the newest ODP.NET using xcopy and added the paths to PATH environment variable for the new ODP. Now the old application doesn't work (probably tries to use new dlls). When I remove paths from PATH variable then the new app doesn't work. I found the way to make it work on one server unders IIS on Oracle pages but that didn't work. Maybe because I didn't install newest ODP.NET but just xcopied it. I will have to try it.
What Oracle says about:
Link: http://www.oracle.com/technology/tech/windows/odpnet/faq.html
Many Oracle applications run on Microsoft Internet Information Services (IIS). Previously, IIS was a single process application without the ability to assign a different System Path to each running web application using the same IIS instance. With IIS 6 on Windows Server 2003, IIS supports multiple processes for the same instance. Since each application has its own IIS process, each web application can be assigned a different System Path directory with its own Oracle Home.
Microsoft documentation provides information on IIS worker process isolation and application pools.
To set up multiple active Oracle Homes running concurrently on the same IIS server:
1) Run IIS 6 in worker process isolation mode on Windows Server 2003
2) Deploy one version of the Oracle Client to one application pool and the second version to another application pool. For example, you can have Oracle Client 9.2.0.2 and ODP.NET 9.2.0.2 be used by one application pool. And Oracle Client 9.2.0.4 and ODP.NET 9.2.0.4 can be employed by another application pool. You won't be able to use two active Oracle Homes in the same application pool. Each active Oracle Home must be in a different pool.
3) Set the DLL directory for each worker process to use the appropriate Oracle Home client directory. To do this, within each ASP.NET application, call SetDllDirectory(directory_name) early in the application lifecycle before any Oracle DLLs are called. The SetDllDirectory input variable is the Oracle Home bin directory of the ODP.NET version used. Note: SetDllDirectory is an unmanaged call.
When adding a second WCF service to an existing WCF project, or adding a first WCF service to a project gives me a dialog box "Specified Cast Is Invalid". WCF files are added to the project except interface file. Web.Config isn't updated neither.
I think the problem started after updating VS.NET 2008 to VS.NET 2008 SP1.
You can always reinstall SP1 if you are uncertain about the installation. A successfully install SP1 should not cause this problem.
When we have had problems adding WCF references there have generally been on of the following problems:
Data contracts incorrectly specified, missing a tag [Datamember], [DataContract]...
Is your Interface marked as public?
If you are referencing a DLL with types from both the client and the server, is everything serializable and public. Are you using the same version of the dll on both sides?
Is your contract very large? You may need to increase the buffer sizes to get the information to build the proxy.