EDIT: I found a way to get it to work locally, but on Azure I still get System.IO.FileNotFoundException on that assembly.
My question might seem like a duplicate to this question here. But it is slightly different, I have already tried that solution and it did not work. Here are the details.
I have an ASP.NET MVC App that has a Reference added to a third party CLR DLL. That third-party DLL requires a native DLL which it invokes. Now if I had control over where the Shadow Copying occurs and what is copied, I would be in paradise. The Shadow Copying misses copying that native DLL despite it's Build Action set as Content and Copy To Output Dir set as Copy Always.
So I searched internet and ran into this discussion on SO, which is same as what was mentioned earlier. I tried adding the code that sets the PATH Environment Variable inside Application_Init and Application_Start of Global.asax, I set the breakpoints in both the methods and to my surprise I get the ASP.NET Error Page before it even hits the breakpoint. This leads me to believe that the referenced assembly at the time of binding hits the native DLL and invokes it. What can I do? Can I delay the reference binding somehow?
EDIT: Yes we can, I opened the Referenced DLL's code which was written in Managed C++, I adjusted the linker setting to Delay Load the Native DLL and now my Application_Start executes first. Yayy! but that does not solve the same problem I am having on Azure
Here is the test solution with DLLs
Here is the source code for the Native DLL
Here is the source code for the Referenced Assembly that uses the Native DLL
To download the Native DLL distribution, Go to their distribution page, choose the windows archive with the bitness you desire (I am using 32-bit), and you will find amzi.dll inside APIs/bin directory.
Actual problem was the wrapper DLL not recognized on Azure server because of lack of support of earlier frameworks and toolsets, as well as Debug CRT.
I used XDT/Application_Start to set the PATH environment variable to include the location of my native DLL
I upgraded my Managed C++ Wrapper DLL to use Toolset 14.0 and .NET 4.6.2
Used Linker Setting of /DELAYLOAD on Managed C++ Wrapper DLL
After downloaded the DLLs and source code which you provided, I found that the native DLL depends on x64 platform. Firstly, we need to change the Platform property of our web app to x64 using Azure portal. If the platform button is disabled, you need to scale up your web app plan to Basic level plan or higher level.
In addition, the original path may end with “;”, so we need to check whether it contains “;” and append right content to it. Code below is for your reference.
string path = Environment.GetEnvironmentVariable("PATH");
Trace.TraceError(path);
string binDir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Bin");
Trace.TraceError(binDir);
if (path.EndsWith(";"))
{
Environment.SetEnvironmentVariable("PATH", path + binDir);
}
else
{
Environment.SetEnvironmentVariable("PATH", path + ";" + binDir);
}
To test whether the path is set successfully, you could add a page to test it.
public ActionResult GetPath()
{
string path = Environment.GetEnvironmentVariable("PATH");
return Content(path);
}
After path is set, the native DLL can be load successfully on my side.
On my end I added a throw new ApplicationException("Test") at the beginning of Application_Start and instead of getting my test exception, I was getting the DLL load error.
It means the setting path code will not executed. To fix it, you could remove the native DLL reference from your web application. Now your application could work fine and set the path environment variable. Then you could add the native DLL reference back.
Another way to do it is that we could create a webjobs and set the path environment variable in webjobs and deploy this webjobs before deploying your web application.
I am using 32-bit distributions, my native dlls depends on x86/32-bit.
If you use 32-bit distributions and the platform targets of your CLR DLL and your web application are set to "x86 or Any CPU", you won't need to change platform to x64 in web app. Please change it back to x86.
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.
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.
I am using a COM dll in my .Net web application. This works fine on multiple different machines.
However on one particular machine I get the following error:
Unable to cast COM object of type 'CServer.CApplicationClass' to interface type 'CServer.ICApplication'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CF0DFA28-046B-4C7D-8AA9-F4B7477D8CAE} ' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
I have registerd the dll using the regsvr32 command.
I have also created a COM+ application for this dll.
Running a search through the registry
I can find the key in numerous places.
I have also tried unregistering the dll and deleting all referneces on the computer to this dll. And afterwards re-adding the dll and re-registering it.
I have written a simple windows script file which tests the dll. This works fine. However the problem exists in my .net project which is running in iis.
Can anyone help me with this?..
If you need anymore info please leave a comment. Thanks.
I had a similar problem, with the "TYPE_E_CANTLOADLIBRARY" message.
Background:
I had a project which used Interop.ReferenceA.dll. This file was created using tlbimp ReferenceA.dll /out: Interop.ReferenceA.dll.
Solution:
When I took a look at ReferenceA.dll using RegDllView I noticed that ReferenceA.dll had a subclass, which was the IID shown in the error message.
I looked around in the source code of the subclass and noticed that it had a dependency to Interop.ReferenceB.dll.
Turns out that the subclass needed Interop.ReferenceB as a type-library to work. So I ran this:
regasm /tlb:Interop.ReferenceB.tlb Interop.ReferenceB.dll (the 32-bit version of regasm was used.)
And the error went away.
Make sure your AppPool is set to x86. Also make sure your assembly is targeting only x86.
I was having a similar issue. First got Access Denied, which after some looking around was resolved, only to be faced with this error message (TYPE_E_CANTLOADLIBRARY). Mind that I'm running a COM+ Component on Windows 7.
After some fruitless attempts which involved messing with the registry, my workmate and I found a way of getting it up and running:
1) Unregister your dll (regsvr32 -u dllname)
2) make sure your references to the dll are cleared up from registry (backup first)
3) Create an empty com+ application (server app) in Component Services
4) Copy the application id to the clipboard
5) go to "c:\program files (x86)\Complus applications" and create a folder with the id on your clipboard
6) copy your dll into that folder and register it
7) Go back to your Component Services and add the component to the app you created using the dll on "c:\program files (x86)\Complus applications{*app id*}"
that did it for me. Hope it helps.
I had a similar problem where the error was triggered on my PC but not on that of other developers.
It turns out that I had been testing an automatic build process on my PC that had updated the version number of the assembly, thus registering the TLB in the registry with a version number higher than the one we were normally using.
When trying to get the interface, the server was consistently using the wrong TLB information leading to the wrong assembly. Once I deleted the higher version entry in the registry, it worked fine.
Now we just have to ensure the build process is not going to cause that issue again. :)
I have several DNN modules that I wish to update silently, using the portal's built-in module upgrade facilities called from a separate application, in this case a Windows service. I was able to make it all work with version 4.3 of the portal by modifying the DNN source in key areas to allow DotNetNuke.dll to function outside of a web application. I'm now trying to do the same thing with the 4.9.0 source code and I'm having problems.
Everything works fine until DNN tries to read from the database. I have my Windows service project, the DNN library project, and several other related projects loaded in one VS solution (the additional projects are the same ones that are in the main solution file provided with the DNN source). I call PaInstaller.Install in my service to update each module. Execution gets to reflection.vb and then it tries to create a DotNetNuke.Data.SqlDataProvider object based on the type name. It raises an exception when calling System.Web.Compilation.BuildManager.GetType. The exception says:
Could not load type 'DotNetNuke.Data.SqlDataProvider' from assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I read this to mean it simply couldn't locate the DotNetNuke.SqlDataProvider.dll assembly. What's strange is that assembly is in the Bin folder for the DNN library project, and I also have it in the folder where my Windows service is running. The actual SqlDataProvider project is also loaded in the solution. I can't for the life of me understand why the runtime environment can't locate the assembly.
Has anyone tried something like this before, or know what could cause an assembly not to be found while stepping through the DNN source? Am I better off using something other than BuildManager.GetType to get an instance of the SQL provider type?
Chris,
Honestly depending on your needs, I would look at doing this a different way, as this is going to be very fragile with each DNN upgrade that happens in the future.
I'd look more towards using the "bulk install" option that DNN already has. Have your service upload the module zips to the /install/modules folder, then from there, call /install/install.aspx?mode=installresources and you are done!
If you need a third party solution to parse the results, have your windows service go through and pull the HTML response and parse it to validate success.