Having a bit of trouble after migrated my app to IIS 7. Everything was working perfectly when it runs under IIS6.
The main problem is I have a UNC mapped folder (Folder A) under the root folder of the my web application. This folder is located in same network but in different server.
So when I try to access this from my ASP.NET site, instead of reading the contents from the remote UNC path, my application looking for FolderA in Web Server which it clearly fails.
The application runs as a custom user which has pretty much all permissions it needs
I'm running out of ideas here and can anyone shed some lights please?
I have an web Application. My application work properly when i hosting as site(www.example.com). But when try to host as a application under my site (www.example.com/everway) css file & javascript (window.location.href) not work.
Your asset URLs when hosted at www.example.com/everway would look like www.example.com/everway/javascripts/application.js, right?
www.example.com/javascripts/application.js and www.example.com/everway/javascripts/application.js are not the same.
Does your application account for that difference?
I have a free hosting account, and two ASP.NET project.
I want to upload both apps in my hosting, like:
www.hosting.com/myaccount/project1/
www.hosting.com/myaccount/project2/
But the problem is when I run project1 or project2
Asp.net considers application main path ("~") as root www.hosting.com/myaccount/
Si I cant load dll, App_themes, and Other.
What can I do to stop that strange behvior!
I cant configure IIS because I am using free hosting.
I applied this answer and no thing happened.
Thank you for hepling.
You can add an application at root that redirects to the other two.
I have a ASP.NET 3.5 web site, which is password protected (form authentication). But yesterday I found I was able to browse the list of directories (which is unexpected).
I searched the web, one article said we need to config it in IIS. But I'm a developer and I'm working on my local machine (no IIS installed).
My question is: are there any way to hide them other than IIS configuration? like set web.config?
This must be configured in your webserver - you cannot handle this in the website itself. Since you are working locally it shouldn't matter that the root directory is browsable. If you need to be able to control the site in this way you really ought to set up a webserver.
if you don't have IIS, you're likely working on your local ASP.NET development server (called Cassini possibly?), in which it is only available locally, so no security worries there.
When you deploy your app, you will likely be on an IIS server, so the configuration will be available
Directory browsing in IIS is controlled in the virtual directory/site configuration.
When you deploy your application to a real server you can configure directory browsing there.
Directory browsing on your local machine shouldn't matter, but this may work for you.
In IIS6: http://blog.crowe.co.nz/archive/2006/03/18/603.aspx
In IIS7: http://technet.microsoft.com/en-us/library/cc731109(WS.10).aspx
In IIS - Website properties, Home Directory tab, untick Directory browsing.
In Cassini (the ASP.NET development server) I don't think it can be turned off. But the server only runs while your debugging.
This one is killing me. I have an ASP.net (2.0 Framework) app that uses integrated security. IIS is setup appropriately and works fine as a virtual directory off the default website. My OLEDB connection (Jet 4.0) works fine and connects to a database file via network share (\GIS1\GIS Server - PublicWorks_StreetSigns).
BUT, when I create an IIS "website" and point it to the exact same home directory I get an error...
Error getting data from DBF. '\GIS1\GIS Server - PublicWorks_StreetSigns' is not a valid path.
Do I have to do something different in a website versus a virtual off the default website to make this work? I've triple checked the virtual settings against the website settings and everything is the same.
Thanks in advance.
I would check the identity of the application pool servicing each website. My guess is that the default identity of the app pool doesn't have permissions to that path.