I'm working on an MVC3 project and receive the following error:
Parser Error Message: Could not load type 'GodsCreationTaxidermy.MvcApplication'.
Source Error:
Line 1: <%# Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.Core.MvcApplication" Language="C#" %>
The error I get is cannot load GodsCreationTaxidermy.Core.MvcApplication but in this screen shot the Core part isn't displaying in the error:
Does anyone have any ideas or a solution to this error?
Check that the project output path (project properties / Build) is set to bin and not bin\Release or bin\Debug
For some reason IIS (VS development Server or Local IIS) always accesses the libraries from the bin directory (and won't look up for subdirectories)
Your local web server is running different code than what you're actually working on. Ensure you have stopped debugging, stop your local web server, clean and rebuild as Peter suggested, double-check your global.asax and global.asax.cs, and try again.
If this doesn't work and you are using local IIS, try removing the site in IIS Manager and recreating it manually.
Try modifying your global.asax file (simple add a space somewhere) and re-run. this will force the built in webserver to refresh and recompile the global.asax file.
Also do a clean and rebuild - should fix the problem
This happens sometimes if you change namespace information (project or class level) after the global.asax is generated.
Right click on the Global.asax file and select "Open With" and then select "XML (Text) Editor with Encoding" (other editors may work as well, but this is what I use).
Then edit the "Inherits" section in the XML directive
<%# Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.MvcApplication" Language="C#" %>)
so that it matches the actual full name of your Application class. And that's it.
Another option is to copy off all your code from Global.asax.cs and then delete and create another Global.asax file (and then copy the code back into Global.asax.cs).
I closed and reopened visual studio and it worked.
I had to go to BUILD -> CONFIGURATION MANAGER and -- ahem -- check the box next to my project to ensure it actually gets built.
I had this issue today, and it took me a while to find the cause.
Basically, my main VS2015 project was including a sub-project which had been built using a higher version of .Net Framework.
Bizarrely, when you have this problem, VS2015 will happily report that the solution has built okay, but when you try and run the website, it just gives you that misleading error, suggesting that your Global.asax.cs file is wrong.
So, if you see this error, and Cleaning/Rebuilding doesn't help, open your Project's References tree, and check for exclamation marks.
Also, check your Output window for messages like this:
The primary reference "C:\Projects\Business Objects 4\bin\Release\BusinessObjects.dll"
could not be resolved because it was built against
the ".NETFramework,Version=v4.5" framework.
This is a higher version than the currently targeted framework
".NETFramework,Version=v4.0".
The solution, of course, is to right-click on your main project, select the top tab, "Application", and change the Target Framework version to a higher version which matches your sub-project.
It's annoying that Visual Studio 2015 will let you fully build and run Solutions which quietly contain this problem. It's asking for trouble..!
"BUILD -> CONFIGURATION MANAGER and -- ahem -- check the box next to my project to ensure it actually gets built."
That and going to the project folder in windows explorer, pressing options and unchecking the "Read only" checkbox helped.
I just encountered this on an MVC5 application and nothing was working for me. This happened right after I had tried to do an SVN revert to an older version of the project.
I had to delete global.asax.cs and then added a new one by right clicking Project -> Add New Item -> Global.asax and THAT finally fixed it.
Just thought it might help someone.
I was working on an older 'folder based' ASP.NET web project (which I loathe) - and found this to be my fix:
Create an App_Code folder (if you didn't have one already)
Move the Global.asax.vb file into the App_Code folder
The markup in Global.asax can leave out any namespaces (at least, for this style of project, afaik):
<%# Application Codebehind="Global.asax.vb" Inherits="MyApp" Language="VB" %>
...where "MyApp" is the name of the class being defined in Global.asax.vb
Delete the .vs directory from the solution root. Clean. Rebuild.
This issue drives me bonkers once in awhile and I inevitably end up here paging through answers. I suspect there are multiple causes that can produce this exception, this once works for me.
You can also check your site's properties in IIS. (In IIS, right-click the site and choose Properties.) Make sure the Physical Path setting is pointing to the correct path for your application not some other application. (That fixed this error for me.)
Empty the bin folder. Build all the dependent class libraries and refer them in the main project, and build the complete solution.
Source
I have to report that I tried at least 4 suggestions from this post. None of them worked. Yet I am happy to report that I recovered by retrieving from back up. Only had to update my last code changes from log file. Took less then 10 minutes. Spent 3 times that reading this post and trying other suggestions. Sorry.
It was a very weird error. Good luck to anyone else encountering this gremlin.
I have same problem when I have 2 instance of Visual Studio running same project. So I closed both Visual Studio and opened only one instance and It works fine now!
This issue I was solved by giving right permission of the folder as well as check from IIS.
I was given permission to everyone as I am testing in my local environment. But in publish mode I think we give only permission to ASP.Net user.
I too faced the same problem. Despite of following every Answer it didnt work.
Then I changed the "Inherits=namespace.class" to "Inherits=fully qualified assemble name" i.e "Inherits=namespace.class,assemblyname, Version=, Culture=, PublicKeyToken="
Hope it helps.
This can also happen if you accidentally forget to set your VS solution to "Multiple Startup Projects" if you are running a Web and WebApi from the same solution.
You can check this by right-clicking on Solution in the Solution Explorer and select 'Properties". Then look for 'Startup Projects'.
I spent multiple days on this issue. I finally got it resolved with the following combination of suggestions from this post.
Change platform target to Any CPU. I did not have this configuration currently, so I had to go to the Configuration Manager and add it. I was specifically compiling for x64. This alone did not resolve the error.
Change the output path to bin\ instead of bin\x64\Debug. I had tried this several times already before I changed the platform target. It never made a difference other than getting an error that it failed to load the assembly because of an invalid format.
To be clear, I had to do both of these before it started working. I had tried them individually multiple times but it never fixed it until I did both.
If I change either one of these settings back to the original, I get the same error again, despite having run Clean Solution, and manually deleting everything in the bin directory.
The solution for me wasn't any of the above.
I had to delete (and not recreate) Global.asax and Global.asax.cs.
These files existed in the folder, even though they weren't referenced in the project.
Apparently the build still saw them.
Since I use OWIN with Startup.cs, the Global.asax file was obsolete and there was no issue with deleting it.
Yes, I read all the answers. However, if you are me and have been pulling out all of what's left of your hair, then try checking the \bin folder. Like most proj files might have several configurations grouped under the XML element PropertyGroup, then I changed the OutputPath value from 'bin\Debug' to remove the '\Debug' part and Rebuild. This placed the files in the \bin folder allowing the Express IIS to find and load the build. I am left wondering what is the correct way to manage these different builds so that a local debug deploy is able to find and load the target environment.
I also got the same error...check the name of the Application you developed properly ie. the namespace and the assembly name alloted and also try physically changing the name of the folder created for the application, all of this should be same as the name in the above namespace present in the file global.asax
I also got the same error...check the IIS Configuration of your Virtual Directory and be sure that Properties - ASP.NET - ASP.NET Version is the same of Project Properties - Application - Target Framework. (That fixed this error for me.)
My app was built in an older version of VS, and didn't have a bin folder. I had upgraded it to a newer version, and had a nightmare getting it to deploy. I finally tracked this error down to the Project > Properties > Application. The Target Framework was set to 2.0; changing it on the server to match in the IIS Manager/App Pool solved the issue for me.
I found that changing the Namespace on the project, without refactoring that across the whole solution was my problem. Check your project Properties and see what your namespace is, ensure that lines up, across the board.
The problem for me is that I didn't include global.asax.cs in my project. And because I was copying files from a .net 4.5 to a 4.0 I didn't comment out lines that are not needed in 4.0. Because it was not included visual studio compiled it anyway without issues. But when I included it, it highlighted the lines that cause problems.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
//using System.Web.Http;
using System.Web.Mvc;
//using System.Web.Optimization;
using System.Web.Routing;
namespace YourNameSpace
{
public class WebApiApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
//GlobalConfiguration.Configure(WebApiConfig.Register);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
//BundleConfig.RegisterBundles(BundleTable.Bundles);
}
}
}
I spent literally a day trying to resolve this.
The only thing that worked was deleting the .sln file, creating a new one, and adding the projects back in one by one.
¯\_(ツ)_/¯ - Programming - ¯\_(ツ)_/¯
For my case, the web assembly was part of GAC... so after build, it need to installed in GAC and it worked.
I encountered this error message and eventually discovered that the error message was misleading. In my case there appears to have been a routing issue in IIS which caused the global.asax from another site on the web server to be read thus generating the error.
In IIS, my site was bound to http:*80:webservices.local and contained an application called MyAPI. I received the dreaded message when calling the MyAPI application using the web server's ip address.
In order to successfully call my application I had to add a host file entry for webservices.local on all of the machines that called the MyAPI application. Then all of my requests had to be prefixed with http://webservices.local/MyAPI/ in order to route correctly.
I tried absolutely everything here and nothing worked. My project was in VS 2013. I have since upgraded to VS 2015 and have been creating all of my new applications in 2015 but loading, compiling, building etc all of my old apps that were built in 2013 in that version.
I ended up just loading the solution in 2015 and it resolved it for me.
Background: I have a DLL I created that includes 2 c files. These c files reference a third c file which defines a user defined type (we'll call it class_pointer), which is a pointer of type class.
E.g.
typedef class pointer_class *class_pointer;
then defines the class:
typedef class pointer_class {..}
pointer_class has various variables and functions associated with it that the original 2 c files make use of through class_pointer.
I am using this DLL in an ASP.NET C# web application. I am using PInvoke to import the functions into the dll. However, when I go to call on these functions that involve the class_pointer, the website running on IIS hangs. This does not happen in the VS debugger. If I comment out said class_pointers, everything runs smoothly -- I have access to the DLL and everything.
I have tried changing the permissions on all the DLLs included in my bin directory (just to be safe) for NETWORK SERVICE to have read/execute permissions. The dll will work without the class_pointers, so I don't think it is an issue of permissions. Does anyone have any advice on what might be causing IIS to hang when these class_pointers are involved?
I finally was able to figure this out with the help of Microsoft's debugging tools.
The class_pointers were written by another developer that has since left the place I work. In the pointer_class, there was a function to get the current application path. When running on the web, this was set to the inetsrv directory in SYSWOW64 (The machine I was running on was a 64bit machine). To solve the issue, we set the application path to the website when we are running the web, rather than where the .exe application was running from (SYSWOW64/inetsrv).
Because the application path was wrong, the native dll was unable to load some files in and was putting up popup warning messages. These pop up messages were waiting for a user response and since we couldn't get one on the web, the application hanged!
Hope this helps someone else out there!
I created the ASP.NET dll with one function that i need to use in Classic ASP page.
I used the below code for creating object in classic asp page
set PeopleSoft = server.createobject("OPS.PSL")
I am getting the below error while executing
Server object error 'ASP 0177 : 80070002'
Server.CreateObject Failed
I searched in stackoverflow i saw some solution. By enabling the "Make assembly COM-visible" and "Register for COM interop".
Please Help me to come out from this issue
You have to register your DLL first, and if the problem persists, do this:
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\
FeatureControl\FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701
Note If the FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 subkey does not exist, you must manually create it. If you're using a 64 bit OS, you may need to use HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\ FeatureControl\FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 instead
Right-click FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701,
point to New, and then click DWORD Value
Type w3wp.exe to name the new registry entry, and then press ENTER.
Right-click w3wp.exe, and then click Modify.
In the Value data box, type 1, and then click OK.
After setting this registry key, a simple app pool restart will apply the change. No longer will your .NET COM components randomly stop working with no real solution except shuffling application pools!
Did you register your dll with regasm.exe on your server ?
http://msdn.microsoft.com/en-us/library/tzat5yw6%28VS.71%29.aspx
I had this problem. When you register .NET COM modules you must use regasm and if you want to call them from applications like IIS you must use /codebase with this command:
regasm yourfilename.dll /codebase
I just had this error appear on a site that had been running perfectly for years. It seems a DLL had somehow become unregistered. It was an unmanaged DLL so I was able to re-register it using regsvr32:
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\regsvr32 "C:\path\to\myAssembly.dll"
(Also see the difference between regasm and regsvr32)
On this website :
http://connect.microsoft.com/VisualStudio/feedback/details/294241/kb937143-breaks-asp-to-net-com-interop
They fix the problem with giving read access to IUSR on HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones.
Run this from the command prompt (replace myassembly.dll with your assembly path):
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\regasm.exe myassembly.dll /codebase
I faced a similar issue and after much research i found the solution ,check if its working for you.
Remote scripting causes tons of errors with different IE versions. If your are passing control from one page to another and creating a new object from there you will get this kind of unable to create object error.
Example:
page x.asp--
function1call()
function2call()
further in page x.asp--
function1call(){
var rs_obj = RSGetASPObject("some-object");
----some other things---
frmPost.action = "someplace.asp";
frmPost.submit();
}
function2call(){
var rs_obj = RSGetASPObject("some-object1"); //you wont be able to create
//this object
----some other things---
}
It seems like the remoteScripting object is not getting initiated . As function1call() calls frmPost.submit().
If you combine these 2 functions it will start to work. I.E
page x.asp--
function1call(){
var rs_obj = RSGetASPObject("some-object");
var rs_obj = RSGetASPObject("some-object1");
----some other things---
frmPost.action = "someplace.asp";
frmPost.submit();
}
There is another reason you might get the error "Server.CreateObject Failed". A COM Visible DLL does not behave the same as a regular .NET DLL when it is being loaded by COM. You can't expect it to load other DLLs that are sitting in the same directory as your DLL, or downloaded through the Nuget package manager. If you want to load other DLLs you have to register them in the global assembly cache (GAC).
see: https://stackoverflow.com/a/23902131/2616170
If the assembly doesn't have a strong name then you won't be able to register it in the GAC.
Going mad here.
I'm new to windows dev and I have registered my dll in the GAC.
I get a message saying "Assembly successfully added to the cache" and I can do a
Gacutil /l "its name" and see it there
But when I try to instatiate it in Classic asp like so:
Set TemperatureComponent = Server.CreateObject("comInteropTutorial")
I keep getting the error:
"Server object: 006~ASP 0177~Server.CreateObject Failed~800401f3"
which I believe means it can't find it?
I have also tried to do the same things for other components that were already in the Global cache like:
Set TemperatureComponent = Server.CreateObject("XamlBuildTask")
and the same thing happens.
Before adding the dll to the GAC, I did the following:
I compiled the dll in Visual studio 2010 and did the following:
Click on project
Application - sign the assembly
Build - register for Com interop
Signing - sign the assembly use a file that you have created using sn command (sn –k )
I'm truely stuck now, can someone recommend anything?
I'm on windows 7 here, dunno if that matters... 64 bit 32 bit etc?
I'd happily step through a process that helps me determine the cause of this problem if anyone can recommend one?
Looks like it is answered in another post: Accessing a .NET Assembly from classic ASP
...make sure your .Net assembly is set to
be COM Visible.
In Visual Studio, does the component show up in list of objects under the 'COM' table if you try to add it as a reference? Does the assembly depend on other assemblies or DLL's?
Just a guess here, sounds like either the regasm step is missing which adds the appropriate stuff to the registry, or in my case recently, IIS was running in 64bit, but the assembly was compiled for 32bit.