This question already has answers here:
MetadataException: Unable to load the specified metadata resource
(47 answers)
Closed 6 years ago.
This code:
using (EntityConnection conn = new EntityConnection("name=ELSCommonEntities"))
{
conn.Open();
}
Gives me the following error:
Test method ELS.Service.Business.IntegrationTest.Base.ServiceBaseIntegrationTest.StartLoggingTestMethod threw exception: System.Data.MetadataException: Unable to load the specified metadata resource..
With the following stack trace:
System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.LoadResources(String assemblyName, String resourceName, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
System.Data.Metadata.Edm.MetadataArtifactLoader.Create(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
System.Data.EntityClient.EntityConnection.SplitPaths(String paths)
System.Data.EntityClient.EntityConnection.GetMetadataWorkspace(Boolean initializeAllCollections)
System.Data.EntityClient.EntityConnection.InitializeMetadata(DbConnection newConnection, DbConnection originalConnection, Boolean closeOriginalConnectionOnFailure)
System.Data.EntityClient.EntityConnection.Open()
ELS.Service.Business.Base.ServiceBase.StartLogging(String userWindowsLogon) in C:\C-TOM\ELS-RELEASE1\ELS.Service.Business\Base\ServiceBase.cs: line 98
ELS.Service.Business.IntegrationTest.Base.ServiceBaseIntegrationTest.StartLoggingTestMethod() in C:\C-TOM\ELS-RELEASE1\ELS.Service.Business.IntegrationTest\Base\ServiceBaseIntegrationTest.cs: line 65
However, this code which uses the same connection string:
using (ELSCommonEntities db = new ELSCommonEntities())
{
var res = from c in db.Logging
select c;
int i = res.Count();
}
Does not give an error.
The connection string is:
<add name="ELSCommonEntities" connectionString="metadata=res://*/Common.CommonModel.csdl|res://*/Common.CommonModel.ssdl|res://*/Common.CommonModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=els5_demo;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
I have also opened up the dll in reflector and the metadata looks ok.
Found the problem.
The standard metadata string looks like this:
metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl
And this works fine in most cases. However, in some (including mine) Entity Framework get confused and does not know which dll to look in. Therefore, change the metadata string to:
metadata=res://nameOfDll/Model.csdl|res://nameOfDll/Model.ssdl|res://nameOfDll/Model.msl
And it will work. It was this link that got me on the right track:
http://itstu.blogspot.com/2008/07/to-load-specified-metadata-resource.html
Although I had the oposite problem, did not work in unit test, but worked in service.
I had the same error message, and the problem was also the metadata part of the connection string, but I had to dig a little deeper to solve it and wanted to share this little nugget:
The metadata string is made up of three sections that each look like this:
res://
(assembly)/
(model name).(ext)
Where ext is "csdl", "ssdl", and "msl".
For most people, assembly can probably be "*", which seems to indicate that all loaded assemblies will be searched (I haven't done a huge amount of testing of this).
This part wasn't an issue for me, so I can't comment on whether you need the assembly name or file name (i.e., with or without ".dll"), though I have seen both suggested.
The model name part should be the name and namespace of your .edmx file, relative to your assembly.
So if you have a My.DataAccess assembly and you create DataModels.edmx in a Models folder, its full name is My.DataAccess.Models.DataModels. In this case, you would have "Models.DataModels.(ext)" in your metadata.
If you ever move or rename your .edmx file, you will need to update your metadata string manually (in my experience), and remembering to change the relative namespace will save a few headaches.
There are several possible catches.
I think that the most common error is in this part of the connection string:
res://xxx/yyy.csdl|res://xxx/yyy.ssdl|res://xxx/yyy.msl;
This is no magic. Once you understand what is stands for you'll get the connection string right.
First the xxx part. That's nothing else than an assembly name where you defined you EF context clas. Usually it would be something like MyProject.Data.
Default value is * which stands for all loaded assemblies. It's always better to specify a particular assembly name.
Now the yyy part. That's a resource name in the xxx assembly.
It will usually be something like a relative path to your .edmx file with dots instead of slashes. E.g. Models/Catalog - Models.Catalog
The easiest way to get the correct string for your application is to build the xxx assembly. Then open the assembly dll file in a text editor (I prefer the Total Commander's default viewer) and search for ".csdl". Usually there won't be more than 1 occurence of that string.
Your final EF connection string may look like this:
res://MyProject.Data/Models.Catalog.DataContext.csdl|res://MyProject.Data/Models.Catalog.DataContext.ssdl|res://MyProject.Data/Models.Catalog.DataContext.msl;
As Shiraz Bhaiji answered, the metadata=res:///Model.csdl|res:///Model.ssdl|res://*/Model.msl was the case.
However I still had problems with constructing the proper string based on my Model localization, namespaces and assemby name. The very simple solution was to rename the .edmx file in Visual Studio(after than rename and get back to the original name), which triggered the automatic refreshing of the string in my Web.config
I had the same problem with three projects in one solution and all of the suggestions didn't work until I made a reference in the reference file of the web site project to the project where the edmx file sits.
I moved my Database First DataModel to a different project midway through development. Poor planning (or lack there of) on my part.
Initially I had a solution with one project. Then I added another project to the solution and recreated my Database First DataModel from the Sql Server Dataase.
To fix the problem - MetadataException when using Entity Framework Entity Connection. I copied my the ConnectionString from the new Project Web.Config to the original project Web.Config. However, this occurred after I updated my all the references in the original project to new DataModel project.
It might just be a connection string error, which is solved by the above process, but if you are using the dll's in multiple projects then making sure the connection string is named properly will fix the error for sure.
I had this problem when moving my .edmx database first model from one project to another.
I simply did the following:
Deleted the connection strings in the app.config or web.config
Deleted the 'Model.edmx'
Re-added the model to the project.
Related
I am attempting to deploy my SSRS solution. I have set the "TargetReportFolder" property of my project to "Reports"
When I right-click and select "Deploy", I get the following error:
The path of the item '/Reports' is not valid. The full path must be less than 260 characters long; other restrictions apply. If the report server is in native mode, the path must start with slash.
Obviously my path is less than 260 characters long. I've tried setting my TargetReportFolder property to "/Reports", to the name of my project, and to the name of my project with a slash at the beginning - all give the same error.
I don't understand this deployment process very well. Can someone help me understand?
(I also feel like this may not be on topic, but was encouraged by the presence of an SSRS tag)
My problem was that I didn't understand how Reporting Services works with SharePoint. My comment above is incorrect, I did need to deploy, but I had the wrong parameters for my properties. This page helped me:
http://msdn.microsoft.com/en-us/library/bb283155.aspx
The key takeaways from this article are:
All Target*Folder properties need to be either a URL to a document library, or empty
If they are empty, they take the value of TargetReportFolder, which can't be empty and must be a URL to a document library
TargetServerURL needs to be the URL of the site collection in SharePoint
Since I updated today to GAE 1.7.2.1, I'm having validation errors in eclipse in all my jdoconfig.xml files.
I have the default jdoconfig.xml content :
[...]
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">
[...]
And eclipse validation throws:
Referenced file contains errors (http://java.sun.com/xml/ns/jdo/jdoconfig).
For more information, right click on the message in the Problems View and
select "Show Details..."
When clicking on details I can see a bunch of lines like:
s4s-elt-character: Non-whitespace characters are not allowed in schema elements
other than 'xs:appinfo' and 'xs:documentation'. Saw 'var_U = "undefined";'.
In different lines and different content in "Saw ... "
It occurs in every single project I start using the "New Web Application Project..." from the google plugin.
So does anyone have this problem? Any fix?
Try this:
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd">
Per the answer here Validating jdoconfig with incorrect url
The xmlns is not a real file/directory, more a namespace, so ought not exist! The version is appended to get the real XSD file, namely http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
There are a couple problems here.
The syntactic problem is that the URI you are giving as the value of xsi:noNamespaceSchemaLocation is redirected to http://www.oracle.com/technetwork/java/index.html and returns an HTML document. The XSD validator you are using is trying without success to parse
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" />
<script type="text/javascript">
var _U = "undefined";
var g_HttpRelativeWebRoot = "/ocom/";
var SSContributor = false;
...
as an XSD schema document, and for one reason or another its attempts to explain what went wrong focus on finding the string var_U = "undefined" in a place where it was not expecting to see character data.
Then there are some conceptual problems.
Your document is in a namespace named http://java.sun.com/xml/ns/jdo/jdoconfig. Why on earth are you pointing the schema validator to a schema without a target namespace (which is that noNamespaceSchemaLocation does), if you want to validate your document? Given that (at least some of) your document's elements are namespace-qualified, you will want (as joncalhoun has already suggested) to use xsi:schemaLocation and provide a pair telling the validator where it can find a schema document for each namespace you want it to know about.
It's possible that a schema document used to be served from the location http://java.sun.com/xml/ns/jdo/jdoconfig, but since it's apparently the standard namespace named for your vocabulary, that's not actually very likely. Most systems distinguish fairly reliably between namespaces, which are abstract and poorly defined things, and schema documents, which are typically XML documents that define specific XSD schema components for a given namespace. It's not illegal to use the URI for a schema document as the name of a namespace, but it is unusual.
Note that the URL given by joncalhoun for the schema document (http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd) actually does resolve (after redirection to http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/jdo/jdoconfig_3_0.xsd) to a schema document, which specifies http://java.sun.com/xml/ns/jdo/jdoconfig as its target namespace. (This means that even if you did succeed in retrieving this schema document by giving its URI as the value of xsi:noNamespaceSchemaLocation, you'd then get an error because it's not a schema document for elements and attributes with no namespace.)
This makes me think that you should read joncalhoun's answer again and try it again, carefully. If it didn't work when you tried it, my money says that either you tried something similar but not exactly what he suggested, or it solved this problem but that simply exposed some other problem, which is easy to mistake for failure.
One solution is setting XML Catalog in Eclipse preferences.
Details:
Entry element: URI
Location: http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
URI: http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd
Key type: Namespace name
Key: http://java.sun.com/xml/ns/jdo/jdoconfig
The syntactic and conceptual issues C.M. mentions are a problem with the plugin and Google's settings where both recommend,
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig
I don't specifically use jdo but I still get the validation error with this namespace. It was fine with this namespace until just recently.
I used LuboM's method and it worked for me. Neither LuboM's nor joncalhoun's is the answer though since it ties me in to jdo 3.0
Oracle is going to have to provide the fix. Apparently their intent was to resolve the namespace issues themselves across versions of jdo.
This is what I did to fix it:
<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig_3_0.xsd">
I am success on this:
Right Click Project -> Properties -> Validation -> XML Syntax
Enable Project Specific Settings (If you need)
Under Validating Files, For No grammar Specified Select "Warning"
Click "Ok"
If you ask for Validating the file, Click "Yes"
You can do the same for all the projects by going to Windows -> Preferences.
Make sure you are validating the file (Step 4).
I had the same issue, and excluded just this jdoconfig.xml file from Eclipse's validation. Even though your Eclipse throws an error for it, it in no way affects being able to deploy the project to GAE correctly.
Here is how to exclude just the jdoconfig.xml file to get rid of that pesky error:
Right click on your Eclipse Project, ->Properties->Validation->XML Validator, click on the "..." button for further options.
You should see Include Group and Exclude Group options. Click Exclude Group->Add Rule...->Folder or file name, and browse to your file.
Clean or rebuild your project. The validation error should be gone.
This worked for me in Eclipse Luna.
You might have try this path to solve your problem:
<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">
I have 'inherited' a test harness application which uses Enterprise Library for its SQL data access. In the app.config file (enterpriselibrary.configurationSettings), it references a "configurationSection" with a path to "dataConfig.config", which is encrypted. I would like to change the database connection properties, but EntLibConfig.exe will not open the dataConfig.config or app.config (I have the FileKeyAlgorithmPairStorageProviderData file).
The test harness application runs, so its configured ok.
I can, in code, using (Microsoft.Practices.EnterpriseLibrary.Data.Configuration.ConfigurationManager.GetConfiguration("dataConfiguration")) read the data configuration, and can navigate all the instances and connection strings (security isn't an issue for this test harness). I can dump everything I need to a hand-crafted XML file (using GetType().AssemblyQualifiedName to get the full name for the classes which read the config file) and then change the app.config to read my new, unencrypted, xml dataConfig file.
All is fine, I can now change my database config settings.
However... given that ConfigurationManager.GetConfiguration("dataConfiguration") returns a fully populated instance of a DatabaseSettings object, is there not a method I can call which will write the XML file (dataConfig.config) for me ?
I appreciate that this is probably a really big hammer way to edit the data configuration, but after half a day of trying, I fell back on the old coding maxim... if you can't find the tool to do what you want, write your own !
Thanks
Well... turns out that its not that hard.
I added a new "configurationSection" to my app.config (dataConfiguration2), with encrypt set to false, with a path pointing to an new empty text file (dataConfiguration.config2). I then copied my encrypted dataConfiguration details using the following code:
using Entlib = Microsoft.Practices.EnterpriseLibrary.Configuration;
using Microsoft.Practices.EnterpriseLibrary.Data.Configuration;
:
DatabaseSettings settings = (DatabaseSettings)Entlib.ConfigurationManager.GetConfiguration("dataConfiguration");
Entlib.ConfigurationManager.WriteConfiguration("dataConfiguration2", settings);
...and it filled the empty file with the (unencrypted) configuration details.
I recently had to edit my app.config file to change the connection string for an Entity Framework data model (.edmx file). But I'd like to know: Is there a way to edit the EF connection string using the designer?
The original connection string is auto-generated by the Entity Data Model wizard. The connection string then cannot be changed - it remains disabled in the properties window of the .edmx designer. I like to avoid editing XML by hand if I can (in app.config), so I was wondering if there is a way to get back into the original wizard screen to make connection string changes and let the tool edit the app.config file for me.
If you remove the connection string from the app.config file, re-running the entity Data Model wizard will guide you to build a new connection.
No, you can't edit the connection string in the designer. The connection string is not part of the EDMX file it is just referenced value from the configuration file and probably because of that it is just readonly in the properties window.
Modifying configuration file is common task because you sometimes wants to make change without rebuilding the application. That is the reason why configuration files exist.
You normally define your connection strings in Web.config. After generating the edmx the connection string will get stored in the App.Config. If you want to change the connection string go to the app.config and remove all the connection strings. Now go to the edmx, right click on the designer surface, select Update model from database, choose the connection string from the dropdown, Click next, Add or Refresh (select what you want) and finish.
In the output window it will show something like this,
Generated model file: UpostDataModel.edmx.
Loading metadata from the database took 00:00:00.4258157.
Generating the model took 00:00:01.5623765.
Added the connection string to the App.Config file.
Follow the next steps:
Open the app.config and comment on the connection string (save
file)
Open the edmx (go to properties, the connection string
should be blank), close the edmx file again
Open the app.config and uncomment the connection string (save file)
Open the edmx, go to properties, you should see the connection string uptated!!
Open .edmx file any text editor change the Schema="your required schema" and also open the app.config/web.config, change the user id and password from the connection string. you are done.
I'm doing a very non-standard build of Entity Framework. I've used EdmGen2 to generate edmx off of a db, and split the component csdl, msdl and ssdl files into their own files. The metadata in the connection string to them looks like this:
C:\Downloads\EDM | filename.csdl | filename.msdl | filename.ssdl
I have a unit test that does nothing but try to open the connection, and I get this error (along with a lot of other chaff):
"Each type name in a schema must be unique"
If I go into the csdl manually and add a "1" to the names, it eventually moves onto the msdl file and starts complaining about it. Clearly, somehow the schema is getting double-defined in the open operation...
There is no reference to the edmx in the test or dependent project. In fact, there are no references to any of those, as this is a project for generating all this stuff dynamically at run-time.
I've seen the Julie Lehrman / Don't Be Iffy post, and it doesn't appear to be that problem.
TIA...
Figured it out...the Metadata workspace is apparently hard coded to look for the three files (which makes sense), and when I removed the directory specification in the metadata tag, it all started working. My metadata attribute now looks like this:
C:\Downloads\filename.csdl | C:\Downloads\filename.msdl | C:\Downloads\filename.ssdl
So I think it's an either / or proposition: either specify the directory where the files are located, or the individual file locations.