It's just not enough to play with a technology...you really have to burn a few wasteful hours on something ridiculous before you can really feel the love. I love Indigo, I hate that I just spent 3 hours on what I'm about to describe to you. I hope that these 3 hours are well spent if it saves one of my 4 readers the trouble on the road to Indigo...

I have this relatively complex service I am working on that implements contracts for the WS-Trust and WS-Transfer specification (more on those another time...but you get the idea, lots going on). And since I'm implementing a standard contract, I don't need to create a proxy for the client, instead the client can dynamically create a channel to access the service, binding to the same IWSTransfer or IWSTrust contract definition (interface-based). I was a little bit curious how this would play out, what little steps I might miss getting the client side channel properly configured, exposing the service endpoint correctly since it has multiple contracts...so I expected trouble when I first ran the client code to hit the service.

First, my client started getting Access Denied errors hitting the service. This was easy enough, I had to tweak a few things on my service directory permissions.

Second, and less obvious, I start getting the hideous “Internal Server Error 500“. So begins my trials to find the cause, without really knowing “what I don't know yet” about Indigo.

The saga begins...

1. I run the service in the browser, and I get this strange error that indicates it can't find the service DLL.

<%@Service language=c# Debug="true" class="IDesign.Samples.Indigo.WSTransferService" %>
<%@Assembly Name="Service" %>

I check, Service.dll exists, everything built fine, so I test another service that I know works, and no problems showing it the browser.

2. Could it be that my complex interfaces are causing a problem? I am after all exposing two contracts, perhaps I missed something?

So I simplify, and copy a test service that I know works, into my WSTransferService' project, and I modify the configs to expose only that service just to check it out. I use the same test client to hit this test service, simply reconfigure the endpoint from http://localhost/vdiroriginal/service.svc to http://localhost/vdirnew/service.svc. IT DOESN“T WORK! So, now, what am I to think? Same error, different project, different virtual directory. Hmmm...

3. Could it be the Virtual Directory settings?

I check IIS, compare them, I find my service doesn't have “Scripts and Execution“ enabled, so I'm thinking EURIKA, I'VE FOUND IT! No go, same error, damn!

So I use the same Virtual Directory and instead redirect it to another physical directory, and use the same simple test client, and I simply swamp the test client configuration from the service it normally hits, to the same service in a different directory. That means the test client configuration is the same, the test service configuration is the same, but the location is in a new physical directory. Still, no go.

4. Could it be some project settings?

I check the project settings, they are identical, so there is no special post build step that could lead to the error.

I know what you're thinking, “What was the freaking solution then??? Why tell me all of this crap???”.  Answer: Well, just to give you an idea of the other possible things you might need to check for other service issues...even if they don't apply to this one. I'm almost there...check it out...

5. Project settings, project settings, project settings...and then it hit me...

The service DLL, you know the one it said in #1 above “can't be found“. Yeah, well the error message couldn't be more clear now could it? The problem is, when you create an Indigo service, you usually create a class library and add the .svc and related code there. If you deploy the service, you deploy as follows:

\root

   service.svc

   web.config

\root\bin

   service.dll

Yeah, well class libraries default to build the DLL in the \debug or \release folder right? Now you feel my 3 hours of pain. I doubted myself, and I shouldn't have. I was sure it was a problem with one of: directory access, virtual directory settings, service configuration errors...or some magical thing I just don't get about hosting in IIS.

NOT

I had to change my project settings to build the output files in \bin instead of \bin\debug or \bin\release.

Had I deployed the app, of course I would have used the correct structure...but I was testing from within the IDE...and that my friends is my first official ghost chase with Indigo. Stupid? Yes. Could it happen to you? Not anymore.