We've got two web servers (win2008 sp2) load balanced. On one of the machines the service name (e.g myService.svc) portion of the SchemaLocation url that is generated in the wsdl types is camelCased while on the other server it is PascalCased (e.g. MyService.svc). Some php soap clients have an issue with this and interpret them as separate urls and end up with duplicate type definitions.
The code is the same on both servers - i've copied it from one to the other to make sure. I've been trough IIS (where i'm guessing the problem may be) however I cannot find anything that would control or affect the casing of only the service name portion of the url. I've even tried renaming the physical file (myservice.svc) to lower case however that had no effect.
Has anyone else had this or can point me in the right direction?
Many thanks.
You can add a configuration attribute httpGetUrl to the service behavior metadata to control what goes into the WSDL SchemaLocation value. This blog post explains how you would do it for the the domain name but it should work for the whole URI.
Related
We have a WCF client and we got the wsdl information in a file. How can I enter a relative URL (to the Visual Studio project) instead of an absolute URL? I tried many forms with no luck, the error message is Invalid URI.
Rationale: Not all developers have checked out the project in the same directory. So it is cumbersome to update the service reference.
What we do in similar scenario is having url pointing to localhost.
Therefore each developer has the service configured in their IIS with same url, something like http:\localhost... so config is the same for all.
If this is not an option you might use Slow Cheetah to transfom web.configs (we use it for configs pointing to DEV, QA, Beta, etc.)
I have wcf client. It uses .NET 3.5.
When I compile the client I get two files:
client.exe and
client.exe.config.
The second file contains configuration for the wcf client.
In my case I need to prevent the user sitting on the computer to see the urls and change some other parameters from the config file.
So the requirements are, the end user not to see and modify the data stored in the config. The config file contains the same data as app.config. I need to forbid the person using the program to see the end point urls so easy.
Also I have a lot of configuration there so I do not like to code in the moment.
Is there any solution for the problem (embedded app.config of something else)?
Edit: I do not need configurable options. The config file is automatically created when adding service reference from the studio.
Regards
You can also create your proxies programatically instead of using the service reference feature.
Every parameter in the serviceModel config section can be represented in code as well.
The ChannelFactory class will help you create proxies to the service.
You can easily encrypt entire parts of your config files - and not just web.config in web scenarios, but also application config's in stand-alone apps.
Check out some resources on how to do this:
Encrypting web.config values
Encrypting passwords in .NET app.config file
Encrypting the app.config file for Winforms application
When I turn on output caching for my service it doesn't appear to be cache-worthy in IIS. It really should be since I'm returning the same JSON content over and over. The varyByQueryString option seems like it would do the trick, but since my resources are URI based, there really isn't a query string, just a path to a resource. Has anyone successfully gotten IIS to output cache a WCF REST service?
After much digging using the FREB logs in IIS, my service is in fact cache-worthy. You can listen to the Cache events in IIS and it will show you exactly what is and is not caching. I found this more helpful that using PerfMon. I used the following link to set it up. Output caching will work and will in fact serve your content right out of memory after things get warmed up.
I'm throwing together a quick data service in WCF to be accessed by a public Silverlight 2.0 application. As my data is very static and relatively simple I'd like to just store it in local XML files (which is made easier as there are a VERY limited number of people who will ever edit it).
I'm wondering what the best way to find a relative path from within my service will be. In traditional ASP.NET I could use the Server.MapPath....within this WCF service nothing similar is available. This solution will ultimately be hosted at a hosting provider I have no control over so I can't hardcode any fixed locations. I'd much rather just get a relative path to some XML files in my AppData folder.
Any suggestions?
You could try using Environment.CurrentDirectory or AppDomain.CurrentDomain.BaseDirectory
Try using HostingEnvironment.ApplicationPhysicalPath.
The WCF services still have access to a lot of the same things as your ASP.NET pages (since, in the end there is still an HTTP request and response). You can still use Server.MapPath like so:
HttpContext.Current.Server.MapPath(...)
You could store the files in IsolatedStorage instead of in your folder for the application. Look at the example on the linked page to see how it works.
First, add an operation to the service to return the current directory. Have the new operation just return Environment.CurrentDirectory. In the client, check to see if you are surprised by what the current directory was. Adjust as needed.
thanks for any assistance.
I'm creating a wcf web service for an external client.
The client is requesting a copy of the wsdl.
I currently am waiting on being able to provide the client with access to the service.
when I go to my local webserver running the service (http://localhost/Services.svc?wsdl) I am shown
the wsdl, the data provided contains the method signatures (from the .svc code behind),
but does not contain the included model objects (Customer, Order, ext).
To get those objects, I can find the references in the shown data and go to the url
For me to provide all needed information to the client, so that they have the entire wsdl
should I provide the main schema and also each of the imported schemas?
or is there any other way of accomplishing this (other then the client hitting a server)
ie: is there a way of packaging all of them within one file?
(Seems like something would be available to extract each of those files?)
If I were to give a .zip with each of the files, would that be enough?
Thanks,
Steven
WCF packages up its WSDL and XSD (XML schema to describe the data being sent around) into various pieces, as you've already noticed. Those are referenced from your main WSDL with additional href's.
Or even better: you can run the "svcutil -metadata" command on the command line against the DLL or EXE which contains your service implementation - this will create all the needed files (typically several WSDl and several XSD) in the directory where you run the svcutil command. That's usually a more reliable way than piecing together the WSDL and XSD files from the ?wsdl URL (you usually end up missing one or two files).
Marc
If you manually downloaded each and every sub-WSDL and XSD referenced, then yeah, it would work; but it's cumbersome, to say the least.
An option worth looking into would be to use Christian Weyer's WCF extensions for flattening your WSDL so that WCF generates everything in a single file, then giving that to your client.