I have a web site that built on Visual studio 2008 and
i need to run it from my computer (Win 7 Ultimate) as a server
I tried to publish it to IIS and this is simply not working
and i have the flowing error :
Error Summary
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
any one can help?
It looks like the Web.config file contains some disallowed section. Some sections can only be set in the machine-wide configuration, some can only be set at the root of a web site, etc.
Simplify your web.config as much as possible (make it as empty as possible) and when the page displays, add one section at a time.
Silly problem but IIS never warn about it
i have missed installing the component (from control panel) that support ASP.NET
when i installed it ,it worked :)
Related
I am working on project, where I need to have an access to debugging option.
I've tried to run my application as usually, but this time I received following message:
Unable to connect to web server 'IIS Express'
When I checked the console output I found there following note:
Failed to register URL "http://localhost:49748/" for site xxx application "/". Error description: The process cannot access the file because it is being used by another process. (0x80070020)
Successfully registered URL "https://localhost:44333/" for site xxx application "/"
I found also that 0x80070020 error - "in the case of IIS Express (or IIS) means that the port that it is attempting to listen on is being used by another process" (link to the similar question).
I can't understand what's happen here. When I try to run this application I'm receiving this error in my Visual Studio, but the application is starting in the background (I can manually navigate to the https://localhost:44333 and app is there). The problem is that I can't debug the code, cause the Visual Studio looks like 'unrelated' to this instance. Previously IIS Express was opening new browser window with URL of the application, and I was able to debugging my code.
I also can't understand why this problem is not appearing for brand new project - I've created new web app project to test this behaviour, and it does what I expect - I can use debugging in VS.
What I've tried to do so far is:
Restart VS,
Restart my local machine,
Change app url in solution explorer/properties/debug,
Remove applicationhost.config from .vs directory
and nothing works for me.
Before this issue appear I forked this repo: https://github.com/jasontaylordev/CleanArchitecture
and downloaded WSL and Docker - I doubt that this have an impact on my solution, but maybe this information will be helpful.
Is there anything what I can change/edit to back to my previous behaviour?
Thanks
I had this issue after upgrading to Windows 10 20H2. There are many answers I found on SO that did not work for me, but I found this blog that helped me figure out the problem. Try running netsh interface ipv4 show excludedportrange protocol=tcp on the command liine and check to make sure that the port you are using is not one of the excluded ports listed. If so, change it to one that is not excluded. I did this and everything worked as normal again.
I have problem with IIS. I googled it but couldn't find a solution. I tried to change my config file but it didn't work. If you want any additional information I'm gladly add it. Thank you for all.
Here is my IIS settings
Here is the image of when I try to debug my website from visual studio 2015 (And my awesome paint skills :) )
Here is the image of my visual studio settings for web
It is some internal design of IIS configuration system that in rare cases such an error page comes without the actual line number for the real error (note the line 0 in the error page).
Based on my investigation so far, the most obvious cause can be a missing section definition in IIS schema folder, which probably breaks the XML parser.
The common module that leads to such missing section can be out of band IIS modules shipped as separate MSI downloads from Microsoft.
URL Rewrite module is probably the most likely culprit in this case, as people use it so often, but it is not included in the default IIS installation. Note that it can still be caused by other OOB modules.
A better way to analyze the problem, is to run Jexus Manager (http://jexusmanager.com) which features an XML written by me, which can tell exactly what section definition is missing.
I've followed the steps to bin deploy my MVC3 application into IIS7, but when I browse it after deployment, it is showing me a list of file similar to ftp website instead running the pages.
The dlls that are explicitly added in the bin folder of my application are:
Microsoft.Web.Infrastructure
System.Web.Abstractions
System.Web.Helpers
System.Web.Mvc
System.Web.Razor
System.Web.Routing
System.Web.WebPages.Deployment
System.Web.WebPages
System.Web.WebPages.Razor
I set security to everyone full control to test, so its not a security issue for sure
and when I try to navigate to home/index for example, IIS wont recognize the path, see error below:
.net 4 is installed, application pool of the website is .net 4 also
not able to find solutions
What I am missing to do, any suggestions ?
Thanks
In order for IIS (this only applies to IIS 7+) to process MVC request, the easiest option is to set your Application Pool pipeline to Integrated instead of Classic. Without giving an MSDN level reason as to why this is, essentially classic mode wants every request to have a file extension. If the request does not have a file extension, IIS will go look for that directory. Integrated mode allows the request to go into the ASP.NET pipeline, which will then trigger your routing in your MVC site and the dynamic content will appear.
When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.
I created an ASP.NET MVC 2 application in Visual Studio 2008. I set the release build to go through the ASP.NET compiler to precompile all the views, minify Javascript and CSS, clean up the web.config, etc. Since the production deployment is going to an IIS6 server, I set up my pseudo-production deployment on my Windows 7 machine to have the application pool run in classic mode targeting the 2.0 runtime. I set up the extensionless handler in the web.config that's necessary and everything worked great.
The problem came when I upgraded the solution to Visual Studio 2010. I'm still targeting the 3.5 framework, but now I'm using MSBuild 4.0 since that's what Visual Studio 2010 uses. Everything still compiles correctly because it runs fine under Cassini, but when I deploy it to the same location (same application pool, identity, etc) it now behaves differently. I still have the extensionless handler in the web.config, but now when I navigate to the root of the application it does directory browsing, and any routes that it had previously handled now come back as 404 errors being handled by the StaticFile handler in IIS. I'm at a loss for what changed and is causing the break.
I have looked at this question, but I have already verified that all the prerequisite components are installed.
Did you try debugging your routes using Phil Haack route debugger on the server?
Edit:
On IIS 7.5 you dont need any special extensionless handler, this is handled automatically, you don't need to change anything. It is only necessary on IIS 6 as far as I know.
Could that be the problem? what if you remove that special handler? maybe this is what is stopping it to kick in the route engine.
Edit:
I double checked, and as I thought, starting on IIS7, the default mode of a AppDomain is Integrated Mode. This means that the Asp.net stack kicks in at every request, while in classic mode, asp.net was called only when an specific extensions where called (aspx ashx axd are mapped by default to the aspnet_isapi filter).
UrlRoutingModule is kicking in at every request without requiring anything from you because it is an HttpModule and not a Handler. (it just needs to be registered in the config file of your application, no need to map it to an extension, but that's by default in an MVC app. You can open you Web.Config file and verify that you have under a node
<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>
Are you sure you deploy the MVC assemblies to the server?
Check that System.Web.Mvc, System.Web.Routing and System.Web.Abstraction references have the Copy Local property set to true to be sure you use the same assemblies locally and on your production server...
If all that is correct, I don't know how to help you more... I hope this will help you, or at least put you on the right tracks.
EDIT:
Oww... just read your last comment... sorry I missed that element about classic mode. Your title mentions IIS7.5 and I assumed too much things. that's why I got confused.
Honnestly now, I had to look in the book of Steven Sanderson. He has a checklist for troubleshooting IIS6 deployment.
I know you're saying it's only when using MSBuild 4 that it fails, but it might still be usefull
Check that Default.aspx is set as default content page. That could be the source of 404.
Then to have extensionless urls, last time I deployed to IIS6 I used a simple wildcard map and I never had a problem...
If you're still in trouble sorry that I could'nt help... not that I didnt try :) good luck
I experienced this problem today, in a similar scenario.
The problem on my case was due the fact that asp 32 bits was registered instead of the 64 bits, causing the problem with the routing.
It was solved by typing the following in the command prompt
CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i
Couple ideas to try
Have you run any kind of comparison
between the output of the VS2008 and
VS2010 projects? Just verifying that the
solution upgrade didn't change
anything.
Do you have the web.config
targetFramework attribute set on the
compilation element?
Are you certain you're not running
into something like running a x86 application
in a x64 app pool?
I'm guessing you're fine on those, but since Cassini has no problems with the application, I still lean toward web.config issues. Do you have your modules/handlers properly registered in the element? Since you're running Classic Mode, you'll need both the "old" and the "new" (reference 1, reference 2).
I've already posted this solution in another thread, but I'll repeat myself.
Use classic pipeline mode of AppPool:
Also dot't forget to install HTTP Redirection module in Turn Windows features on or off.