For configuring my ASP.Net Application I'm using Custom Configuration Sections in my web.config. But I would like to get IntelliSense support for my own-build configuration sections. I figured that it is possible to create a XSD Schema Definition and include that in the web.config. But is there a less painful way of getting that schema?
With Configuration Section Designer I found a tool offering a GUI for creating my configuration section and generating the schema. But I like coding and I don't want to learn how to deal with another GUI.
So, is there a possibility of automatically generating the schema for my code?
I have used this tool to generate generic schema from xml; See if it helps in your case.
Related
In my code, I have custom element in web.config. To access that i saw a model in a file with .csd.cs extension which was generated by a tool.Its an old code base. I need to know how it got generated. What tool we need to use to generate this file?
I think config section designer is the tool you are looking for: https://github.com/hybridview/ConfigurationSectionDesigner
Might help if you are dealing with a legacy project, but I think you should consider integrating generated sections into your source and remove dependency on the extension.
My goal is to implement the changing values of resources and give the admin the ability to maintain the language through the portal. In order to do that, I need to be able to change resx files at the runtime, because all their values are stored on the resx files. I have 3 resx files for each different language. In my case I want the translation can be maintain later by an admin at runtime. For example admin can add, edit or delete the entry for the language at runtime.
As #Xerillio mentioned in his comment this is a lot of effort.
Recently I've created a nuget that may save your time and effort. Have a look at XLocalizer, it creates resources and uses online translation services to auto translate the missing resources and save them in XML or DB, then it provides an easy interface to export them to RESX. Finally you may see XLocalizer.Samples, it contains sample setup for different scenarios.
If you need another file/DB type to store the resources, you may create your custom resource provider and register it in startup.
The DB sample provides UI to edit resources, but with XML sample I didn't create a UI for editing resources, instead you may download the XML, do your corrections if any, then upload and use the built-in exporter to export to RESX.
With this nuget, all I have to do to add a new culture even in runtime, is just to add the culture name to the supported cultures list, then do some correction to the auto translations, all the rest is handled by XLocalizer.
Notice: it was not possible to put all this in the comment, thats why I posted as answer :)
I've very new to Symfony. Before I've used mostly Laravel.
Lets assume I have an API Key which I want to use here and there thru the project.
It doesn't feel right to store it as a class constant because I can't find any class to keep it in. And it seems pretty dumb to have it in various places thru the app as a string.
Normally using Laravel I would have used a config file specifically for this task.
However in symfony I can't seem to do the same(either that or my google-fu skills are pretty bad). If they are, a simple link to some documentation will do just fine.
So my question is: Where can I store various constants used thru the app?
I'm sorry, but I'm afraid your Google-fu skills let you down this time.
Symfony.com has an excellent article about Configuration: Configuration -
Symfony Best Practices
The common way to save configuration parameters is by using parameters.yml. It supports environment variables as of Symfony 3.2.
The best practice for Symfony 2.x and 3.x:
Define the infrastructure-related configuration options in the
app/config/parameters.yml file.
The best practice for Symfony 4:
Define the infrastructure-related configuration options as environment
variables. During development, use the .env file at the root of your
project to set these.
LINQ to SQL Connection Strings with class library projects
By default, creating a new LINQ to SQL model (.dbml) will put the
connection strings in both the application settings file and also
web.config / app.config. This is not so much of a problem for web
projects, but what about class library projects? i have a connection
class where I can use it to check connection in all pages but I have an
error where it cant read DataContext at all.
This is a photo that shows my problem.
Generally speaking, class libraries don't support config files. There are ways to make it work, but it's not considered a good practice since different applications may use the same library to interact with different instances of the database. I would recommend looking at a dependency injection or inversion of control solution like Ninject to pass the connection string to the constructor from the app that references the library.
UPDATE:
If you absolutely must read a config file from an assembly instead of the calling application, it can be done with ConfigurationManager.OpenExeConfiguration(). There are several answers here on SO that provide code samples for doing so, but I'm not going to link to them because I strongly encourage you not to go down that road.
By the looks of it you're not using LINQ to SQL - all I can see is an EntityFramework edmx. Check your code generation strategy, and make sure you're trying to instantiate the correct context name (think it's whatever the Entity Container Name is set to).
Also you need to make sure System.Configuration is referenced.
You need to put the connection strings in the main application app.config
Just put a copy of the connection strings in there and you can access them or in this case web.config
I'm developing a web application (ASP.NET 3.5) that will consume a number of web services. I have created a separate dll-project for each web service: these projects contains the service reference and client code.
However, the calling website MUST have the <system.serviceModel> information (the <bindings> and <client> nodes) in it's web.config, even though this information is also in the dll's app.config file! I have tried copying the serviceclass.dll.config over to the bin directory of the website, but this didn't help.
Is there any way to centralize the configuration of a WCF client?
I've only limited WCF experience, all with BasicHTTP bindings. But I'm allergic to WCF's xml files and have managed to avoid them thus far. I don't recomend this generally but I put the configuration details in my apps existing configuration store and then apply them programatically. E.g. With a Web service proxy I use the constructor for the Client that takes 'bindings'and 'endpoint' and programatically apply the settings to the bindings & endpoint.
A more elegent solution appears to be descibed here: Reading WCF Configuration from a Custom Location, but I haven't tried it yet.
From my experience, library projects never read app.config.
So you can really delete the file because it is not used. The library's host configuration is read instead, so that is the only place the endpoint and binding configuration should be.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Remember that a configuration file is is read by an executable that has an entry point. A library dll does not have an entry point so it is not the assembly that will read it. The executing assembly must have a configuration file to read.
If you would like to centralize your web configs then I would suggest you look into nesting them in IIS with virtual directories. This will allow you to use the configuration inheritance to centralize whatever you need.
There are 2 options.
Option 1. Working with channels.
If you are working with channels directly, .NET 4.0 and .NET 4.5 has the ConfigurationChannelFactory. The example on MSDN looks like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "Test.config";
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
fileMap,
ConfigurationUserLevel.None);
ConfigurationChannelFactory<ICalculatorChannel> factory1 =
new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
new EndpointAddress("http://localhost:8000/servicemodelsamples/service"));
ICalculatorChannel client1 = factory1.CreateChannel();
As pointed out by Langdon, you can use the endpoint address from the configuration file by simply passing in null, like this:
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
null);
ICalculatorChannel client1 = factory1.CreateChannel();
This is discussed in the MSDN documentation.
Option 2. Working with proxies.
If you're working with code-generated proxies, you can read the config file and load a ServiceModelSectionGroup. There is a bit more work involved than simply using the ConfigurationChannelFactory but at least you can continue using the generated proxy (that under the hood uses a ChannelFactory and manages the IChannelFactory for you.
Pablo Cibraro shows a nice example of this here: Getting WCF Bindings and Behaviors from any config source
First of all class libraries (DLLs) do not have their own configuration, however they can read the configuration of their host (Web/Executable etc.). That being said, I still maintain an app.config file on the library projects as a template and easy reference.
As far as the service configuration itself is concerned, WCF configuration can make somebody easily pull their hair out. It is an over-engineered over-complicated piece. The goal of your applications should be to depend least on the configuration, while maintaining flexibility of deployment scenarios your product is going to come across.