PostgreSQL LINQ to Entities Framework model not working

PostgreSQL LINQ to Entities Framework model not working

Postby TonyV » Thu 18 Aug 2011 20:51

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

          providerName="System.Data.EntityClient" />


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
 
Posts: 74
Joined: Wed 25 May 2011 15:03

More info

Postby TonyV » Fri 19 Aug 2011 18:43

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
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby StanislavK » Tue 23 Aug 2011 11:43

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.
StanislavK
Devart Team
 
Posts: 1710
Joined: Thu 03 Dec 2009 10:48

Update. One problem resolved but another exists.

Postby TonyV » Tue 23 Aug 2011 14:44

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
 
Posts: 74
Joined: Wed 25 May 2011 15:03

app.config

Postby TonyV » Tue 23 Aug 2011 14:52

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


 
   Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
   
   Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
    
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
   
 
 
   
   res://LPRDataAccess/CarSystemModel.ssdl|
res://LPRDataAccess/CarSystemModel.msl;
provider=Devart.Data.PostgreSql;provider connection string=&quot;User
Id=CarSystem;
Password=ELSAGelsag;
Host=BREW-LAB-04;
Database=CarSystem;Persist Security Info=True;Schema='&quot;&quot;CarSystem&quot;&quot;'&quot;"
       providerName="System.Data.EntityClient" />
   
   connectionString="User Id=CarSystem;
Password=ELSAGelsag;
Host=BREW-LAB-04;
Database=CarSystem;
Persist Security Info=True;
Schema='&quot;CarSystem&quot;'"
       providerName="Devart.Data.PostgreSql" />
   
   connectionString="User Id=CarSystem;
Password=ELSAGelsag;
Host=BREW-LAB-04;
Database=CarSystem;
Schema=security"
       providerName="Devart.Data.PostgreSql" />
 

 
   
    
              invariant="Devart.Data.PostgreSql"
         name="dotConnect for PostgreSQL"
         type="Devart.Data.PostgreSql.PgSqlProviderFactory, Devart.Data.PostgreSql, Version=5.30.172.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
   

 


 
   
               hashAlgorithmType="SHA1"
            userIsOnlineTimeWindow="15">
    
      
      
                type="EOCSecurityModel.Custom.EocMembershipProvider, EOCSecurityModel"
          connectionStringName="PgSqlServices"
          enablePasswordRetrieval="false"
          enablePasswordReset="true"
          requiresQuestionAndAnswer="false"
          requiresUniqueEmail="false"
          passwordFormat="Hashed"
          maxInvalidPasswordAttempts="5"
          minRequiredPasswordLength="6"
          minRequiredNonalphanumericCharacters="0"
          passwordAttemptWindow="10"
          applicationName="/" />
    

   

             defaultProvider="AspNetPgSqlProfileProvider"
          enabled="true"
          inherits="CarSystem.Properties.UserProfile, CommonCode">
    
      
                connectionStringName="PgSqlServices"
          name="AspNetPgSqlProfileProvider"
          type="Devart.Data.PostgreSql.Web.Providers.PgSqlProfileProvider, Devart.Data.PostgreSql.Web" />
    

   

                cacheRolesInCookie="false"
             cookieName=".ASPROLES"
             cookieTimeout="30"
             cookiePath="/"
             cookieProtection="All"
             defaultProvider="EOCRoleProvider">
    
      
      
                connectionStringName="PgSqlServices"
          name="EOCRoleProvider"
          type="EOCSecurityModel.Custom.EocRoleProvider, EOCSecurityModel" />
    

   

 

 
   
    
      1234
    

    
      80fdc536-581a-4ee2-8563-cfba2fa6e94a
    

    
      Car54
    

    
      Car54
    

    
      False
    

   

 

 
   
 

 
   
    
      
    

    
      
    

   

 


TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby Shalex » Thu 22 Sep 2011 13:06

"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

TonyV wrote: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.
Shalex
Devart Team
 
Posts: 7659
Joined: Thu 14 Aug 2008 12:44

Questions about fix

Postby TonyV » Wed 16 Nov 2011 14:00

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
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby Shalex » Fri 18 Nov 2011 09:32

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.
Shalex
Devart Team
 
Posts: 7659
Joined: Thu 14 Aug 2008 12:44

That breaks my project on Windows 7

Postby TonyV » Fri 18 Nov 2011 16:13

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
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby Shalex » Tue 22 Nov 2011 11:37

TonyV wrote: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?
Shalex
Devart Team
 
Posts: 7659
Joined: Thu 14 Aug 2008 12:44

Response

Postby TonyV » Tue 22 Nov 2011 15:29

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
   providerName="System.Data.EntityClient" />


3. The exception was generating when running the application.

Tony
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03

Postby Shalex » Wed 23 Nov 2011 17:42

TonyV wrote: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\*.*


TonyV wrote:2c. Here is the connection string before and after changing the setting:
Code: Select all
   providerName="System.Data.EntityClient" />

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
   providerName="System.Data.EntityClient" />

Notify us about the results.
Shalex
Devart Team
 
Posts: 7659
Joined: Thu 14 Aug 2008 12:44

Issue is resolved

Postby TonyV » Fri 02 Dec 2011 16:10

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
TonyV
 
Posts: 74
Joined: Wed 25 May 2011 15:03


Return to dotConnect for PostgreSQL