Or is it? And why should the rocket need surgery, anyway? And don't we all just love debugging stuff that fails intermittently, but always works correctly on our own machines? So it happened with WCF-based services for AJAX recently.
This wasn't my first entanglement with ASP.NET's temporary files. The clue comes in various forms: You get a build error for a file that's right in front of you, and which compiles cleanly. You get a run-time error that says ASP.NET couldn't find a file that you know is there. Except that it has a funny name, like "App_Web_zxemnnhw.5.cs". That's an ASP.NET temporary file, and you'll find them in places like C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\breidert web\6d823db7\f71b84dd.
The problem is that ASP.NET decides that it can leave some source code to be compiled-on-demand, even at run time. It doesn't seem to affect code-behinds, or code (anywhere in the web project or web application) that is called directly from code-behinds. The issue sneaks in when code in the web application project is only referenced in web.config - things like providers, HTTP modules, or services. This time, the nasty pointy snarly teeth belonged to a WCF service. (Check it out; you can embed WCF services directly in your web application. Right-click on the project or on a folder inside the project, click "Add -> New Item...", and add a web service or a WCF service. This is in VS 2008, where all web apps are AJAX-enabled.)
What you get is a pair of files, one called "MyServiceThing.svc" and a code-behind, "MyServiceThing.svc.cs". You also get some new references and a <system.serviceModel> section in web.config that contains behaviors and bindings for your WCF service. (To use your new service, you'll need to code a service reference in your ScriptManager tag for ASP.NET AJAX.)
And there the problem begins, because there is no direct call or reference to your service code in your C# (or VB) code. ASP.NET figures that it can stash this code in its temporary files, and compile on demand. But wait! There's more! This is a development or staging machine, and you're going to publish to a web server, and maybe copy from there to a production machine. That's where the ASP.NET temporary files get lost, because they don't seem to tag along with the publishing and deployment process. (Note that sometimes the problem doesn't even take this much effort to throw errors in your face. Gotta love it when a project builds cleanly but publishes with errors.)
When you encounter problems with ASP.NET temporary files, there's a simple solution: Move the code to a separate project, and reference the project in your web app.
For WCF services, it gets a little trickier because of the interplay between hosting and ASP.NET AJAX. You need that .svc file, and it needs to stay in your web project. That is specifically an ASP.NET web "page", and it includes an ASP.NET declaration:
<%@ ServiceHost Language="C#" Debug="true"
Service="NorthwindLINQ.MyServiceThing"
CodeBehind="MyServiceThing.svc.cs" %>So to move the WCF service out of the web app, you only want to move the code-behind to a new project. Leave the .svc file where it is, delete the CodeBehind reference and file, and make sure the Service reference is the fully qualified class name of the service.
<%@ ServiceHost Language="C#" Debug="true"
Service="NorthwindLINQ.Services.MyServiceThing" %>Note that this declaration type is "ServiceHost". This is how WCF services get hosted in an ASP.NET application. Hosting is a critical aspect of WCF, and ASP.NET pretty much takes care of that for you. The constraint is that you're not building a general-purpose service that anyone can call; it's going to be restricted to your web app. On the other hand, it goes through the full ASP.NET pipeline, so it has access to authentication and authorization status, session data, etc.
Also, make sure your ScriptManager tag points to the .svc file:
<asp:ScriptManager ID="ScriptManager"
EnablePageMethods="true"
runat="server" EnablePartialRendering="true">
<Scripts>
<asp:ScriptReference Path="~/jscripts/myStuff.js" />
</Scripts>
<Services>
<asp:ServiceReference Path="~/someFolder/MyServiceThing.svc" />
</Services>
</asp:ScriptManager>
Check your web.config; you may not have to change the serviceModel there, but it's good to verify rather than trust. Things to watch for include the fully qualified class (service) name, and the reference to the service contract. Yes, it's OK for the address to be an empty string; ASP.NET takes care of that for you. ASP.NET AJAX supports only webHttpBinding, and you don't need a metadata binding.
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="NorthwindLINQ.Services.NorthwindLINQAspNetAjaxBehavior">
<enableWebScript />
</behavior>
</endpointBehaviors>
</behaviors>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<services>
<service name="NorthwindLINQ.Services.MyServiceThing">
<endpoint address=""
behaviorConfiguration="NorthwindLINQ.Services.NorthwindLINQAspNetAjaxBehavior"
binding="webHttpBinding"
contract="NorthwindLINQ.Services.IMyServiceThing" />
</service>
</services>
</system.serviceModel>
Next comes the question of adding services in a separate project. WCF has its own way of doing this, and it's not really what we want. The project can be a normal class library. When you add a web service to a class library, Visual Studio creates an interface file and a class file (but no .svc file, since that's specific to ASP.NET). It also creates an app.config and puts the WCF binding in it. Get rid of the app.config file, since the bindings you want are already in web.config, and you don't want any other bindings making the service available to any other callers and/or hackers.
When you add a WCF service to ASP.NET, you don't get an interface file for the service contract. When you add a WCF service to a class library, you do get the interface file. I like interface files for service contracts. (You'll have to modify the contract name in web.config to point to the interface.) However you do it, though, you will probably want to modify the contract attributes. Here's a sample interface with service contract:
namespace NorthwindLINQ.Services
{
[ServiceContract(Namespace = "NorthwindLINQ.Web", Name = "ThingService")]
public interface IMyServiceThing
{
[OperationContract]
string DoWork(string thing);
}
}
And here's the associated class file:
namespace NorthwindLINQ.Services
{
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class MyServiceThing : IMyServiceThing
{
public string DoWork(string thing)
{
try
{
if (string.isNullOrEmpty(thing))
{
throw new Exception("Service tantrum");
}
return thing + " : Done!";
}
catch (Exception ex)
{
throw new Exception(string.Format("{0}: {1}", ex.GetType(), ex.Message));
}
}
}
}
The namespace and name parameters on the service contract are important; these are the namespace and class names that ASP.NET AJAX will use to construct a proxy for calling your service. The AspNetCompatibilityRequirements attribute is also important so that WCF and ASP.NET AJAX will work smoothly together.
Calling your service from Javascript is easy, finally:
function PageLoad()
{
NorthwindLINQ.Web.ThingService.DoWork("whatever", onCompleted, onError);
}
function onCompleted(results, context, methodName) {
alert(methodName + " : " + results);
}
function onError(errorInfo, context, methodName) {
alert(methodName + " : " + errorInfo);
}
onCompleted and onError will have either your results, or the error info, respectively. Note that you call the service using the namespace and class specified in the service contract.
And that's the rocket surgery to fix the ASP.NET temporary files problem for WCF services.
Update:You know what? It still doesn't fix everything! The .svc file that remains in the web project is still subject to ASP.NET temporary file madness.
So if you have temporary file problems, there's always "Clean Solution" followed by "Rebuild Solution." If that fails, then next time I'm calling a real rocket surgeon.
No comments:
Post a Comment