when adding a service reference an app.config is generated. What I'd like to know is, do the bindings, endpoints and everything else reflect the service, that I created the reference to? Do they specifically define that services bindings, security type,..etc, or is it simply a generic app.config? There seem to be a lot of settings..
Yes, the amount of stuff the Add Service Reference wizard dumps in your app.config/web.config is staggering - and largely unnecessary (because it basically puts in all the settings, even all of those that are default values).
Yes, the settings include thing like
binding and binding configuration (parameters like timeouts, proxies etc.)
behaviors (client-side)
client endpoint(s)
If you're interested in learning how to manually create those configs to the bare minimum (which is very easy to do, very easy to understand, too!), watch these videos:
DotNet Rocks TV Show #122: Miguel Castro on Extreme WCF
DotNet Rocks TV Show #135: Keith Elder Demystifies WCF
Both show how easy it is to create manual configs and how little you really need to supply! Highly recommended.
The settings do pertain to the service reference you just created. At least sometimes, the app.config is not useful in itself. For instance, if you are consuming services from a web application, the information in app.config needs to be copied to the appropriate section of web.config to be used.
If the service moves to a different location, you can just change the endpoint in the configuration accordingly, and the service should work as before.
Related
I have created a WCF Service Application project and created a single .svc file with a single method that takes a string and returns a string. I published the service to our IIS test server (not local machine IIS) and I can see the default page when browsing to http://wcftesting.com/WCFService.svc.
At this point, I am going to create a small html page to test that I can access this service and that it returns data properly. Before doing that I googled around to see if there were any pre-requisite steps that needed to be taken, but couldn't find anything concrete and most of the information was at least a few years old.
Is there anything else that needs to be done to make this work? Everything is pretty standard. No changes have been made to the web.config file, and no additional attributes have been added to the methods. I had seen some mentions of added RESTFUL attributes to the operation contract, but in all honestly I'm very new and wanted to keep things as bare bones as possible.
We are using Visual Studio 2015 and I believe IIS 7.
There is ServiceReferences.ClientConfig file that holds different settings of WCF services Silverlight application is using. Nice and easy, except once you set them you cannot change them later without modifying a xap.
I want to make these setting configurable with a less pain.
There are several options:
Add a dedicated section in web.config where an administrator could change them. Transfer these settings to silverlight then rendering object on page. Parse it in silverlight, then build channel manually. Something I'd rather avoid.
It would be nice if we could say silverlight application to load ServiceReferences.ClientConfig not from xap resources, but from a specified uri. That way I could place this config along web.config. Nice. Not possible though.
If I could substitute resource stream resolver, that would work too. Sadly it doesn't seem to be possible either. There is IApplicationResourceStreamResolver, but it's internal.
Maybe there is a way to rewrite application resource stream after a silverlight application is started?
I guess you want to make the servicesclient config file at the runtime.
If that is the case then simply create object of System.ServiceModel.BasicHttpBinding and assign properties and assign service URL to System.ServiceModel.EndpointAddress. This binding object and endpointaddress object can be then assigned to the client object constructor and voila!
My client insists not to store prone-to-change configuration settings in the Web.Config file for our webservice (WCF). His reasoning is that he will have to deploy the application every time he wants to change this or that setting in the configuration file. He, then, told me to store this configuration information in the database because, he says, that way one can change it whenever one needs without re-deploying the whole application, and because it is a more central place if we ever need to have more than one instance of the service running.
Of course I find this argument and reasoning plainly wrong. However, I would like to provide him with clear evidence in that he his mistaken. Can anyone please point me out a source or two I may site to show him that changes in Web.Config are automatically propagated to the runtime and that he doesn't need to do any kind of re-deployment?
Straight from MSDN on ASP.NET Configuration.
ASP.NET Configuration Overview
ASP.NET detects any changes to the configuration files and then
automatically applies those changes to the affected applications,
restarting the applications in most cases.
See How to: Transform Web.config When Deploying a Web Application Project
Well, the problem is how to organize assemblies for several WCF services hosted in the same domain, when the services might use different versions of the same referenced assemblies?
The thing is, that I have a series of WCF services which are currently hosted in the same domain, but the burden of updating one of these services is overwhelming due to the fact that I cannot be sure not to break other services when doing so. Therefore, it requires that I bring all other services up-to-date with the new version of assembly or assemblies which I am going to publish.
Updating the service - in my case - would be do change one or more assemblies in the bin folder. The problem is that other services might need the same assemblies. I would like to have the possibility of defining subfolders with the name of the service, and in each of these folder have a bin subfolder, the .svc file and all other stuff related to the service. This way I could isolate the service on the same domain.
I have searched for a solution and I have found a blog post by Scott Hanselman about probing, but it seems to apply to .NET 1.1, ASP.NET...
http://www.hanselman.com/blog/PermaLink.aspx?guid=4d0ef4fb-f8ae-4355-a658-3c0432c98dbe
Unfortunately, I cannot make it work for my scenario (.NET 4.0). Furthermore, I am not sure that this would scale the way I need. Even if I could make it work, then is it going to be seperate AppDomains, and if not would that be a problem? I need the complete isolation of the service, but still being hosted in the same domain.
Thanks, Jacob.
Update
Actually, I got a bit further. I tried to put the [ServiceName].svc.cs and the interface into its own project and compile it, and then change the .svc file slightly to reference the assembly just created as described by Hanselman. If I leave out the Import statement also mentioned in his post and doing the other bits aswell, then it actually works.
The only thing is if I have a list of paths, something like...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Tasks\bin;Products\bin"/>
</assemblyBinding>
</runtime>
... then can I be sure that the assemblies used are from the right folder, and not resolved in the order they appear in the list? An example could be if the ProductsService uses the same assembly as TaskService but in a different version, then if the assembly is resolved in the order they appear in the privatePath string above then it would use the wrong assembly I guess? Then it is not completely isolated after all.
If I am right in this assumption, then perhaps strong-naming is the answer?
Thanks again, Jacob.
I believe what you need is Service Versioning rather than probing.
You have clients which need to use different versions of the same service over the network. This is a common issue and is addressed by Service Versioning. So they are not referencing DLLs, they connect to the service.
So you just create a new version, deploy to a new endpoint and get new clients using the new service.
Has any put much thought into this? Personally, I think managing endpoints in configuration files are a pain. Are there any pros/cons to doing one over the other?
Only points in favour of configuration files from me.
Managing endpoints in configuration files mean that you don't have to update your application if (or perhaps I should say when) the endpoints change.
You can also have several instances of the application running with different endpoints.
I tend to like the config approach myself too, other than the config file can get pretty big.
The one thing I have noticed with WCF configuration is that there is a lot of stuff that you can do from code that you can't do in XML config without adding your own custom extensions. In other words, doing config in code will allow more flexibility, of course you could also just code your own extensions and use those from configuration.
However, do note that there is what I would consider a 'bug' in Visual Studio that if you start making your own extensions and including them in XML, then VS won't like your config file any more and will tag them as errors, and then if you try to add a new service through the wizards, it will fail to add the endpoint to the configuration.
This is sort of a followup to my own answer:
After months of having everything in xml configuration, I'm changing everything to construct the endpoints and bindings in code. I found a really good case for having it in code;
When you want to have a deployable / sharable .dll that contains WCF clients.
So for example if you have a CommonClients.dll that contains all your WCF interfaces and contracts to communicate with some remote server, then you don't want to also say "here is 100 lines of xml that you also have to drop into your app.config for every client to make it work". Having it all constructed in code works out much better in this case.
There is also a "feature" of .NET 3.5 where if you have some wcf extensions, you have to specify the fully qualified assembly name. This means that if your assembly containing the extensions changes the version nnumber, you have to go change the assembly name in the config file too. It is supposedly fixed in .NET 4 to use a short assembly name and not require the full name.
Offhand, an endpoint in a config file doesn't need to be recompiled when it's changed. This also means that you just need to update your config file when moving an application from Development to UAT to Production.
If your just coding something for your own use at home, then there's no real difference. However in a business environment, having the enpoint defined in your config file saves all sorts of headaches.
When using an app.config, your application does not need to be recompiled to adjust to a change. Also it can be resused in multiple situations with the exact same code. Finally, hardcoding your endpoints (or anything subject to change) is poor coding practice. Don't fear the configuration file, it's declarative programming. You say, "I want to use this endpoint." and it does the work for you.
I generally do programmatic configuration, as I don't want to expose my applications internal structure the the user. The only thing I keep configurable is service address, but even this I keep in userSettings section, not system.ServiceModel.
I prefer and recommend the configuration file approach. It offeres a lot of flexibility by allowing to make change to your server without the need to recompile the applcation.
If you need security, you can encrypt the config file.
The biggest worry with plain config files could be that it can be accidentally (or on purpose) modified by the end user causing your app to crash. To overcome this you could make some tests in code to check the configuration is ok in the config file and if not, initialize it programatically to some defaults. I presented how you could do that in another answer to this question.
It's just a question of how much flexibility you need.
Usually I prefer the config file approach.
Check out the .NET StockTrader app. It uses a repository to store config data and has a separate app to manage the configuration. The setup and structure is pretty advanced and there's a fair bit of head scratching for anyone like me that only has the basics of WCF configuration so far, but I would say it's worth a look.