Error: allowDefinition='MachineToApplication' beyond application level - asp.net
I have downloaded the online project in ASP.Net. While running application I get an error
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
What changes should i make in web.config or elsewhere to make this work?
I've just encountered this "delight". It seems to present itself just after I've published a web application in release mode.
The only way to consistently get round the issue that I've found is to follow this checklist:
Clean solution whilst your solution is configured in Release mode.
Clean solution whilst your solution is configured in Debug mode.
Build whilst your solution is configured in Debug mode.
Just come across this post and that was happening to me.
Just Clean the project and the error goes away. (must be a VS2010 bug)
I have just had this problem when building a second version of my website. It didn't happen when I built it the first time.
I have just deleted the bin and obj folders, run a Clean Solution and built it again, this time without any problem.
None. You need to set up the directory you've placed the website as a web application within IIS.
This error occurs when you attempt to open a project as a website. The easiest way to determine if you've created a website or a project is to check your solution folder (i.e. where you saved your code) and see if you have a *.sln file in the root directory, if you do then you've created a project.
Just to add, I encountered this error just now when I attempted to open a project I created a while back by selecting "File", "Open Website" from the Visual Studio menus whereas I should have selected "File", "Open Project" instead. I facepalmed as soon as I realised :)
If you have MVC project with enabled views build, one of the solution is to delete obj folder before build. Add to project file:
<Target Name="BeforeBuild">
<!-- Remove obj folder -->
<RemoveDir Directories="$(BaseIntermediateOutputPath)" />
<!-- Remove bin folder -->
<RemoveDir Directories="$(BaseOutputPath)" />
</Target>
Here is article: How to remove bin and/or obj folder before the build or deploy
In Visual Studio 2013 I struggled with this for a while and it is pretty much easy to solve just follow what the exceptions says "virtual directory not being configured as an application in IIS"
In my case I had WebService planted inside IIS website so
I opened the website in IIS manager
right clicked the WCF folder
clicked Convert to Application
and then submitted with Ok
WCF is back and running.
The error suggests that the code you are using is expecting a virtual directory to be setup on IIS.
Look up the documentation and add the required virtual directory. It should be a directory that has a web.config in it (not the root directory).
A recent web.config change may be in the wrong web.config file.
A <machineKey...> property had been added to Views/web.config. No matter how many Cleans and Rebuilds the error remained. The fix was to move the property into the root /web.config.
if you ever encounter this error
It is an error to use a section registered as
allowDefinition='MachineToApplication' beyond application level. This
error can be caused by a virtual directory not being configured as an
application in IIS
SOLUTION
I had the same issue with VS 2012.
I resolved this by
Unload your current project
edit your .csproj
Find this <MvcBuildViews>false</MvcBuildViews>
Instead of false change the value to true
Load again your project and you should not have any more this error
If you do have then one solution is to delete the content of the obj folder in the project generated by compiler.
In my case, the problem appeared only after I published the project to the subdirectory. Because of my lack of knowledge, I have placed my web_publish subdirectory inside the web_project directory.
It is clear that the web_publish contains also the same Web.configs that the project contains. However, the web_project does not know that my web_publish should be avoided when searching Web.configs in the nested subdirectories. This way, the Web.configs were duplicated and the error appeared.
The solution was to place my web_publish somewhere else.
In my case there was a "Backup" folder which contained another copy of the whole website in there. This meant another web.config and so the build failed with this error. I deleted the "Backup" folder, did a Clean solution on the Debug and Release builds, and the error disappeared.
In my case,
Solution contains 6 projects, 1 main and 5 sub directories. all the sub directories having web.config.
When running any page within sub directories, I was getting same error.
I removed this line from web.config,
<authentication mode="Windows"/>
that worked for me.
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
My problem was I had accidentally published my webservice to a pre-completed location on a fresh install of VS2010.
I had published to a folder called PreCompiledWeb, and the presence of the web.config I suspect messed it up.
I simply nuked the folder, and refreshed the project.
When double-clicking this error - it took me to that erroneous web.config file, which tipped me off.
It may be the version problem like you download the project of .Net framework 2.0 and want to open it into the VS2008 then you will need to upgrade to the latest version and VS will create the Backup of the folder in same root directory.You will get the answer here.
I had this error when building the solution with Web Deployment Project created into my solution. I resolve the error by deleting the folder where Web Deployment Project is built to. This folder is specified in "Project Folder" attribute of WDP properties
Delete bin and obj folders. Then rebuild the solution.
Apparently there were two web.config files in my solution. I am using MVC4 and there was another config file under Views and i was making the change in the wrong file. Fixed there helped me.
But you can always change the default redirect/route in the global.asax file.
Probably you have a sub asp.net project folder within the project folder which is not configured as virtual directory. Setup the project to run in IIS.
I added to my website publish script. At the end, delete the obj folder from your website folder.
I've this problem more frequent if "true" is enabled in the project file.
Set false
As Jonny says:
Clean solution whilst your solution is configured in Release mode.
Clean solution whilst your solution is configured in Debug mode.
Build whilst your solution is configured in Debug mode.
I had a project that I didn't want to be a web application I wanted it to be a folder. The answer was to delete the web.config file altogether. It only belongs in the root of an application.
If you face this problem while publishing your website or application on some server, the simple solution I used is to convert folder which contains files to web application.
I've got the same problem in VS 2013 after publishing my project in debug mode. The problem has been solved by removing obj/ files
I have a website project.
In my case I had moved the solution file to another path and that cause the problem. I restored it to the previous location and the problem went out.
For any one still looking, my solution was to delete both the bin and obj folders and restart visual studio seems to fix it.
Via Visual Studio, I had published a WCF Service via FTP, to an external server. It worked fine locally, and when publishing to an internal server, but not to the external. The solution was to publish without providing a Site Path (in other words, publish directly to the root of the virtual directory).
I'm not sure why it worked, since I had already tried moving the files to the root via an external FTP Client - among many other attempts, including all listed here. Maybe it was something with the publish profile, like it was for FabianVal. But I'm not in the mood of testing anymore at this point, since I'm in a hurry to get up to speed after all the days wasted on this problem.
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/
(all files)
You should have to open demo from vs... not demo1.
I tried every solution above, but none of them worked for my problem. (I'm sure there are 1000 solutions to this problem) For my scenario, I was attempting to publish my WCF web service that I had in test into production.
However, I failed to realize that in production we are HTTPS only, meaning we redirect everything to HTTPS. As it turns out, I was pointing to the service via HTTP instead of HTTPS, thus causing the error. The solution in this scenario was to simply to change the address protocol to HTTPS rather than HTTP.
I hope that helps some poor soul out there trying to figure out this problem.
Related
ASP.NET failing to call a dll
My question may have already been asked but any of the answers match my case. I need to do a website (ASP.NET MVC 4) with some features of a software. I have finished to developed my website and wanted to test it in a test environment (Windows server 2008 - 64bits). It works perfectly fine with my dev computer(windows 7 - 64bits). But after I deployed it on IIS, one of my features doesn't work. This feature is a bit particular. It need a 32 bits COM written in VB6 (this dll can't be change) that call an other dll. When I test the website deployed on IIS, the first ddl is called fine but the 2nd seemed to be not called at all. This dll are in the installed file of the software. I have the same version of on both computer. I authorize my app pool to use 32bits application. I tried to give some access to my dll (the COM and interop) like IUSR, IIS_IUSRS. But nothing seems to work. I have checked both of my dll are registered properly. I'm a bit lost. Can someone help me ? PS: Sorry for my English, I can speak but I'm really weak with syntax.
Some suggestion here: You need to figure out which managed dll, native dll and lib files are referenced by your application (directly or indirectly). For managed dll, make sure they are in the web's bin folder. For native dll and .lib files, check out whether those .dll and .lib files are in the PATH. If not, you can either copy them to there; or, you can put them into a folder and add that folder into the PATH. Then restart VS and IIS (command "iisreset") to make sure the setting is picked up. By the way, putting all of the files in the web's bin folder won't help. The reason is CLR copies the files into a temporary folder under framework directory and run the web there, but CLR only copies away managed dll (not the native ones), so you still get "module not found" error. I have reproduced this error using the following sample solution Web1 references a managed c++ project say "MCpp1.dll". The project further references two unmanaged c++ projects with the output say "Lib1.lib" and "Lib2.lib" If I copy all of those files into web's bin folder, I get the exception of "module not found error". I create a folder say "C:\Lib" and copy "Lib1.lib" and "Lib2.lib" into it and add this folder into PATH. I restart VS, and also run "IISReset" since I have a IIS web Open VS and request a page and it works now I have also contacted the CLR/Fusion team for suggestion of how to get the related module name when this exception happens, which should be very helpful to make diagnosis. Hope this helps , GODFATHER
Website is running a cached dll somehow after changing it
The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll. They've checked the GAC and don't see it there. I've checked the dll with reflector to verify I gave them the correct new dll. This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on. On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great! But .... We had same trouble deploying to production and the above did not work. Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in: "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ). If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
You don't have to stop IIS to deploy your update, you just copy them over. Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.
We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.
Error running ASP.NET MVC on IIS 7
I have been trying to deploy my asp.net mvc site to IIS 7 and having a bit of an issue. Whenever I run the site, I get a "Could not load type 'System.Web.Mvc.ViewPage'.". When I try to access a page with a master page, I get a Could not load type 'System.Web.Mvc.MasterViewPage'" error. I tried using tracing rules in IIS 7 to narrow down on the issue with no anvil. On the bright side, when I run the site through the built-in visual studio webserver, the site runs just fine but not on IIS 7. Has any one run into this before or has any idea what could be causing this error. Thanks.
OK, so after playing around with this issue for a while. I finally fixed it. I was publishing to IIS 7 using visual studio deployment tools with copy 'only files needed to run this application". For some reason, using this publishing configuration doesn't copy all the files needed for mvc to run correctly. When I changed my publishing setting to copy " all project files", it worked. I am yet to actually discover whats was missing between the two publishing configuration for one to error out but wanted to post the solution now just in case someone runs into the same problem.
You need to include the mvc DLL's by opening your solution, opening the references folder, right clicking on each of them, get their properties and setting them to Copy Local = true. system.web.mvc system.web.routing system.web.abstractions those are the three i think
Did you deploy all the necessary assemblies? ViewPage and MasterViewPage are in the same assembly.
ASP.NET hostingEnvironment / shadowCopyBinAssemblies
Today I stumpled upon the shadowCopyBinAssemblies option in the hostingEnvironment tag. Appearently this attribute it is a web.config (system.web) configuration Boolean option indicating whether the assemblies of an application in the Bin directory are shadow copied to the application's ASP.NET Temporary Files directory. <hostingEnvironment shadowCopyBinAssemblies="false" /> A colleague had to enable this setting because (only) on his development machine he frequently got that ASP.NET error in the web browser: Cannot create shadow copy assembly file dll when that file already exists. compiling a specific web project in Visual Studio 2008 and openining a page. So now my question: can I preserve this setting in a production environment or could it harm performance and/or create other issues? Thanks!
I get this error from time to time, and usually doing Clean Solution followed by Rebuild Solution takes care of the problem. If this works for your colleague, then there's no need to play with the setting (especially in production).
Could not load type 'XXX.Global'
Migrating a project from ASP.NET 1.1 to ASP.NET 2.0 and I keep hitting this error. I don't actually need Global because I am not adding anything to it, but after I remove it I get more errors.
The reason I encounter this issue is because I change the build configuration. When I set a web project to x86, it changes the output path to bin\x86\Debug. However, the output path should be bin and the web server won't find the binaries because of this. The solution thus is to change the output path of the website back to bin after you change the build configuration.
There are a few things you can try with this, seems to happen alot and the solution varies for everyone it seems. If you are still using the IIS virtual directory make sure its pointed to the correct directory and also check the ASP.NET version it is set to, make sure it is set to ASP.NET 2.0. Clear out your bin/debug/obj all of them. Do a Clean solution and then a Build Solution. Check your project file in a text editor and make sure where its looking for the global file is correct, sometimes it doesnt change the directory. Remove the global from the solution and add it back after saving and closing. make sure all the script tags in the ASPX file point to the correct one after. You can try running the Convert to Web Application tool, that redoes all of the code and project files. IIS Express is using the wrong root directory (see answer in VS 2012 launching app based on wrong path) Make sure you close VS after you try them. Those are some things I know to try. Hope one of them works for you.
I've found that it happens when the Global.asax.(vb|cs) wasn't converted to a partial class properly. Quickest solution is to surround the class name 'Global' with [square brackets] like so (in VB.Net): Public Class [Global] Inherits System.Web.HttpApplication ...
Deleting the existing global.asax file and adding a new one, clears out this error. This has worked for me many times.
If your using visual studio 2010 this error can occur when you change the configuration deployment type. The 3 types are x86, x64 and Mixed mode. Changing to mixed mode setting for all projects in solution should resolve the issue. Don't forget to delete the bin, Lib files and change the tempdirectory output if your an ASP.NET website.
This just happened to me and after trying everything else, I just happened to notice on the error message that the app pool was set to .Net 1.1. I upgraded the app to 2.0, converted to web application, but never changed the app pool: Version Information: Microsoft .NET Framework Version:1.1.4322.2490; ASP.NET Version:1.1.4322.2494
This one drove me completely insane and I couldn't find anything helpful to solve it. This is probably not the reason most people have this issue but I just hope that someone else will benefit from this answer. What caused my problem was a <clear /> statement in the <assemblies> config section. I had added this because in production it had been required because there were multiple unrelated applications on the same hosting plan and I didn't want any of them to be affected by others. The more correct solution would have been to have just used web config transforms on publish. Hope this helps someone else!
Changing the address's port number (localhost:) worked for me :)
I fixed this error by simply switching from Debug to Release, launch program (It worked on release), then switch back to Debug. I tried just about everything else, including restarting Visual Studio and nothing worked.
I had this same problem installing my app to a server. It ended up being the installer project, it wasn't installing all the files needed to run the web app. I tried to figure out where it was broken but in the end I had to revert the project to the previous version to fix it. Hope this helps someone...
In my case, a AfterBuild target in the project to compile the web application was the reason for this error. See here for more info
Removing Language="c#" in global.asax file resolved the issue for me.
In my case, I was duplicating an online site locally and getting this error locally in Utildev Cassini for asp.net 2.0. It turned out that I copied only global.asax locally and didn't copy the App_code conterpart of it. Copying it fixed the problem.
When you try to access the Microsoft Dynamics NAV Web client, you get the following error. Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 This error can occur when there are multiple versions of the .NET Framework on the computer that is running IIS, and IIS was installed after .NET Framework 4.0 or before the Service Model in Windows Communication Foundation was registered. For Windows 7 and Windows Server 2008, use the ASP.NET IIS Registration Tool (aspnet_regiis.exe,) to register the correct version of ASP.NET. For more information about the aspnet_regiis.exe, see ASP.NET IIS Registration Tool at Microsoft web site. try this solution https://www.youtube.com/watch?v=LNwpNqgX7qw
Ensure compiled dll of your project placed in proper bin folder. In my case, when i have changed the compiled directory of our subproject to bin folder of our main project, it worked.
Had this error in my case I was renaming the application. I changed the name of the Project and the name of the class but neglected to change the "Assembly Name" or "Root namespace" in the "My Project" or project properties.
Deletin obj, bin folders and rebuilding fixed my issue
I had this problem. I solved it with this solution, by giving CREATOR OWNER full rights to the Windows Temp folder. For some reason, that user had no rights at all assigned. Maybe because some time ago I ran Combofix on my computer.