I have a client that references two assemblies : a WCF service and DLL containing dataContracts.
At the same time, the client consumes the WSDL of the WCF Service. The problem is that the service reference does not proxy DataContracts (just the service methods). Instead it puts the DataContracts into 'Properties/DataSources/' folder. Each has an extension 'datasource' When opened i get an XML that looks like this :
<?XML version="1.0" encoding="utf-8"?>
<!--
This file is automatically generated by Visual Studio .Net. It is
used to store generic object data source configuration information.
Renaming the file extension or editing the content of this file may
cause the file to be unrecognizable by the program.
-->
<GenericObjectDataSource DisplayName="DataContractClass" Version="1.0" xmlns="urn:schemas-microsoft-com:xml-msdatasource">
<TypeInfo>MySolution.ContractClasses, MySolution, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null</TypeInfo>
</GenericObjectDataSource>
Thanks in advance for your replies.
Ok I understand now, it seems to be a cool feature of WCF : instead of proxying the datacontracts it reuses (maps to) the dll containing the DataContracts.
UPDATE : I've tried it on a bigger solution and it works like a charm, I just have one if DEBUG instead of plenty (namespaces):
#if DEBUG
static Service client = new Service();
#else
static ServiceClient client = new ServiceClient();
#endif
Related
I am having multiple Services in my application.i have a datacontract that i need to use in more than 1 service.
Eg: class myCommonClass is being used in 2 of my services service1 and service2
To do this, at a service level, i have a MyApplication.Common library and this library contains myCommonClass. Since both my services have a reference to MyApplication.Common, they can both use it.
My client application has service references to both service1 and service2.
To my client application, service1.myCommonClass is a separate namespace as compared to service2.myCommonClass and therein lies my problem
In my Reference.cs (generated via svcutil - the namespace of BOTH classes is the same i.e.
System.Runtime.Serialization.DataContractAttribute
(Name="MyCommonClass", Namespace="http://A.B.MyCommonClassNamespace")])
However, both of these are in 2 separate reference.cs files and the namespaces in the reference.cs is different due to being part of two separate service references.
Hence, to my client application they appear as two completely unrelated classes.
*Question 1 * : Is there any way that can i indicate to my client application that service1.myCommonClass and service2.myCommonClass are inherently the same class?
*Question 2 * : Is there something inherently wrong with my design here for me to run
into this problem?
No, your design is fine. Instead of adding service reference from Visual Studio, generate the proxy class using svcutil on the command prompt. Create a class library project and add the generated .cs files to it. You can create a batch file and run it in pre build step as well.
Use svcutil as below to generate the proxy class in a single file from service dll (the dll that implements your two service)
svcutil.exe /t:metadata "PATH\service1.dll" "PATH\service2.dll"
svcutil.exe /t:code *.wsdl *.xsd /o:Proxy.cs
I need to load a custom app.config for WCF.
I've tried he solution entitled "Relocating app.config to a custom path", but unfortunately, this technique just won't work for WCF, it still throws an error saying it can't find the .config file (correct me if I'm wrong).
Thanks to WCF Client without app.config/web.config by Kishore Gorjala, I eliminated all reliance on an app.config as follows:
EndpointAddress endpointAddress = new EndpointAddress("http://myServiceURL.com");
WSHttpBinding serviceBinding = new WSHttpBinding();
serviceBinding.ReceiveTimeout = new TimeSpan(0, 0, 120);
MyServiceClient myClient = new MyServiceClient(serviceBinding, endpointAddress);
According to this blog, you might want to try BasicHttpBinding instead of the WSHttpBinding as well.
This technique is also mentioned on the blog Minimal WCF server/client WITHOUT app.config.
Experimental evidence: This worked perfectly - and no more app.exe.config to worry about.
As you can see from the question you referenced, this does not work. In fact, it doesn't work anywhere in .NET - the problem is not specific to WCF.
There is only a single config file per AppDomain. Period. You will always have to copy settings from the DLL's app.config into the single config file.
There is a method to load app.config from a custom location, see Loading the WCF configuration from different files on the client side by Pablo M. Cibraro (aka Cibrax).
This method relies on overriding CustomClientChannel with a constructor that loads a custom app.config, then using the following code to create the client:
CustomClientChannel<ICalculator> channel = new CustomClientChannel<ICalculator>("OtherConfig.config");
ICalculator client = channel.CreateChannel();
Download the Microsoft Visual Studio sample project here.
To fix the compile errors under Visual Studio 2010, upgrade both projects to .NET 4.0, and reload the five referenced assemblies it can't find. To add it into your project is simple: just add the extra class, and replace the original channel instantiation line with the new one that uses a custom app.config.
I am developing a custom HttpHandler, to do so I write a C# Class Library and compile to DLL.
As part of this I have some directory locations which I want not hard coded in the app, so i'm trying to put it in the app.config which I've used before.
Before this has worked by just going building the app.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="Share" value="C:\...\"/>
</appSettings>
</configuration>
And then obtaining this in code like:
var shareDirectory = ConfigurationManager.AppSettings["Share"];
But when I compile it and put it in the bin folder for the webservice, it keeps getting null for shareDirectory, probably because it can't find app.config. So how do I make sure this is included so I don't have to hard code my direcotry locations? I notice it will essentially after compiled we get the assembly.dll and the assembly.dll.config which is the app.config file, so it's definetly there in the bin folder!
That is because your web service uses web.config
You're probably confusing the scope of your class library.
Remember, your config, be it web.config, or app.config, is the config present in the HOSTING application. In this case your hosting application is the WebService, hosted of course by IIS, so your config file is the web.config.
If you had a console app which somehow used that class library (though probably not in an http handler context), then the config would be the app.config in the console app, not the app.config in your class library.
You need to put the configuration in your web.config file, not in assembly.dll.config: .NET does not (by design) read assembly.dll.config files.
I am creating solution and inside I have three projects:
A WCF Service Library Project
A DataAccess Project (Class Library)
A Web site for hosting WCF service
The implementation of the service is on the project # 1, but in order to access the DataBase I use a second project that implements the data access using a class library project.
That problem is in order to get data access I need to configure a connection string, but that connection string must be configurable in a production environment, I meant in production I am going to deploy the site, which is a very simple project that contains only a reference WCF Service Library Project then a guy from database department will configure the connection string.
In development I have an app.config on the data access project but when I do the release that app.config is embedded on the dll.
Any ideas how can we achieve our purpose
The connection string must be in the application configuration file of the executing assembly. This means that you can provided the configuration file for your assembly along with the assembly itself but anyone who wants to use your assembly must update their configuration file to include the values that your assembly relies on.
The connection string in your app.config (data layer) is not embedded in the dll.
If you look in the app.config file in your data layer project, you will probably have a connectionStrings section. you need to put the connectionStrings in the web.config of your WCF service website.
This can be configured in your production environment.
I had a mistake, I was using a different name on the web.config of the WCF site, I just copy the the exact part of the app.config to the web.config and its working now.
Thanks for your help
I have an old WSDL file and I want to create a server based on this WSDL file.
The WSDL is generated from a ASMX (I suppose but I am not sure).
How can I achieve this ?
original question where the OP thought he needed to create a client based on the WSDL.
Using svcutil, you can create interfaces and classes (data contracts) from the WSDL.
svcutil your.wsdl (or svcutil your.wsdl /l:vb if you want Visual Basic)
This will create a file called "your.cs" in C# (or "your.vb" in VB.NET) which contains all the necessary items.
Now, you need to create a class "MyService" which will implement the service interface (IServiceInterface) - or the several service interfaces - and this is your server instance.
Now a class by itself doesn't really help yet - you'll need to host the service somewhere. You need to either create your own ServiceHost instance which hosts the service, configure endpoints and so forth - or you can host your service inside IIS.
There are good resources out there if you know what to search for. Try "Contract First" and WCF. or "WSDL First" and WCF.
Here is a selection:
Basic overview of WSDL-First development with WCF and SvcUtil.exe.
WSCF - A free add-in to Visual Studio enabling Contract-First design with WCF
Introduction to WSCF
A walkthrough of using WSCF
The WSCF project page on CodePlex (WSCF is now open source)
Article on how to design "WCF-Friendly" WSDL
Use svcutil.exe with the /sc switch to generate the WCF contracts. This will create a code file that you can add to your project. It will contain all interfaces and data types you need to create your service. Change the output location using the /o switch, or you can find the file in the folder where you ran svcutil.exe. The default language is C# but I think (I've never tried it) you should be able to change this using /l:vb.
svcutil /sc "WSDL file path"
If your WSDL has any supporting XSD files pass those in as arguments after the WSDL.
svcutil /sc "WSDL file path" "XSD 1 file path" "XSD 2 file path" ... "XSD n file path"
Then create a new class that is your service and implement the contract interface you just created.
You could use svcutil.exe to generate client code. This would include the definition of the service contract and any data contracts and fault contracts required.
Then, simply delete the client code: classes that implement the service contracts. You'll then need to implement them yourself, in your service.
Using the "Add Service Reference" tool in Visual Studio, you can insert the address as:
file:///path/to/wsdl/file.wsdl
And it will load properly.