just want to know what happens behind the seen when we create a wcf service in a project and add service reference in another project.
So to know it i am doing it all without Visual Studio i.e. writing service code in notepad files and using command line to run svcutil.exe.
My question is do i need to run svcutil at both side (service side and client side) to export and import metadata?
And what files at minimum are generated by svcutil.exe.
Thanks friends.
SvcUtil will generate a proxy class and a configuration file which will specify things such as the bindings the service uses, security credentials, read quotas, the address of the service, the contract etc. SvcUtil will generate the metatadata, serialization code and so on. You run SvcUtil on the service machine and the two files it gives you (proxy class and configuration file) may be used to create clients on different machines.
Typically these are also generated by the visual studio 'add service reference' feature so you don't really have to use SvcUtil. Visual studio actually uses SvcUtil behind
the scenes to generate the client proxy, so it seems a bit less 'messy' to use Visual Studio for generating client proxies.
In SOA terms some argue that generatting clients manually using SvcUtil or Visual Studio is not good practise since thes etools generate unnecessary code with too much coupling and don't give you much flexibility. You can separate your assemblies, such as your services, contarcts, proxies etc. and create service channels using the ChannelFactory class. This nice article is a proponent of the latter practice of generating client proxies.
Related
I've been working with about a dozen WCF Services that have been deployed to various machines with IIS. All binding/configurations have been kept in the usual "web.config" file that was created to keep the services more configurable and keep the service code itself more clean. However, I've just recently been tasked with creating a Windows Service to host these WCF Services. One question that I have is, do I just copy all the settings from the web.config file to the App.config file for the windows service? Or do I need to reconfigure all the endpoints/bindings/etc. using a different format in the App.config file? I've never created a windows service before and not 100% sure what I need for setup once I've created the Windows Service Host. Thanks in advance.
The WCF configuration elements in web.config should translate directly to app.config. I've cut and pasted web.config elements like this in the past. The only thing to watch out for is that neither web.config nor app.config like certain elements repeating, so if you're merging configuration data from multiple web.config files, you'll have to ensure that you don't repeat sections that should only exist once.
I always thought the .NET config model didn't fit well with WCF service configuration.
There's a way to teach WCF to retrieve its configuration from an alternative location. I like to set it so that the WCF service retrieves its configuration information from ServiceName.config rather than web.config or AppName.exe.config. This solves the problem of repeating elements mentioned by Harper Shelby.
Here's a full explanation and some code.
Using that custom service host, moving a WCF service from IIS to a self-hosted model is really simple.
See also, WCF Configuration - Split it out of app.config
I have a solution in VS2010 with 3 projects:
WCFServiceLib - a project created with the WCF Service Library template.
ServiceHostConsole - a project created with Console Application template.
ServiceClientConsole - a project created with Console Application template.
The VS template created an app.config in the WCFServiceLib that contains all the settings for the services I want to expose.
The ServiceHostConsole has WCFServiceLib as a reference and hosts the service but does not have it's own app.config file.
If I try to run the host project without an app.config, it fails to host the services, so I moved the app.config from the WCFServiceLib to the ServiceHostConsole.
The ServiceClientConsole has a Service reference to a service inside WCFServiceLib. But once I move the app.config from the Lib project to the Host project, I can no longer Update Service Reference or add new services that I added to the lib project.
In order for the client project to see the service references I have to move the app.config back to the lib project, do the updates/additions to the service references on the client, and then move the app.config back to the host project.
Note that I cannot leave a duplicate app.config file in both the Service Lib project and Host project as this will cause the host to also fail to start. This would be a bad solution anyway as it would create duplicate config in different places. A change to just one of them could create issues that are difficult to track.
It seems very strange that this moving around of the app.config file needs to happen to make things work for both the host and the client, and that they can't both work at the same time.
I'm sure this must be an issue with the way I set things up (although I set them up with the default templates), and I guess there must be a better way to solve this.
This problem becomes very annoying when you are actively developing the services and need to constantly run the host and test the client with the updated services, hence the title of the question:
How do you maintain a WCF Service Library in VS2010 for both a Host and Client projects?
WCF service library creates a config because it is used by a tool called WcfServiceHost.exe. This tool hosts your service if you try to test it without your own hosting application and based on your description it also hosted the service when you added a service reference in the client (because of that you cannot update the reference when you move the config from the library). The config in the library is never used by a hosting application and it doesn't collide with a config used by the hosting application.
A hosting application always needs its own config and there should be no problem to have a config in both the host and the library. You should not create a service reference from the library itself. Once you have your own host use it when you add service reference and maintain only the config in the host.
There is one little problem. To add service reference the service must run. If both the client and the host are part of the same solution you must run the service without debugging (or outside of visual studio) to be able to add service reference to the client.
I'm concerned about files should be included in a deployment of a .NET project. I have console applications that are consuming a WCF service. The WCF service is running over HTTP. Do I need to deploy all the XSD, SVCINFO, WSDL & SVCMAP files that are in the Service References folder?
Thanks for any help. I sure wish there was a single page at Microsoft that definitively explained what file types were required in a deployment.
The only bits you need at installation time are the compiled code and the .config file. The rest of the pieces (the code, WSDL, etc) or all for compile / design time.
I have a WCF service composed by two projects:
WCF service library
WCF Web application
The First project has a service call IMyService implemented by MyService. It is configured by using WS binding and if I press F5 on this project the WCFTestClient render the WS binding.
In the web app I have an .svc file with this markup with the same name
<%# ServiceHost Language="C#" Debug="true" Service="[Namespace].MyService" %>
If I press F5 on this project it renders a BasicHttpBinding. Same in the Client.
Why?
I have just checked that WCF Service Library project by default creates app.config with WSHttpBinding used for default service. When you run WCFTestClient it always uses this local config. If you want to use WCFTestClient to test additional services you must add their configuration to this config. This config is never used for anything else.
WCF Service application uses web.config. In WCF 4.0 it uses simplified configuration which adds endpoints based on some predefined conditions. By default it adds BasicHttpBinding endpoint to all services exposed over HTTP with common ServiceHostFactory.
How is your config file configure? If you configure the endpoint to use the wshttpbinding, this is the one that should be used.
Would you mind adding some code here (including the binding and endpoint details from the config file), so we could take a look?
Thanks,
Roberto Lopes.
I believe the original question was very poorly posed, to get a satisfactory answer you need to clearly state all the details.
First which version of Visual Studio are yo using? Since nothing is said, I'll assume it's the latest version VS2010 with SP1.
Let's say you have a visual studio solution that has two projects, one is a WCF Service Library, another is a WCF Application, both created using the default project template without any manual tweaking.
The WCF Service Library will have a app.config file with the following line:
in short, Visual Studio 2010 (SP1) uses wsHttpBinding for WCF Service Library projects by default.
The WCF Service Application project, however, will have a web.config file that contains no explicit endpoint definition, in which case, the default endpoint binding used is basicHttpBinding.
The OP said "When I pressed F5 on this project ....", this is a very misleading statement.
What does it mean to "press F5 on a project"? Do you mean you selected the project node in the solution tree, then pressed F5? if that's the case, what happens will always depend on which project is set as the start-up project in the solution (not on which project node is currently selected in Visual Studio UI).
If the WCF Service Application project is the start-up project, pressing F5 will NOT cause the WCF test client to run, instead, it will cause the folder of the project to be displayed in IE.
If the WCF Service Library project is the start-up project, the WCF test client will be run, and this is only because in the debug section of the project's properties window, the start options has the following by default:
/client:"WcfTestClient.exe"
this is B2B scenario, one client (at least for now).
Server environment:
WCF service, IIS6, .NET v3.5
Client environment:
dev shop is .NET 2.0/VS2005. Will be calling my WCF service.
Question: should i
(a) open WSDL gen for the client(not desirable for security reasons)
(b) send a WSDL file(s) to the client
(c) pre-compile Proxy into dll (on my side) and send it to the client
(d) ???
?
Any suggestions on what would be the best practice for this scenario, any pros/cons?
Thanks in advance,
Igor
Why is a publicly available WSDL not desirable for security reasons?
I may be willing to admit that publishing an API (which is basically what you are doing with WSDL) makes you a bit more vulnerable than if you didn't, but it would be wrong to assume that hiding the WSDL constitutes any kind of security. This is ironically called security by obscurity, and it will be broken by any determined attacker.
The web service should be secure in itself. WCF offers many security features, but that is perpendicular to your question.
I'd prefer publishing the WSDL. If you don't want to do that, or if there is a policy in place that says that you can't do that, then send the WSDL to the client team so they can use it as they wish.
Precompiling the proxy will only enforce your coding conventions on the client team, and they may not appreciate that - for example, I often prefer my proxies to be generated with the /i switch that makes the generated classes internal. I also like to be able to specify the .NET namespaces so that they fit the rest of my code. That would not be possible if I got a precompiled assembly (I would be able to use it anyway, but it would just annoy me).
If you don't want to actually publish the WSDL and make it available online for calling clients, then I would prefer the "send me the WSDL and XSD" approach.
That way, you still give the client calling you the ability and flexibility of creating the proxy the way they see fit.
I would only consider using a pre-compiled proxy in an assembly if the calling party was unable or unwilling to create the proxy themselves, and only if they asked me to supply that code in assembly form.
Marc
In order of preference I would be inclined to:
Have the service expose the WSDL (with security enabled)
Send a WSDL file to the service consumer
I was going to list option 3 as sending a proxy DLL but on second thought I wouldn't even list it as an option. It seems to me that shipping your client a proxy DLL opens up a big can of worms that I would not want to deal with.
The main problem is that you end up having to support executable code that is deployed at the client site. The proxy code could be generated by svcutil but if there is some sort of problem invoking the service I can just see the client calling you for support and telling you that your proxy is not working. Now, their claim is probably not correct but it's hard for you to prove it since you don't know what they are doing on their side. e.g.
Maybe they didn't install the proxy DLL?
Maybe there is some permission problem?
Maybe they don't know what they are doing (yeah, I know that never happens. :) ).
Maybe a .NET upgrade on their side affected your proxy?
You might even run into some versioning headaches when sending them new proxies.
If your customer is not that savvy instead of trying to help them by creating proxy DLL perhaps putting some time and effort into assisting them in getting the correct configuration and usage of your service would be a better approach?