I've just got to the bottom of this, and couldn't find the problem documented anywhere, so thought I would post the question (and answer) for future reference:
I've just installed CruiseControl.NET on a (virtual) Windows Server 2003 and I can't access the Dashboard. CruiseControl (ccnet.exe) runs fine, and IIS6 is up and running, and the the CruiseControl installation installed the Dashboard app under Default Web Sites as "ccnet". It's pointing to the dashboard folder, and the dashboard files are visible in IIIS Manager, but when I try to access http://localhost/ccnet I get a 404: Page Not Found error. I get this whether I use IE or Chrome, or try to Browse the site from IIS Manager.
What's wrong?
ASP.NET was Prohibited, and needed to be Allowed - in IIS Manager, click on Web Service Extensions under the server, select ASP.NET and click Allow.
Related
I'm in the process of setting up my first ASP.NET vNext web application project.
I've got as far as getting the default project to build and run fine in both Windows and OSX. I've tested with kestrel on the mac, and in Windows IIS Express along with kestrel.
The problem I have encountered is that in Windows, editing a cshtml View file while the web server is running isn't reflected when I next refresh the browser.
In OSX, I can run 'dnx web' and navigate to localhost:5000 and browse the site. I can then edit the .cshtml View files, switch back to the browser, hit refresh, and I can see all the changes. This is what I expect to happen and happened in previous versions.*
In Windows, I can either run dnx web or IIS Express on the same site as I was using on OSX, navigate to localhost:5000 (or for IIS Express its own port number) and browse the site. I then switch to edit the cshtml View files, but when I switch back to the browser to reset, the changes aren't shown. It's not until I restart kestrel or IIS express that the changes are shown.
Curiously, however, I can edit a .cs Controller file and the site then recompiles by itself and I don't need to re-start it - in Windows at least. (In OSX, editing a controller file doesn't cause an auto-recompile, but that's an aside, I believe dnx-watch will fix that).
Is there something that I've missed in the project.json, or another setup file, which is causing the issue in Windows?
I have tried:
creating a second completely clean web application project
reinstalling ASP.NET
desperately, lastly, creating a clean install of Windows 10 with Visual Studio 2015 Community Edition, to no avail
What's the way to get Kestrel or IIS Express in Windows to serve the updated cshtml View file after it's been edited, without restarting the server?
*side note, ASP.NET MVC in OSX is awesome!
Following on from #SRQ Coder's response, in particular the reassurance that it's supposed to work as I hoped, I found the reason but as yet no decent solution.
My project directory is located on a network share and I load the projects directly from there (I run Parallels Desktop on a mac). This works great with ASP.NET 4.x / MVC 5 (and earlier). However it looks like ASP.NET 5 doesn't support this setup.
The moment I copied the project folder to the local C: drive it all worked fine
When opening the project from a \\network-share, the project loads and I can run/debug the website, but CSHTML edits aren't shown in browser until IIS Express/Kestrel is restarted
Opening the project from a X:\ mapped network drive doesn't make any difference
I'm not able to recreate your problem on my machine: VS2015; Win10 etc. in either the IIS mode or Web: localhost/5000 mode and on multiple browsers.
I can edit both 'shared' cshtml files like '_Layout' and also the default 'home/index cshtml file with no problem.
Since you've re-installed so much of your system, I'm wondering if you have not re-installed web-essentials and enabled 'browser link'.
I feel your pain...
New to IIS8, but previously created sites on an IIS7.5 server without any problems. I've created a site on IIS8 and although the pages are being served to remote computers, when I click 'Browse Website' in IIS, the server itself cannot see the page. Any suggestions? Could it be permission based?
I feel this may be linked to a problem we're having downloading images.
You didn't mention the specifics of "the server itself cannot see the page". However, since you can access the site remotely but not locally, it sounds like it may be anti-loopback checking. Check out http://blogs.msdn.com/b/jiruss/archive/2008/10/21/loopback-security-check-feature-iis-7.aspx and see if it applies in your case.
In our MVC web application, we have integrated windows workflow. Its working locally without any issue. After deployment of the application in windows server 2008, workflow functionality is not working. I am not getting any error. But the application in browser is keep on running with no result.
Note: .Net4.5 framework is installed in server.
When I googled, I found few solutions and I tried the below
Right click the web site that hosts your service in the IIS Connections pane, click Manage Websites -> Advanced Settings and add ,net.pipe to the end of the “Enabled Protocols” setting (no spaces!)
Still facing the issue. Please guide to fix this issue
When I see the event viewer, I observed an information saying that
"Login failed for user 'IIS APPPOOL\ASP.NET v4.0'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors."
I have added user, "IIS APPPOOL\ASP.NET v4.0" to DB Logins by openning SQL Management Studio, Navigate to database then open the Security then Logings and add new login. It solved the issue.
I'm trying to change IIS express and Website URL to point to a custom URL so i can try the website from my mobile. The point is, the changes I made (read below) don't change the website starting url.
I already changed the part at the IIS Express applicationhost.config file, from port:localhost to a port:custom name, tried to change the part at the .sln file where it points to the localhost.
I uploaded a screenshot from my project's property page, I can't find Use Custom Server option under Server or the Use Local IIS Web Server option.
First Right-click on your Web Site in Solution Explorer and select Convert to web application and then you can find the options you need under Properties -> Web
I'm stumped. There are several threads out there that reference a similar problem, but not the same one. I'm trying to get a simple WCF service up and running in Azure, but my problem is happening before I even deploy. I'm following this article:
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/
Which says to create your project, build the "Hello World" service interface and class, and then start your project locally. I get a 403 error when I try to start my project.
The only step I'm not following exactly is that I don't have a "Start Without Debugging" option (I'm using Visual Studio Express Web Developer), so I just push "Start Debugging."
Why would I get a 403 error on my own machine? I am running Visual Studio as Administrator.
On the WebRole project right click on your .svc (Service1.svc) and choose "Set As Start Page" And then run the project. Make sure to do this on the WebRole project not the Azure Cloude Project.
Is the Azure project the default project or is the WCF Web Role? If it's the role itself, that may be your issue - it's trying to access the root of virtual directory containing the web service versus running the cloud app in the local emulator. If you browse to http://127.0.0.1:81/Service1.svc in a new browser window do you still get the 403?
It seems VS has lost the its project settings. Bring up "Properties" page on the web service in VS. Go to the "Debug" tab. Under Servers/Virtual Path: my configuration was set to just "/". Put the name of your server back in there "/Service1.svc" and it should work from the debugger now. This fixed the problem for me.
The problem went away when I upgraded to VS 2010 Pro. I never fixed it on Express, but after upgrading the problem was gone ... I had the "Start without Debugging" option in the Pro edition, so I suspect that the problem may have been specific to Express.