edit web.config to pass parameters [duplicate] - iis

I have an ISAPI DLL installed under a directory like:
c:\inetpub\wwwroot\emsserver\emsserver.dll
This is a Delphi RAD Server app.
In IIS Manager (Windows 10), under Root (computer name) -> Sites -> Default Web Site -> Emsserver, I have a handler set up to handle "*.dll" requests with that DLL. The end result is I can access the app like:
http://localhost/emsserver/emsserver.dll/some-action
That works fine. All good there, output as expected. But the URL isn't very end user friendly.
Question:
Using IIS Manager on Windows 10, how can I configure it so that I can access the application without the DLL portions of the URL? So, like "http://localhost/some-action"?
Seems like it should be a simple enough thing to do, but I'm not seeing how. I tried setting up a handler both in the root server entry in IIS manager, as well as for the 'Default web site', but neither did the trick. I haven't used IIS in 20 years (been almost exclusively Linux & Apache), so I'm a bit out of my usual neighborhood.

You can use url rewrite to achieve this. Download the module from here.
Here is the result of the rule.

Related

Setting up existing site on dev server, how do I make "/some folder/file" direct to the application folder instead of the server root?

I have been given a zip file of an existing site to make some changes. All of the paths within the site use a path structure that starts with "/". In an environment where the site is mapped to a domain name, that is fine. However, when I drop the site into a folder on my development server which i reference like:
"//[myserver]/[thissite]/[index.cfm]"
I get constant 500 errors because every include or location reference looks at:
"//myserver/file"
This is probably a really simple issue to resolve but in my 20 years of developing sites, I have never had to deal with it as I always use links relative to the file instead of to the site root.
My first inclination was to just replace the links with relative links but with more than 800, it is not only impractical, but additionally, I can't change every page in the site. I am just supposed to fix the things that are broken.
My development server is running ColdFusion 11 integrated with IIS so the files are located in the "c:\inetpub\wwwroot\siteFolder"
I have tried:
Setting application mapping in an application.cfc file:
this.mappings[ "/" ] = expandPath("/siteFolder");
this.mappings[ "/" ] = expandPath("/siteFolder/");
this.mappings[ "/" ] = getDirectoryFromPath(getCurrentTemplatePath());
this.mappings[ "/" ] = getDirectoryFromPath(getCurrentTemplatePath()) & "/";
Tried setting up a new site in IIS:
Creating another website in IIS and binding it to siteFolder.myserver and myserver.siteFolder both of which resulted in DNS errors
I have also converted the folder to an application in IIS and still no difference.
I am thinking there might be a way to do it through url rewriting, but before spending more time on something that may not work, I thought I was ask for a little help to see if I was on the right track.
It sounds like your current process is to drop applications into subfolders of a single CF website on your IIS server. This will generally work as the presence of an Application.cfc in the subfolder will designate it as a new application with its own scopes, etc. As you've discovered however, it will mess with any absolute paths you may have in the templates.
Your best bet is to set this up as a new site in IIS. You need to set a binding up for it (I tend to use sitename.local) and you'll need to add that to your hosts file with the following format:
127.0.0.1 yoursite.local
Once this is done, you'll want to let IIS know that this is intended to be a ColdFusion application. ACF comes with the Web Server Configuration tool which should be in your start menu. (If not, you can find it in \runtime\bin\wsconfig.exe).
This will let you select which IIS sites are expected to use CFML and will set up the IIS connectors properly.

IIS gives localhost URI instead of server name

IIS7 serving .Net web application (simple database site).
I have a weird issue where the backgroundimage(URL) property of a element will be served as "http:\localhost" instead of "http:\servername". This is a problem because when a user connects to my site, "localhost" would be their workstation, not the IIS server. So the image (in this case a button) is blank.
The issue is intermittent, recycling the application pool seems to fix the issue for a time and then it comes back. IIS server also runs a SQL instance which eats ~28/36GB RAM.
Anyone ever seen anything like this?
In order to fix this you need to search for all locations where "http:\localhost" is hardcoded in your web app and replace it with a dynamic path. Even though localhost can work in your code if it is relative to the server, there are times when it will not work, such as in a link. You should get in the habit of never hardcoding your urls.
If you are using MVC -
value = Url.Content("~/Images/MyImage.png");
If you are using Forms -
value = ResolveUrl("~/") + "Images/MyImage.png"
Or relative pathing -
value = "~/Images/MyImage.png"

Hosting ASP.NET 5 WebAPI in IIS using a virtual directory/application

I am trying to host a new ASP.NET 5 WebAPI project in IIS, and I am using the ASP.NET 5 RC 1 runtime. The project that I am using is the standard generated template for a new ASP.NET 5 WebAPI project. (No code changes.)
I have successfully published the project using the command line, and I can get the application to work in a new web site using a specific port, such as localhost:12345. For example, accessing localhost:12345/api/values returns the values.json data from the project template.
However, when I try to use an IIS Application folder for the project, I am getting a 404 error. In other words, localhost:12345/WebApi1/api/values returns a 404 error. But I can see Kestrel running on a random port in the Event Viewer, and if I access the data on that port, I do get values.json back, so I know Kestrel is running.
Is there something special that needs to be done to get an ASP.NET 5 WebAPI project working in an IIS Application folder under a web site?
Side note: if I use --server.urls to set a port for Kestrel, it's running both on the requested port and the random port logged in the Event Viewer. (So it's actually available from Kestrel from 2 URLs, not the single one configured by --server.urls.)
Kiran Challa's link above indeed does fix the problem. Put this in your Configure method in Startup.cs
app.Map("/IISApplicationFolderName", (myAppPath) => this.ConfigureApp(myAppPath, env, loggerFactory));
where IISApplicationFolderName is the name of the IIS application folder that you want to host under. The rest of the configuration code moves to the new method ConfigureApp, since you're delegating your configuration to that method.
This also looks to be a temporary patch until ASP.NET 5 RC2 is released.

IIS 8 and ARR with multiple other servers

I am trying to setup IIS 8 with ARR and Url rewrite 2 module to work with two other servers (running Youtrack and TeamCity) and it just dont work...
Lets say my server have following URL: server.test.domain.com (i have no control about this part) so i want to 3 web sites:
server.test.domain.com -> default web site in IIS (classic web)
server.test.domain.com/youtrack -> Catalina with Youtrack
server.test.domain.com/teamcity -> Catalina with TeamCity
on server when i look on localhost:81 i have working Youtrack and on localhost:82 i have TeamCity also workin OK.
I followed this tutorial: http://blogs.endjin.com/2010/11/a-step-by-step-guide-to-hosting-teamcity-in-iis-7/
but in last part he url rewrite it on some domain name and i dont know what URL rewrite RULE i have to use to make it work my way.
Ok so the trick was with this rewriteRule : ^(.*)/youtrack/(.*), Thanks man you really helped me. Only i have to rewrite to localhost:81/{R:2} then. Also as Malvin said there is a par wher you have to enable Application request routing in hidden menu and that was whole trick.

ABCpdf (AddImageUrl) not working in IIS 7.5 for localhost

We have been using ABCpdf for years now. In fact we are on version 6.1 still. It has just always worked. But we have recently upgraded to Windows 2008 x64 / IIS 7.5.
Our code that converts HTML pages (Invoices) to PDF now does not work. The basics are that there is a QueryString based URL that renders the Invoice in HTML, this allows us to "preview" it, then to send it to the client we use ASP .NET to execute the ABCpdf code (calling that same URL from the server to the server). This time the output is PDF, and that's what is attached to an email and sent off to the client.
Pretty simple and straight forward stuff right?
This is what we noticed about ABCpdf:
1) PdfObj.AddImageUrl("http://localhost/..."); // Localhost does not work.
2) PdfObj.AddImageUrl("http://127.0.0.1/..."); // Local IP does not work.
3) PdfObj.AddImageUrl("http://41.XX.XX.XX/..."); // Live IP does not work.
Now this:
4) PdfObj.AddImageUrl("http://www.google.com/"); // Works perfectly!
So we know the code and everything about it technically can and does work.
But it seems that any time the AddImageUrl() function calls a location that points to itself, the page does not render and we get "Unable to render HTML. Page load timed out. Unable to load page."
I know it's not to do with the timeout because if I use Fiddler (on the server) to execute the exact same code, it works perfectly.
I suspect this is to do with permissions... what what permissions? I read this: "... this is because ABCpdf uses the Microsoft MSHTML component" but how do I set the permissions on this component. I have already turned off "IE ESC".
What am I missing?
So it turned out after fiddling with just about every setting, that it came down to the fact that IIS did not allow URL calls from w3wp.exe to the same "site" within the same IIS.
There is more on that here: http://support.microsoft.com/kb/316451
It wasn't the "MSXML2.ServerXMLHTTP.3.0" requests, these seems to work - and why it was so confusing. But in ABC PDF, there is obviously something similar, and so IIS was blocking it... in fact the entire "site" locked up while it was failing.
In the end all it took was to make a clone of the main site ("site2"), and changing the URL that was parsed to ABC pdf to use the clone site.

Resources