We have a website that we would like to extrapolate user controls from and put them into an assembly of their own. This is so we can more easily reuse these controls in other similar projects. I think we can do this fairly easily by creating a new class library project, moving the .ascx and .ascx.cs files over to this project, adding the appropriate .net assembly references, and modifying our project's references to these user controls to pull them from the library.
The problem I'm foreseeing at this point is that these controls are heavily dependent on a certain database schema. Historically, we have always kept our connection strings in the web.config, and have been using LINQ to SQL for our database management, so I am having trouble conjuring up a "best-practices" way to share database connection information in the web.config with the assembly. The only way I could think of doing it is to add a ConnectionString property to each of my user controls, and on Page_Load, set the ConnectionString property (which will in turn create an instance of the data context using that connection string). However, I was hoping to instead accomplish one of the following:
Somehow have the assembly pull the connection string directly from the web.config. Since the assembly is not a web application, I obviously can't just call ConfigurationManager.ConnectionStrings["connection"]. Is this possible?
Less likely, but figure out a way to set the connection string once on application start and have each instance of my user controls somehow reuse this. I would think there would be a way to cache this value for reuse by the assembly, but I can't think of a way to do it.
Any suggestions are greatly appreciated.
The controls will use whatever connection strings are included in the config of the calling application. There is no need for a seperate config.
I obviously can't just call ConfigurationManager.ConnectionStrings["connection"]. Is this possible??
Yes!
Calls to System.Configuration.ConfigurationManager.ConnectionStrings will return results from the application's web.config even if the calling code is placed in it's own assembly. Remember: it's not assembly.config, it's web.config.
If your user controls are expecting a connection string named "MyDatabase" then every web application that they're used in will need a MyDatabase connection string defined in its web.config.
Related
I have a class where I retrieve certain settings from a database (usernames and passwords). This database is sitting on a network, and it means that if the passwords are changed, I can simply change it in the database, and all the applications that use this class will still work.
I am fully aware of the pros and cons of storing usernames and passwords in a database and in a separate location. I don't want to discuss those, please.
The class has a hard-coded static string that is the path to the database. It is a fully qualified network name (not just the drive letter). I did this because we had an issue where our network DNS got screwed up, and drive letter mappings stopped working, and some people have different drive mappings anyway.
We recently had our server moved, so I now need to go through and change these hard-coded strings.
I was thinking that I should store the path in a settings / configuration file instead. I considered "application.settings", but it is not an application setting; its specific to the class. Is there a preferred way of doing this in the existing .Net framework (this is a C# issue)?
I could simply have a small text or XML file that sits in the application directory, which is probably fine... is there an existing framework namespace or open-source code snippet that someone knows of that I can use?
I think, if you want class specific configuration, you should try to have those class instances, configuration driven. Another way of thinking but; Defining a something in a configuration file, will create an instance of the defined classname.
For example: Create a section, and call it, <Modules> and create items in like: <module type="<namespace>.DBConvertor" param="username=root;passwd=whatever"> This type will be created at startup (you need some coding here). And it's even possible to create more than one instance simultaneously with it's specific configurations.
This kind of configuration is already implemented:
You might take a look at this: "How to: Create Custom Configuration Sections Using ConfigurationSection" https://msdn.microsoft.com/en-us/library/2tw134k3.aspx
And creating instances from typenames, use the Activator class.
Besides that, there are many module/plugin libraries, (like Managed Extensibility Framework (MEF) https://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx but could be a little over the top in this case).
Ok so i have 2 classes so far that i want to put in my common dll, logger and db. im moving them from my current project to a new class library project and changing their namespaces and whatnot. The issue I am having is that I wish to use the app config of my application (or any app that I want to reference my commonlib.dll) but I dont know how to use the referencing projects app.config. Is there any way to do this?
The OpenExeConfiguration() methods of ConfigurationManager are your ticket. One of them will take a path to the executable, allowing you to open the app config of a specified application (even a different one; you can use this technique to change the configuration of another application before launching it with Process.Start()). The other one will open the app.config of the current application (even if your library is used by multiple apps) for a specified user level (All users, current roaming user, and current roaming and local user). Usually, when dealing with an actual app.config, you want the one that applies to all users; the per-user configs are stored in each user's AppData folders.
Also, one last thing; unless your library has its own config file, the ConfigurationManager properties, like AppSettings, will be populated based on the current executable's app.config. So it could be as simple as using those properties. Keep in mind that those properties are read-only and only loaded once at program startup, so if you make changes to your config during program execution that you want to be effective immediately, it's better to explicitly load/save config files.
In an MVC web application I want to override connection strings based on the development machine I'm using. I can use Web.config transformations, but I also need to override connection strings in various non-web config files. I can use the SlowCheetah extension, but then I will end up creating the same transformation for every project that accesses the database. This is a hassle to maintain when the project becomes bigger and has more developers.
What I would like to do is modify the way Entity Framework or ASP.NET look for connection strings, adding a class of my own that looks for connection strings, and only implement the transformation logic once. I would hopefully use Ninject to inject it only when relevant.
Is there such an "IConnectionStringProvider" interface I can implement and register, and automagically have ASP.NET and EF use it?
EDIT. I have found this, but it seems real nasty. If there's no cleaner way, I'll just use multiple identical configuration translations, and maybe let the source control system duplicate them properly.
You can tell Entity Framework to use a different connection string - it doesn't have to use the default one in web.config.
Here is an example: http://www.codeproject.com/Tips/234677/Set-the-connection-string-for-Entity-Framework-at
Here is another: http://msdn.microsoft.com/en-us/library/bb738533.aspx
It's up to you how you architect the rest of it.
Personally I use an app setting in web.config to tell my code which connection string to use for a particular part of the system, e.g.
var connectionStringNameForMyFeature = ConfigurationManager.AppSettings["connectionStringNameForMyFeature"];
myFeature.ConnectionString = ConfigurationManager.ConnectionStrings[connectionStringName];
This is a common problem for me. I have a solution that contains a Form App or two, a couple of websites(Intranet, External site kinda thing) and a class library where I want to store my data objects to be shared among the other project mentioned.
Normally, I'd have my connection strings stored in web.config and app.config files. However, with the class library, this isn't really possible. Not without passing in configuration information each time I want to access data. I'd prefer not to do that.
What's the best way to solve this problem?
If you put your connection strings in the web.config and the app.config of the referencing applications the Dll's will read them fine. If you want them shared you can put them in a machine config. You could also put them in a separate file and reference them from each web and app config.
I have a class that inherits from SPItemEventReceiver and implements ItemAdded, ItemUpdated, and ItemDeleted. These all work just fine and I'm getting the data I need.
However, I want to push some of the data to a 3rd party server via a web service. What is the best way to configure the external dependency of the web service for various environments (dev/test/production) without hard-coding the end point for each environment?
I'd prefer to avoid any static *.ini type files if possible. Can I add a configuration section to SharePoint's web.config and read it from the event handler?
Yes, best place to store that settings is web.config file. Below, some related articles:
Event handlers configuration settings best practices
Reading Settings from the Web.Config file from an Event Handler
Think of it like that - what would happen if you created yet another site of the same type and having the same event receiver and everything. Would you still use the same configuration? Is it a setting per each list? Per website? Per server farm? If you decide it's a server farm setting, then web.config is good for you. If you think that each web needs different config, then you have to persist the configuration somewhere else. For instance, if it's at web level, you can write your config string to SPWeb.Properties. This setting can later be read easily from that object, for instance SPContext.Current.Web.Properties["RemoteWebServiceURL"]. You can also set the value form a tiny PowerShell script. A SPList object has a similar property bag.