I have an F# library project that I'm using from a C# web project. I would like to use the Entity Framework Type Provider in my F# project, and have it get the connection string from the Web.config - but I'm having trouble getting this working.
type internal FooDb =
SqlEntityConnection<ConnectionStringName="FooDb", Pluralize=true>
At design time, I'm required to have an App.config file in the F# library project with a connection string having the matching name.
At runtime, when calling my F# code from the C# web project, I get an error that it can't locate the "App.config" file. This surprises me, because I was expecting that at runtime it would just use ConfigurationManager.ConnectionStrings to load the connection string from the currently-active config file (in the case of a web app, Web.config). However this doesn't seem to be the case.
I tried adding the ConfigFile parameter:
type internal FooDb =
SqlEntityConnection<ConnectionStringName="FooDb", ConfigFile="Web.config", Pluralize=true>
But this just made it complain at design time that it couldn't find Web.config.
Then I renamed the App.config file in the F# library project to Web.config and that seems to have gotten things working. However, I'm uneasy about this solution. Is this really how it's intended to work? I have to have a web.config file in my library project? What would I do if I wanted to use the same library from a command-line executable, and in that environment the config file is called AssemblyName.exe.config?
Forcing me to hard-code the name of a config file that can have different names in different contexts seems very brittle, and a poor design. Please tell me I'm missing something.
The issue you've encountered seems rather unfortunate indeed, and I don't know whether you are missing something or not. However, the SqlEntityConnection documentation says that FooDb should have a GetDataContext overload where a "connectionString parameter may be used when the connection string is determined at runtime." Perhaps that will give you a decent enough work around (i.e. pass in the connection string from ConfigurationManager.ConnectionStrings yourself).
Related
I wanted writing an IDE plugin to simplify work with references to code in my documentation, but decided to first check the existence of a specification (like URI) so as not to reinvent the wheel.
I tried to find the answer to this on the internet but failed.
We know that such references work in different IDEs:
appRoot.folder.file.Class#method
appRoot.folder.file:35
appRoot/fodler/file.ext:35
But what if you need to get the path to the nested property JSON or XML?
I naively imagine that the sign # means the root and then for the JSON path I could use something like this:
appRoot/folder/jsonFile.json#oneLevelProp.twoLevelProp
But this of course does not work at the current moment in any IDE that I know of.
im developing a class library (dll) with visual studio 2012, this library contains a model first created database, with the connection string setted on its app.config file.
Now, im creating a console app (actually a test, but for this its pretty much the same) with an added reference to the dll project.
At first i thought the console app didnt need to know anything about the database, since it was using the dll, however i got a connection string missing error. Fine i added it and it worked, but this isn't what i want, i need the dll to encapsulate all the database related stuff.
Also, what bothers me the most, is that the connection string is also needed on BOTH the dll and the app, even the .mdf file(im using local sql server) generated in the dll/bin/debug folder is needed and copied over to the app/bin/debug folder so i need the file to be on both sides...
How can i make the dll to work by itself, using its own config file and not the app config file? And no, using some kind of service is not an option, it needs to be a dll!
in your database class you can add your connection string like this as base parameter
public class mydb:DbContext
{
public mydb() :base("Server=....")
{
}
}
or you can add your Connection string to app.config and just put its name in base
Example:
public mydb() :base("ConnectionstringName")
I'm trying to get the constants (ConstantsWithLookup) stored in the client side in my server side, but it can't figure out how to do it. I have my constants interface and my constants properties in the same folder.
I've tried tips of other similar threads with no success.
I tried Hermes, gwt-i18n-server, gwt-dmesg, GTWI18N, using a ResourceBundle, trying to get source file properties.
For the first two, it seems that the main reason is the outdated support for the newest GWT version. As for the ResourceBundle, it cannot find the properties file because at deployment, there isn't a properties file, just a Constants.class.
I'm trying to avoid changing my properties file to another location (like /WEB-INF/constants).
I'm using Hermes with GWT 2.5.0.rc1, and it works fine. Usage:
put hermes-1.2.0.jar into war/WEB-INF/lib
Then on the server side write something like
MyConstantsWithLookup my = Hermes.get(MyConstantsWithLookup.class, "de");
String string = my.getString(key);
A properties file MyConstantsWithLookup.properties must exist in the same package as MyConstantsWithLookup.java, even if that properties file is empty (which might be the case if you're using #DefaultStringValue etc.)
Also add MyConstantsWithLookup_de.properties etc.
Make sure, that these properties files are copied next to your classes when compiling. Javac doesn't do that, so it must be done in an additional build step (Eclipse usually does this automatically, but it won't happen by itself when you build e.g. with Ant)
Many build setups will skip the java and properties files from the "client" package when compiling the server side. In that case, put your constants files in the "shared" package (if you have one).
I'm writing a Powershell script which is going to go out into a client's current source control system and do a mass rename on all of the files so that they follow a new naming convention.
Being the diligent TDD developer that I am, I started with putting together a PSUnit test case. At first I was thinking that I would pass in a string to my function for the file name (along with a couple of other relevant parameters) and then return a string. Then it occurred to me that I am going to need to break apart the file name into an extension and a base name. Since System.IO.FileInfo already has that functionality, I thought why not just pass in a file object instead of a string?
If I do that however, then I don't see how I can write my PSUnit test without it being reliant on an external resource (in this case, the file must exist for me to get the FileInfo object - or does it?).
Is there a "clean" way to handle this? How are others approaching these issues?
Thanks for any help or advice!
My suggestion is: Be pragmatic and pass in the base name and extension as two separate strings. For convenience reasons, you can provide an overload that accepts a FileInfo.
I have two projects:
ASP.Net 3.5 website (frontend, UI)
VB Class Library (dataaccess logic)
Where should I save my connectionString, so that I can use if from the class library? And how does this affect where it is placed when I deploy/publish?
Note:
I don't want to pass it to every function in my VB Class
Depending on how you constructed your DAL -- LINQ, TableAdapters, etc. -- it may automatically look for it in the web.config file. If you created the DAL via a designer, likely it stores the default connection string in the app.config file for you class library. I copy the connection strings section from the app.config file to my web.config and change the connection string to the correct database (I have separate web.config's for DEV/QA/PROD). This makes it trivial since the designer generated code already has the code implemented to retrieve it from the configuration file.
If you are hand-coding your DAL and need to pass in the connection string, I suggest setting up a strongly-typed configuration class that interfaces to the web.config and does lazy loading of your configuration values. Use a factory to create your DAL and inject the configuration class into your factory via constructor so that it knows how to create your DAL with the connectionsString retrieved from the configuration file.
My question came from having spent half a day of trying to make this work, but I kept getting the wrong connection when deploying (where I use another database).
My problem was, that I was using
My.Settings.DefaultConnectionString
...To retrieve the connectionString in my VB Class Library.
After following tvanfossons anwer, I dug around some more and found out, that I can simply use (after referencing system.configuration) :
System.Configuration.ConfigurationManager.ConnectionStrings.Item("DefaultConnectionString").ConnectionString
It looks in the web-config for webapplications and app.config for windows/class library apps.
I am glad it now works, but even more glad I know why. ;)
I had the same issue you were having and I ended up using the System.Configuration.ConfigurationManager class to obtain the connection string stored in my web.config file from my class library like Kjensen's answer suggested. This worked wonders, if I had more experience I would vote that answer up.
I needed the connection string to build my Linq2Sql data context, which this method provided me with.
I now build my data context like below (remembering to add a reference to System.Configuration) -
public MyDataContext() : base(System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"]
.ConnectionString, mappingSource)
And as long as the web.config file contains "MyConnectionString" the configuration manager takes care of the rest.
We keep ours in the machine.config of each server and have a custom DAL to handle all DB interaction for our web apps.
Put it in the web.config in the connection strings section.
In the VB project use HttpContext.Current.GetSection to retrieve the section.
A fellow developers idea once was that we should store all the connection strings in a database table.
Don't try doing that. You won't get very far. :)