I will be as specific as I can, but honestly, I do not know where to look for the problem.
I was in the middle of actively writing some code on a visual studio project (VS 2010) on my laptop. That project communicates via WCF to the office server. During this activity, Windows automatic update decided to shutdown my machine, update, and reconfigure it, before automatically rebooting.
Now something has changed and I can no longer communicate durring debugging with the server application (maybe something with the ASP.Net development server?). I'm sure this is an easy fix--if you know where to look. (All my files seem intact and the project compiles normally without difficulty or error).
(As this service has been working correctly for many months, I really don't want to rebuild it.)
Can someone please tell me what Windows update changed? (I'm sorry if this is too vague, but I really don't know how to go about finding the setting(s) that were changed).
For what its worth, here is the app.config for the client:
<?xml version="1.0"?>
<configuration>
<!--
useLegacyV2RuntimeActivationPolicy=true is needed to run handwriting recognition with IALoader.dll
-->
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true"/>
<endToEndTracing propagateActivity="true" activityTracing="true" messageFlowTracing="true"/>
</diagnostics>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_INovaDataService" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647" />
</basicHttpBinding>
<wsHttpBinding>
<binding name="WSHttpBinding_INovaDataService" />
</wsHttpBinding>
</bindings>
<client>
<endpoint address="http://xxxxxxxxxx:43175/NovaWebSite/Nova.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_INovaDataService"
contract="DataService.INovaDataService" name="OfficeService" />
<endpoint address="http://yyyyyyyyy:9000/Nova.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_INovaDataService"
contract="DataService.INovaDataService" name="LibraryService" />
</client>
</system.serviceModel>
</configuration>
Thanks for any help with this (it is quit aggravating).
Hopefully this can help anyone getting here. After many hours of study, I noticed that the project I needed as the start up project in the Visual Studio Solution was no longer checked. Somehow when Windows Update forced closed the Solution (VS 2010), it also changed the startup/main project to the ASP.Net Website (which is in my same solution as the client project). When the correct project was selected, all runs well once again. Don't know how this happened, but problem solved. Thanks everybody.
Related
I'm running IIS 8.5 on Windows Server 2012 R2. It's a test server and I have 3 sites running on it, Dev, QA, and Staging.
The issue is with QA. The ASP.NET Sitefinity application running there resolves the incorrect domain name when it dynamically creates links. Specifically it uses the www in the domain instead of qa. So, https://qa.myexamplesite.com is the desired link, but it creates https://www.myexamplesite.com.
There is a www.myexamplesite.com but it is hosted on a completely different machine. Also, the application code does not contain references to the domain.
Dev and Staging are working fine. I changed the physical path of QA to point to Dev, but QA is still broken. I changed the physical path of Dev to point to the QA application code, but Dev does not break - still works fine. At this point, I'm reasonably sure that there is a configuration issue in IIS but I've so far been unable to find it. I've also been unable to recreate the issue on my local machine.
Here are the configuration details from the ApplicationHost file ommiting any sensitive or non-pertinent information:
<applicationPools>
<add name="DefaultAppPool" />
<add name=".NET v4.5 Classic" managedRuntimeVersion="v4.0" managedPipelineMode="Classic" />
<add name=".NET v4.5" managedRuntimeVersion="v4.0" />
<add name="dev.myexamplesite.com" autoStart="true" />
<add name="staging.myexamplesite.com" autoStart="true" />
<add name="qa.myexamplesite.com" />
<applicationPoolDefaults managedRuntimeVersion="v4.0">
<processModel identityType="ApplicationPoolIdentity" />
</applicationPoolDefaults>
</applicationPools>
<sites>
<site name="dev.myexamplesite.com" id="1" serverAutoStart="true">
<application path="/" applicationPool="dev.myexamplesite.com">
<virtualDirectory path="/" physicalPath="S:\Dev\myexamplesite" />
<virtualDirectory path="/App_Data/Sitefinity/Search" physicalPath="S:\Dev\SitefinitySearch" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:dev.myexamplesite.com" />
<binding protocol="https" bindingInformation="*:443:dev.myexamplesite.com" sslFlags="0" />
</bindings>
</site>
<site name="staging.myexamplesite.com" id="3" serverAutoStart="true">
<application path="/" applicationPool="staging.myexamplesite.com">
<virtualDirectory path="/" physicalPath="S:\Staging\myexamplesite" />
<virtualDirectory path="/App_Data/Sitefinity/Search" physicalPath="S:\Staging\SitefinitySearch" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:staging.myexamplesite.com" />
<binding protocol="https" bindingInformation="*:443:staging.myexamplesite.com" sslFlags="0" />
</bindings>
</site>
<site name="qa.myexamplesite.com" id="2" serverAutoStart="true">
<application path="/" applicationPool="qa.myexamplesite.com">
<virtualDirectory path="/" physicalPath="S:\QA\myexamplesite" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:443:qa.myexamplesite.com" sslFlags="0" />
<binding protocol="http" bindingInformation="*:80:qa.myexamplesite.com" />
</bindings>
</site>
<siteDefaults>
<logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
<traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
</siteDefaults>
<applicationDefaults applicationPool="DefaultAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
I've been working through the resources to try to find where this problem could exist. The application is using Sitefinity propietary methods to dynamically create the links, so I've been unable to pin down exactly what method they are using. Here is some of the weird behavior I've been able to document.
I can refresh IIS, flushdns etc but the behavior does not change. I've restarted the server but the issue remains.
After a refresh, if I navigate to the site using a browser on the server then the URLs resolve correctly consistently. If I navigate to the site from an incognito browser then similarly the URLs are correct UNTIL I reload a few times, usually by the second or third page load the URLs are incorrect again. This is true regardless of the browser I'm using.
It seems like an IIS caching issue - but I can't track down where this is configured. There is no configured output caching that I can detect.
(aside) If it's helpful - the application code is calling this method from the open sourced Sitefinity library feather:
https://github.com/Sitefinity/feather/blob/master/Telerik.Sitefinity.Frontend/Mvc/Helpers/HyperLinkHelpers.cs
It's specifically calling GetFullPageUrl (line 149). However, I found this of limited use since it calls UrlPath which is a member of the proprietary Telerik.Sitefinity.Web.
I appreciate any insight, resources, direction, thoughts or rebukes on this problem.
Thanks
Can you go to Administration > Settings > Advanced > System > Site URL Settings
and see if Enable non-default Site URL Settings is checked and if the Host field is hard-coded to any of the other sites.
If so, you may want to correct it.
I want to partially credit Veselin Vasilev since he was on the right track. So here's what happened and how we fixed it.
At the time the error had started to occur we had another Sitefinity instance running and pointed to the QA db. Sitefinity, for some reason, started referring to a piece of db configuration after this event. It's not clear what this trigger was precisely, or what allowed it to work so long prior to that event with this incorrect information.
The db configuration in question is a table called sf_sites. There is an entry called live_url that must be changed in order to fix this. We had restored a production instance of Sitefinity in our test environments to test a Sitefinity upgrade, not knowing that the Sitefinity db kept domain name records.
The configuration that Veselin was talking about overrides that live_url property (although I could never get that override to work properly). What's odd is that we had restored over the test db with production db months ago and were never presented with an issue. It wasn't until we had multiple sites hitting the same db that the issue presented and even after removing the second site would not go away.
Anyway, updating the sf_sites table is what did the trick. Please add this to your check list if you need to copy one environment's Sitefinity db into a new environment.
Before some one commenting that it is a duplicate, please note that i have gone through the suggestions given in internet.
Scenario:
I am having a web api call and have only one end point in the webconfig`
<client>
<endpoint address="http://localhost/RegistrationService/RegistrationService.svc"
binding="basicHttpBinding" bindingConfiguration="RegistrationService"
contract="RegistrationService.IRegistrationService" name="RegistrationService" />
<endpoint address="http://localhost/ElectronicCustomerFileService/ElectronicCustomerFileService.svc"
binding="basicHttpBinding" bindingConfiguration="ElectronicCustomerFileService"
contract="ElectronicCustomerFileService.IElectronicCustomerFileService"
name="ElectronicCustomerFileService" />
</client>
`
following is the binding equivalent
`
<bindings>
<basicHttpBinding>
<binding name="RegistrationService" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" />
</binding>
<binding name="ElectronicCustomerFileService" />
</basicHttpBinding>
</bindings>
`
While i run the application i am getting error
An endpoint configuration section for contract 'ElectronicCustomerFileService.IElectronicCustomerFileService' could not be loaded because more than one endpoint configuration for that contract was found. Please indicate the preferred endpoint configuration section by name.
Tools Used
I am using Visual studio 2017 . I had Visual Studio 2019 and uninstalled it thinking that the issue is due to visual studio version issue
Interesting Fact
If i remove the end point from the webconfig , and try connecting to the web api, it is working properly . I checked the folder to see if any other webconfig is there in root folder and cannot find it
From where this web config is getting called
I restarted IIS. Deleted temporary files in Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files. But not working
It seems like the default website directory was pointing to a different project location
Go to IIS manager
Select Default Web site
go to basic setting in right hand side
Check if the Physical path is pointing to a different location
If the path is not pointing to above, change the physical path to
%SystemDrive%\inetpub\wwwroot
I develop asp.net apps on a mac using parallels. I am trying to achieve that when I run a web, it opens in my Mac Chrome. There is a nice guide how to do that:
http://www.dontpaniclabs.com/blog/post/2015/08/25/browser-debugging-between-os-x-and-visual-studio-in-parallels/
I have followed the guide and it works with one annoying issue that I am trying to fix but haven't succeeded yet. When I open the solution and the web project loads or when I save the project settings I get the following warning:
The error occurs when I modify bindings in a site element in applicationhost.config which can be found in <solutiondir>\.vs\config\*applicationhost.config:
Modified site element/bindings
<site name="UnitechSales" id="2">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Projects\UnitechSalesApp\UnitechSales" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:51267:localhost" />
<binding protocol="https" bindingInformation="*:44300:localhost" />
<binding protocol="https" bindingInformation="*:44300:arrakis-win" />
</bindings>
</site>
The original file simply does not contain the binding elements with the computer name and contains only localhost bindings.
When I run the website, it correctly opens in my mac browser. However, getting the error all the time is quite annoying.
Edit
.csproj IIS
<UseIISExpress>true</UseIISExpress>
<IISExpressSSLPort>44300</IISExpressSSLPort>
<IISExpressAnonymousAuthentication />
<IISExpressWindowsAuthentication />
<IISExpressUseClassicPipelineMode />
.csproj Web project ext
<WebProjectProperties>
<UseIIS>True</UseIIS>
<AutoAssignPort>False</AutoAssignPort>
<DevelopmentServerPort>51267</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>https://arrakis-win:44300</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>
<CustomServerUrl>
</CustomServerUrl>
<SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile>
</WebProjectProperties>
You forgot to keep your project file (.csproj/.vbproj) in sync with your config file.
More technical details can be found in my blog post,
https://blog.lextudio.com/2015/11/jexus-manager-secrets-behind-visual-studio-iis-express-integration/
I have added multiple sites inside a azure web role, like below:
<WebRole name="site1" vmsize="Small">
<Sites>
<Site name="site1" physicalDirectory="..\site1">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.site1.nl" />
</Bindings>
</Site>
<Site name="site2" physicalDirectory="..\site2">
<Bindings>
<Binding name="ndpoint1" endpointName="Endpoint1" hostHeader="www.site2.nl" />
</Bindings>
</Site>
</Sites>
......
I have added two configurations for each web application to make database connection string different -> Web.Dev.Config and Web.Staging.Config.
When i right click the Cloud Service projcet -> 'Publish', and choose the 'Build configuration' to 'Dev', these two web site were be published successful.
But in the site2, the connection string inside Web.config seems incorrect , the folder of site2 contains all configurations of web.config files like Web.Dev.config and Web.Staging.config, and all cs files still exists, it seems the site2 was not build correctly.
Is there anybody has experience about this?
I have the same issue, but I've found a few other articles that explain how to resolve this.
https://kellyhpdx.wordpress.com/2012/04/11/deploying-multiple-web-applications-to-a-single-azure-instance-and-applying-web-config-transforms-correctly/
Windows Azure with Multiple Sites in One Role not transforming 2nd web.debug.config to web.config
I have a C# ASP.NET project with 15 WCF/ASMX Service References. Each service is deployed to three different servers; test, staging and live.
Often we need to change the URLs of these service references to different servers, to be able to debug using the correct service with the correct implementation and data.
When managing these Service References I'm having a hard time keeping the URL in sync. When creating a Service Reference FooService it stores the URL in three seperate files:
FooService.disco
configuration.svcinfo
Reference.svcmap
Along with creating an endpoint node with the URL in the Web.config.
If I change the endpoint URL in the Web.config and rebuild the project, it doesn't update the URL in the other files, so it's out of sync. So when I right-click the FooService and click Update Service Reference it doesn't use the URL stored in the Web.config, it uses the URL in the other files.
So the only way is to right-click the FooService and click on Configure Service Reference and enter the new URL. But that doesn't always work, because sometimes it creates a new node in Web.config named FooService1, so I get an error when running my application saying that there are two instances of the same endpoints.
So often I need to skim through the Web.config and delete duplicates of endpoints, which is very frustrating.
What is the best way to manage multiple WCF service references when changing the URL to the service often?
First an overview
The way I handle it is to not add the service reference via Visual Studio. What I have is each service has it's own Proxy project in the solution, to proxy is created using a simple one line batch file. Each of these is then included in the website(s) as a "vanilla" reference. The end point is configured manually in the web config. I have three deployment options: Debug (local), Staging and Release. At the web.config level the different addresses are handled by web.config transformations . The proxy project files are configured so that the correct end point address is used depending on the solution configuration. However it is important to note that web.config transformations only apply on publishing the solution.
In pre-VS2010 I had 3 variations of the web.config files which would overwrite the active web.config; however overwriting the web.config in this way always felt "risky" to me. In this case I think that using transforms for publish will still work, but in the actual web.config file have block of connections that you can comment in and out on those occasions when you want to debug the staging or development servers.
I only have 2 services, so my set up was pretty easy, with 15 there will be a fair bit of work involved to set up, but it will save you head aches in the long run.
Implementation
Back Up Everything First!!
Also keep handy a copy of the existing web.config to help with configuring the end points later on.
Also note that the batch files won't work if your solution is in a path with a space in its name, e.g. the default location VS puts its' projects. All my projects are in the following structure C:\Source\vs2008\, C:\Source\vs2010\ etc. I'll see if I can find a better solution for this.
0 Run VisualStudio as an administrator
Right click Visual Studio from the start menu and select "Run as Administrator". We need to do this as VS will be writing files.
1 Delete Existing service references
You shouldn't need any help on this one.
2 Add Proxy Projects
Doing this now means you only need configure the solution for test|staging|live once.
From the File menu select "Add" then "New Project" and from unser the "Visual C#" tmplates select "Class Library" and name it something sensible. I'll be using FooService.proxy for this example. Rename the class file, I'll be using FooService_proxy.cs in this example.
Add the following references to the project:
System.Runtime.Serialization
System.ServiceModel
Add one project for each service. We will comeback and update these projects later.
3 Configure The Solution to handle test|staging|live
I'm assuming you use test when developing the asp.net website on your local machine.
Open the "Configuration Manager" by selecting it in the Build Configuration dropdown menu.
Under the "Active Solution Configuration" dropdown select "New"
For the Name I'd suggest "Staging" and check the "Create new project configurations" check box.
In the Solution Explorer, right click on Web.Config and select "Add config transforms". This will add a new file for the staging web.config transformation. Click the expander arrow and you will see three sub files: Web.Debug.Config, Web.Release.Config, Web.Staging Config.
4 Set Up Proxies
Add a batch file to each proxy project by Clicking on the project in the solution explorer and selecting "Add > New Item". Use a text file and name it "CreateProxy.bat.
Insert the following into the new file and save:
:: ============================================================================================
:: Create the proxy file from the service wsdl
:: Input parameters
:: SDK Path The location of svcutil.exe
:: WSDL File Arg1 (%1)
:: Output Proxy .CS file Arg2 (%2)
::
:: Called by the build process of the BeforeBuild target to re-gen the proxy code.
:: Make sure to change FooService.proxy
:: ============================================================================================
svcutil %1 /ct:System.Collections.Generic.List`1 /serializer:DataContractSerializer /tcv:Version35 /n:*,FooService.Proxy /out:%2
Now right click on the proxy project and click "Unload Project", saving if prompted. This will enable us to get in and modify the project file. Right Click the now greyed out proxy project name and select "Edit".
Add the following just befor the closing </project> tag. Note you may need to change the
path SDKPath depending on your location of svcutil. Also make sure to name FooService_proxy.cs whatever you named the proxy file.
<PropertyGroup>
<!-- These properties are used by the svcutil batch file task in the BeforeBuild Target to regen the proxy code -->
<SDKPath Condition="'$(SDKPath)'==''">C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SDKPath>
<WSDLPath Condition="'$(WSDLPath)'=='' and '$(Configuration)' == 'Debug'">http://[Path to TEST Server Service]</WSDLPath>
<WSDLPath Condition="'$(WSDLPath)'=='' and '$(Configuration)' == 'Staging'">http://[Path to STAGING server Service]</WSDLPath>
<WSDLPath Condition="'$(WSDLPath)'=='' and '$(Configuration)' == 'Release'">http://[Path to LIVE Server Service]</WSDLPath>
<SkipProxyRegen Condition="'$(SkipProxyRegen)'==''">false</SkipProxyRegen>
</PropertyGroup>
<Target Name="BeforeBuild">
<Message Importance="normal" Text="Rebuilding the proxy code from batch file '$(ProjectDir)CreateProxy.bat'" Condition="'$(SkipProxyRegen)'=='false'" />
<Exec Command="$(ProjectDir)CreateProxy.bat $(WSDLPath) $(ProjectDir)FooService_proxy.cs" WorkingDirectory="$(SDKPath)" Condition="'$(SkipProxyRegen)'=='false'" />
</Target>
Save the changes and then right click on the greyed out project name and select "Reload Project".
Right click on the project and select build, make sure that your proxy file is now populated.
Set each proxy project so that it always build into only its' \bin directory, e.g. not bin\debug etc. Right click on the proxy project and select "Properties". Select the "Build" tab and change the "Configuration" drop down to "All Configurations". Set the "Output path" to bin\
5 Add Proxy References and End Points To Your Website
Add a reference to each proxy project to your website by right clicking "References > Add reference" and then going to the "Projects" Tab.
Now open up your web.config file and add the bindings, use your previous web.config as a guide.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="fooServiceEndpoint" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="524288" maxReceivedMessageSize="2147483647"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="8192" maxNameTableCharCount="2147483647" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
<!-- Insert other binding as required -->
</basicHttpBinding>
</bindings>
<client>
<!-- Test Server Endpoints - Used for day-to-day development -->
<endpoint address="http:[Path to TEST Server service]"
binding="basicHttpBinding" bindingConfiguration="fooServiceEndpoint"
contract="FooService.Proxy.IFooService" name="fooServiceEndpoint" />
<!-- Add Other endpoints as required -->
<!-- Staging Server End Points - Used Occasionaly
<endpoint address="http:[Path to STAGING Server service]"
binding="basicHttpBinding" bindingConfiguration="fooServiceEndpoint"
contract="FooService.Proxy.IFooService" name="fooServiceEndpoint" />
<other end points here too />
-->
<!-- LIVEServer End Points - Used Rarely and with CAUTION
<endpoint address="http:[Path to LIVE Server service]"
binding="basicHttpBinding" bindingConfiguration="fooServiceEndpoint"
contract="FooService.Proxy.IFooService" name="fooServiceEndpoint" />
<other end points here too />
-->
</client>
</system.serviceModel>
Now you can simply modify the web config with comments depending on which server you want to be debugging on.
6 Set up web.config transformation for deployment
Expand the web.config node in the solution explorer.
Open the web.staging.config file and add the following:
<system.serviceModel>
<client>
<endpoint address="http:[Path to STAGING server Service]"
binding="basicHttpBinding" bindingConfiguration="fooServiceEndpoint"
contract="FooService.Proxy.IFooService" name="fooServiceEndpoint" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</client>
<!-- Repeat for additional end points -->
</system.serviceModel>
Now add the same to Web.Release.Config changing the paths to tho the LIVE server paths. This will now use the appropriate endpoints when published using the VisualStudio publish command.
E.g. If deploying a STAGING version of the web site, select "Staging" from the Build Configuration drop down. Right click on the WebSite project in the solution explorer and select "Publish". Choose how you wish to publish and click the "Publish" button. The whole solution will then rebuild, proxies will be generated form the Staging server and the web.config file will be published with the Staging setting.
That's it, you're done
You now have proxies that will generate based on your build configuration, one location to change paths via commenting for debugging purposes, and automatic web.config updating on publishing.
Update
Gaui, the OP, has created a small exe that simplifies this somewhat. It is available on GitHub.
I've had a lot of problems with this, too. But I ended up in finding a nice and easy way. My example with a fictious service address:
Create a command line EXE
Add service reference with address https://service.somePortal.com/FooConnector.svc and namespace "MyServiceReference"
Let's say the service is offering an Interface "IFooConnector". Choose OK to generate (a lot of) code to consume the service.
After that, in your App.config file you will see a new serviceModel section:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="NetHttpsBinding_IFooConnector">
<binaryMessageEncoding />
<httpsTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="https://service.somePortal.com/FooConnector.svc"
binding="customBinding" bindingConfiguration="NetHttpsBinding_IFooConnector"
contract="MyServiceReference.IFooConnector" name="NetHttpsBinding_IFooConnector" />
</client>
</system.serviceModel>
You can now use a service method like this:
using TestClient.MyServiceReference;
namespace TestClient
{
class Program
{
static void Main(string[] args)
{
using (var client = new FooConnector())
{
client.DoSomething();
}
}
}
}
Now the important part:
To use three inkarnations of the same service, like DEV (Development), TEST (Testing) and PROD (Production) at different addresses, but having the same interface, you only have to manually edit your App.config and use a different constructor to instantiate the client!
Here's the new App.config with the changed serviceModel section:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="NetHttpsBinding_IFooConnector">
<binaryMessageEncoding />
<httpsTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="https://dev-service.somePortal.com/FooConnector.svc"
binding="customBinding" bindingConfiguration="NetHttpsBinding_IFooConnector"
contract="MyServiceReference.IFooConnector" name="DEV" />
<endpoint address="https://test-service.somePortal.com/FooConnector.svc"
binding="customBinding" bindingConfiguration="NetHttpsBinding_IFooConnector"
contract="MyServiceReference.IFooConnector" name="TEST" />
<endpoint address="https://service.somePortal.com/FooConnector.svc"
binding="customBinding" bindingConfiguration="NetHttpsBinding_IFooConnector"
contract="MyServiceReference.IFooConnector" name="PROD" />
</client>
</system.serviceModel>
As you see, we're now having three endpoint sections with different service addresses. I've also changed the endpoints name properties to match my desired DEV, TEST and PROD naming.
To call the required service you can now use a different constructor of the client, having one parameter: string endpointConfigurationName.
So you can now use the same service method in its three inkarnations like this:
using TestClient.MyServiceReference;
namespace TestClient
{
class Program
{
static void Main(string[] args)
{
using (var client = new FooConnector("DEV"))
{
//Call method in DEV
client.DoSomething();
}
using (var client = new FooConnector("TEST"))
{
//Call method in TEST
client.DoSomething();
}
using (var client = new FooConnector("PROD"))
{
//Call method in PROD
client.DoSomething();
}
}
}
}
That's it! :-)
P.S.: In my real project, I have an enum user setting to choose DEV, TEST, PROD to change the used service by configuration.
One technique is to get the endpoint and replace the URL in code (e.g., you can do it from a database), with something like this:
endpoint.Endpoint.Address = new System.ServiceModel.EndpointAddress(remoteUrl);