I have a solution (WCF service) that has many Entity Framework modules in it. Each dll is named differently.
When I (and my co-workers) run this locally it all works fine. When we run the auto build and copy the files to a Dev Server it all works fine.
But when we copy the files to a Test Server I get an error:
Resolution of the dependency failed, type = "OrderManagementInterfaces.IOrderModel", name = "(none)".
Exception occurred while: Calling constructor OrderDAL.OrderEntities(System.String connectionString).
Exception is: MetadataException - Schema specified is not valid. Errors:
OrderDataModel.csdl(3,4) : error 0019: The EntityContainer name must be unique. An EntityContainer with the name 'OrderEntities' is already defined.
It then follows with all the parts of my schema saying that each was already defined. When I first got this error it was the same kind of error but for a different Entity Framework module. (Not sure if that is important or not.)
So my question is: Is there an IIS Setting that could cause this? Why would it work in my dev server and not my test server?
And what can I do to fix it.
NOTE: I have checked many times to see if I have a duplicate module or container name. There is only one module and container named OrderEntities.
I saw that sometimes this is a product of the metadata part of the connection string. My Connection String looks like this:
metadata=res://*/OrderDataModel.csdl|res://*/OrderDataModel.ssdl|res://*/OrderDataModel.msl;provider=...
All the others are the same except the Data Model name is different.
Note: when I deploy to IIS. I delete all files and only copy in the stuff from the auto build. (Same stuff to both locations.)
Turns out it was nothing to do with my code.
I had my Identity in my App Pool incorrectly set. Once that was switched to the right value, it all started working :)
Related
I have spent 2 days chasing this one round and round, and I have tried several solutions (detailed below).
Problem. When retrieving Geographical data from a Microsft SQL Database I get an error
DBServer routine OpenDataSet has failed with error DataReader.GetFieldType(3) returned null.
From what I have read, this is typically because the project cannot load or access Microsoft.SqlServer.Types, so it can't interpret the returned data effectively
What I have tried;
Removing and readding the reference.
Setting the assembly to copy Local
Removing and reinstalling via Nuget (v14.0)
Referencing said assembly in the web.config
Adding a utility class in Global.asax, then calling that on Application_Start to load in the other dependent files
LoadNativeAssembly(nativeBinaryPath, "msvcr120.dll")
LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial140.dll")
The error happens whether I am running locally (not such a key issue) or on an Azure vps (SqlServer Web Edition).
The stored procedure I am calling to return the data works fine. (In fact, this code is a lift and shift project. the old vps works fine if we fire it up, so it is most likely a configuration issue and all the above I have done is wasted effort. But the original developer is not contactable, nor are there any notes on how this was made to work.)
I'm re-importing my workstations but the static pool workstation: give me back the following error:
AWSJCS011E An internal error has occurred. The error is the following: "AWKRAE015E A requested resource is unknown. The following error was returned:"AWKRRP018E Unable to find source or target resources for the creation or update of a relationship
does anyone know what that means?
That message means a problem occurred while looking for a workstation into the system. In your scenario, you should make sure that all the agents beloging to the pool are up and running and correctly linked.
In addition to that, for every agent, you should also check the AgentID matches with the one you can find in the respective JobManager.ini file.
I hope this can help!
I am trying run SOA Suite and when I execute startWeblogic.sh I got the following message error:
Unresolved reference to WseeFileStore by [<domain name>]/SAFAgents[ReliableWseeSAFAgent]/Store
at weblogic.descriptor.internal.ReferenceManager.resolveReferences(ReferenceManager.java:310)
at weblogic.descriptor.internal.DescriptorImpl.validate(DescriptorImpl.java:322)
at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:332)
at weblogic.management.provider.internal.DescriptorManagerHelper.loadDescriptor(DescriptorManagerHelper.java:68)
at weblogic.management.provider.internal.RuntimeAccessImpl$IOHelperImpl.parseXML(RuntimeAccessImpl.java:690)
at weblogic.management.provider.internal.RuntimeAccessImpl.parseNewStyleConfig(RuntimeAccessImpl.java:270)
at weblogic.management.provider.internal.RuntimeAccessImpl.<init>(RuntimeAccessImpl.java:115)
... 7 more
Does anyone know how to fix this error?
I am running the system over 64 bits Suse
The quick and dirty way to get your admin server back up:
cd to <domain name>/config
Back up config.xml just in case
Edit config.xml, find and remove the <saf-agent> tags that point to your non-existent WseeFileStore
When you have the admin server back up. You can look at the Store-and-Forward Agents and Persistent Stores links to see what is already configured there. It sounds like a SAF agent was somehow created but the backing Persistent Store was not.
You can always created the Persistent Store later and add that SAF agent back in if you need it.
This happens simply because the automated tool used to adapt the config.xml file to the new cluster structure is... well, far from efficient.
It can create all other relevant structures ok, but the <saf-agent> entry is wrongly created.
Just open and look briefly to the config.xml file and you should see that something is not right with this entry.
I will use my environment as an example for this situation:
I have a single cluster with two managed servers named osb1 and osb2. Both are administered by the cluster's AdminServer and all these components are in a single machine called rdaVM. The whole domain was created with the Configuration wizard and, upon the first AdminServer start, I've got that dreadful error for quite some time.
The solution does reside in the config.xml file located in <DOMAIN_HOME>/config/config.xml
When I opened this file in the editor and did a quick search for WseeFileStore I got some curious entries:
<jms-server>
<name>WseeJmsServer_auto_1</name>
<target>osb1</target>
<persistent-store>WseeFileStore_auto_1</persistent-store>
</jms-server>
<jms-server>
<name>WseeJmsServer_auto_2</name>
<target>osb2</target>
<persistent-store>WseeFileStore_auto_2</persistent-store>
</jms-server>
and
<file-store>
<name>WseeFileStore_auto_1</name>
<directory>WseeFileStore_auto_1</directory>
<target>osb1</target>
</file-store>
<file-store>
<name>WseeFileStore_auto_2</name>
<directory>WseeFileStore_auto_2</directory>
<target>osb2</target>
</file-store>
but looking at the offending entry:
<saf-agent>
<name>ReliableWseeSAFAgent</name>
<store>WseeFileStore</store>
</saf-agent>
Obviously there's something missing here. Looking at the <DOMAIN_HOME> I could see two folders there: WseeFileStore_auto_1 and WseeFileStore_auto_2. So no WseeFileStore and hence that annoying error. Also, the saf-agent element doesn't have a target.
Solution: using just the underlining logic, I adapted the <saf-agent> entry to:
<saf-agent>
<name>ReliableWseeSAFAgent_auto_1</name>
<target>osb1</target>
<store>WseeFileStore_auto_1</store>
</saf-agent>
<saf-agent>
<name>ReliableWseeSAFAgent_auto_2</name>
<target>osb2</target>
<store>WseeFileStore_auto_2</store>
</saf-agent>
I.e, created a <saf-agent> for each of the cluster's managed servers, targeted each entry to a managed server and added the _auto_# suffix, where # is the ordering number for each managed server, to the <name> and <persistent-store> entries.
After it, I was able to run the startWebLogic.sh script without problems (from this source at least...)
I am developing a winforms application in Vb.net
when i try to add a tableadapter to an existing dataset I am receiving the error:
Failed to open a connection to the database.
"An attempt to attach an auto-named database for file ###Filelocation### failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share." Check the connection and try again.
This same dataset has 2 other tableadapters using the same dataconnection (as I am selecting the already existing dataconnection) which work fine
this connection is using application connection strings:
Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\test.mdf;Integrated
server=localhost;user id=root;password=password;database=testuser;persistsecurityinfo=True
this error pops up every time I select the dataconnector on the first window that pops up.
Why is this happening
additional info:
The other 2 tableadapters were added to this dataset using a different computer
this is for a mysql connection
I found this post on the MSDN forum:
An attempt to attach an auto-named database ....\aspnetdb.mdf failed
One of the suggestions is as Mr. DonBoitnott correctly says, add User Instance=True;. But, there's also another suggestion posted by Luke A.
"For the record, not one single error message given to me during the course of trying to fix this was relevant to the actual problem. Upon first receiving "An attempt to attached an auto-named database..." I looked online for every suggestion I could find: use an absolute path to the MDF, reorder TCP/IP and named pipes in the server configuration, disable/enable UserInstance (depending on where you looked), change security settings, reconfigure authentication, give specific login credentials.
None of these worked. All of these led to different vague/ambiguous error messages, which led to another problem which required a solution which led back to the original error message... an endless loop of problems, completely unrelated to what was actually wrong.
_Also, posts about setting correct permissions on the App_Data folder are deceptive, as they imply the default permissions were not sufficient for SQL Express (in fact, they are). The whole point of this VS environment is that you can develop a web application and plop it right onto an IIS/SQLExpress setup and have it work. This makes the applications more portable (within IIS, of course) and secure. Of course, everything configuration-related has been obfuscated enough to make it several orders of magnitude more difficult than it has to be."_
So: Try prepend Initial Catalog=uniquenamehere to your connection string.
Though he says "... where 'uniquenamehere' is some name for your project.", try replacing uniquenamehere with the actual name of the database where the table exists.
the file is a .mdf file so it is a mssql file
my guess would be that as you stated you are using mysql the connection string has to be a tad different and therefore the Dataset can't connect to Mysql
Try adding User Instance=True; to the connection string.
I have have a solution that I created with the new modeler tools. This gave me
two full "endpoints" in a single solution.
Now when I run them through my automated build, I have two dlls in the same
folder that implement IConfigureThisEndpoint.
If I just run NServiceBus.Host.exe \install (to get a Windows Service), it gives
me the (expected) error that there is more than one class that can be used.
I did some searching and Udi states here:
http://tech.groups.yahoo.com/group/nservicebus/message/3937 that "You can
specify which class you want loaded and avoid these issues - as the server
project in the pub/sub sample shows".
I looked at the pub/sub sample and I can't see how I can specify my class (at
least not at the command line).
Is there a way to get around having to modify my build to put the files in
separate folders? (Not really an easy task for me.)
Add a config entry to your app settings with the key EndpointConfigurationType and the value being the assembly qualified name of the type.