I have an EF project which has embedded connection details.
Then when I use this project from a client library I get told to copy the config file across, which includes the connection details.
What are the rules re which connection string would be used here? i.e. does the database connection string in the client project override any connection strings in the EF library project?
The connection strings in the library project are never used, they aren't in the bin folder with your final executable. Only the connections strings you copy over to the application or web config files (as appropriate) are used.
But don't copy the whole config file over - you want just the connection strings.
Related
I'm running a remote language server on with vscode via an extension I'm developping. Both client and server have access to the code via a mounted shared folder. The issue is that this folder is located on different places on the client and on the server. (/home/username/myproject on the client, /mnt/shared_folder/myproject on the server)
My question is can I configure the vscode language client so that it translates the path from the local location to the remote location and vice-versa?
If I'm running the language client from a project with a workspace, can I configure it so that it send file URI relative to the workspace root rather than sending the absolute file path? Doing so I can simply reconstruct the file uri on the server side with the path of the shared folder mount point.
I heard of Middlewares or uriConverters but I'm not sure if this the purpose they are intended to be used for.
Thank you!
It's expected by the Language Server Protocol that the URIs to reference files are the same on both server and client side.
I think the best is to place on the server (which after all is the one that has the "clone" of the files and not the orginal ones) the logic to turn the client URIs "/home/username/myproject" into server URIs "/mnt/shared_folder/myproject" when trying to access the files. Accessing the file is part of your implementation, so it's not something that's part of the LSP API, and conversion should happen inside your implementation.
What is the idiomatic way to store and retrieve configuration settings in a deployed Clojure Luminus app?
In the Luminus template on which I base my app, the profiles.clj file is used to store the database connection string. However, when I compile the app using lein uberjar the profiles.clj settings do not seem to be included in the compiled file. And I would nevertheless not want the database connection to be stored in the compiled file but rather reside in a configuration file on the production server.
Optimally, local configurations should be stored and retrieved in the same manner regardless of whether the app is run in development or production mode. But I can't figure out how to do it.
You may be interested in using the environ library. From their README:
Let's say you have an application that requires a database connection. Often you'll need three different databases, one for development, one for testing, and one for production.
Lets pull the database connection details from the key :database-url on the environ.core/env map.
(require '[environ.core :refer [env]])
(def database-url
(env :database-url))
The value of this key can be set in several different ways. The most common way during development is to use a local profiles.clj file in your project directory. This file contained a map that is merged with the standard project.clj file, but can be kept out of version control and reserved for local development options.
{:dev {:env {:database-url "jdbc:postgresql://localhost/dev"}}
:test {:env {:database-url "jdbc:postgresql://localhost/test"}}}
The http://www.luminusweb.net/docs/environment.md#edn_based_configuration page helped me.
java -Dconf=config.edn -jar app.jar will start a compiled app with the configurations stored in config.edn.
I am kicking the tires with EF 7, specifically the revEng command.
I have been able to run the revEng command and get the context and POCO files generated.
However there are two things I would like to tweak:
The context and POCO files are created in the project root.
The database connection string is hard coded on the context file.
Is there a way to move the file to another folder from the command? In other words, a Models folder? I could move the files manually, but doing that each time I update the model sounds like it would get old.
Is there a way to have the generated context file reference a connection string from the config.json?
If what I ask is not available, is it in the backlog, and this just life in preview land?
The abibilty to specify a project folder will be available in beta 8 https://github.com/aspnet/EntityFramework/commit/5b19fbbff82987ba9e1aafe051ff8c4fd02bf8cf
I'm getting the following error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
I've just created my first ever EF project. It's an MVC app and I added the entity model in the MVC project. I also added a DataAccess class and a class for running tests using NUnit. Eventually, I'll add a service class which will reference the DataAccess class. So, the code currently looks like this (I'm just trying to get a test working to prove EF is doing its thing):
Text Fixture calls DataAccess class
DataAccess class calls Entity Framework
Entity Framework accesses a local database
For the time being, I'm just trying to return all rows/one column from one table. Remember, all these files are in a single project. I've read quite a lot that this problem stems from having multiple projects, but that doesn't seem to apply in my case. I've checked in the "main" web.config file. The connection string looks okay. I copied that same config section (i.e., connectionStrings) into the Debug-specific config file, too, but that didn't make a difference. Any ideas why I'm seeing this error?
Thanks,
Jay
Connection strings:
This is the connection string from the dialog box when creating the Entity Access file (data source is a period in both strings [i.e., local host]):
metadata=res:///EntityDataModel.csdl|res:///EntityDataModel.ssdl|res://*/EntityDataModel.msl;provider=System.Data.SqlClient;provider
connection string="Data Source=.;Initial Catalog=URIntake;Integrated
Security=True"
This is the connection string from the web.config file. They seem the same, for all practical purposes:
metadata=res:///EntityDataModel.csdl|res:///EntityDataModel.ssdl|res://*/EntityDataModel.msl;provider=System.Data.SqlClient;provider
connection string="data source=.;initial
catalog=URIntake;integrated
security=True;multipleactiveresultsets=True;App=EntityFramework"
Microsoft Zlatko Michailov Says,
app.config is not in the binary directory where the exe is. Please do
the following:
Visually verify that the app.config with the expected content is in the directory where the exe is compiled. (Existence in the project
root directory is not enough.)
Use System.Configuration.ConfigurationManager from within your app to examine the content of the app.config your exe is using.
I’m also looking at the content of the connection string, and I can say
that it may not work in a multi project environment (unless you’ve
duplicated the EDM in each project).
The reason for that is “.”
resolves to the directory where the exe is loaded from. If you want to
reuse the same EDM, you at least have to make a few steps back in the
path and then navigate to the project where the EDM is, e.g.
“......\Proj1\AdventureWorksModel”.
Additionally you may consider
using the |DataDirectory| macro - when you load an AppDomain you can
set |DataDirectory| to point to the exact directory where the EDM is,
and then use that in the connection string, e.g.
“|DataDirectory|\AdventureWorksModel”.
If you are working on an
ASP.NET project, you can use “~” which refers to the project root. In
that latter case, you can’t reference a model outside your project’s
hierarchy though.
For more information Check Here
UPDATE 1 :
Here you can try below mentioned steps
Clear connection string content on the web.config file like below
Then Remove your *.edmx file from your project
Recreate it again like below (sample one).Don't forget to tick the "save entity conncetion settings in web.config as :"
Final Step : After that go to the web.config file and check whether your connection string is exactly the same as on which showed on "Entity Connection String :" as above step(I showed it on red mark above image).
I hope this will help to you.
I'm trying to use EF 4.3 migrations feature. My ASP.NET MVC project stores connection strings in external file:
<connectionStrings configSource="bin\connections.config" />
All runtime procedures (including automatic migrations) work fine. However, no powershell commandlet, connecting to the database, is able to find external file. It throws "Unable to open configSource file" exception. I was trying to place .config file in different places as well as changing configured external file location to no avail. Is there any workaround available?
Update: I've found that EF creates a temporary AppDomain with configuration file located in temp directory. So the only workaround at the moment, it seems, is to place external configuration in the same temp directory. Any other suggestions?
Using EF 6.1 here.
If like me you were linking to a connectionStrings.config file located in another project than your Entity Framework migrations project (using Add as link), you'll probably need to move the file back to this EF project and link to the moved file from the other projects instead...
There are unfortunately no easy way to handle external configSource files with the powershell cmd-lets in EF migrations. I've given up on it and moved the connection strings into the config file for the class library that contains the db code. The alternative is, as you've found out yourself to manually copy the file. Unfortunately the copy process doesn't honor the build settings of the project, so setting the external config file to be copied at build doesn't help.
EF 4.3.1 supports configSource.