I have a WCF Web Service hosted in a Windows Service.
The service is configured using the following attributes (VB)
<ServiceBehavior(ConcurrencyMode:=ConcurrencyMode.Multiple,
InstanceContextMode:=InstanceContextMode.PerCall,
UseSynchronizationContext:=False)>
I created a test client, which creates 50 threads at once and and I am starting them straight away, all querying an operation on the WCF Service. The first 30 or so openings (client.open()) work, but afterwards I get an error message on my client that the opening couldn't be done because there was a timeout while trying to open the service and thus I get an EndPointNotFoundException. (The operationss I am calling are all synchronous if that matters.)
Can I expect that sort of behaviour and thus simply have to live with these exceptions or do I have to look at some of my settings, either the above, or any other settings? (I am using a NetTcpBinding.)
What I see is that the client works on the request of the at once created threads simultaneously, so the above settings have the desired effect of making the service multi-user-at-the-same-time-enabled.
But ideally I wouldn't get timeout exceptions. Rather I would want the clients to wait longer to get their response than to time out.
Any ideas?
Thanks all!
Check settings such as these:
<behavior name="CommonServices_Behavior">
<serviceThrottling maxConcurrentCalls="100" maxConcurrentSessions="50"
maxConcurrentInstances="50" />
</behavior>
I seem to recall that some of these values have defaults set in your machine.config file. There is also a MaxConnections value to check for NetTcpBinding.
Related
I have a queue named log on a remote machine. When I call that queue locally, I specify a custom dead-letter queue by modifying my NetMsmqBinding:
_binding.DeadLetterQueue = DeadLetterQueue.Custom;
_binding.CustomDeadLetterQueue = new Uri(
"net.msmq://localhost/private/Services/Logging/LogDeadLetterService.svc");
This works fine; when I force my message to fail to get to its destination, it appears in this queue.
Now, I have a service hosted in IIS/WAS to read the dead-letter queue. It it hosted in a site called Services, at Services/Logging/LogDeadLetterService.svc. Here's the service in my config:
<service name="Me.Logging.Service.LoggingDeadLetterService">
<endpoint binding="netMsmqBinding"
bindingNamespace="http://me.logging/services/2012/11"
contract="Me.Logging.Service.Shared.Service.Contracts.ILog" />
</service>
And here's my activation:
<add relativeAddress="LogDeadLetterService.svc"
service="Me.Logging.Service.LoggingDeadLetterService" />
My actual service is basically this:
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any, // Pick up any messages, regardless of To address.
InstanceContextMode = InstanceContextMode.Single, // Singleton instance of this class.
ConcurrencyMode = ConcurrencyMode.Multiple, // Multiple callers at a time.
Namespace = "http://me.logging/services/2012/11")]
public class LoggingDeadLetterService : ILog
{
public void LogApplication(ApplicationLog entry)
{
LogToEventLog(entry);
}
}
My queue is transactional and authenticated. I have net.msmq included as enabled protocols both on the Services site and on the Logging application, and I added a net.msmq binding to the Services site. If I have the binding information as appdev.me.com, I get the following error when browsing to http://appdev.me.com/Logging/LogDeadLetterService.svc (appdev.me.com is setup in my HOSTS file):
An error occurred while opening the queue:Access is denied. (-1072824283, 0xc00e0025).
If I have the binding information as localhost, I get the following error:
An error occurred while opening the queue:The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003).
No matter which way I have it set up, the service isn't picking up the dead letter, as it's still in the queue and not in my event log.
Now, I realize that both of these reference a permissions issue. However, in the interest of getting the code part of this tested before figuring out the authentication piece, I have given Full Control to everyone I could think of - to include Everyone, Authenticated Users, NETWORK SERVICE, IIS_USERS, ANONYMOUS LOGON, and myself. (The app pool is running as me.)
Any help as to how to get my service to be able to pull from this queue would be phenomenal. Thanks!
EDIT: According to this MSDN blog entry, 0xC00E0003 corresponds to MQ_ERROR_QUEUE_NOT_FOUND, and 0xc00e0025 corresponds to MQ_ERROR_ACCESS_DENIED, so it looks like I want to have the binding information as appdev.me.com. However, that still doesn't resolve the apparent permissions issue occurring.
EDIT2: It works if I host the service in a console app and provide the following endpoint:
<endpoint address="net.msmq://localhost/private/Services/Logging/LogDeadLetterService.svc"
binding="netMsmqBinding"
bindingNamespace="http://me.logging/services/2012/11"
contract="Me.Logging.Service.Shared.Service.Contracts.ILog" />
So what's going on differently in the console app than is going on in IIS? I'm pretty confident, due to EDIT above, that I'm hitting the queue. So why can't I get into it?
EDIT3: Changed Services/Logging/LogDeadLetterService.svc to Logging/LogDeadLetterService.svc per the advice given here, but no change.
//
[Bonus question: Do I need to handle poison messages in my dead letter queue?]
So, three things needed to be changed:
The binding does have to be localhost.
The queue has to be named Logging/LogDeadLetterService.svc to be found - it's the application and the service, not the site, application, and service.
I had something messed up with the application pool - I have no idea what it was, but using a different app pool worked, so I backed out all of my service-related changes and then recreated everything, and it works.
Well, that was a lot of banging my head against my desk for something as simple as "don't mess up your app pool."
I have a WCF service to consume in .NET. As per requirement the Action element in the header has to be "http://abc" and the To element has to be "ws://xyz" in order for the service to recognize and respond to the request. The soapAction of the operation is however blank in WSDL and it can't be changed.
My service configuration built programmatically is this:
text message encoding binding with Soap11 envelope version and WSAddressing10 addressing version
no security biding
http transport binding
The setup I found achieving this requirement is "ws://xyz" as the endpoint URL and Request.Headers.Action set to "http://abc" in BeforeSendRequest using a message inspector added using an endpoint behaviour attached to the endpoint. Then I also attach a ClientViaBehavior with the URL of "http://abc".
On my development machine this causes as required
<a:Action>http://abc</a:Action>
<a:To>ws://xyz</a:To>
However on the test server it generates
<a:Action>http://abc</a:Action>
<a:To>http://xyz</a:To>
I don't know exact configuration of the server but I believe it is Windows server as is my development box. Does the same code generates different messages on two different machines or how else would I achieve this? I should also say it worked fine for several weeks and stopped last Monday.
I have found the following later:
The test server has .NET 4.5 on it as well as another machine I tried it on (also failed). The dev machine where it works fine has just .NET 4.0 on it which would suggest it could have something to do with it. However I have no evidence it is caused by .NET 4.5 as it was installed several weeks before the problem appeared. Moreover there have been no Windows updates since it stopped to work!
I've also tried to set the To element in my ClientMessageInspector implementation but the protocol still gets flipped to http.
I think the BeforeSendRequest is not called due miss configration of your service bindings. Check if you have added the the extention configuration to you service endpoints you want to have the behavior.
I've got a duplex WCF service which hangs after the magic 10 proxy instantiations. The specific error on the client is:
"System.TimeoutException: This request operation sent to net.tcp://localhost:8080/RoomService/netTcp did not receive a reply within the configured timeout (00:00:59.9960000)".
There aren't any apparent error messages on the server.
Note that this isn't the standard, obvious problem, i.e., failing to close my proxy connections, as I'm closing every instance of my proxy connection appropriately before opening the next one:
try
{
client.Close();
}
catch (CommunicationException)
{
client.Abort();
}
catch (TimeoutException)
{
client.Abort();
}
catch (Exception)
{
client.Abort();
throw;
}
And I've set my throttling behavior to 500 simultaneous everything:
ServiceThrottlingBehavior throttlingBehavior = new ServiceThrottlingBehavior()
{
MaxConcurrentCalls = 500,
MaxConcurrentSessions = 500,
MaxConcurrentInstances = 500
};
I've set the ConcurrencyMode of my service to Multiple, and I've tried all three possible values for InstanceContextMode.
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Multiple)]
I've tried self-hosting the service, and hosting it within IIS, and I get the same results on each.
I've tried the NetTcpBinding, the WSDualHttpBinding, and the PollingDuplexBinding (on Silverlight), with the same results on each. I can't try the BasicHttpBinding or the WSHttpBinding, as this is a duplex service.
There was one place in my code where I was launching multiple threads (to execute multiple callbacks simultaneously), but for troubleshooting purposes I've commented that bit out, and it hasn't made a difference.
On the client, I've tried using new proxies for each test, and reusing the same proxy across all tests, but without any luck. I've tried creating a new InstanceContext for each proxy, and reusing the same InstanceContext across all proxies, and again, no luck.
Whatever I do, after the 10th test executed in my test harness, the next call to the service hangs.
Any thoughts on what I might be doing wrong?
OK, so I made at least one stupid mistake: I was creating the throttling behavior, but was neglecting to add it to the service proper. It's now added correctly:
ServiceThrottlingBehavior throttlingBehavior = new ServiceThrottlingBehavior()
{
MaxConcurrentCalls = 500,
MaxConcurrentSessions = 500,
MaxConcurrentInstances = 500
};
base.Description.Behaviors.Add(throttlingBehavior);
And now I can run more than 10 tests, and hence my immediate problem is solved.
But I'm still puzzled as to why I'm running into this problem at all, since I'm specifically closing one proxy before moving on to the next. A MaxConcurrentXXX of 2 ought to be working in this scenario; I shouldn't need a MaxConcurrentXXX of 500. I'm a tad worried about scalability if every client that connects to the server continues to chew up a connection beyond the time that it's actually connected.
Maybe I'm making a stupid mistake somewhere else -- it wouldn't be the first time -- but I've specifically stepped through the code that's closing the proxy, and it's definitely getting called.
I've had this happen when I had a semaphore on the server-side which wasn't being released after a client was done being serviced.
Are any server-side resources or locks not being released properly? Since your service instance is per session, I'd suspect that the server object is hanging around and holding a lock. What if you change the behavior to per call?
I don't have an answer but I do have some debugging advice.
1) Attach the visual studio debugger to the service process and see if it can catch whatever is going on.
2) Configure the service behavior to pass exception information back to the client and see if the service is throwing an exception that isn't being reported:
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceDebug includeExceptionDetailInFaults="True"/>
</behavior>
</serviceBehaviors>
</behaviors>
3) Turn on service logging with ActivityTracing enabled and use the Service Trace Viewer (from Windows SDK) to analyze the log and see if anything pops up
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
<listeners>
<add name="sdt" type="System.Diagnostics.XmlWriterTraceListener" initializeData="Service.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
4) Isolate the service wrapper from the functional code and see if the service still hangs. If it doesn't then incrementally add functionality back until you figure out what is making it hang
5) If you are using an HTTP binding, proxy the service with fiddler and log the http traffic.
6) Try Hosting the WCF service in a Managed Windows Service and attach a debugger to the service process after you start it up.
Take a look at ServiceBehavior.AutomaticSessionShutdown.
At the begining of the Callback function in the client use
OperationContext.Current.Channel.Close();
This will solev the problem.
We have an application that has a WCF service (*.svc) running on IIS7 and various clients querying the service. The server is running Win 2008 Server. The clients are running either Windows 2008 Server or Windows 2003 server. I am getting the following exception, which I have seen can in fact be related to a large number of potential WCF issues.
System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.
I have increased the timeout to 30min and the error still occurred. This tells me that something else is at play, because the quantity of data could never take 30min to upload or download.
The error comes and goes. At the moment, it is more frequent. It does not seem to matter if I have 3 clients running simultaneously or 100, it still occurs once in a while. Most of the time, there are no timeouts but I still get a few per hour. The error comes from any of the methods that are invoked. One of these methods does not have parameters and returns a bit of data. Another takes in lots of data as a parameter but executes asynchronously. The errors always originate from the client and never reference any code on the server in the stack trace. It always ends with:
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
On the server:
I've tried (and currently have) the following binding settings:
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"
It does not seem to have an impact.
I've tried (and currently have) the following throttling settings:
<serviceThrottling maxConcurrentCalls="1500" maxConcurrentInstances="1500" maxConcurrentSessions="1500"/>
It does not seem to have an impact.
I currently have the following settings for the WCF service.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
I ran with ConcurrencyMode.Multiple for a while, and the error still occurred.
I've tried restarting IIS, restarting my underlying SQL Server, restarting the machine. All of these don't seem to have an impact.
I've tried disabling the Windows firewall. It does not seem to have an impact.
On the client, I have these settings:
maxReceivedMessageSize="2147483647"
<system.net>
<connectionManagement>
<add address="*" maxconnection="16"/>
</connectionManagement>
</system.net>
My client closes its connections:
var client = new MyClient();
try
{
return client.GetConfigurationOptions();
}
finally
{
client.Close();
}
I have changed the registry settings to allow more outgoing connections:
MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.
I have now just recently tried SvcTraceViewer.exe. I managed to catch one exception on the client end. I see that its duration is 1 minute. Looking at the server side trace, I can see that the server is not aware of this exception. The maximum duration I can see is 10 seconds.
I have looked at active database connections using exec sp_who on the server. I only have a few (2-3). I have looked at TCP connections from one client using TCPview. It usually is around 2-3 and I have seen up to 5 or 6.
Simply put, I am stumped. I have tried everything I could find, and must be missing something very simple that a WCF expert would be able to see. It is my gut feeling that something is blocking my clients at the low-level (TCP), before the server actually receives the message and/or that something is queuing the messages at the server level and never letting them process.
If you have any performance counters I should look at, please let me know. (please indicate what values are bad, as some of these counters are hard to decypher). Also, how could I log the WCF message size? Finally, are there any tools our there that would allow me to test how many connections I can establish between my client and server (independently from my application)
Thanks for your time!
Extra information added June 20th:
My WCF application does something similar to the following.
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
Using WireShark, I did see that when the error occurs, I have a five TCP retransmissions followed by a TCP reset later on. My guess is the RST is coming from WCF killing the connection. The exception report I get is from Step3 timing out.
I discovered this by looking at the tcp stream "tcp.stream eq 192". I then expanded my filter to "tcp.stream eq 192 and http and http.request.method eq POST" and saw 6 POSTs during this stream. This seemed odd, so I checked with another stream such as tcp.stream eq 100. I had three POSTs, which seems a bit more normal because I am doing three calls. However, I do close my connection after every WCF call, so I would have expected one call per stream (but I don't know much about TCP).
Investigating a bit more, I dumped the http packet load to disk to look at what these six calls where.
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
My guess is two concurrent clients are using the same connection, that is why I saw duplicates. However, I still have a few more issues that I can't comprehend:
a) Why is the packet corrupted? Random network fluke - maybe? The load is gzipped using this sample code: http://msdn.microsoft.com/en-us/library/ms751458.aspx - Could the code be buggy once in a while when used concurrently? I should test without the gzip library.
b) Why would I see step 1 & step 2 running AFTER the corrupted operation timed out? It seems to me as if these operations should not have occurred. Maybe I am not looking at the right stream because my understanding of TCP is flawed. I have other streams that occur at the same time. I should investigate other streams - a quick glance at streams 190-194 show that the Step3 POST have proper payload data (not corrupted). Pushing me to look at the gzip library again.
If you are using .Net client then you may not have set
//This says how many outgoing connection you can make to a single endpoint. Default Value is 2
System.Net.ServicePointManager.DefaultConnectionLimit = 200;
here is the original question and answer WCF Service Throttling
Update:
This config goes in .Net client application may be on start up or whenever but before starting your tests.
Moreover you can have it in app.config file as well like following
<system.net>
<connectionManagement>
<add maxconnection = "200" address ="*" />
</connectionManagement>
</system.net>
If you havn't tried it already - encapsulate your Server-side WCF Operations in try/finally blocks, and add logging to ensure they are actually returning.
If those show that the Operations are completing, then my next step would be to go to a lower level, and look at the actual transport layer.
Wireshark or another similar packet capturing tool can be quite helpful at this point. I'm assuming this is running over HTTP on standard port 80.
Run Wireshark on the client. In the Options when you start the capture, set the capture filter to tcp http and host service.example.com - this will reduce the amount of irrelevant traffic.
If you can, modify your client to notify you the exact start time of the call, and the time when the timeout occurred. Or just monitor it closely.
When you get an error, then you can trawl through the Wireshark logs to find the start of the call. Right click on the first packet that has your client calling out on it (Should be something like GET /service.svc or POST /service.svc) and select Follow TCP Stream.
Wireshark will decode the entire HTTP Conversation, so you can ensure that WCF is actually sending back responses.
from: http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx
To avoid this timeout error, we need
to configure the OperationTimeout
property for Proxy in the WCF client
code. This configuration is something
new unlike other configurations such
as Send Timeout, Receive Timeout etc.,
which I discussed early in the
article. To set this operation timeout
property configuration, we have to
cast our proxy to IContextChannel in
WCF client application before calling
the operation contract methods.
I'm having a very similar problem. In the past, this has been related to serialization problems. If you are still having this problem, can you verify that you can correctly serialize the objects you are returning. Specifically, if you are using Linq-To-Sql objects that have relationships, there are known serialization problems if you put a back reference on a child object to the parent object and mark that back reference as a DataMember.
You can verify serialization by writing a console app that serializes and deserializes your objects using the DataContractSerializer on the server side and whatever serialization methods your client uses. For example, in our current application, we have both WPF and Compact Framework clients. I wrote a console app to verify that I can serialize using a DataContractSerializer and deserialize using an XmlDesserializer. You might try that.
Also, if you are returning Linq-To-Sql objects that have child collections, you might try to ensure that you have eagerly loaded them on the server side. Sometimes, because of lazy loading, the objects being returned are not populated and may cause the behavior you are seeing where the request is sent to the service method multiple times.
If you have solved this problem, I'd love to hear how because I'm stuck with it too. I have verified that my issue is not serialization so I'm at a loss.
UPDATE: I'm not sure if it will help you any but the Service Trace Viewer Tool just solved my problem after 5 days of very similar experience to yours. By setting up tracing and then looking at the raw XML, I found the exceptions that were causing my serialization problems. It was related to Linq-to-SQL objects that occasionally had more child objects than could be successfully serialized. Adding the following to your web.config file should enable tracing:
<sharedListeners>
<add name="sharedListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\Temp\servicetrace.svclog" />
</sharedListeners>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="sharedListener" />
</listeners>
</source>
</sources>
The resulting file can be opened with the Service Trace Viewer Tool or just in IE to examine the results.
Are you closing the connection to the WCF service in between requests? If you don't, you'll see this exact timeout (eventually).
Did you try using clientVia to see the message sent, using SOAP toolkit or something like that? This could help to see if the error is coming from the client itself or from somewhere else.
Did you check the WCF traces? WCF has a tendency to swallow exceptions and only return the last exception, which is the timeout that you're getting, since the end point didn't return anything meaningful.
I've just solved the problem.I found that the nodes in the App.config file have configed wrong.
<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>
<bindings>
<wsHttpBinding>
<binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
<**security mode="None">**
<transport clientCredentialType="None"></transport>
</security>
</binding>
</wsHttpBinding>
</bindings>
Confirm your config in the node <security>,the attribute "mode" value is "None". If your value is "Transport",the error occurs.
You will also receive this error if you are passing an object back to the client that contains a property of type enum that is not set by default and that enum does not have a value that maps to 0. i.e enum MyEnum{ a=1, b=2};
Looks like this exception message is quite generic and can be received due to a variety of reasons. We ran into this while deploying the client on Windows 8.1 machines. Our WCF client runs inside of a windows service and continuously polls the WCF service. The windows service runs under a non-admin user. The issue was fixed by setting the clientCredentialType to "Windows" in the WCF configuration to allow the authentication to pass-through, as in the following:
<security mode="None">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
I'm not a WCF expert but I'm wondering if you aren't running into a DDOS protection on IIS.
I know from experience that if you run a bunch of simultaneous connections from a single client to a server at some point the server stops responding to the calls as it suspects a DDOS attack.
It will also hold the connections open until they time-out in order to slow the client down in his attacks.
Multiple connection coming from different machines/IP's should not be a problem however.
There's more info in this MSDN post:
http://msdn.microsoft.com/en-us/library/bb463275.aspx
Check out the MaxConcurrentSession sproperty.
My silverlight application loads data fromt he SQL fine when I build locally but when I upload it to the live site it will just wait for data to be loaded but show no errors. It worked up until yesterday where I fear I may have changed a setting somewhere and now I cant access the data it seems?
UPDATE 1: it seems to be a problem with the service references. Everytime I update them, it will clear the ServiceReferences.ClientConfig file and then the program wont build.
UPDATE 2: I have tried cleaning and building but still the same problem.
UPDATE 3: Found an error when trying to access the service reference on the live site:
This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item
It sounds like your application is waiting for something, does it time out after 30 seconds? If so, check your SQL connection string.
If there is another tier between Silverlight and SQL (such as a web service), then set up a connection test to make sure that Silverlight is actually reaching SQL...
Did you accidentally replace your live web.config file? If so, try restoring the old web.config as it may have a setting that's not compatable with your server.
Re: Update 1:
Is there an error? If so please paste it. Also please paste the config file in question on pastebin and link to it from here.
Re: Update 3:
The error "This collection already contains an address with scheme http." is caused by not telling a WCF service explicitly what address you wish to bind to when there are many to chosoe from. In this case it looks like IIS is using multiple URLs, for example, consider these fictional addresses:
www.mysite.com
mysite.com
... so the WCF service has no idea which to use unless you tell it.
The solution, to this is to explictly define what URL to use with the following config lines in the web.config (within the system.serviceModel node) of your WCF service.
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<baseAddressPrefixFilters>
<add prefix="http://www.mysite.com/SomeDirectory/MyService" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
Important:
You should update your question title to indicate that WCF is involved in the solution you have created.