I was using SoapUI to test a WCF endpoint (unsuccessfully I am add) which has message based security using an X509 certificate.
After much head scratching and searching I discovered that SoapUI does not like X509, message, wsHttpBinding and came across WCF Storm.
This works out of the box, but my concern is that nothing appears to have moved on the project since 2015.
Is this still a dead project now?
Does anyone know?
Thanks
Related
I want to debug my WCF service hosted with my WCFClient application in the same dev box. I can run my WCFClient application successfully. My WCF service binary model is Debug. WCFClient application and WCF service are compiled under .Net4.5 framework within windows8 OS. And my WCF service hosts in IIS7 in the same box as well.
The error is :
Unable to automatically step into the server. Unable to determine a stopping location. Verify symbols are loaded. Error while processing breakpoint.
Hi Anyone who enters here. I resolved the issue with a console application by invoking my WCF service, this is a bit tricky.
I run my WCF application in asp.net web form. So there will be issue after attaching w3wp.exe process. Then I tried to use a console application to test
my WCF service, I can debug into the code.
Thanks anyway. I am new to the stackoverflow. Who can help me to know how to close my question?
Thanks,
Ethan
Most of the time, when you type an error message in Google, you find your answer... It's typically faster than asking a duplicate question on SO.
It's also a good idea to write the error message in plain text instead (or in addition to) a screenshot. This way, a person having the same problem will easilly find your question and eventually an answer.
Take a look at this forum post and this one.
I am new to creating WCF services. I have created a WCF service that is using TCP. The service is running on IIS 7. From within the solution file I have a client project that I have used to test my service. I've run the client project using a TCP endpoint and it accesses the service and everything is fine.
Now, I want to access my TCP service from a new standalone project, one that is not part of the service's solution like the client project. I created a new project in VS 2008. I clicked on Add Service Reference, entered the net.tcp address (net.tcp//.......) and clicked go. An error is returned saying that the "Metadata contains a reference that cannot be resolved."
Is there something further in IIS 7 that needs to be configured? Am I correctly adding a reference to a service that is using TCP? If needed I can supply more information but at this point I am not too sure what I need to post. As I said the service works perfectly from the client project but I can't even access the service from a standalone project.
Thanks in advance for your help.
Look at your Web.config file. Do you have an entry that starts out like
<endpoint address="mex"...
and then specifies a contract="IMetadataExhange? If not then you need to add a meta data exchange endpoint.
If you have $29 to spare, you can save yourself a LOT of time and watch some great videos by Aaron Skonnard on WCF (in the beginner examples there is an 8 minute video on hosting WCF in IIS), The $29 gets you a one month subscription so you can watch anything in the library. Money very well spent in my opinion. [Edit] I forgot to mention you can get a free trial, I think it's good for a month or 4 hours of viewing whichever comes first.
I have a WCF service and 2 clients I'm testing with. The first client is written in c# .NET 3.5 and has no trouble connecting to the WCF service. The other client is written in Delphi7, and it's the one I'm interested in getting working. This is the interesting part. If I start the service then hit it with the Delphi client, it won't connect... but if I start the service then hit it with the .Net client then try the Delphi client, it works ! Could be something to do with the design-time addresses, I'm not sure. Maybe a more experienced person will know what's going on and what I need to do to get my Delphi client working without needing a .Net client running alongside it. It might be relevant to note that the service is currently being hosted in a winforms app.
regenerating the wsdl and re-importing it into Delphi 7 seems to fix it.
I've been reading the documentation on IIS settings, and haven't been able to find much on the MSDN site. I'm trying to figure out the preferred settings for a WCF REST service hosted in IIS6. Main goals of these settings should be reliability, restarting the service when needed, and max throughput.
My service will use some processing power as its converting back and forth from XML, of course. Suggestions, or suggested URLs to read?
Thanks.
I've started to find some answers to my own question. I'll post everything I find here.
Internet Information Services Hosting Best Practices
System.ServiceModel namespace
serviceHostingEnvironment
How to do away with the .svc file
this is B2B scenario, one client (at least for now).
Server environment:
WCF service, IIS6, .NET v3.5
Client environment:
dev shop is .NET 2.0/VS2005. Will be calling my WCF service.
Question: should i
(a) open WSDL gen for the client(not desirable for security reasons)
(b) send a WSDL file(s) to the client
(c) pre-compile Proxy into dll (on my side) and send it to the client
(d) ???
?
Any suggestions on what would be the best practice for this scenario, any pros/cons?
Thanks in advance,
Igor
Why is a publicly available WSDL not desirable for security reasons?
I may be willing to admit that publishing an API (which is basically what you are doing with WSDL) makes you a bit more vulnerable than if you didn't, but it would be wrong to assume that hiding the WSDL constitutes any kind of security. This is ironically called security by obscurity, and it will be broken by any determined attacker.
The web service should be secure in itself. WCF offers many security features, but that is perpendicular to your question.
I'd prefer publishing the WSDL. If you don't want to do that, or if there is a policy in place that says that you can't do that, then send the WSDL to the client team so they can use it as they wish.
Precompiling the proxy will only enforce your coding conventions on the client team, and they may not appreciate that - for example, I often prefer my proxies to be generated with the /i switch that makes the generated classes internal. I also like to be able to specify the .NET namespaces so that they fit the rest of my code. That would not be possible if I got a precompiled assembly (I would be able to use it anyway, but it would just annoy me).
If you don't want to actually publish the WSDL and make it available online for calling clients, then I would prefer the "send me the WSDL and XSD" approach.
That way, you still give the client calling you the ability and flexibility of creating the proxy the way they see fit.
I would only consider using a pre-compiled proxy in an assembly if the calling party was unable or unwilling to create the proxy themselves, and only if they asked me to supply that code in assembly form.
Marc
In order of preference I would be inclined to:
Have the service expose the WSDL (with security enabled)
Send a WSDL file to the service consumer
I was going to list option 3 as sending a proxy DLL but on second thought I wouldn't even list it as an option. It seems to me that shipping your client a proxy DLL opens up a big can of worms that I would not want to deal with.
The main problem is that you end up having to support executable code that is deployed at the client site. The proxy code could be generated by svcutil but if there is some sort of problem invoking the service I can just see the client calling you for support and telling you that your proxy is not working. Now, their claim is probably not correct but it's hard for you to prove it since you don't know what they are doing on their side. e.g.
Maybe they didn't install the proxy DLL?
Maybe there is some permission problem?
Maybe they don't know what they are doing (yeah, I know that never happens. :) ).
Maybe a .NET upgrade on their side affected your proxy?
You might even run into some versioning headaches when sending them new proxies.
If your customer is not that savvy instead of trying to help them by creating proxy DLL perhaps putting some time and effort into assisting them in getting the correct configuration and usage of your service would be a better approach?