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.
Related
I've built and compiled my WCF client to run successfully. I've found that as long as these two files are together, my client will run anywhere on my computer:
Client.exe
Client.exe.config
When I move these files to another computer, there's an error:
System.InvalidOperationException: Could not find default endpoint element that
references contract 'Service.IService' in the ServiceModel client configuration
section. This might be because no configuration file was found for your
application, or because no endpoint element matching this contract could be
found in the client element.
I've already made sure that the service URL is accessible from the intended host of the computer.
After looking up the issue, seems like a solution is to copy the config retrieved from executing:
svcutil http://host/Service.svc
to the application configuration file. However, the config info is already in the App.config file when I built the project.
Do I need to recompile/build on every client machine that intends to use the WCF web service?
I seem to have resolved this by copying over the entire compiled folder:
Client.exe
Client.config.exe
Client.pdb
Client.vshost.exe
Client.vshost.exe.config
I don't have the time to go back and forth to see which subset of files are core or whether all these files are necessary, but hopefully someone can follow up with an answer to that.
I'm looking for an example in C# how to programmatically create WSDL file based on XSD files where WSDL file contains 1 main XSD file, which contains several import directives to subsequent XSD files. After that WCF service should be invoked based on created WSDL file. The service contract is known.
I've spent a lot of time on internet trying to find something but no luck so far.
There is a program that comes with .net sdk called wsdl.exe You could invoke this program using the methods of the Process class.
See this:
http://msdn.microsoft.com/es-es/library/e8zac0ca.aspx
And this:
http://msdn.microsoft.com/en-us/library/7h3ystb6(v=vs.100).aspx
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
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.
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.