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.
Related
I am currently making a WCF service that is hosted on an IIS. There are however some of my parameters that are hardcoded as strings inside the service and I would like to be able to adjust these without having to restart the service or the IIS.
I was thinking about reading them from a file but preferably the parameters should not be adjustable by anyone but me.
Then I thought about making a separate library with the parameters and add it as a dependency to the main project. Whenever I would have to change parameters I would just switch the library in the bin folder of the project on the IIS, but I don't know if this is even feasible.
You can think of what I am trying to accomplish as a licensing module. Say I have a license code and a date in my file/library and every 3 months (otherwise the service will not work) I have to replace it (if the customer renews) and it should only be me that can do it. I realize this is probably not how you would do licensing it is just an example.
Peter
You probably know that if it is a .NET app, then it is very easy to decompile and patch it.
You can use DPAPI for encryption like this:
1. Create a winform/console application which will do the encryption with "LocalMachine" context or a dedicated user on that server.
2. Encrypt a secret string with that app.
3. Decrypt the secret on web application startup with "LocalMachine" or run the application pool with a dedicated user.
Include reference to System.Security, then do something like below and you're done.
DPAPI password encryption in C# and saving into database.Then Decrypting it using a key
My web app currently uses the old FedEx WSDL API for rates and tracking and I have to now test it for FedEx's SHA-2 changes coming in Jan 2016.
I am a little confused about how to easily switch between "Production Environment" and "Test Environment" and need some advice.
I will first explain how the Web Service is currently integrated into my app so you understand the context of my question:
I initially uploaded the FedEx WSDL files to my second server (not the actual server the website app is on) and "Added Web Reference" to the remote url in my project. This may not have been necessary and there may have been an easier way (locally for instance) but because I did not fully understand how it all works this was the easiest route for me at the time.
This created an "App_WebReferences" folder within my project and within that a WSDL file and a discomap file for the track and rate services.
I also have two key/value pairs in my Web.config file under that point to these web references and gateway.fedex.com. I can't remember if I manually created them or if the WSDL import did it automatically.
I know that for testing purposes I need to use the "gatewaybeta.fedex.com" url and my FedEx "Test Credentials" not my "Production Credentials" but I am confused how it all works and where exactly I need to swap over the endpoint urls.
For instance, can I just change the url in the Web.config file or do I have to also change it in the WebReference and the original imported WSDL files that are on my second remote server?
After the import, is the WSDL file on the second remote server even needed or used in a live call by my app to the FedEx web service or can it be deleted now?
The discomap file references the original wsdl file location on my second server so how does that work and what would happen if I deleted the wsdl file from my second server?
Ultimately what I would like to do is create a simple admin FedEx web page with a basic form on it where I can enter a default FedEx tracking number and/or shipment details and then select from a drop-down list between TEST and PRODUCTION and have the aspx.vb code handle the url/credential changes so I don't have to manually change wsdls and webreferences and web.config file keys etc.
Hope someone can clarify this for me and set me on the right track!
Thanks.
Switching from test to production
If you haven't created your production credentials yet, go to the FedEx Web Services page, click "Move to Production" and follow the instructions. Your organization will need a FedEx customer account and you will need that info.
In your Visual Studio project, change the URLs in Properties\Settings.settings and App.config/Web.config. (If you use the UI to change Settings.settings, the config file will update automatically.)
Update the project to use your production credentials.
Consider taking advantage of config transformations to keep your test and production credentials in different config files.
How to add the web reference
What you did (placing FedEx's WSDLs on your own server so you can add the web reference using an http link) is fine but was a little more work than was necessary.
Next time you need to do this, simply keep the WSDLs on your own computer, and when you add the web reference, use a local file path (ex: C:\Users\Desktop\RateService.wsdl).
The WSDL and discomap files
These files are only used by Visual Studio to create the proxy classes. They are not referenced during the actual service calls. You could delete them but, for future reference, make sure they are part of your project.
I don't think there's a problem with the discomap pointing to the WSDL on a different server even if that address no longer exists. I think this reference is only used if you were to update the web reference (right click > Update Web Reference), which you shouldn't be doing because you're supposed to download the latest WSDLs from FedEx's developer site.
FYI: I have found the easiest way to switch between production and test environment endpoint urls and credentials is simply to change the service class object values within the code behind of the page according to the admin user's drop-down list selection.
So if they choose "Test" it's TrackService.Url = "gatewaybeta.fedex.com" and if it's "Production" then it's TrackService.Url = "gateway.fedex.com".
This overrides the endpoints in the web.config and WSDL files.
You have to remember to swap the key/password/meternumber credentials too.
I have an .Net webapplication which connects to a reporting web service.
In my development studio, I just add an webreference, then specify the path where the reporting server is installed and reportservice2010.asmx is found and ready for use.
But i do not know how to deal with it, after my application is compiled.
When I would like to distribute it on lets say 100 different servers.
The path to reportservice2010.asmx may(and surely will) change.
Of course what will make my application corrupt.
Please help !
When you added the web reference, Visual Studio should also have added a new section to the application's configuration file. That section specifies the environment-specific details of the web reference.
If, for any given target environment, the target address of the web reference changes then you can simply change the URL in the application's configuration file.
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
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.