I want to use unity (2.0) to resolve my dependencies in a way so that i can configure policy injection (policies, matching rules and call handlers) in the .config file.
Or an other way to put it; i want my resolved objects to be "policy enabled", so that i can add and change to policies in config without have to recompile.
Any ideas on how to do that?
OK - I also posted in the Unity-communitysite on CodePlex (http://unity.codeplex.com/Thread/View.aspx?ThreadId=215690) and got an answer there.
The trick is to add the EnterpriseLibraryCoreExtension to your container when you construct it. Like this:
_container.AddNewExtension<EnterpriseLibraryCoreExtension>();
This will pick up the configuration for your appdomains (app.config or web.config).
And that will give me the behavior I want!
Related
I have an asp.net application which uses some web services(WCF) in the solution exporer ( Through add reference). I can see that end points are defined in Web.config
Now i do not want to touch the web config in the production and i have two questions.
1. What dll should i be putting on production - Released one or debug dll.
2. Whatever is taken as reference (WCF) in our asp.net applicaiton. I hope only defining end point is sufficent assuming that i havent changed anything in the WCF Service.
I will appreciate if someone can guide in this regard.
Thanks in Advance- New to .net :(
Specific to your questions, here are the answers
1) On production servers "Release" build (dlls) is the best bet because they are optimized for performance. you don't need to add the reference again, unless there is some code change (which changes the wsdl of service)
2) End points will not be changed, therefore just by copy new service dlls, you should be good to go. The types in config file remain the same as in WCF service.
Check in your VSS for Configuration Manager,which one you are pointing it.It can be release or debug.
Whichever is choosen,you have deploy the corresponding one.WCF service,defining end point is fine.
Folks,
This is probably very simple, but I couldn't turn up anything explicitly on point.
I have a web app (ASP.Net 4.0) that references a class library. The class library has various settings. I'd like to use the strongly-typed Properties.Settings capability within the class library. However, since class library config files are ignored under ASP.Net, I'd like the backing store for the settings to be a section of web.config as opposed to a class library-specific app.config.
I figure this is either outrightly forbidden or is as easy as pie to do. Can anyone tell me how to make it work?
Thanks,
Ann L.
I'm not 100% sure what you're asking, but I see two possible questions:
The class library has properties that are controlled (set) by the config file, but class libraries don't consume config files. If that's the case, then all you need to do is move those settings to the calling app's config file - the class library will automatically use the calling app's Web.config (or App.config, as appropriate).
You want to create a custom Configuration Section, which can also be done: How to: Create Custom Configuration Sections Using ConfigurationSection
Unless I've totally misread your question (always a possibility with me :) ), I'd go with #1 as it's easier, unless there's something unique or required in your design to move you to option 2.
Rather than calling it a question, i would like to call it a discussion and the topic is Flex Remoting. Forms and blogs explaining remoting in flex always mention 2 things:
service-config.xml
endpoint url
Now what i want to know is that
1. is service-config file actually needed if we need to bind our front end (which is in flex / air) with some database (mySql for instance). Coz i've done a couple of projects in flex and air and didn't use this config file. I used Flex 3. Though i used this config file in the projects i did in earlier version of flex 2.0 .
2. What actually this endpoint url does; could someone please explain it.
The way i implement remoting is like this:
<mx:RemoteObject id="remoteObj" source="MyPHPCls" destination="AMFPHP" result="remoteResult(event)">
<mx:method name="someServerSideMethod" result="onMethodResult(event)" />
</mx:RemoteObject>
Also if you could please tell me if the approach i am following to use remoting is incorrect.
Hope to hear from someone soon :).
Thnx,
Jatin
The services-config.xml data is compiled, or hard coded, into your application at compile time. You don't need to use a services-config.xml file if you don't want to; but if you want to use RemoteObject, that data will need to be available to your SWF somehow.
Here is a good blog post on setting the services-config file at runtime.
The end-point URL is just a URL to a Remoting Gateway.
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.
How can one specify the connection string in a config file of a class library and later modify this when used in a ASP.NET Web Application?
The Class library is a data access layer that has a Dataset connecting to a database based on a connection string specified in a config file (Settings.settings/app.config).
This class library is used in a web application where user inputs data and is written to the database using the DAL classes & methods exposed in the class library.
Now, I want to migrate this application from development environment to testing environment and later to production. The problem I'm facing is that after migrating to testing, the app in testing still connects to development database. I've changed the connection string mentioned in <class library>.dll.config file but this seems to have no impact.
Can someone explain the right way to achieve this? Thanks in advance for any help. Cheers.
With the .config files the name has to match the main executing assembly. For example I had a situation like yours, I needed a class library to have its settings in a .dll.config file. While it was able to reference it the actual application would not be able to read the config file because it was expecting .exe.config. Renaming the .dll.config to .exe.config fixed the problem.
In your case migrating your connection strings from .dll.config to web.config should fix your problem!
Good luck!
Joshua is partly right ... For posterity I would like to add a bit more to this answer as I have delt with the same problems on several occasions. First, one must consider their architecture. There are several issues you can run into with .config files in ASP.NET based on deployments.
Considering the architectural ramifications:
Single tier (one server):
A simple web application may be able to leverage a reference to the sites Web.config file and resolve your issues. This would be a fine solution for a single tier application. In the case of a windows application leveraged as a .exe file, the App.config will work too.
Multi-tier (more than one server):
Here is where things became a bit hairy for me the first time I was working with .config files across boundries. Remember the hierarchy of the config structure and keep this in mind (MSDN Article on .Config structure) - there is a machine.config at the root in the appropriate ASP.NET folder. These reside at each physical server. These are overridden by the site Web.config (or App.config) which are in turn overridden by subfolder .config files. If you have more than one .config file you may want to use one of the methods to pass the file path for the specific .config you want to use. More importantly, these files each may have connection information. ASP.NET's machine.config holds some for the framework ... so you should at least be senstive to the fact this is an "inheritance" chain. Second, any changes to the Web.config file once deployed will tell the application to restart. This will result in loss of state (bad if you have active users on the site). The way around this is to keep a separate .config file (e.g. connections.config) and put a reference to that file in the Web.config. This will allow you to change the connection information (e.g. password) without having to restart the application. Here is a link to more info: MSDN: Working with Configuration Files. This article lays out all the details you need to be aware of in a normal server / IIS deployed application. Keep in mind that the .config files are mainly intended for applications, not libraries. If you have several tiers, chances are you are using some communicaiton / messaging layer (e.g. WCF). This will have / allow its own Web.config. You can keep connection strings there (and encrypt them if needed), but better yet, put them in a second file referenced by the Web.config for manageability. One final point, if you are ever going to consider the cloud, .config files are wrapped for application deployments which in effect removes all of the benefits they offer in terms of "not having restart or redeploy". Azure deployments will want to consider this article to save themselves from nightmares of maintenance: Bill Lodin blog - Configuration files in Azul / Cloud. One other point on this article – great example on how to programmatically select configuration depending on deployment! Be sure to check that out if you want to add flexibility to deploy in or out of the cloud .
I hope these points saves all of you time and headaches. I know I lost a couple days of programming time dealing with these issues ... and it was hard to find all the reasons in one place why may app was not "implementing" its connection object. Hopefully this will save you all from the same fate I had.