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.
Related
I am looking to move some .NET Core applications into production and with the old .NET framework you could update the compiled DLL's for the application's code at any point.
The next time the application pool recycled, you would get your new code - or you could recycle the app pool manually.
With .NET Core, it appears that the running application locks the DLL and it cannot be overwritten until either the process is closed through inactivity, or is ended via Task Manager (Window's server here).
Is the a preferred method to publish a new version without having to set a maintenance window for all the users? This is on a Windows 2012 R2 server running the .NET Core framework via IIS 8 and the App Pool having no managed code.
For ASP.NET Core hosted with Kestrel runs in separate process and IIS works like Reverse Proxy. So there is not way for DLL release unless you implement it you your application.
Set up a hosting environment for ASP.NET Core on Windows with IIS, and deploy to it section Deploy the application, item 4.
If you want to avoid downtime simply setup two websites on IIS with same set of settings, make an update on second website, put first down, and start second.
I think the simplest way is to copy all files into a fresh folder and changing the physical path of the web site.
For example, you have all web sites under C:\WebSites, you also have a subfolder for each web site such as C:\WebSites\MyWebSite and a subfolder for each version, such as C:\WebSites\MyWebSite\V01.00.
To deploy a new version V01.01, create a new subfolder C:\WebSites\MyWebSite\V01.01 copy all files to that folder and change the physical path of the web site.
You can easily change the physical path with PowerShell:
Import-Module WebAdministration
Set-ItemProperty -Path "IIS:\Sites\MyWebSite" -name "physicalPath" -value "C:\WebSites\MyWebSite\V01.01"
This is a form of "hot publishing". Additionally you can easily roll back to the previous version if something goes wrong.
Another alternative is to use symbolic links, for example C:\WebSites\MyWebSite may point to C:\WebSiteVersions\MyWebSite\V01.00. To deploy a new version, copy all files to C:\WebSiteVersions\MyWebSite\V01.01 then change the symbolic link so that C:\WebSites\MyWebSite points to C:\WebSiteVersions\MyWebSite\V01.01, and finally recycle the application pool. Click here to see code for doing that
There is also another option called "blue green deployment" strategy. This strategy requires configuring a single server web farm and two web sites. Please see this article for a complete description.
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.
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.
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