Is it possible to use custom XML to store unity container configuration in my IoC class library project?
I dont want to store the IoC config at the startup project (WPF project).
Regards
Bryan
You can use ConfigurationManager.OpenMappedExeConfiguration to load an arbitrary file, but you'll need to do that yourself - the simpler overloads will go to the appdomain's config file by default.
If you have the Unity source code, you can look in the Unity\Tests\TestSupport.Unity\Configuration\ConfigFileLoader.cs file for an (perhap overly complex) example. There we pull a config file out of a resource, dump it to disk, and then load it via ConfigurationManager.
Related
My application supports running on many dbms and it requires user to configure dbms connection setting and also provide the jdbc jar file.
Now the application is to be packaged as OSGi bundle. There will be another main jar which lanches OSGi server and starts the application as bundle.
Can you please suggest how can I package the application as bundle and let user provide the jdbc jar file.
Will it require something like the main launcher jar specifying JDBC driver classes as FRAMEWORK_SYSTEMPACKAGES property?
Thanks in advance,
Aman
There are two ways of doing this:
1) Adding the driver.jar to the classpath of the main launcher and, like you say, expose its packages via the framework by specifying that property (or actually you can use the FRAMEWORK_SYSTEMPACKAGES_EXTRA property to just specify additional packages, instead of specifying all of them).
2) Manually wrapping the driver.jar as a bundle, or doing it dynamically at runtime. For example, you could try to wrap bundles that are copied to a certain folder (similar to what Apache Felix File Install does) by using Pax URL or some other tool that can create a bundle out of an ordinary jar file for you (see http://team.ops4j.org/wiki/display/paxurl/Pax+URL).
I have a large directory structure with JavaScript, images, etc. that depend on each other. I would like to encapsulate it all into a DLL so I only have to reference one thing and not have multiple copies of all these files across projects.
Because the files depend on each other, I'm thinking I can create an IHttpModule that registers a route to accept URLs such as /MyEmbeddedDir/subdir/file.js. Anything in MyEmbeddedDir would then be handled by a custom IHttpHandler that does the correct mapping. Each web application would then need to reference the DLL and add the module and handler to web.config. Does this seem reasonable?
Also, is there an easier way to embed/reference the files than to set the build action to embedded resource and add [assembly: WebResource(...)] to each file (there are dozens!)? Thanks!
Edit: If I'm not using WebResource.axd then I shouldn't need to add [assembly: WebResource(...)]
Yes, having a single container is a great way to manage large number of files (and no, SQLite won't help here! ;).
We have a product, named SolFS, which is a virtual file system, that lets you keep your data in custom storage (resource DLL is one of the options) and provides file API for accessing the files. We even implemented asynchronous pluggable protocol for IE (on the client side, but the task is very similar to yours). SolFS includes a manager application that lets you easily create container files and import files into container.
I ended up going with the IHTTPModule (register route) and IHTTPHandler (obtain embedded resource). The route is configurable in web.config in case it conflicts with existing content.
This is maybe a really simple question, but I couldn't locate an answer:
For a client I need to HOST a webservice. The client has sent me a wsdl file that the webservice should 'implement'. How do I go about that? I've generated any number of client-rpoxies but this is the other way around. I can use both ASP.NET 2.0 webservices or Windows Communication Foundation.
wsdl.exe /server.
Generates an abstract class for an XML
Web service based on the contracts.
The default is to generate client
proxy classes. When using the
/parameters option, this value is a
element that contains
"server".
You can do a similar thing with svcutil.exe for WCF- something like:
svcutil.exe thewsdl.wsdl /language:c# /out:ITheInterface.cs (I've not tested this).
Edit- John Saunders makes a good point in his answer to favour the WCF approach- I recommend this too.
Actually, you should do this with svcutil.exe, not with wsdl.exe. WSDL.EXE is part of the ASMX web service technology that Microsoft now considers to be "legacy" code, which will not have bugs fixed.
You can do plenty with that WSDL (wissd'le) file.
From doing the WS Class manually to use the Auto Generated class from wsdl.exe
let's imagine that, for your example, you have this WDSL (tooked from WebServiceX.Net)
to create a C# auto generated proxy you go to your command prompt and write:
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts http://www.webservicex.net/TranslateService.asmx?wsdl
Note: inside your C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin folder you will find wsdl.exe or just do a dir /s inside your C:\Program Files\
if you want in Visual Basic, just use /language:vb or /l:vb
/language:
The language to use for the generated proxy class. Choose from 'CS',
'VB', 'JS', 'VJS', 'CPP' or provide a fully-qualified name for a class implementing System.CodeDom.Compiler.CodeDomProvider.
The default
language is 'CS' (CSharp). Short form is '/l:'.
This command will put inside your C:\myProxyScripts the auto generated proxy.
if your using the WSDL file in your computer, just change the URL to your full path, for example
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts C:\myProxyScripts\myWsdlFile.wsdl
Note: your Generated proxy will be called the Service Name, the one you have specified, in our example, as:
<wsdl:service name="TranslateService">
I hope this helps you, understand the WSDL, the Auto Generated Proxies and that you can manage now everything in your end to fulfill your client wishes.
You can use the wsdl utility from microsoft to generate the server interfaces and implement them
Here is a short description of the WSDL utility.
wsdl.exe -
Utility to generate code for xml web service clients and xml web
services
using ASP.NET from WSDL contract files, XSD schemas and .discomap
discovery documents. This tool can be used in conjunction with disco.exe.
Is it possible to configure ms Unity container from an xml document and NOT from a file?
Not sure about that, but you can configure programmatically without a .config, so you could have your own xml file, read settings and programmatically setup your Unity container. It's ashame this facet isn't covered in alot of the documentation. There are alot of scenarios where the App.config isn't available or appropriate.
Edit:
By default, this is the App.config or
Web.config file for your application.
However, you can load configuration
information from any other XML format
file or from other sources.
See: http://msdn.microsoft.com/en-us/library/cc440941.aspx
Why don't you save the XMLDocument in some file localy on the machine and then load that XML file in the Unity container.
Unless there is any restriction in saving the XMLdocument i think it would work.
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.