Given an XML comment on a class something like this:
///<summary>Handles the AuthenticateRequest event in the ASP.NET page request lifecycle to authenticate users.</summary>
///<remarks>
///<para>This module will authenticate users based on cookies, form posts, or an impersonation request from the admin system.</para>
///<para>If authentication succeeds, both the <see cref="System.Threading.Thread.CurrentPrincipal" /> and the <see cref="System.Web.HttpContext.User"/> property are set to an instance of <see cref="MyPrincipal"/> representing the authenticated user.</para>
///</remarks>
How can I get the references to System.Threading.Thread.CurrentPrincipal and System.Web.HttpContext.User to link to the appropriate pages in the framework documentation?
You can use href tag to link to MSDN (or any other source for that matter) and do something like this:
... both the <see href="http://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal.aspx">System.Threading.Thread.CurrentPrincipal</see>...
Based on this url, the msdn url cheatsheet
and these two experiments applying the things learned from the cheatsheet
link to 1.1 version of frameworkclass
System.Threading.Thread.CurrentPrincipal
link to 4.0 version of frameworkclass
System.Threading.Thread.CurrentPrincipal
Related
I've used the solution from here for logging (and insert to DB) REST request successfully, now i have to do the same to WCF
[LogApiRequest]
public NadlanData GetNadlanData(decimal Id, KodFamilyEnum KodFamily)
{
ClsDalByTz objByTz = new ClsDalByTz();
return objByTz.getDataFromMF(Id, DateTime.Now.Year - 5, (decimal)KodFamily);
}
I've tried to do the same by adding [LogApiRequest] to the WCF function but it did not work.
How can i implement the same solution for WCF?
The custom attribute - LogApiRequest - derives from System.Web.Http.Filters.ActionFilterAttribute. Action filter attributes are documented here - https://www.tutorialsteacher.com/webapi/web-api-filters and here - https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/controllers-and-routing/understanding-action-filters-cs.
The reason your attribute works in your web api is because asp.net or asp.net core processing pipeline supports calling custom code defined in user defined code - you are plugging custom feature in the processing pipeline.
Know more about asp.net pipeline here - https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/september/asp-net-request-processing-filtering-and-content-redirection
The reason it does not work with WCF is because that processing pipeline does not support customisation through HTTP filters.
WCF has its own way of doing logging. Check out these links - https://learn.microsoft.com/en-us/dotnet/framework/wcf/diagnostics/tracing/configuring-tracing and https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging
You will find yourself editing custom configuration files most of the time.
I cannot give you a short attribute name or configuration script because it depends on type of WCF endpoint you are implementing, their name etc. The tracing and message logging link above contains some samples. Copy paste those configurations but edit file path and interface names based on what you have got code. That should work.
What is the purpose of the ApplicationBuilder.Properties collection? Why not simply use HttpContext.Items?
About the only thing I can come up with is if you want to pass objects from one piece of middleware to another, but again, you could just as easily use HttpContext.Items for that.
I suppose there is an argument for reducing scope.. if an object is only of use for middleware, why pollute HttpContext.Items?
Back in the Owin days, we would use Owin properties, and you could get these properties in your app by using GetOwinContext(), but there doesn't seem to be any equivalent of that in the asp.net middleware. So that doesn't seem like it holds the answer.
I did some searching through the framework and couldn't find anything using it within the framework itself. I might have missed something though.
Any ideas?
What is the purpose of ApplicationBuilder.Properties?
According to source code on Github
/// <summary>
/// Gets a key/value collection that can be used to share data between middleware.
/// </summary>
IDictionary<string, object> Properties { get; }
to speculate about anything else would be primarily opinion-based.
I have ASP.NET WebApi configured with Swashbuckle to show swagger ui. I run it from within VS in IIS Express.
The solution was in VS 2013 and it worked fine. After migration to VS 2015 the swagger shows no methods. There's no error, just empty list. The response returned is:
{"swagger":"2.0","info":{"version":"v4","title":"Swashbuckle Dummy API V4"},"host":"localhost:35622","schemes":["http"],"paths":{},"definitions":{}}
I checked the troubleshooting chapter in documentation but based on it the configuration is ok.
What can I try next?
I have found the problem. I briefly describe the situation:
We have versioned API and use custom ControllerSelector (derived from DefaultHttpControllerSelector) to select the right version of the controller. (The API version is taken from Http header.) There are subfolders in Controllers folder (like V1, V2, ..) and the controller classes are placed in those subfolders.
Generally, for documentation generation it is used ApiExplorer class fed by DefaultHttpControllerSelector, which internally manages list of HttpControllerDescriptors keyed by controller name (the short name without 'Controller' suffix). When it builds this list it checks if the controller name has already been added to the list and if yes, it not only does not add the other one but also removes the one already added.
In our case it means there are no descriptors for controllers that have multiple versions.
I was able to fix it by overriding IHttpControllerSelector.GetControllerMapping() in our custom controller selector and passing in the controller name prefixed with version, which is also a valid route. Our custom ControllerSelector accepts also version passed in URL.
I have created a simple WCF web service with a method. This method has comments on it.
Why does the comment not appear in the service reference for a consuming app?
Is there some other way to propagate to method comments to the proxy?
/// <summary>
/// Do some work
/// </summary>
public void DoWork()
{
}
It doesn't appear on the service reference because the comments aren't part of the service metadata. There are two options you can use to have the comments appear on the proxy:
Share the contract interface between the server and the client (i.e., not generate the proxy, but simply reuse your interface on the client side).
Use some custom WSDL export extension which is aware of the comments (or other attributes), and a custom WSDL import extension which can understand those when generating the client. The sample at http://msdn.microsoft.com/en-us/library/aa717040.aspx is one possible implementation.
Perhaps WCF Extras would work for you. It sounds like what you want.
"Adding WSDL Documentation from Source Code XML Comments"
Make sure your service reference is marked as internal instead of public and the warning will go away.
is there some way of sending the summary info of properties in a DataContract?
e.g.
[DataContract]
public class MyClass
{
/// <summary>
/// My Summary information
/// </summary>
[DataMember]
public int MyProperty {get;set;}
}
can this be available to the client that gets the datacontract? I doubt it, just hoping somebody knows something I don't, which is quite likely. :)
Take a look at WCFExtras on CodePlex. I haven't used it, but it sounds like it does exactly what you want:
Adding WSDL Documentation from Source Code XML Comments
This extension allows you to add WSDL
documentation (annotaiton) directly
from XML comments in your source file.
These comments will be published as
part of the WSDL and are available for
WSDL tools that know how to take
advantage of them (e.g. Apache Axis
wsdl2java and others). Release 2.0
also includes a client side WSDL
importer that will turn those WSDL
comments to XML comments in the
generated proxy code.
If you're referring to the XML comments, then no, they cannot be sent. There is noplace within a WSDL in which they could be sent in such a way that a client could use them.