Scenario:
I am consuming a web service in my class library project and it generates a binding name and end point in app.config. If I reference the class library in my UI project, I also have to include the same configuration in web.config. My problem is I don't want to include this configuration in web.config because of the dependency. I want to use assembly as it own with out any dependency.
My solution approach:
When I create the instance of proxy class in the class library project it shows me constructor to pass binding and endpoint.
Example
wsProxy proxyClass = new wsProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.Endpoint endpoint)
I was wondering if I can pass the same binding and endpoint that I have in app.config so that I don't have to include either in app.config and web.config.
Yes, you can create these classes without having matching configuration in the main .config file. Where you get that configuration is up to you; it could be App.config, a YML configuration file, a database, etc. As long as your code satisfies the constructor requirements for the classes you're instantiating, you'll be fine.
With WCF, everything defined in your configuration file can be done programmatically.
You just need to create the objects needed to instantiate your client. Depending on the WCF features you want your application to be leveraging, you'll need classes like EndpointAddress, AddressHeaderCollection, Uri, EndpointIdentity (DnsEndpointIdentity or SpnEndpointIdentity), Binding (WSHttpBinding, NetTcpBinding etc.). And you might want to have these objects populated from a decoupled, centralized configuration store such as a database.
Related
We converted our projects to the 'new' SDk format csproj files. To add a new WCF webservice we right-click the project and choose: Add => Connected Service. Then we choose 'Microsoft WCF Web Service Reference Provider'. That all works, but the generated code does not contain an option to pass an endpoint name to the service-client constructor (which was an option in the older csproj add service reference option) so it would do a lookup in the web.config-file to configure the service (endpoint and behaviours e.d).
It looks configuration is all hardcoded in the generated service code file (servicereference.cs). I know it's a partial class and could just add an extra constructor accepting an endpoint name as a string like ctor(string enpointname):base(endpointname){} but i'm lazy and believe it should be able to work out of the box.
I think the question (and comments) contains the answer already. The only way to use the Config-file is to add a constructor in partial class in a new file.
I'm trying to make the same project to work with WCF and MVC.
My problem is:
MVC is working perfectly, than I included the interface and the .svc that I had in WCF service.
When I try something like this:
http://localhost:2986/PAGENAME.svc
I get the following error:
The resource cannot be found.
NOTE: PAGENAME.svc is in root (and so as the interface).
Looking forward this problem, I included the ignore methods in RegisterRoutes:
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");
routes.IgnoreRoute("{resource}.svc");
But didn't work either =/
Does anyone know how to fix this?
Thank you!
You need to make sure that you have all the files required, which are referenced from the Service Host (.svc file), i.e.:
<#% ServiceHost Service="..."/>
Where Service specifies the service implementation.
The service contract (the interface that the service implementation implements) is usually configured in web.config.
You don't need to ignore the route if the service host file is at the root of your solution.
You need to reference System.ServiceModel.
If you want to test your service you can by opening visual studio command prompt and running wcftestclient, File -> Add service and add the url for your service, e.g.:
http://locahost:12423/MyService.svc
It's been a while since I've played with this, but I think when using MVC you need to register a service route... but I don't remember if that's what I had to do or if I just wanted to do that for cleaner routes.
To add a service using a service route, you would do something like the following
routes.Add("MyService", new ServiceRoute(
"some/path",
new ServiceHostFactory(),
typeof(MyService)
));
I have a project that has a web service reference. I also have an app.config file that contains the binding information and endpoint. In one of my classes I'm invoking the the soap client object generated by the web service reference. I can initialize the soap client object to one of the endpoint I created in the app.config file. My confusion is with the constructor that takes in two strings. One is for the endpoint name in the app.config file and the other is the remote address. Why would I want to provide a remote address when I could just specifie it in the app.config file under the endpoint element?
And what if you'd like this address to be dynamic?
You surely DO wish to have an constructor taking the remote address as a parameter rather than sticking only with a static configuration.
The constructor which takes both the binding and the endpoint address gives you most flexibility. We often delete the static configuration from the configuration files and create the proxy instances using this particular, two-argument constructor.
This way, it's easiest to dynamically relocate your application without the need to touch anything.
It's an overload if you for some reason don't want to specify your configuration in the app.config file, it could be that you are storing it in a database or some other configuration mechanism.
it looks like I am not able to succesfully move my WCF proxy code into a separate DLL (as opposed to an EXE as I can see in all the examples I have run into).
The reason I am trying to do this is that I would like my proxy code to be invoked by different clients (possibly unmanaged code), which might not know anything about WCF but just need to access to the services (through a Facade exposed by the proxy maybe?).
Whenever I move the following code that creates a new proxy to a different VS project within the same solution, I get the dreaded "Could not find default endpoint element that references contract 'localhost.IRemoteCommandService' in the ServiceModel client configuration section" exception.
localhost.RemoteCommandServiceClient proxy =
new localhost.RemoteCommandServiceClient();
The same code works smoothly whenever used within a Main method in the same project where the proxy code is (auto-generated from Visual Studio).
Any idea? I hope that the client code of my proxy does not need to have the service model XML configuration as the proxy, because that would defeat the purpose I am moving the WCF proxy code into a DLL in the first place.
Thanks,
Stefano
The endpoints are indeed normally specified in the configuration file. You must look at the serviceModel data in the config file, and copy it into your calling app.config - or you need to use the more verbose way of creating the proxies in your code (i.e. specifying the address, binding, configuration etc through code to the constructors).
If you don't want to have to endpoint configuration on the client, you'll have to embed it into your proxy dll by specifying everything in code.
Another option would be to use a dynamic proxy, like this one, which would allow you to not have the serviceModel in your client apps.
I have WCF Client initialized like this
MyServiceClient client = new MyServiceClient();
so it uses the app.config to read the endPoints.
I would like to dynamically change the default config file to a file I define.
I know I can open a configuration file like this:
Configuration myConfig = ConfigurationManager.OpenExeConfiguration
but how can I set myConfig to replace the default configuration?
Check out this article here: Read WCF Configuration from a Custom Location.
It basically involves creating a custom ServiceHost that will read the configuration from a different file which you can specify, rather than from web.config or app.config.
Here's another excellent article on using custom config files for WCF services hosted in IIS:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/22/custom-service-config-file-for-a-wcf-service-hosted-in-iis.aspx
Marc
I've seen something similar done by just reading values out of a custom config file (that was just opened and read with a standard XML parser). Then the values were plugged into the WCF configuration entries programmatically.
This was done because multiple projects in the same solution all read their WCF configuration entries out of the same file. I'm not sure why they went with that architecture, but in the end it worked just fine.