A route I had working in VS2010/.NET 4/MVC3 seems broken in VS2012 and .NET 4.5 (although with MVC3 still).
Previously I had a route like this:-
routes.MapRoute("TMS", "{controller}/{action}/{id}.{extension}");
which was successfully matched for a uri:
/Test/Test/tile.png
which invoked the Test action on TestController:-
public ActionResult Test(string id, string extension)
With id = "tile" and extension="png".
Yet, in an identical project in VS2012, albeit with .NET 4.5, I get a 404 because the route does not match. Changing the period to a / in the route, and the uri, causes the route to match and invoke the action, but that's not good enough - i need to have that period in the route, as was working previously (because this action is designed to serve tiles as a TMS server; the URL format is an API).
Has anyone come across a problem like this?
<httpRuntime relaxedUrlToFileSystemMapping="true"/> does not help at all.
I wonder if the web server settings are different between the 2 environments you are testing: If the .png extension is not set up to be handled by MVC or the "verify that physical file exists" option is checked.
Related
I have a working self-hosted OWIN based 2.2 WebApi project. I wanted to put authorization into it and share the identity service with my MVC 5 website. (There a numerous opinions on if or how easy doing so may be.) My attempt to share the authorization/authentication cookie has lead me into a hole. I discovered that the WebApi code was not seeing/processing the cookie even though it was in the request header. I then decided to try a test in which I would generate the cookie in the WebApi on one call and accept it on another. That attempt lead me to the fact that CreatePerOwinContext is not working as I thought it should.
I placed the following code in a method to generate the cookie.
var ctx = Request.GetOwinContext();
var asim = ctx.Get<ApplicationSignInManager>();
asim.SignInAsync(user, false, false);
and discovered that the Get was returning null. I then investigated the code in my startup
appBuilder.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);
I placed a breakpoint on ApplicationSigInManger.Create and never reached it. I placed a breakpoint at the same location in my MVC 5 code and did hit the breakpoint. Yes, I did verify that I am reaching and continuing past the call to CreatePerOwinContext. The lack of hitting the breakpoint has lead me to conclude that the call to CreatePerOwinContext is not working the same in WebApi as in MVC 5.
Both the MVC project and the WebApi project are using .Net 4.6 release code and the latest versions of their respective NuGet packages.
I need to bypass an MVC route for an application where the developer left - we're going to fully replace it, but for now if I can bypass this one route, it'll save us a ton of time.
The route is (e.g.) www.this.site/path/subpath
Since it's on IIS, I can take advantage of the default document and create the following folder / file structure: /path/subpath/index.htm
However if I do this, I'll "break" the parent www.this.site/path route (it throws a 403 - Forbidden: Access is denied) because I now have an actual file folder where the /path/ route was.
Is there a way to get around this / have IIS defer to MVC on /path/ but still handle the child html file?
thanks. Again, this is not intended as a long term solution but a work-around until we can replace the app entirely.
Perhaps a better workaround would be to use the IIS AAR module and it's reverse proxy functionality out the app.
To do so:
a) stand up the app at it's own site the proper path -- so it should work at something like http://localhost:1234/path/subpath/index.htm
b) install IIS AAR module and enable the reverse proxy functions using the WebPI and the IIS management tools
c) Ignore the /path/subpath route in your app
d) Add a virtual directory for /path/subpath to IIS
e) Configure that to reverse back to localhost:1234 or whatever port you configured the site
This will keep the legacy app completely separate while keeping the public facing URLs looking correct for the rest of the world.
I am looking for a way to batch requests to the server. I found a post by Brad Wilson outlining how to make a batch handler using a message hanlder http://bradwilson.typepad.com/blog/2012/06/batching-handler-for-web-api.html#more but I wasn't able to get this working.
first I had compile errors because webapi did not understand "route-specific endpoint handler" like Brad's example used. there were also problems with the media type and/or formatter (can't remember which). My next attempt was to make a batch controller. so instead of a batch handler I had a batch controller. I almost has this working except when I used the MessageHandlerInvoker to call the individual commands I got exceptions about the additional handlers I have regsstered (1 for logging request/response and another to mimic user authentication).
At that point I stopped and reverted back to individual requests, not ideal, but it works.
My environment:
.net 4.0
VS 2010
mvc 4 front end (calls webapi)
webapi as a service tier
Has anyone else had any success with batched messages and webapi?
To be able to use per-route handlers you need ASP.NET Web API RTM which was only released yesterday (at the time when Brad wrote the article, it would only work with nightly MyGet feed builds or against Codeplex source).
You can get entire MVC4 RTM here or simply off Nuget.
Do I even need this rule anymore?
I don't see any requests incoming for resource.axd files (as opposed to when I ran webform applications)
WebResource.axd is an HTTP Handler that is part of the .NET Framework
that does one thing and one thing only – it is tasked with getting an
embedded resource out of a DLL and returning its content. What DLL to
go to and what embedded resource to take are specified through the
querystring. For instance, a request to
www.yoursite.com/WebResource.axd?d=EqSMS…&t=63421… might return a
particular snippet of JavaScript embedded in a particular assembly.
Its still part of the framework and you can still retrieve embedded resources using the above handler. You dont want your route handler to handle such requests and that is why it is ignored. My guess is that you can get rid of it if you are completely sure that your app/libraries that you use dont use it.
My company currently builds separate MSI's for all of our clients, even though the app is 100% the same across the board (with a single exception, an ID in the app.config).
I would like to show them that we can publish in once place with ClickOnce, and simply add a query string parameter for each client's installer.
Example: http://mysite.com/setup.exe?ID=1234-56-7890
The issue that I'm having is that the above ("ID=1234...") is not being passed along to the "myapplication.application". What is happening instead is, the app is being installed successfully, and it is running the first time with an activation context, but the "ActivationUri" does not contain any query string values.
Is there a way to pass query string values FROM THE INSTALLER URL to the application's launch URL? If so, how?
After much searching (and discussing), the answer is simply that the current version of ClickOnce doesn't work that way. The installer does not pass the URL onto the application up it's first run.
Here is what I have done for a workaround (and it works great).
Change my setup package to have all of the required files uncompressed and loose (as apposed to using a CAB file, or embedding them in the installer).
Make an ASP.NET application (using Routing for URL handling) that listens for a request to "mysite.com/Installer/00123/Setup.exe"
Note: the route should listen for "/Installer/{ID}/*" where {ID} is 5 digits.
There is actually no directory called "00123", but rather, I'm using ASP.NET Routing to pickup those requests and then I map it to my actual directory that has the installer file in it.
I then hijack the request (parse the setup.exe to find the embedded URL that tells the installer program where to find the rest of the files... I then replace "/00000/" with the request URL that the user went to - in this case "00123".
As each file is being requested, I know which "version" of the file to send, because the ClickOnce Installer will be looking for "mysite.com/Installer/00123/SomeFile.dll" (or whatever).
Instead of using a 5-digit ID, you could use a GUID... it's up to you.
This solution works great for our organization... we currently have 37 clients who require unique customizations to their installer package, but we only have to actually build and publish ONE installer package and simply use the hijack method above.
At this point we have placeholders that we swap out so that it's easy to customize installers for as many clients as we want.
Example: in the app.config file we have displayName="{OrgName}" which is automatically replaced by one of the values in the database.
For me, "http://mysite.com/myapplication.application?id=1234-56-7890" seems to do the trick.
I know this is outdated, but I just wanted to provide the current solution.
To retrieve querystring parameters in a ClickOnce application:
Point the app/download/setup link to the application (with .application extension), not "setup.exe"
Add this function to your ClickOnce application to retrieve the querystring parameter collection:
private NameValueCollection GetQueryStringParameters()
{
NameValueCollection nameValueTable = new NameValueCollection();
if (ApplicationDeployment.IsNetworkDeployed)
{
string queryString = ApplicationDeployment.CurrentDeployment.ActivationUri.Query;
nameValueTable = HttpUtility.ParseQueryString(queryString);
}
return (nameValueTable);
}
Then to get a querystring param value:
var querystringParams = GetQueryStringParameters();
string param_value = querystringParams["param_name"];
Don't forget the Usings:
using System.Collections.Specialized;
using System.Deployment.Application;
using System.Web;
Source: https://learn.microsoft.com/en-us/visualstudio/deployment/how-to-retrieve-query-string-information-in-an-online-clickonce-application?view=vs-2019