MvcMiniProfiler profiling web app and lower layers - wcf

I have MiniProfiler set up and working in my ASP.NET MVC app. My controllers make calls via WCF to a BLL which in turn talks to the database. I would like to see profiling from the WCF service alongside the existing profiling I see from the web app. Is it a case of making MiniProfiler a parameter in all service calls?

In a recent release of the MvcMiniProfiler they added WCF support (version 1.8 or greater). This is a 3 step process to get this working:
Add References
First add references to the MvcMiniprofiler and MvcMiniProfiler.WCF in your UI layer and WCF layer via nuget (or download the source and compile your own).
Setup WCF Host
Second, within the web.config of the service host you have to add the miniprofiler as an endpoint behavior. All of the config sections belong in "configuration/system.serviceModel".
<endpointBehaviors>
<behavior name="miniProfilerBehavior">
<wcfMiniProfilerBehavior />
</behavior>
</endpointBehaviors>
Then add the behavior extension (Note the version number needs to match your version of the MvcMiniProfiler.WCF):
<extensions>
<behaviorExtensions>
<add name="wcfMiniProfilerBehavior" type="MvcMiniProfiler.Wcf.WcfMiniProfilerBehavior, MvcMiniProfiler.Wcf, Version=1.8.0.0, Culture=neutral" />
</behaviorExtensions>
</extensions>
Then setup the endpoints to use the profiler behavior you setup:
<services>
<service behaviorConfiguration="BaseBehavior" name="BSI.Something">
<endpoint address="" behaviorConfiguration="miniProfilerBehavior" binding="basicHttpBinding" bindingConfiguration="http" contract="BSI.ISomething"/>
</service>
</services>
Depends on your setup but I had to add one more web.config setting to run all managed modules for all requests. This config is in the root "configuration" section:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Setup WCF Client
Last, setup the wcf client to "turn on" the mvc profiler by doing much the same above.
Add the extension:
<extensions>
<behaviorExtensions>
<add name="wcfMiniProfilerBehavior" type="MvcMiniProfiler.Wcf.WcfMiniProfilerBehavior, MvcMiniProfiler.Wcf, Version=1.8.0.0, Culture=neutral" />
</behaviorExtensions>
</extensions>
Add a behavior:
<behaviors>
<endpointBehaviors>
<behavior name="wcfMiniProfilerBehavior">
<wcfMiniProfilerBehavior />
</behavior>
</endpointBehaviors>
</behaviors>
Setup the endpoints to use that behavior:
<client>
<endpoint address="http://something/Something.svc" behaviorConfiguration="wcfMiniProfilerBehavior"
binding="BasicHttpBinding" bindingConfiguration="BasicHttpBinding_HTTP"
contract="BSL.ISomething" name="BasicHttpBinding_ISomething" />
</client>
And you're done!
Side Note:
How does the MvcMiniProfiler actually work over WCF?
Basically the client behavior sets up a SOAP header that tells the wcf host to turn on the profiler. It passes that header along which is read by the endpoint behavior on the WCF host side. It then turns the profiler on in the host. Lastly when the WCF host is replying back to the client it stuffs all the profiler goodness into the SOAP response header which is in turn read by the WCF client. Pretty ingenious.

That's one method, but in order to get the reference to the libraries you would have to add references in the lower layers for MvcMiniProfiler anyway.
What I did in this very same situation is to take advantage of the global access point that MiniProfiler provides as a singleton. So, I just added the reference in the lower levels (deleted the stuff relative to MVC, such as the views) and just used MiniProfiler.Current as if I were on the upper layers.
It works like a charm. :)

Related

Simplest Console Hosted WCF Service generates a 404 when browse to it

I have the very simplest Console based host for a simple WCF service. The app config for the service is:
<system.serviceModel>
<services>
<service name="MagicEightBallServiceLib.MagicEightBallService"
behaviorConfiguration="EightBallServiceMEXBehavior">
<endpoint address=""
binding = "basicHttpBinding"
contract = "MagicEightBallServiceLib.IEightBall" />
<!-- Enable the MEX endpoint-->
<endpoint address="mex"
binding ="mexHttpBinding"
contract ="IMetadataExchange" />
<!--Need to add this so MEX knows the address of our service -->
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/MagicEightBallService"/>
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="EightBallServiceMEXBehavior">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
The host program shows its running perfectly:
** Console Based WCF Host *
***** Host Info ******
Address: http://localhost:8080/MagicEightBallService
Binding: BasicHttpBinding
Contract: IEightBall
Address: http://localhost:8080/MagicEightBallService/mex
Binding: MetadataExchangeHttpBinding
Contract: IMetadataExchange
**************************************************
The service is ready
When I attempt to browse to or generate a proxy I get:
HTTP Error 404.0 - Not Found
I can't figure out what's wrong. You can't get any simpler than this!
I have faced the same problem when reading Troelsen's book and could not find any answer online. Anyway it seems that the problem is in the project type for MagicEightBallLib. Troelsen suggests that you create a Visual C# -> Windows -> Class Library project, but he does not explain what modifications you need to make for it to work. If you instead use the Visual C# -> WCF -> WCF Service Library project, it will automatically start the WcfTestClient.exe, and add new tab in project's Preferences called "WCF Options". I tried to compare the differences between .csproj files for both types of projects but there is just too many.
So the solution is to just start with the WCF Service Library project type instead of Class Library, and adjust names of interfaces and classes so they fit what is in the book.
If anyone knows which particular parts of the .csproj file are responsible for enabling this, I'd very much like to hear about it.
Hope this helps.
Instead of using localhost:8080 use 127.0.0.1:8080. That's how I got the example to work on my windows 10 machine.

WCF SOAP + REST/Json service without .svc - do I have twice the number of service factories?

Ok, so I wanted to have a single service exposed as a SOAP as well as REST (Json) end point. Since it's off the "WCF Service Application" template, I have a web.config and I added the following into the ...
web.config
<configuration>
...
<system.serviceModel>
<services>
<service name="MySvcClass">
<endpoint address="" binding="webHttpBinding" contract="MySvcInterfaceClass" behaviorConfiguration="restBehavior" />
<endpoint address="soap" binding="basicHttpBinding" contract="MySvcInterfaceClass" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="restBehavior">
<webHttp helpEnabled="true"/>
</behavior>
</endpointBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
...
</configuration>
Assuming the MySvcClass class is implemented within \MySvcClass.svc, the above exposes ...
Original Endpoints
localhost\MySvcClass.svc\ (rest endpoint)
localhost\MySvcClass.svc\mex (Metadata Exchange to the use the SOAP end point below)
localhost\MySvcClass.svc\soap (soap endpoint)
So far, so good (I think!).
Then I wanted to get rid of the ugly ".svc" seen in the paths above. So I followed this MSDN blog post and had this in my ...
global.asax
void Application_Start(object sender, EventArgs e)
{
RouteTable.Routes.Add(new ServiceRoute("MySvcClass", new WebServiceHostFactory(), typeof(MySvcClass)));
}
Interestingly, when I put a breakpoint inside Application_Start, VS2010 doesn't hit this particular breakpoint - even when I stop->start debugging or stop->start the IIS application pool. Bizarre! Anyway, back to the point, I can now access the services the above listed endpoints AND
Cleaner Endpoints
localhost\MySvcClass\ (rest endpoint)
localhost\MySvcClass\mex (Metadata Exchange to the use the SOAP end point below)
localhost\MySvcClass\soap (soap endpoint)
Questions
Am I having TWO service factories? One from the web.config and the other from the global.asax? If yes, how can I avoid it while still having clean URLs (without .svc). I don't really need the ones with .svc in the path ...
I dislike cluttered web.configs, so is there any way I can move the above SOAP and REST configuration from the XML (web.config) into code (eg global.asax?) ? I know how to move the REST only end point - wipe out in the web.config, leave global.asax as is. However doing that kills the SOAP endpoint.
[Update]
I had tried URL rewrites too but this killed the SOAP endpoint while keeping the REST endpoint alive. Wht I did was : Used MS's URL Rewrite 2.0 module with this in the web.config
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<rewrite>
<rules>
<rule name="RemoveSvcExt" stopProcessing="true">
<match url="^MySvcClass(.*)$" />
<action type="Rewrite" url="MySvcClass.svc{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
However, this leaves the web app in some inconsistent state because there are some parts which still stick to the .svc URLs. eg: the HTML help page at the service endpoint shows svcutil.exe http://localhost/MySvcClass.svc?wsdl Even the WSDL at the clean location at http://localhost/MySvcClass?wsdl makes references to http://localhost/MySvcClass.svc inside it - this effectively kills the SOAP endpoint.
That's why I think ($0.02) the rewrite is just a kludge. Sigh, at this point I'm fighting with the framework to get stuff done. And it feels such a time burner ...
For services without .svc search for file less activations in wcf
http://www.a2zdotnet.com/View.aspx?Id=188
I have a REST project that as both REST and SOAP service being exposed. Now I placed an .svc file for the SOAP service to be accessed by some clients.
The below screenshot gives the folder structure of my project, the route configuration in global.asax, Output accessing the Rest Service and accessing the .svc file (SOAP service). To remove the .svc extension use the URL rewrite module.
Please find my web.Config (My application is hosted on IIS):
Please find my class that implements my interface ISampleService:

WCF 3.5 running SOAP and REST services side by side in IIS

I know that similar question was asked here :
Running SOAP and RESTful on the same URL
Hosting WCF soap and rest endpoints side by side
but didn't find an answer to my problem.
I have two custom servicehostfactories that enables Dependency Injection :
public class StructureMapSoapServiceHostFactory : ServiceHostFactory
public class StructureMapRestServiceHostFactory : WebServiceHost2Factory
The implementation details are not important here.
Then I definied two endpoints in web.config
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="mexGet">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="jsonBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<mexHttpBinding>
<binding name="mexHttpBinding" />
</mexHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="mexGet" name="ServiceImplementation.ServiceCategory">
<endpoint address="rest"
binding="webHttpBinding"
contract="Contracts.ServiceContracts.Mobile.IServiceCategory"
behaviorConfiguration ="jsonBehavior"/>
<endpoint address="soap"
binding="basicHttpBinding"
contract="Contracts.ServiceContracts.Mobile.IServiceCategory" />
<endpoint name="mexHttpBinding"
address="mex"
binding="mexHttpBinding" bindingConfiguration="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
Then I created two .svc files for each custom host factories :
ServiceCategoryRest.svc
ServiceCategorySoap.svc
I don't like it. What I would like to do is to have URL in that style :
REST : http://server:port/rest/categories/{id} which mapps to the implementation of my ServiceCategory.GetCategory(int id)
SOAP : http://server:port/soap/GetCategory?id=someId
My questions are. Do i need different svc files to activate host services ? If I need there two .svc files, how can I achieve the URI above ? I'm afraid that I should configure IIS rewriting or something but would like to avoid that.
Thanks in advance for your help.
Thomas
You can achieve what you're looking for with service routes - part of ASP.NET routing, available from ASP.NET 3.5 SP1 on up.
Check out these resources:
RESTful WCF Services with No svc file and no config
Drop the Soap: WCF, REST, and Pretty URIs in .NET 4
making a WCF REST stand-alone service exe from scratch – part 1 of 4, creating the minimal bare service
Using Routes to Compose WCF WebHttp Services
In .NET 3.5 SP1, you need to add some extra infrastructure to your web.config (web routing module etc.) - while in .NET 4, this is all already built in.
After few searches I found out that in fact I don't need two different .svc files and two different ServiceHostFactories.
I kept only the StructureMapRestServiceHostFactory : WebServiceHost2Factory and ServiceCategoryRest.svc which handles well requests in REST mode and call in RPC-SOAP mode.
So if you want to run side by side the REST and the SOAP you can do it only with WebServiceHost2Factory.
If then you want to get rid of the .svc part from the URL, please read the Rick Strahl post west-wind.com/weblog/posts/570695.aspx.

WCF base address not found

My service can work with normal WCF calls, but to expose metadata (the wsdl file) I have to change configuration in such a way the normal WCF host fails.
I've spend countless hours on google trying to solve this, big problem there is that hosting a service inside a website is never discussed (yes this is different).
requirements:
Runs in an existing web site
Use sessions
Operable with Java, and as much .net versions as possible.
Expose metadata (wsdl will be enough)
edits:
IIS cannot be used
I'm using .NET 4 and WCF 4.
In this configuration the metadata can be reached (through the wsdl file) but when trying to host the normal wcf endpoints I get and InvalidOperationException:
Could not find a base address that matches scheme http for the endpoint with binding WSHttpBinding. Registered base address schemes are [].
So the base address is ignored.
But when I supply full addresses to the endpoints (simply copy the base address in front of the current address) the normal WCF calls work fine, but when trying to access metadata I get the following error:
No protocol binding matches the given address 'http://localhost:8080/Functionality'.
Protocol bindings are configured at the Site level in IIS or WAS configuration.
Here is the web.config serviceModel section, I made a small test web site just for testing this, but it would be to much to post all of it here, if you send me a pm though I will e-mail it to you.
<system.serviceModel>
<services>
<service behaviorConfiguration="metadataSupport" name="MyStuff.TestWithMetadata">
<endpoint address="Functionality" binding="wsHttpBinding" name="FunctionalityBinding"
contract="MyStuff.ITestWithMetadata" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<endpointBehaviors>
<behavior name="metadataSupport">
<webHttp />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="metadataSupport">
<!--Navigate with browser to httpGetUrl for the wsdl file-->
<serviceMetadata httpGetEnabled="true" httpGetUrl="Metadata" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false">
<serviceActivations>
<add relativeAddress="TestWithMetadata.svc" service="MyStuff.TestWithMetadata" />
</serviceActivations>
</serviceHostingEnvironment>
</system.serviceModel>
If anyone has any ideas on how to solve this, please help out.
When you host your service in IIS (which I assume from your requirement "Runs in an existing web site"), then your base address in the config is moot - it will not be used at all.
When hosting in IIS, your service address is determined by:
your server name
possibly a port number
the virtual directory (and possibly subdirectories thereof) where the *.svc file lives
the *.svc file itself (including extension)
So it might be something like:
http://MyServer:7777/ExistingWebApp/TestWithMetadata.svc
or whatever it is that you have in your case.
You seem to be using .NET 4 and WCF 4 (never mentioned that.....) and in that case, you could skip the *.svc file altogether by adapting your config entry:
<serviceHostingEnvironment multipleSiteBindingsEnabled="false">
<serviceActivations>
<add relativeAddress="MyService" service="MyStuff.TestWithMetadata" />
</serviceActivations>
</serviceHostingEnvironment>
In this case, the value of relativeAddress= becomes the service address (within the virtual directory this web.config lives in) - so your service address would be something like:
http://MyServer:7777/ExistingWebApp/MyService
No need for a *.svc file at all in this situation.
Turned out I should use httpGetUrl link to get the metadata, instead of the .svc file, with that the base address can be ignored.
I also moved this test stuff to the actual web site and got tons of problems with zero endpoints being loaded. That was caused by the service reference in serviceActivations not set to the full service name (needs to have namespace included).
I accepted marc's answer because he did help me along and to prevent this question from popping up in unanswered.

WCF Service ajax method call returns 404

I have deployed a WCF service to SharePoint and on my own machine everything works fine. Navigating to the .svc works and, as expected, navigating to service.svc/Operation generates a "method not allowed message". Posting to the service using jQuery also works perfectly on my own machine.
However, when my colleague gets the latest version from source control and deploys the feature, he can navigate to the .svc allright, but navigating to service.svc/Operation generates a 404, and off course posting wiht jQuery doesn't work either.
I am thinking this has to do with something I did configure on my machine (and forgot afterwards :-S) and my colleague did not configure yet. We did run ServiceModelReg -i on his machine.
The .svc file looks like this:
<%# ServiceHost Language="C#" Debug="true" Service="NameSpace.ServiceName" Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory" %>
The service's assembly is loaded in the web.config's assemblies section and is loaded (break points are red when debugging).
Edit: Anyone?
One thing I can think of is you missed the serviceModel section in web.config... is that the case? It's something like
<configuration>
<system.serviceModel>
<services>
<service behaviorConfiguration="behavior1" name="HelloWorld.service1">
<endpoint address="" binding="wsHttpBinding" contract="MyServices.IHelloWorld" />
<host>
<baseAddresses>
<add baseAddress="http://server/_wcf/HelloWorld.svc" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="behavior1">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
I managed to fix the problem. We were using Sahil Malik's excellent open source solution, WCFSupport. Somehow the dll was not being loaded (even though the registration was in the web.config for teh HttpModule and the assembly).
After first trying the service itself in a dummy web app project I created in visual studio (added the .svc file, added assembly reference to my service's dll in the web.config and added new site in IIS), I came to the conclusion that it was not the service itself, nor any configuration issue in IIS (i.e. the servicemodelreg.exe tool).
So it had to be the code that mapped requests for a .svc, and more importantly request for any of it's operations was not working. I copied Sahil's code to our own solution, deployed that and then it worked. Why the code works now, no idea, maybe the original WCFSupport dll was corrupt, we'll never know.
Anyway, it works now!