This may be a basic question since I am new to WCF. I don't even know if this is supported or not.
I have a WCF Service called MyCustomService. I added this service reference in my client solution and now I can create a proxy object by calling:
MyCustomServiceClient myClient = new MyCustomServiceClient();
myClient.GetData();
myClient.GetData();
How, do I layout my Service so that I can pass the parameter during proxy instance creation i.e.
MyCustomServiceClient myClient = new MyCustomServiceClient("SomeString");
I noticed every method call I make creates a new instance of the MyCustomService(i.e I can get the breakpoint hit on MyCustomService Ctor). So, I want the value that I had passed when creating proxy object (i.e. SomeString) to exist for all the calls I make until the lifetime of myClient
Any ideas ?
The proxy generation feature of Visual Studio (or svcutil.exe) creates a proxy class with five different constructor signatures. The one that you are asking about, the constructor that takes a single string, is a very useful one, because it allows you to reference different client configurations from your app.config or Web.config file.
Take this extremely simple hypothetical configuration file:
<configuration>
<system.serviceModel>
<client>
<endpoint name="serverABinding" />
<endpoint name="serverBBinding" />
</client>
</system.serviceModel>
</configuration>
You can then control which binding you use for the proxy:
string endpointName = useB ? "serverBBinding" : "serverABinding";
var myClient = new MyCustomServiceClient(endpointName);
Of course, the endpoint bindings I've shown above are too simple to actually be useful, but hopefully you get the idea.
Your motivation isn't exactly clear, but it sounds like you want to control the proxy behavior across all proxy instances of your application. If that's what you want, then don't use a constructor: use the endpoint configuration in your app.config or Web.config file to control the proxy connection. The default endpoint configuration that is generated by Visual Studio uses an endpoint name that matches the default name of the proxy client. Change this endpoint definition, and you'll change the behavior of your service client.
Since you are new to WCF, my advice to you is this: learn all about configuration files. Once you understand a WCF configuration file, you understand WCF.
You can not have constructor with parameter in your WCF service, even when you try to create such service you will get below error.
The service type provided could not be loaded as a service because it
does not have a default (parameter-less) constructor. To fix the
problem, add a default constructor to the type, or pass an instance of
the type to the host.
Now if you want the data to persist for a client you can set ServiceInstanceContextMode as below as a attribute on Service Class
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class Service : IService
Related
I recently migrated one of our assemblies (a referenced library) from the old CSProj format to the new CSProj format (the Microsoft.Net.Sdk format). This helps a lot due to the globbing rules and how it handles dependencies (reference, project reference, package reference) so well.
After the transition, there is no longer an option for "Service References", instead we have "Connected Services". I removed the old Service Reference files (code, wsdl, xsd, etc.) and created a new Connected Service.
It seems cleaner because it generates a json configuration (used for auto-generating code) and a single Reference.cs file. The auto-generated code is a bit different than the old service reference code that was generated. Firstly, all methods are async (makes sense), so I adjusted our code to account for this.
The problem I am running into is that we had originally relied on the application's Web.Config file (also Web.Dev.Config, Web.Test.Config, etc.) -- during our deploy process we rename/replace the Web.Config with the appropriate environments configuration. This worked just fine, our app added a reference to our library and the app held the config information.
With the new Connected Services auto-generated code, it is hard coding in the localhost address as the endpoint because I used that to auto-generate the code.
Basically, the old "Service Reference" generated code had the default constructor of the client pull the endpoint from the application config. The new Connected Service offers overloads, but does not by default pull the endpoint from the config.
<system.serviceModel>
<client>
<endpoint address="http://xdev/xservice.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IXService" contract="XService.IXService" name="BasicHttpBinding_IXService" />
</client>
</system.serviceModel>
What do I do different to take advantage of my app config with the new WCF Connected Services auto-generated code?
See this answer:
There is a partial abstract method partial void ConfigureEndpoint in your service client to override. There you can programmatically set the endpoint via serviceEndpoint.Address = new EndpointAddress(...).
This URL can be stored in the <appSettings> of your .config or in the appsettings.<Environment>.json, depending on your platform.
Note, that the development endpoint from which the code was generated gets hard-coded into the sources and remains as a fallback. If for some reason your overridden method does not get called, you have a very hard to spot error. If someone has a solution for that, I'd be very interested.
I'm new to WCF and am trying to make my first service (a simple usage reporting service). I've gone through examples and tutorials and created a service. I have a simple test program that can run my core code and send the report. Currently I'm running locally hosted in the debugger, but running this simple exe program hosts the service, sends the report, and the service creates the log file just like it's supposed to... all is good.
Now, my actual program is an addin to another commercial program that runs in it's API (Autodesk Revit). When I run the exact same code inside of the Revit API I get an error that there is no endpoint defined. My guess is that this is because it's looking for the main Revit.exe.config which obviously will not have my endpoint defined. I have a .config file for my dll created (MyLibrary.dll.config) and in the executing directory for my code and it defines the endpoint properly, but that doesn't seem to be recognized.
So my question is how do I get it to load the connection settings from this config file? Or is there another way I should be doing this? I'm open to setting it in code somehow or whatever, just can't figure out how to get it to connect...
I'm not sure if it matters, but here is the configuration that is working in the standalone program:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IReportingService" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:8733/Design_Time_Addresses/SPECtrumReportingService/Service1/"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IReportingService"
contract="ReportService.IReportingService" name="BasicHttpBinding_IReportingService" />
</client>
</system.serviceModel>
</configuration>
My constructor that is throwing the endpoint exception is simply:
_reporter = new ReportingServiceClient();
Here is the exception that is thrown:
Could not find default endpoint element that references contract 'ReportService.IReportingService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at System.ServiceModel.ConfigurationEndpointTrait`1.CreateSimplexFactory()
at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait)
at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()
at RDES.Revit.Sumex.CommonUse.ReportService.ReportingServiceClient..ctor() in c:\RD\Projects\13-004 SPECtrum\Code\SPECtrumBase\Service References\ReportService\Reference.cs:line 241
at RDES.Revit.Sumex.CommonUse.ImportVM..ctor() in c:\RD\Projects\13-004 SPECtrum\Code\SPECtrumBase\ImportVM.cs:line 41
Any help would be greatly appreciated...
it's not relevant that the dll's configuration file is in the same folder as the application. only the application's (executable's) app.config file is read. the solution is to copy the WCF service configuration from the dll config file to you application's app.config file.
the other solution, for modular applications, is to set the service's ABC in code. the problem with this is that you cannot configure it without rebuilding and redeploying the addin.
to create a WCF proxy entirely in code you could use something like this:
IServiceContract proxy = ChannelFactory<IServiceContract>.CreateChannel(new WSHttpBinding(),
new EndpointAddress("<you url here>"));
I found this post that lead me to a possible answer. I have now updated my constructor as follows:
_reporter = new ReportingServiceClient(new BasicHttpBinding(), new EndpointAddress("http://localhost:8733/Design_Time_Addresses/SPECtrumReportingService/Service1/"));
I've left the binding as just default although it looks like I can set other properties if I need to. I just pulled the endpoint address out of the config file that worked in the standalone program and used that to construct.
This seems to be working as expected inside of Revit at least with preliminary tests. Can anyone comment on if this would cause any issues or if there is a better way to handle this situation?
Though you can inject endpoint info into a proxy class ReportingServiceClient through your application codes, the first class programming approach is to use app.config.
In your client config, you have an endpoint named "BasicHttpBinding_IReportingService", to use this endpoint, you should then write:
_reporter = new ReportingServiceClient("BasicHttpBinding_IReportingService");
If you want
_reporter = new ReportingServiceClient();
to work, remove the name attribute or make the name attribute value in the client endpoint defined in the client config. This will be the so called "default endpoint element" mentioned by the exception.
i am learning wcf so often questions comes to my mind.recently i developed a small calculator wcf service. i had three project one has service contract and another has wcf service with main class from where i self host the service. in app.config file i gave my endpoint address
net.tcp://localhost:5555/Calculator
i always thought that i have to give my service class name at the end of service url. in my apps my service url looks like above and Calculator is my service class name.
just few days ago i was browsing a wcf code and i saw that there service class name was chatsrv but service url would look like net.tcp://localhost:5555/chat
i like to know that can i give any name to my service at the end?
1) if so then how self host code can understand at which url service need to start ?
2) if i set false for <serviceMetadata httpGetEnabled="false"/> then how other client consuming my service because i have set httpGetEnabled="false" and self host the service but from other .net project i could consume that service by channel factory and as add reference? so tell me what people need to set httpGetEnabled="true" if false works fine?
whatever i know that if httpGetEnabled="false" then mex endpoint will not expose to other client and hence forth no other client may not be able to add reference to their project of my service reference. i am new so not good about the service internal. if possible please discuss it in detail.
3) why mex endpoint is required when client can instantiate & call service function through channel factory without mex endpoint then why & when mex endpoint would require?
thanks
UPDATE
1)
i like to know that can i give any url as endpoint address ?
i have given this net.tcp://localhost:5555/chat as my endpoint address and it works but if i give the endpoint address like net.tcp://localhost:5555/Mychat then does it work?
i like to know what is the convention of giving endpoint address url?
2) now regarding mex endpoint. in my service config file i disable mex like but still i saw any client can add reference like net.tcp://localhost:5555/chat/mex how it is possible ?
when mex is disable then mex point should not be expose or accessible before client...am i right?
please guide me. thanks
I'll try to answer some of your questions:
1) When you configure your service, you have to configure the endpoint URL, either with the popular config file or in code like this:
Dim URL as string = "http://ServerName:port/SomeClass/SomeFunction"
Dim ServiceHost As New ServiceHost(GetType(YourImplementationClass), URL)
Dim ServiceHostEndPoint As EndpointAddress = New EndpointAddressURL(URL)
ServiceHost.AddServiceEndpoint(GetType(iYourImplementationClass), binding, ServiceHostEndPoint.ToString)
ServiceHost.AddServiceEndpoint(ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpsBinding(), "mex")
ServiceHost.Open()
2) You can give your clients the URL and xsl directly, but exposing your endpoint with Mex is easier for everyone. Also, if you make changes, they can re-reference your mex metadata and automatically update their interfaces.
3) mex isn't required if clients are configuring the endpoints themselves using the channel factory, it's just easier using mex. Just typing your endpoint URL into a browser will generate most of what they need to connect to your web service.
Hope that helps.
Comment out below line because it'll be added automatically while configuring the proxy in your configuration file where you defined endpoints of the service.
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
If you want to check, Right click on service proxy where you added service proxy, and select "Configure Service Reference" and you'll notice /mex is added in URL of the service at last
In my Managed Application, I currently have my WCF services running as:
SomeService service = new SomeService(container) //IUnityContainer
ServiceHost serviceHost = new ServiceHost(service, serviceAddress);
Whats the catch ? SomeService defined with:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single
This is not good anymore, I need to make it InstanceContextMode.PerCall.
When trying to .Open() If changing the InstanceContextMode to "PerCall" - it will throw:
System.InvalidOperationException: In order to use one of the ServiceHost constructors that takes a service instance, the InstanceContextMode of the service must be set to InstanceContextMode.Single. This can be configured via the ServiceBehaviorAttribute. Otherwise, please consider using the ServiceHost constructors that take a Type argument
Is this the solution to my problem ? How do I pass values to the constructor on my wcf service?
My Main concern:
I run different types of services inside this managed application, It seems that this solution is good only if i run one type of service.
When more than one service instance will be needed (PerCall or PerSession) then passing a single service instance into the ServiceHost isn’t enough... which is the exception.
Controlling instance creation is managed by the IInstanceProvider.
Is this the solution to my problem ? How do I pass values to the constructor on my wcf service?
This only answers half your question. You are using Unity. The management of creating the container needs to be part of the implementation. The most common solution is to use Unity.WCF which is also available as a NuGet package.
Note that Unity.WCF doesn’t support object lifetimes based WCF OperationContexts. There are multiple (more complicated) implementations like this that do.
Environment :
Visual Studio 2010 Professional
.NET Framework 4
C#
Added Service Reference using the following WSDL : https://www.paypalobjects.com/wsdl/PayPalSvc.wsdl
Problem 1 : When compiled simply like this, get a bunch of errors from the Reference.cs file. Looks like namespace errors. It mentions that it cannot find the Service Reference Namespace in my project's Namespace. Therefore, I went into the Reference.cs file and whereever I got this error, I removed the project's namespace before the method names, and now it compiles.
Finally getting access to all classes.
Created and populated DoDirectPaymentReq and CustomSecurityHeader objects with the required properties.
Created an instance of PayPalAPIAAInterfaceClient class, which contains the method DoDirectPayment which takes in the arguments of type CustomSecurityHeader and DoDirectPaymentReq. Looks like this :
using (var client = new **PayPalAPIAAInterfaceClient**())
{
var credentials = new CustomSecurityHeaderType
{
Credentials = new UserIdPasswordType
{
Username = "xxxxxxxx#xxxxxx.com",
Password = "xxxxxxx",
Signature = "jksadfuhasfweakjhasf"
}
};
_doDirectPaymentResponseType = client.DoDirectPayment(ref credentials, _doDirectPaymentReq);
}
Problem 2 : After writing a TestMethod for the method which contains the above code, I get the error as follows :
System.InvalidOperationException: Could not find default endpoint element that references contract 'Paypal.PayPalAPIAAInterface' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName, Configuration configuration)
at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at System.ServiceModel.EndpointTrait`1.CreateSimplexFactory()
at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait)
at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()
at System.ServiceModel.ClientBase`1..ctor()
at PaymentEngine.Paypal.PayPalAPIAAInterfaceClient..ctor() in Reference.cs: line 30063
Therefore, so far I have not been able to make a successful transaction using PayPal SOAP protocol via using WSDL in C#.
I was under the impression that this is very simple. Simply Add Service Reference and utilize the Classes with their properties and methods created in the proxy from WSDL.
Where am I going wrong ?
Am I using the wrong WSDL ? I'd like to test against Sandbox first and then go Live.
If I am right with the WSDL, looks like the class PayPalAPIAAInterfaceClient doesn't know its endpoint, which I don't know if I am suppose to set manually or not since its already there in the WSDL definition at the end (check it out). I think the class itself should know which endpoint to call depending on whether I am using Signature or Certificate to populate CustomSecurityHeaderType.
But how does the PayPalAPIAAInterfaceClient class know whether I am trying to call into the Sandbox (testing) or it is a live transaction ?
PayPal used to have two different WSDLs for Sandbox and for Live. They can be found here :
->https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_soap_PayPalSOAPAPIArchitecture
After speaking to their support I was asked to use the following WSDL for both Sandbox and Live:
->https://www.paypalobjects.com/wsdl/PayPalSvc.wsdl
But how do I tell the PayPalAPIAAInterfaceClient class when it is suppose to perform Live or Sandbox tests. And also to which end point to use depending on my method of SOAP and Signature. The endpoints from PayPal are mentioned here :
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_endpoints
HELP !
You have a few problems here, but none should be too painful to resolve. First of all, when I add a Service Reference to the WSDL you link at the top of your post I don't have any of the problems with namespaces that you describe. It could be that your own namespaces/references are conflicting somehow with the auto-generated terms, or perhaps that you selected some strange option during the add reference process? A delete-and-re-add might solve the problem, or I guess you can just ignore it since you've already worked around it. (It is kind of a hassle to edit auto-generated code, however, so you should plan on a fix eventually.)
To resolve the InvalidOperationException, you probably just need to specify one of the endpoints that Visual Studio has automatically added to your app.config file. You should have something like this in your config file:
<system.serviceModel>
<client>
<endpoint name="PayPalAPI" ... />
<endpoint name="PayPalAPIAA" ... />
</client>
</system.serviceModel>
You can pass the name of the endpoint you want to the constructor of the proxy class. There are other options to solve this problem, but just specifying an endpoint is easy and clean. (Note: if you don't have this section in your config file, then something went wrong during the Add Service Reference phase. Again I would just suggest resetting your project and re-adding the reference.)
Finally, you don't want to use a using block when you make use of the proxy class in spite of it being IDisposable. Basically, there's a design bug in WCF.
I had the same problem, because I was doing unit testing.
You have to copy the application.config file to the test project, otherwise it won't find the WCF config.