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.
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.
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.
In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
EDIT
The command line that works fine for publishing is
MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=
In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.
Some answers to your questions.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can
this be done? If I leave the username and password empty, I am
prompted for it. Is there a way like manually modifying the .pubxml
files?
Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know.
If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in
PublishProfileName.pubxml.user that is local to each user? I could
at least save the username but obviously don't want that to be checked
in.
We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.
If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.
We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of
The Configuration itself is not part of PublishProfileName.pubxml but is stored in
PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.
The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way:
msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.
You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.
To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.
Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.
By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.
Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.
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.)
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