Just want to ask you to confirm that I'm right (but may be totally wrong :).
Situation: I have a VS2010 Solution with 3 projects A) WCF Library, B) Web Site that host this library C) test application that use the web service. Last I could configure two different ways: adding reference to the WCF Lib or Web Site.
I've discovered that when I'm referencing WCF library directly (some may be remember those endpoints http://localhost:8732/Design_Time_Addresses/...) the configuration of custom servicehostfactory in app.config element
<serviceHostingEnvironment><serviceActivations>..
is ignored.
Since interpretation of serviceHostingEnvironment is responsibility of the host I make an assumption that VS2010 WCF Library Host have such feature - ignore serviceHostingEnvironment? Am I right?
P.S. May be I could ask you to point me the doc where I could find the information about VS2010 WCF library's host.. It seems I should get to know better.
Description of test service host is here. ServiceHostingEnvironment element controls integration with web server = I don't think that any part of this configuration section is used for self hosted services and test host is self hosting.
ServiceActivations element contains file-less activation configuration for web server. That means ability to activate service without physical existence of hosting .svc file. That is something which doesn't make sense in self hosted scenario.
Related
I've been searching for a quite while now and not found what I'm looking for. I've self hosted a http WCF in a windows application. Now in one of my service's methods I need to receive a file and some form data fields. In similar questions the case is either sending one single file (Which is done by streaming data and then converting it) or they have hosted WCF in an environment that Asp.Net Compatibility can be turned on to access HttpContext and then getting all the needed data from HttpContext.Current. Any Suggestions ?
After a while I found out that someone has already answered my question. for anyone out there facing a similar problem here is the link to the answer :
https://stackoverflow.com/a/14514351/11797674
this approach also uses stream input but not for a single file. It also can manage to get multiple files and form data by key. the sample presented in the answer is a little bit old. I suggest that you check the git repository and follow the sample there. It works like a charm for Http WCF's that are self hosted on a application type that is not web application and Asp.Net Compatibility mode activation is not a option (Since Sessions are different than web application and no http context is saved by the application which WCF is self hosted on)
I have a C# MVC application hosted in IIS test environment with only one action method in APIController. Clients call this single method and depending upon the parameters different small processes are performed.
I am using IIS 10.0.17763. Application is built in .Net Framework 4.6
I have disabled these modules as i don't need them.
WebDAVModule
WindowsAuthentication
ScriptModule-4.0
DefaultAuthentication
ServiceModel-4.0
UrlAuthorization
FileAuthorization
The problem is that under load test from jmeter, all calls somehow stay longer in ResolveRequestCache State.
Can someone guide me the problem behind or suggest me something to check. I am not using any kind of caching due to business requirement.
Here is the Screenshot of requests states from IIS
Edit. I have removed some other modules too to check the effect.
Here is the list of loaded modules in my application
I use VS2008, .net 3.5.
There is an external Web Service (it is PHP implementation, but dont mind implementation -.net, java, php,...-).
In my project csproj, I want add Service Reference to WebService and I want use WCF.
When I add Service Reference in VS2008, WCF proxy is created.
Any best practices (patterns and practices) for add service reference (external service) ?
The WCF Proxy Generator (I think the same svcutil command) generates source code like this. Perhaps it will be interesting manages the code generated (ServiceContractAttribute Namespace="http://192.168.50.63/WebService" use IP address, and OperationContractAttribute(Action="http://devservername/webservice/SmoBridge.php/login" use servername).
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://192.168.50.63/WebService", ConfigurationName="ServiceEasyVista.WebServicePortType")]
public interface WebServicePortType {
[System.ServiceModel.OperationContractAttribute(Action="http://devservername/webservice/SmoBridge.php/login", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(Style=System.ServiceModel.OperationFormatStyle.Rpc, Use=System.ServiceModel.OperationFormatUse.Encoded)]
[return: System.ServiceModel.MessageParameterAttribute(Name="return")]
string login(string SESSION_ID, [System.ServiceModel.MessageParameterAttribute(Name="LOGIN")] string LOGIN1, string PASSWORD, string COMPANY_ACCOUNT);
Update:
the Erwyn’s recommendations about the correct closing of a faulted WCF Channel.
http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx
Why does ClientBase Dispose need to throw on faulted state? (Or, what's the difference between close and abort?)
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/b95b91c7-d498-446c-b38f-ef132989c154/
check this out:
http://www.sanity-free.com/125/php_webservices_and_csharp_dotnet_soap_clients.html
i think that one is sophisticated technique.
Regards,
Mazhar Karimi
I don't know why there would be any particular best practices around adding a reference. Having said that, the "Refresh Reference" command in Visual Studio (right-click on an existing service reference) sometimes doesn't work too well, so it can be easier to use the svcutil command manually, and have a .bat file in your solution that updates the service reference (svcutil is what "Add Service Reference" is using behind the scenes).
Also, if the service you're referencing is returning an array, you can get WCF to automatically turn it into a generic list (or some other type) - this might make things easier.
I am attempting to add a WCF web service to my project and each time I add a new web service it adds a new Service Behavior, new Service configuration, and changes the formatting of my web.config.
Is it possible to add a new WCF Web service (.svc extension) to my project without it changing my web.config file? I am willing to add the information I need manually.
Yes, the behavior of the Add Service Reference part in Visual Studio is a major PIA - and it's not been improved a single iota in VS 2010, unfortunately :-((
And even more unfortunate, you cannot really tell the importer to leave your existing stuff alone - what I do is create a backup of my web.config, import the WCF service and let the importer mess up my web.config, and then I just slap my backup over the mess again and go about making the necessary additions manually.
One alternative is to use svcutil.exe on the command line - first of all, you can tell it to /noconfig and skip messing with your config (or you can output the recommend config into a separate config with a different name), and secondly, it'll happily create your client-side proxy service class in a C# or VB.NET file for you, ready to use.
But yes - of course you can add all the necessary information by hand!
In a typical client side config, the most important point is the <client> tag - just add whatever it is you need - using the "ABC of WCF" - (A)ddress, (B)inding, (C)ontract:
<client>
<endpoint name="something-useful"
address="your-address-on-the-server"
binding="wsHttpBinding" -- or whatever it is you're using
contract="IYourServiceContract" />
That's the minimal client-side config you need. Anything else is just additional stuff, used when needed. This uses all the default settings for your binding, obviously.
Here are two really good videos that show how to do a lot of manual WCF configuration - sounds scary, turns out to be much easier than deciphering the mess the VS importer creates....
DotNet Rocks TV Show #122: Miguel Castro on Extreme WCF
DotNet Rocks TV Show #135: Keith Elder Demystifies WCF
I have a WCF service with a namespace called:
MyCompany.MyApplication.Configuration.ConfigurationHelperService
On the client side I have an assembly called which consumes this service:
MyCompany.MyApplication.Core (this is the default namespace)
When I add the service reference, the namespace I'm asked to specify in the Add Service Reference dialogue ends up getting tacked on the end of the client assembly namespace:
MyCompany.MyApplication.Core.MyCompany.MyApplication.Configuration
.ConfigurationHelperService
Because I'm asked for a namespace at this time it seems natural to specify the name of the remote service namespace. i.e. I'd like to refer to my remote service classes using their namespace MyCompany.MyApplication.Configuration.ConfigurationHelperService because they're technically not part of the client.
My questions are:
What's the rationale behind this, is this something to do with semantics?
Should I try to resist changing this behaviour by modifying the client side generated source to get the namespace I want?
I've lived with this for a long time (you have the same problem with ASMX web service clients) but have never seen a written down explanation why Visual Studio (and I guess svcutil.exe) works this way.
Well, I think you have two choices, really:
if you control both ends of the wire, e.g. you write the server and the client, you could put all the shared items like service contracts, data contracts etc. into a separate assembly and share that between client and server. That way, nothing would be duplicated, and both ends of the communication would refer to the exactly identical items in a given namespace of your choice
get used to the fact that if you add a WCF service reference in Visual Studio, you're basically getting a whole slew of duplication - because if you're not controlling both ends of the communication, that's really all WCF can go on - the metadata exchanged between service and client (through the WSDL or the MEX endpoint on the service). And since this clearly is part of the client, which is completely separate from the service (all they share, typically, are the wire-formats defined in the XML schema - nothing else), its namespace will also be client-oriented. I think this is a (good) feature, and not something I'd try to combat.....
By default, in a SOA world using WCF, the client and the service are totally independant of one another. There's no "remote object" connection or anything like that between the two: the client proxy has a method call happen, bundles up those parameters passed in plus some information what method on the server to call, and serializes it all up into a serialized message (read: a text / XML message, basically). That message is sent across the wire to the server which then handles that message and returns a response.
So this is not just a .NET function call or something - those two pieces of your system are (by default) absolutely independent of one another. Considering that, to me at least, it makes sense that everything the client does will be placed in the client's namespaces - after all, the server could be something totally different, like Java, PHP, a IBM mainframe - you typically don't have any clue what it is (and don't need to).