locked
Metadata Path not found with EF + WCF Windows Service Host RRS feed

  • Question

  • Hello,

     

    I am using Entity Framework and WCF in a project. I use an architecture in layers. So, the client (web) calls the WCF services that access the EF Object Context. 

     

    My WCF services are hosted in a windows service. The problem is that when the service creates the instance of the object context, the following exception is thrown: "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."

     

    I know that the path of the files (csdl, ssdl, msl) must be corrected in the connectionstring. I know too that the app.config that contains the connectionstring must be in the Windows Service (WCF Host) folder. I have been trying to use relative paths but I always get the same error. I have also tried to copy the metadata files to the windows service bin\debug directory and use the simplest relative path (Ex: ".\FileName.msdl"), but again I got the same error.

     

    The only way that it worked was with an absolute path.

     

    Does anyone know if it is a bug? Am I doing something wrong?

     

    André Magalhães

    Wednesday, August 27, 2008 4:05 PM

Answers

  • You could try to have the schemas embedded in your assembly. Embedded resource loader loops through all assemblies loaded in the current application domain.

     

    What you are experiencing is a known issue and we couldn't make the solution in our first release. For windows services application, when the service starts up,  ".\" actually points to C:\Windows\system32 where services.exe lives, instead of where your WCF service binary is.

     

     

    Thanks,

    Friday, September 5, 2008 10:19 PM

All replies

  • Could you provide the path you are trying to use in your connection string?

     

    I'll work with the prodcut team to get you a better explanation of allowable paths.

     

    Jeff

    Wednesday, August 27, 2008 6:07 PM
  • This is the connectionstring that I use when the files are in "bin\Debug" directory of the service.

     

    connectionString="metadata=.\AppLogDB.csdl|.\AppLogDB.ssdl|.\AppLogDB.msl;provider=System.Data.SqlClient;provider connection string="Data Source=GMSD-ANDREM;Initial Catalog=AppLogDB;Integrated Security=True;MultipleActiveResultSets=True""

     

     

     

     

     

    Wednesday, August 27, 2008 6:16 PM
  •  

    try:

    connectionString="metadata=~\bin\AppLogDB.csdl|~\bin\\AppLogDB.ssdl|~\bin\\AppLogDB.msl;provider=System.Data.SqlClient;provider connection string="Data Source=GMSD-ANDREM;Initial Catalog=AppLogDB;Integrated Security=True;MultipleActiveResultSets=True""

    Thursday, August 28, 2008 5:36 AM
  • I apologize for the delay.

     

    I tried and it didn't work either. I think that it works when using IIS host and the configuration is in the web.config. In my case, the service's host is a windows service.  

     

    Friday, August 29, 2008 3:18 PM
  • You could try to have the schemas embedded in your assembly. Embedded resource loader loops through all assemblies loaded in the current application domain.

     

    What you are experiencing is a known issue and we couldn't make the solution in our first release. For windows services application, when the service starts up,  ".\" actually points to C:\Windows\system32 where services.exe lives, instead of where your WCF service binary is.

     

     

    Thanks,

    Friday, September 5, 2008 10:19 PM
  • Thank you Jing. At least now I understand what is happening. It's good to know that it's a known issue and that in the future it will be fixed.

     

    I have decided to pre-generate views to improve performance. It's why my metadata files are in the file system.

     

    More information:

    http://msdn.microsoft.com/en-us/library/bb896240.aspx

     

    So, in this context I have to use absolute paths with this EF first version. Anyway, it is not a so big problem in my case.

    Saturday, September 6, 2008 10:26 PM