Develop Reference

Debugging a Web API Project in Visual Studio 2017

I currently have a solution which contains two projects: an ASP.NET site and a Web API project. On the site, I have a page that is meant to call the API using the POST method at address http://localhost:52855/api/v1/GetPrices asynchronously (e.g. response = await base.SendAsync(request, cancellationToken where "base" is a DelegatingHandler). Part of the data that is posted is an API key along with a signature to ensure the user is authorized. However, nothing happens; the Chrome tab just shows the loading symbol continuously.
But, if I use Fiddler and make a POST request to the same address (http://localhost:52855/api/v1/GetPrices), but without the API/signature information, I get back the correct response - a 401 Unauthorized and a "WWW-Authenticate: amx" header (where "amx" is the authentication scheme I'm using for testing. If I include the authorization header in Fiddler then I get a 500 Internal Server Error
My biggest question is how can I debug the Web API project in Visual Studio 2017 Enterprise edition? I have breakpoints set on all the methods (e.g. the Post method in my GetPricesController : ApiController as well as my HMACAuthenticationAttribute which implements the IAuthenticationFilter). I feel that if I can at least start seeing what's going on when I make the requests with Fiddler, that I may be able to figure out the web app from there.
I'm supposed to be doing a demo on this Web API project tomorrow early afternoon and I've been working for the back 11 hours on finishing this up but I'm completely stalled now and have no idea where to go from here. Any help/guidance would be so greatly appreciated. Thank you.
P.S. I was using this article http://bitoftech.net/2014/12/15/secure-asp-net-web-api-using-api-key-authentication-hmac-authentication/ to implement the API key validation.

SSO MVC App compiles without errors but throws 404

I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?

Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.

While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole problem.

elegant maxrequest handler

Another question from me. This wont be an easy one!
I'm having issues with handling a simple upload.
Pre Requirements to test with:
- No Flash (hijacking)
- Basic upload field usage + form to post
- Max file size is 20MB (web.config maxrequestlength)
- I'm running the web site with the build in IIS development tool in visual studio (i think)
- I'm using a MVC web project
Question: Is it possible to show a nice error message to the user when a file is larger than 20MB? (Without getting the whole file to the server first)
These links helped me the most:
http://www.telerik.com/community/forums/aspnet/upload/maximum-request-length-exceeded.aspx
ASP.NET MVC: Handling upload exceeding maxRequestLength
http://forums.whirlpool.net.au/archive/809909
http://forums.asp.net/t/1106579.aspx/1
Catching "Maximum request length exceeded"
But still i haven't been able to fix the issue. Atm i use the code of the accepted answer of the last link (Catching "Maximum request length exceeded"), but my code crashes when i run the code line below:
this.Server.Transfer("~/error/UploadTooLarge.aspx");
Error message: Error executing child request for ~/error/UploadTooLarge.aspx.
I think i get this message because i'm using VS.NET's build in web server (see: http://forums.asp.net/t/1106579.aspx/1 last post of that page).
I'm affraid i made the whole question a bit hard to read. In short:
How can i show a neat error message when i uploaded file is too large (using S.NET's build in web server)?

If you don't want to send to whole file to the server first, then your only option would be javascript.
The FileReader object would solve that for you
https://developer.mozilla.org/en-US/docs/DOM/FileReader
Problem being it won't work on older browsers.
Now, if older browsers are not a problem for you then you should find plenty of tutorials showing you how to use the FileReader object. With it you can do asynchronous uploads so you even add a nice progress bar considering is fairly large file.

POSTing to a re-written URL on IIS 6 doesn't work

I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]

The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx

It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?

I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.

Using a custom URL rewriter, IIS6, and urls with .htm, .html, etc

I have a custom site I'm building with automatic url rewriting using a custom engine. The rewriting works fine as long as the page url doesn't end in somehting like .htm or .html. For these pages it goes directly to the iis 404 page instead of hitting my rewriting engine first.
I have the * wildcard handler in the "Home Directory" section of the IIS6 configuration of that website but these urls seem to be ignored by it (altho things like css, jpg, js, etc to get sent to the url handler in my web project). How do i set up IIS6 to force these urls to get sent to the handler, while still serving the page if it exists normally?
The handler basically does this
if (!File.Exists(Request.Path))
{
doMyRewriting();
}
I have to assume that using a block like this (just and example, the real one does some other stuff to format the Request.Path to be proper with everything) should run the "doMyRewriting()" if the requested file does not exist otherwise it will serve the page normally. Am I mistaken?
If I tell IIS specifically to send .htm and .html pages thru to the .NET handler the rewriting works but if the page is actually there it will not serve it.
Any help would be greatly appreciated.
Thanks in advance!

Don't know if you can or would want to do this, but there is the Ionics Isapi url rewriter you can use.
http://www.codeplex.com/IIRF
Basically install that then set a rule to remove the .html that way it hits your rewrite engine. I use it on IIS 6 with several of my blogs.

I think if you are having IIS send all requests to .NET and your handler, then your handler will need to detect if the page exists and serve it instead of rewriting.
UrlRewriting.NET has an option to do this - you might want to look at their code to see how they're handling this case.

In my opinion, rewriting URLs with IIS 6 is best handled with an ISAPI filter written as unmanaged native code. Otherwise, you run into the issues you've mentioned - having to map all extensions to ASP.Net and losing the ability for simple file handling. With an ISAPI filter, you can choose to not rewrite some URLs and let IIS handle them as normal.
To get started, I suggest reading the ISAPI Filter Overview on MSDN.
If your filter absolutely needs the .Net framework runtime, it is possible to write a small ISAPI filter shell that hosts the CLR and forwards the requests to some managed code. The Filter.Net Framework takes this approach and may be suitable for your needs. There is the small drawback to this approach in that you will have to use the same .Net version as any ASP.Net applications that are run in the main IIS process.