On the utility of .svc files

I could really use some customer feedback here.

In the Indigo Beta 1 code, when you’re hosted in IIS Indigo requires you to represent the service on disk as a physical file with a .svc extension. Most of the time, that file just contains one line of code:

    <%@ Service Language=”CS” Class=”MyService” %>

It’s currently possible to put code in there too.

What if instead of the @Service directive, that file just has a comment that said something like:

//This file represents a service. The contents of this file are completely unimportant and are
//ignored by Indigo. In fact, the file itself is completely unimportant and you can delete it if you
//want.

//It’s just here to remind you that the code for an Indigo service lives in App_Code, or in a compiled
//.dll in the \bin directory.

//The way you give your service an address is through configuration:
//
//   
//

Would not having to deal with the presence of the .svc file be a good thing Would it be a better thing if Indigo didn`t require the .svc extension in the service URI at all If I told you that the web.config for this service lived at http://localhost/myapp, could you easily guess what the service address would be

The way I see it, there are usability concerns both ways. If we require physical .svc files, then it requires extra work to pick up a .dll with some Indigo services and plop it in IIS. You have to create a physical file for each service in that case. If we go the config-only route, then there’s no physical representation of the service on disk and it might feel wierd if you’re used to having such a thing.

This is an area where strong customer feedback one way or the other could really impact the final product. I want to make sure we meet the needs of our customers, so I’m asking: what would you like to see in the product Leave a comment here or mail me at smaine (at) microsoft.com and let me know what you think!