I've inherited a C#/NHibernate/MS SQL Server project and am new to NHibernate. One of the first tasks given to me was to migrate the database from MS SQL Server (2008 R2) to Postgresql 9.2. I'm using the Npgsql 2.0.12 (.net 2.0 version). The Mono.Security.dll and Npgsql.dll are included in my project References and they exist in my bin directory. When the code executes the following line:
SessionFactory.OpenSession();
an exception is thrown with the message
"Could not create the driver from NHibernate.Driver.NpgsqlDriver."
Searching the web, gave me a few ideas but none have worked. This code I've inherited is in production at several clients with no issues using MS SQL Server. Here is my hibernate.cfg.xml file:
<?xml version="1.0" encoding="utf-8"?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.PostgreSQLDialect</property>
<property name="connection.driver_class">NHibernate.Driver.NpgsqlDriver</property>
<property name="connection.connection_string">server=localhost;Port=5432;Database=vehicletracker;User Id=postgres;Password=********;</property>
</session-factory>
</hibernate-configuration>
I did not forget to include "using Npgsql;", it is there. Any suggestions?
Regards,
B
I found the answer to my own question. There were several issues specific to my work environment but ultimately the Mono.Security.dll and Npgsql.dll were not available in my final output directory. The two files were present in the bin directory of my Data Access Layer (a class library) but not in the bin directory of my Test Project that called the class library. Everything is working fine now.
If you're using NuGet for the nhibernate libraries try uninstalling the packages and reinstall them. I'm sure there is a more efficient way someone knows of to fix this kind of issue but for me it solved this exact issue.
Related
I am building an Eclipse RCP-based product, and I am running into an issue where when I try to use the built-in p2 UI to install updates to the product, I get an error message in the dialog that "Insufficient access privileges to apply this update."
I have debugged into Eclipse and found that the 'root cause' is that there is a p2 .profile file that has xml that includes this snippet:
<iuProperties id='com.datical.db.ui.product' version='1.33.0.201412032223'>
<properties size='4'>
<property name='org.eclipse.equinox.p2.internal.inclusion.rules' value='STRICT'/>
<property name='org.eclipse.equinox.p2.type.root' value='true'/>
<property name='org.eclipse.equinox.p2.type.lock' value='3'/>
<property name='org.eclipse.equinox.p2.base' value='true'/>
</properties>
</iuProperties>
The relevant line is the one that says <property name='org.eclipse.equinox.p2.type.lock' value='3'/>
I'm not sure what I am doing wrong - I think I must have something awry in my product definition or my feature definition or in my install process that is causing this line to be there.
When I step through the Eclipse code (our target environment is 3.7/Indigo) I see that the profile is being written inside org.eclipse.equinox.internal.p2.engine:SurrogateProfileHandler:addSharedProfileBaseIUs (which is private static.) That is called from SurrogateProfileHandler:createProfile
The product's p2 repository is being built using the tycho plugins, version 0.15.
We finally discovered another piece of information that may be relevant. We were using a custom OSGI directory name. When we removed that, everything started working as expected.
It seems that you have a shared install where the product you would like to update is (potentially) used by many installations as a base - and therefore cannot be updated.
This kind of problem goes beyond what can be answered well on stackoverflow because you'd really need to provide an example project and exact steps to reproduce the problem.
The most plausible cause for the symptoms you are seeing is some kind of file system permission problem. This documentation mentions that you need write permission to the installation directory for running Eclipse with -initialize. Maybe you are lacking some permissions making some of the -initialize procedure fail and leave the installation in an inconsistent state.
My pre-generated views for EF4 Code First using this T4 template does not work in the build server. I am not re-generating the view in the build server, just compile and run the MSTest. Error is thrown when the tests are ran:
System.Data.MappingException: The mapping and metadata information for
EntityContainer 'DB' no longer matches the information used to create
the pre-generated views
I ran the same template in another machine and the hash values are different. I guess this is the reason why its it does not work in the build server. The hash values are different at runtime in other machines, hence the verification fails and throws the exception.
Im using:
VS 2010 Pro
.Net Framework v4.0.30319
Entity Framework v4.2 (Code First)
EF CodeFirst View Generation T4 Template for C# (v1.0.1) - slightly modified GetEdmxSchemaVersion to return the correct EntityFrameworkVersions version for my setup.
using Class Library project template
The tests that I am running connects to a SQL DB file that is checked in with the code.
I have checked the build server and its using the same EF dll version and .Net Framework version.
Any idea why the hash values are different?
UPDATE:
I've generated and compared two XML file from two dev machines using EdmxWriter.WriteEdmx().
Here is schema version (the same in both machine):
<?xml version="1.0" encoding="utf-8"?>
<Edmx Version="2.0" xmlns="http://schemas.microsoft.com/ado/2008/10/edmx">
The obvious difference are the order some nodes in the XML files. Here is an example:
Machine 1:
<EntityType Name="PersonEntity" BaseType="Self.Entity" />
<EntityType Name="CompanyEntity" BaseType="Self.Entity" />
Machine 2:
<EntityType Name="CompanyEntity" BaseType="Self.Entity" />
<EntityType Name="PersonEntity" BaseType="Self.Entity" />
Any idea why they are in different order?
UPDATE 2:
The Edmx (xml) from the build server is also different for the other 2 dev machines. Again, the order of some nodes are different.
Machine 1 and build server both have System.Data.Entity.dll (same File and Product version -- v4.0.30319.1) in %windir%\Microsoft.NET\assembly\GAC_MSIL\System.Data.Entity\v4.0_4.0.0.0__b77a5c561934e089.
UPDATE 3:
I also looked at the version of System.Data.Entity.Design.dll. The T4 template references this assembly. Machine 1 has two copies of this dll ... in GAC (v4.0.30319.233) and in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0 (v4.0.30319.1). This is also true in the build server and Machine 2. I wonder if hash validation function during runtime is using this dll as its not referenced in my project. If it does, which version is used. But then again, the hash validation is successful in Machine 1.
I'm answering my own question. Here's how we solve the main problem (how to pre-generate views in EF Code First that is usable in different machines). I am now using .Net runtime 4.0.30319.17929.
In the ABC.csproject where MyContext.cs is located, delete the T4 template and MyContext.Views.cs.
Compile ABC.csproject
Create a console app that will generate the views. I copied most of Pawel's T4 template. Reference the ABC.dll (and other required dlls). Here's one of the changes:
var edmx = GetEdmx(typeof(MyContext));
Save the string output of GenerateViews() to a text file.
Run the console app.
Add new file named MyContext.Views.cs to ABC.csproject and copy the content of the text file to this class.
Recompile ABC.csproject
I find my solution insane and must be simplified or automated but it works.
I've recently upgraded a WFC project that uses Entity Framework from v4.3.1 to 5.0.
I'm running Coded migrations only (no automatic migrations).
Previously, I was using the Publish Profiles to deploy this solution and apply the migrations. Since upgrading the project to EF5, the migrations portion no longer works and the publish dialog doesn't detect the context as having code-first migrations.
Specifically, the .pubxmlfile changed from detecting my context as <Object Type="DbCodeFirst">to <Object type="DbDacFx"> which is incorrect for my context.
As a workaround, I've manually added the <entityFramework> database initializer configuration to my web.config transforms, but I'd like to understand why the publish profiles aren't working. That was a much nicer solution.
It once happened on me when merging another developer's commit and triggered Visual Studio project reload. That's how it caused the "DbCodeFirst" to "DbDacFx" change.
If I restart Visual Studio then everything goes back to what it should be.
Just another thought.
You probably missed adding the reference to EntityFramework into your project. By just adding the reference you should be able to control whether or not the DbCodeFirst option is available or not.
As this post suggests, try using the fully-qualified name of your DbContext as the name of the connection string. Instead of:
Web.config
<connectionStrings>
<add name="MyContext" .../>
</connectionStrings>
Use:
Web.config
<connectionStrings>
<add name="MyNamespace.AnotherNamespace.MyContext" .../>
</connectionStrings>
In my case, in order to use my existing publish profiles (.pubxml), I also had to manually edit the <ObjectGroup Name="..." ...>. Probably recreating the publish profiles would work too.
I had the same issue but not in the same context.
I had been using Code First Migrations with existing ASP.NET MVC 5.2.3 application using EF 6.1.3 for a month without issues. At one point in time I added support for Windows Azure Storage but I made some mistakes:
I added a new project. Unfortunately I chose "Console Application" instead of "Class Library". I tried to fix it by changing it back to "Class Library" in "Project Settings"
I used Nuget to Install-Package WindowsAzure.Storage but I installed it on the MVC project and not on the class library. I tried to fix it by doing Uninstall-Package on the MVC project and installing it to the correct project
I called the class in the class library "WorkOrderStorage"
I added the connectionString to <connectionStrings> element in web.config and a transformation in web.release.config
I guess my project was now in an inconsistent state. I noticed that it would forget about Code First Migrations (I monitored the changes to the .pubxml file):
when I put a reference between the MVC project and the library
containing the WorkOrderStorage class
when I created an empty 'WorkOrderStorage' class in one of the existing libraries
In the end I fixed it by recreating this library correctly from scratch as a class library (because of observation 1). I also named the class WorkOrderRepository (because of observation 2).
I'm trying to mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0 and I keep getting the following errror:
The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.Test\obj\Debug\Moles\ssm\m.g.csproj] my-test-project.Test\m.g.cs 293022 43
This interface appears to have been removed from System.ServiceModel.dll in .NET 4.0 as I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when I search in the Object Browser.
I'm able to reproduce this via the cmdline using moles.exe and I've tried altering the moles file to only generate type names I specify but it doesn't appear to make any difference. This was working fine prior to my upgrade to VS2010 SP1 so I suspect it's a bug, but any help would be appreciated.
Thanks
Nick
I debugged this on my own as well and found that the root cause appears to be that VS2010 SP1 (and the related GDR KB update for .NET 4) update one set of DLLs but not another:
The System.ServiceModel.dll in %ProgramFiles(x86)%\Referenced Assemblies\ doesn’t match the one in the .NET v4 install at %windir%\Microsoft.NET\Framework64\v4.0.30319...
Post VS 2010 SP1 update:
%Program Files(x86)%\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.ServiceModel.dll -> File version 4.0.30319.1
%windir%\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll -> File version 4.0.30319.225
Comparing these two dlls in the Object Browser in VS as well as in Reflector yields the result that the IHttpCookieContainerManager interface has been removed in the newer file. So I suspect that this is a combination of .NET probing finding the newer DLL and Moles reflecting over the older one when doing mole/stub generation. I was able to manually generate a Moles dll for the newer DLL by running the Moles exe manually with no reference paths of any kind as opposed to the MSBuild target that adds a bunch of ref paths during a build.
I don't know why that happens, but I had the same issue, and I resolved it by using Moles type filters, and only including the ones I really need (which has the nice side-effect of speeding up compilation quite a lot!!). This is an example .moles file I'm using:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System.ServiceModel"/>
<StubGeneration>
<Types>
<Clear/>
<Add Namespace="System.ServiceModel.Description!"/>
</Types>
</StubGeneration>
</Moles>
It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles was using for compilation.
I had recently installed the Microsoft .NET Framework 4.5.
After uninstalling this and re-installing 4.0 everything worked.
Well, in case anyone is working with legacy code and happens to be cornered into using Microsoft Moles, I've done extensive digging on this topic and hope to save some from the anger and frustration I encountered.
I tried using the accepted answer's suggestion, which meant going to the Moles directory (in C:\Program Files..) and running the command line utility (moles.exe) as Administrator. There a lot of options, one of which allows you to include referenced assemblies (as suggested above).
However, even when trying to run the utility without referenced assemblies, the utility ultimately calls the C# compiler (csc.exe) with pre-defined referenced assembly paths, which is where I conclude that the confusion between .NET Framework versions occurs. I couldn't get it not to include these assembly paths.
My specific scenario was that I was trying to Mole a custom assembly, however because, apparently, I had .NET 4.5 installed on this machine, it was complaining upon compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think one other.
Solution: The only solution I got to work was to use Mole filters, which I read about on other posts and on the Microsoft Moles website (there is a special link for .NET 4.5 troubleshooting on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my referenced custom assembly via right click in Solution Explorer. I then tried to build. For each error I received, I noted the offending classes and excluded them from being Shimmed or Stubbed by adding the following to the moles file:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name = "MyCustomAssembly" />
<StubGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</MoleGeneration>
</Moles>
Now clearly that's not going to work if you need the classes that you're excluding from mole/stub generation, however for my case it worked fine because the offending classes were not important and I wouldn't be needing to Stub or Shim anything in those classes.
I created a template project named sample and started it with spring tc server. The application gets deployed but then when I go to http://localhost:8080/sample/ I get the following error
INFO: Server startup in 12669 ms
WARN : org.springframework.web.servlet.PageNotFound - No mapping found for HTTP request with URI [/sample/] in DispatcherServlet with name 'appServlet'
I followed the same steps as shown in http://www.youtube.com/watch?v=Y0V4oEnCcyA to create a spring web App.
I asked my friend to follow the same steps and test it on his Ubuntu 10.04 machine and it worked fine out of the box. I came up with the conclusion that it must be something with my machine. I'm facing this problem on Mac osx 10.4 and
SpringSource Tool Suite
Version: 2.6.0.RELEASE
My host file contains the following entry
127.0.0.1 localhost
Can anyone guide me as to how to rectify this problem?
Thanks.
That warning means that you didn't set something up right in your project, plain and simple. Without code we can only guess.
Speaking of guessing, check your web.xml and make sure it actually says "sample".
Template project does not work for me either.
I changed the servlet mapping onto
<servlet-mapping>
<servlet-name>appServlet</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
Follow up the request mapping in the controller
#RequestMapping(value = "/home.do", method = RequestMethod.GET)
Now you can open http://localhost:8080/sample/home.do
Check the log in your eclipse server console window (bottom screen). If you're like me, there's a bug when resolving the path for the home.jsp file. It comes from the servlet-context.xml file :
<beans:property name="suffix" value="/" />
should be
<beans:property name="suffix" value=".jsp" />
Make sure you clean and restart the server after doing that change, because it seems like this servlet-context.xml file is heavily cached.