PostgreSQL LINQ to Entities Framework model not working

[TonyV]

I've got a program that I've been developing on a Windows 7 desktop, sing .NET 4.0, PostgreSql 9.04, and Devart's dotConnect version 5.30.172.0. I also have an Entity Framework 4 model that I created from the PostgreSql database using Entity Developer. Everything has been running fine on my development machine to date & is still running fine there.

This software needs to run on Windows XP. So I set up a vitual machine running XP on my workstation. The program has been crashing during the initialization phase, so today I installed Visual Studio 2010 on the VM & debugged the code.

I've traced the issue into the Entity Framework. My first call to instantiate the model has been terminating. I've added a try-catch around the constructor call and, with the help of Google, I've worked through one issue after another, including not having all required assemblies copied into the bin/Debug folder, adding a missing configuration section to app.config, and adding a licenses.licx file to the application.

The latest issue I'm having has to do with the meta data in the Entity Framework connection string. Here's the stack trace for the exception:

Code: Select all

Unable to load the specified metadata resource.
   at System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.LoadResources(String assemblyName, String resourceName, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
   at System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
   at System.Data.Metadata.Edm.MetadataArtifactLoader.Create(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
   at System.Data.Metadata.Edm.MetadataCache.SplitPaths(String paths)
   at System.Data.Common.Utils.Memoizer`2.c__DisplayClass2.b__0()
   at System.Data.Common.Utils.Memoizer`2.Result.GetValue()
   at System.Data.Common.Utils.Memoizer`2.Evaluate(TArg arg)
   at System.Data.EntityClient.EntityConnection.GetMetadataWorkspace(Boolean initializeAllCollections)
   at System.Data.Objects.ObjectContext.RetrieveMetadataWorkspaceFromConnection()
   at System.Data.Objects.ObjectContext..ctor(EntityConnection connection, Boolean isConnectionConstructor)
   at System.Data.Objects.ObjectContext..ctor(String connectionString, String defaultContainerName)
   at CarSystem.LPRDataAccess.DataModel.CarSystemEntities..ctor() in C:\ElsagTFS\EOC4\Client UI\LPRDataAccess\CarSystemModel.Designer.cs:line 77
   at CarSystem.LPRDataAccess.DataAccessModel..ctor() in C:\ElsagTFS\EOC4\Client UI\LPRDataAccess\DataAccessModel.cs:line 43

The Entity Framework model is in an assembly called LPRDataAccess.Dll. This is a project in the solution. Here's what the connection string in the app.config looks like:

Code: Select all

As I've said, this works fine on my development machine but fails on the XP machine. I think this is because of the "*" in the resource URI. Can someone tell me what I should be entering in place of the "*" or if there's something else I'm doing wrong?

Thanks

Tony

[TonyV]

I have tried changing the connection string so it reads:

Code: Select all

metadata=res://LPRDataAccess.dll/CarSystemModel.csdl| ... 

with no success. Everything still runs fine on my development platform where dotConnect for PostgreSQL is installed and fails on a box that does not have dotConnect installed. I'm still getting the metadata not found exception.

I've even used .Net Reflector to confirm that the .csdl, .ssdl and .msl files are in the LPRDataAccess.dll file's resources, and they are there. The assembly is NOT strongly typed, so I don't think I need to specify a version and token.

The interesting thing is that when I let the program rethrow the exception, I get another one that complains about an invalid license because of problems with the dotConnect for PostgreSql installation. Of course, it's not installed on thta machine -- the DLLs are all in the bin\debug folder.

Please help.

Tony

[StanislavK]

The asterisks mean that the metadata resources can be embedded into any assembly of the solution. To qualify the path to these resources more precisely, you can replace the asterisks by the assembly name (without the extension, e.g. "metadata=res://LPRDataAccess/CarSystemModel.csdl..." )

To check if the issue is related to the technical license, please try opening the compiled assembly in Reflector and check if the license resource is embedded into either the main library or the DAL one. Please tell us about the results.

Additionally, you can send us a small project or a compiled executable, with which the problem can be reproduced, so that we are able to analyze the issue in details.

[TonyV]

I have been testing this by building the appliction in Visual Studio 2010 installed on a virtual machine that is running Windows XP. I have installed .NET Reflector on the VM & built the application. The .csdl, .msl, and .ssdl files are not in the LPRDataAccess.dll's resources in this build.

I have built the application on my own workstation, which has the complete dotConnect package installed on it. Then I copied the executables generated by a build of the project to the VM. This runs but runs into another issue which is occurring on my workstation as well.

This error has to do with dbMonitor. I downloaded it and installed it on my workstation. In the MainWindow of the WPF application project, I added a call to instantiate a PgSqlMonitor object. Then, in the initialization sequence, I try to retrieve a row from one of the tables in the database. I am receiving a System.Data.EntityException, with an inner exception of type Devart.Data.PostgreSql.PgSqlException, "No connection could be made because the target machine actively refused it 127.0.0.1:5432".

I have seen this error on my workstation since last Friday when I started trouble shooting problems with getting my application to run on XP. I was making changes to the app.Config file when this issue started. When I run DbMonitor, this error does not occur. I have attached my app.config to this post; can you please look at it & let me know what I might have in it that could be causing this issue?

Thanks

Tony[/list]

[TonyV]

I couldn't find any "attach file" button on the post. I guess it's because the code section I inserted in the first post made the posts too wide for the page design.

Here's the app.config as plain text.

Code: Select all

  
	
	  
	
	
	  
	
  
  
	
	
	
	
	
	
  
  
	
	  
	  
	
  

  
	
	
	  
		
				-->
		
		
	  
	
	
	  
		
		
	  
	
	
	  
		
				-->
		
		
	  
	
  
  
	
	  
		1234
	  
	  
		80fdc536-581a-4ee2-8563-cfba2fa6e94a
	  
	  
		Car54
	  
	  
		Car54
	  
	  
		False
	  
	
  
  
	
  
  
	
	  
		
	  
	  
		
	  
	
  

[Shalex]

"MetadataException: Unable to load the specified metadata resource." is a message of Entity Framework run-time, which tries to find and load metadata that is mentioned in connection string. The dotConnect for PostgreSQL code is not used yet.

Please refer to these threads and try its suggestions:
http://www.devart.com/forums/viewtopic.php?t=14973
http://www.devart.com/forums/viewtopic.php?t=18544

I am receiving a System.Data.EntityException, with an inner exception of type Devart.Data.PostgreSql.PgSqlException, "No connection could be made because the target machine actively refused it 127.0.0.1:5432".

I have seen this error on my workstation since last Friday when I started trouble shooting problems with getting my application to run on XP. I was making changes to the app.Config file when this issue started. When I run DbMonitor, this error does not occur.

This is a designed behaviour. Please do not create an instance of PgSqlMonitor in your code if the dbMonitor tool is not launched.

[TonyV]

I have been busy working on other issues and I just now came back to look at this one. Just to be clear about my current environment, my workstation is running Windows 7 64 bit. My application is built using the .NET Framework 4.0.

I just checked on my workstation and the Devart.Data.Entity.targets and Devart.Data.Entity.Build.Tasks.dll files are in C:\Program Files (x86)\MSBuild\Devart\v3.5. They are not in the %Windows%\Microsoft.NET\Framework\v3.5 folder.

Should I copy these files into the %Windows%\Microsoft.NET\Framework\v3.5 folder?

The meta data resource files created by the Entity Developer are definitely in the executable's resources when I build them on this workstation. Everything works fine when I run the program on Windows 7. I don't understand why the program can't find them when it runs on XP.

Again, the problem only occurs when I try to run my executable, created on Windows 7 64 bit, on 32 bit Windows XP.

Tony

[Shalex]

Please try copying metadata to output directory instead of embedding it in your assembly: select your model in Model Explorer > navigate to the Properties window > set Metadata Artifact Processing to CopyToOutputDirectory.

[TonyV]

I set that property in the Model Explorer to Copy To Output Directory and now I get an exception in Windows 7:

The specified metadata path is not valid. A valid path must be either an existing directory, an existing file with extension '.csdl', '.ssdl', or '.msl', or a URI that identifies an embedded resource.

This error occurrs during the call to the context object's constructor.

I've tried refreshing the design from the database and regenerating the design.cs file. Now it just crashes without throwing an exception.

I've put everything back to the way it was and at least its working in Windows 7.

Tony

[Shalex]

I set that property in the Model Explorer to Copy To Output Directory and now I get an exception in Windows 7:

The specified metadata path is not valid. A valid path must be either an existing directory, an existing file with extension '.csdl', '.ssdl', or '.msl', or a URI that identifies an embedded resource.

Please answer to the following questions to help us to identify if there are problems with our build action:
1. Were the '.csdl', '.ssdl', and '.msl' files generated in bin\Debug of your project after setting Metadata Artifact Processing=CopyToOutputDirectory? Have you deployed your application with these files?
2. Connection string:
a) was your connection string changed after setting CopyToOutputDirectory?
b) are you using the context constructor without parameters (connection string is taken from *.config) or with parameters (you create and pass connection string yourself)? Try the constructor without parameters;
c) post here your connection string (roughly, without credentials) before and after setting CopyToOutputDirectory.
3. You have got an exception in Windows 7 when running application in VS or in deployment?

[TonyV]

First, a little info about my solution. The Entity Framework model lives in a Class Library project. The executable is in a totally separate, WPF application project within the same solution.

1. The .csdl, .ssdl and .msl files were indeed generated in the bin\Debug folder of the class library project. These were NOT copied to the bin\Debug folder of the WPF application project, however.

2a. The app.config file is in the WPF application project. It does not appear that the connection string is changing.

2b. I am only using the constructor without parameters.

2c. Here is the connection string before and after changing the setting:

Code: Select all

3. The exception was generating when running the application.

Tony

[Shalex]

1. The .csdl, .ssdl and .msl files were indeed generated in the bin\Debug folder of the class library project. These were NOT copied to the bin\Debug folder of the WPF application project, however.

Please copy the .csdl, .ssdl and .msl files to WPF's bin\Debug manually OR set the following commands in pre-build event of your WPF project:

Code: Select all

cd d:\PATH_TO_CLASS_LIBRARY_PROJECT\bin\Debug\copy *.* d:\PATH_TO_WPF_PROJECT\bin\Debug\*.*
cd d:\PATH_TO_CLASS_LIBRARY_PROJECT\bin\Release\copy *.* d:\PATH_TO_WPF_PROJECT\bin\Release\*.*

2c. Here is the connection string before and after changing the setting:

Code: Select all

Here is a difference between the metadata parts of connection strings depending on the Metadata Artifact Processing values:
a) Embed in Output Assembly -
metadata=res://CarSystemModel.csdl|res://CarSystemModel.ssdl|res://CarSystemModel.msl;
b) Copy to Output Directory -
metadata=.\CarSystemModel.csdl|.\CarSystemModel.ssdl|.\CarSystemModel.msl;

Please open the *.config file of your WPF application and change the connection string as follows:

Code: Select all

Notify us about the results.

[TonyV]

I'm still using the EmbedInOutputAssembly Metadata Artifact Processing setting, but the application now runs fine on XP.

The machine I'm using now is not the same one I was using when this issue began, so it was probably some kind of configuration issue with that machine that kept it from working.

This machine was a fresh install of XP with all of the latest updates applied. I had to install .NET Framework 4.0 on the machine before I could get my code to work. Plus I had to correct the issues from my recent thread about licensing and wrong version exceptions occurring. Once all of those were corrected, everything ran fine.

Thank you for all of your help!

Tony