From an existing WebApplication I use to make calls to WCF services. Proxies for these services was created using Add Service Reference menu. Thus generating >> Web.config in this project.
I have added another class library project to the solution. This project also adds reference to the service. Thus generating >> App.Config file in this project.
I understand, in an N-Tier application, we should have common gateway to the service. Just out of curiosity I would like to know -
For WCF calls originated in WebApp, propagated to class library which config file (App/Web) would be referred
for locating client endpoint configurations ?
The web.config file will be used for locating the service.
The reason is because in this case, the app domain belongs to the web app, not the class library, and the default config file for this app domain is the web.config.
#musefan is correct. It is the web.config that is used.
If you want to, you can split some confuguration sections into seperate files and reference them from the main web.config. You might want to do this so you can maintain the WCF client and server config in a single place to ensure they are consistent.
foe example, if you want to seperate out the <client> section, you would do this:
<client configSource="client.xml" />
Where client.xml is a file containing the relevant client config information.
This blog post tells you how to do it in a bit more detail.
http://blog.andreloker.de/post/2008/06/keep-your-config-clean-with-external-config-files.aspx
Related
I have two servers on which the identical .net 2.0 WCF service code has been deployed. On both servers the code is running in a dedicated web application with a dedicated application pool assigned to it. Both the web applications and the application pools are configured, as near as I can tell from IIS, identically on both machines. Furthermore, both machines have the same exact versions of the .net framework installed.
On one server the SVC info page served up by IIS lists a fully qualified machine name but the other lists a non-fully qualified machine name. I've provided sample URLS to the info page and the results below:
://server1:1995/Service.svc yields:
You have created a service. To test this service, you will need to
create a client and use it to call the service. You can do this using
the svcutil.exe tool from the command line with the following syntax:
svcutil.exe ://server1.domain.com:1995/Service.svc?wsdl
://server2:1995/Service.svc yields:
You have created a service. To test this service, you will need to
create a client and use it to call the service. You can do this using
the svcutil.exe tool from the command line with the following syntax:
svcutil.exe ://server2:1995/Service.svc?wsdl
I wouldn't normally care about this except for the fact that a packaged product I'm using appears to insist that the URL I give it for the WSDL match exactly what the info page states and I can't figure out why it needs to be different for these two (seemingly identical) machines.
Any help would be greatly appreciated!
(please note I had to delete "http" from the hyperlinks above to keep StackOverflow happy)
The solution here was to add the following line to the SVC web.config file. The behavior was inconsistent across different versions of IIS (and possibly the .net CLR) but adding this line normalized the behavior:
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
I have two projects in my solution: an ASP.NET MVC web app project with a web.config per environment (production/UAT/dev) and another DAL class library project referenced by the web project that uses EntityFramework Database First to handle persistence. At the moment, the DAL class library project has its own App.Config that specifies the connection string to be used.
I require different connection strings (or rather, different data source) for the different environments.
How would I go about moving the connection strings to the web.config in the the web project and referencing them from the DAL project at runtime?
The auto-generated EF Model.Context.cs code that currently references the connection string name is [name changed for anonymity]:
public EodActivityEntities()
: base("name=DatabaseNameEntities")
{
}
Your application will only ever read a single app.config or web.config at run time which will be the one from your start-up project.
Therefore if you have the following in your DAL:
public EodActivityEntities()
: base("name=DatabaseNameEntities")
{
}
... and you run your web application as your start-up project, it will pick up the connection string with name DatabaseNameEntities from that project's web.config, ignoring what is in your DAL app.config. So it's already doing that for you. Therefore I would say that you shouldn't need to have your connection string in your DAL's app.config file at all.
Now, for the different environments you want different connection strings. Create new Solution Configurations for your environments DEV, UAT & LIVE and you can use web.config transformations (info here and here) and it will build with the correct connections strings.
I would recommend passing the connection string in the constructor of your context. The base constructor created by EF takes a string and can either be a named value from a configuration file or simply the connection string itself.
Then move your connection strings per environment to the MVC project where you can instantiate the context using values in it's web.config
var connectionString = WebConfigurationManager.AppSettings["connection"];
var context = new EodActivityEntities(connectionString);
Coulton is correct in that only one configuration file will be loaded, and a solution could be to name the connection strings the same so that the web.config will load when you run the application. However, this is spreading your configuration around rather than pushing that to the context root of the application.
When you reference your DAL project from your Web project, the built DAL.dll should automatically be copied into the /bin folder of your Web project at the time the Web project is built. First, check that is indeed happening. If not, look at the Web project References, find your DAL project in the list and view the properties. CopyLocal should be set to True.
When your Web project is running, any reference made by your DAL to settings that would have come from your DAL's app.config, will instead come from your Web app's web.config, as the DAL will be running under the context of the Web application.
So you are right, that you need to add settings to your web.config.
The best way to utilise different values for different environments is to use web.config transforms. In a Web application, you may already have a couple of these as child solution files sat under your web.config (web.debug.config & web.release.config). Visual Studio will apply these transformations when publishing. We typically have a publish profile for each environment and a matching transform file for each environment, but only one actual web.config file with all the default (untransformed) settings in.
You didn't mention which version of Visual Studio you are using, but this article may help you along the way:
http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/web-config-transformations
This explains further: http://go.microsoft.com/fwlink/?LinkId=125889
I have been given a WSDL file from a provider and I have added it as a Service Reference to my C# project in Visual Studio 2013.
I can see the relevant classes I need but when I call the functions on them nothing is transmitting from my program. I have configured Wireshark to listen but no data is coming from my program when I run it.
Where in Visual Studio can I see the IP address/URL that the web service is trying to connect to? At some point I assume it establishes a HTTP connection, where can I see this code to check the URL/IP address?
The WSDL file does not contain the address of the service endpoint. You probably created a Service Reference or a Web Reference, which has created a client class for you. If you instantiate this client (lets call it ExampleClient) with the default constructor:
var serviceCLient = new ExampleClient();
Then the URI will be the path of the WSDL file you imported. This mostly works fine if you import a generated WSDL file file the actual service URI, but in your case, you need to tell it where the service is running. You can either pass the service URI in the constructor:
var serviceCLient = new ExampleClient("http://example.com/service/endpoint");
Or edit your app.config or web.config (depending on project type). It will have something like this:
<system.serviceModel>
<client>
<endpoint address="C:\path\to\your.wsdl" etc etc etc... />
</client>
</system.serviceModel>
And you should change the address attribute there.
For old style web references, you can right click on the reference in Visual Studio (under your project in the Web References folder, and select "properties". The properties screen contains a "Web Reference Url" which you can edit to point to the actual service URI.
I am in need of help with manipulating the web.config of a site programmatically via C#. The site in question hosts a Silverlight 5 application which communicates with the server runtime via WCF RIA services.
The code that I am writing is part of a bootloader for an automated build-deploy-test scenario aimed at testing the WCF Ria service stack. The issue at question is that in order to test the services properly the unit test code needs to be able to communicate with the Ria Services via a new soap endpoint.
To effectively make this work the site needs a copy of the Microsoft.ServiceModel.DomainServices.Hosting dll in it's bin folder, and a new soap endpoint which would make the domain services config section look like the following:
<system.serviceModel>
<domainServices>
<endpoints>
<add name="OData" .../>
***<add name="Soap" type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory, Microsoft.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>***
</endpoints>
</domainServices>
</system.serviceModel>
While I do believe I could modify the web.config via the C# xml api, I was wondering if there is another way to do so via the ConfigurationManager?
I would do config manipulation as part of the build script.
I am currently using YDeliver as the build/deploy framework in my project and since it runs on top of Powershell, I manipulate XML using the xml api in posh.
I know similar flavors of this question has been asked before, but I am asking something a little different. I know how to use applicationSettings and such, but what I am trying to do is to make it into a config. i.e., I have a web application which as a reference to a class library. This class library has a reference to a web service. In doing that, it created a .settings file. When I am using this class library in the web application, everything works fine locally. However, in staging and production, I would like to have different URLs for the web service - the only way to do that seems to take the applicationSettings section, and put it in the web.config of the web application project. I'm trying to avoid muddying up the web.config, so is there a way to have this applicationSettings section in another files referenced by the web.config?
<appsSettings configSource="appSettings.config" />
This moves the whole app settings section to a separate file.