I have a Biztalk application that is basically a housing for a schema that other applications are using. I now want to remove this application, but am unable to from the BizTalk Server Admin Console, when I right-click --> Remove I get an error that says
Could not load file or assembly <assembly_name>.dll or one of its dependencies. The system cannot find the path specified (mscorlib)
followed by:
The system cannot find the path specified (Exception from HRESULT: 0x80070003)
So I go to remove the assembly from the Application and get the exact same error. I remove all references to it in other biztalk resources and still the same error when trying to delete the application or resource. I did notice that in the Modify Resouces dialog of referencing assemblies, this rogue assembly is listed as a dependency status of Not Found.
The strange thing is, when Messages come through, the resources which depend on the rogue assembly, still work fine and no errors are thrown (despite them using components of the assembly which shows as Not Found).
I have made sure to check the GAC and the assembly is loaded to it.
So now I have to ask:
where is Biztalk actually looking for this assembly?
is there a way I can just force a deletion of this application?
why does it care if the assembly is not found, when I'm trying to delete it?
why does it show as Not Found, yet still work?
Thanks.
I think the key is "or one of its dependencies." If it's a dependency it may be using the standard windows mechanism for finding a dll. It searches the current directory and the windows directory for them.
"where is Biztalk actually looking for this assembly?"
Look in the 'resources' section of your application in the biztalk management console. It shows a column with the location of the assembly.
I'd stop all the host instances/orchestrations, and then unload all your stuff from the GAC - if messages are actually still going through then stuff is still loaded that is using your schema.
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 have a web project called "TestResourceApp" with Labels.resx in App_GlobalResources folder. I want to add another language by creating a satellite assembly.
Here are the steps I took to create the satellite assembly. The default text always get displayed. What did I do wrong ?
1) Create Labels.fr.resx in a different folder.
2) Generate resource file:
Resgen Labels.fr.resx TestResourceApp.App_GlobalResources.Labels.fr.resources
3) Generate satellite assembly:
AL /t:lib /embed:TestResourceApp.App_GlobalResources.Labels.fr.resources /out:french.dll /c:fr
4) Copy french.dll to TestResourceApp/bin/fr
I have uiculture set to auto in web.config and I have change the language on the browser.
I was able to use this page to solve some satellite assembly issues I was having. I'll throw in a few more things to check.
It's helpful to decompile the "neutral" assembly and see how it's put together. A tool like ILDASM.exe is helpful for this purpose. Once you get it decompiled, look through the text output for ".mresource", and you should see one with your naming. For example, if you add a resource to a Visual Studio project, they're named MyAssemblyName + ".Properties.Resources" + a language (if any) + ".resources" Examples:
MyAssembly.Properties.Resources.resources (neutral language)
MyAssembly.Properties.Resources.en-US.resources (English (US))
In my case, I had the file named properly, and in the appropriate folder (such as Bin\en-US). I was able to verify that much by using ProcMon.exe (by the SysInternals guys) and could see the worker process finding and reading in my DLL file (instead of just saying "PATH NOT FOUND"). However, it was not finding the resource by the name that it expected it to. That's when some disassembly helped to get to the bottom of the naming problem.
So, use ProcMon.exe to narrow down the kind of problem you might have. Hopefully that's helpful to someone.
It's complicated but here are a few tips for those who run into this problem:
Try to include the resx in the web project and let VS do the job for you.
Reflector is your friend. Compare satellite assemblies you created and those created by VS.
If you web app is targetting ASP.NET 2.0, you should use Resgex and AL that come with .net 2.0. Open the assemblies in Reflector and check the "references". It should reference mscorlib version 2.0.
If you deploy your web app using web deployment project, make sure the namespace for the resources in your satellite assemblies is correct. Again, compare with what VS creates. In my case, I used the wrong tool to generate the designer.cs file because I wanted them to be accessible from a different assembly. Make sure you are using GlobalResourceProxyGenerator. Otherwise, the namespaces won't match and the deployment code will not be able to find your resource. The namespace in the designer.cs should simply be "Resources", not "XXXX.App_GlobalResources"
Did you have set enableClientBasedCulture to true in globalization ?
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.
I have a local website which I run through Visual Studio 2008's internal development web server (through the run / compile button).
I have an external library which is referenced on a page of that website and resides inside the web site's "bin" folder.
I've recently changed a class' property name inside that library (renaming it, from "ValidFrom" to "VisibleFrom"), recompiled its dll and have overwritten the original dll inside the bin folder.
This class is mapped with FluentNHibernate, I've also changed the mappings and recompiled / redeployed the library.
When I try to run the site and navigate to the page where the library is used, I'm getting a MethodNotFound exception for the method get_ValidFrom, related to FluentNHibernate's configuration call. This should be get_VisibleFrom now!
Now I've reconfigured my NHibernate SessionProvider so that it generates a new Configuration for NHibernate on each call, and does not retrieve it from the Http Session entity like it did before, because I figured there might lie the problem.
I'm still getting the exception however. I've then deleted the Temporary ASP.NET folder's content... but I'm still getting the error.
Where is the generated schema for NHibernate stored, when using FluentNHibernate?
Anyone knows where else this could somehow be cached?
Thanks
FNH does not cache the schema, it is generated on-the-fly when you make a call to Fluently.Configure() and the schema is passed directly into an NHibernate Configuration object which is used to build an ISessionFactory.
Try clearing out all compiled objects/libraries/executables, removing the reference to your library from all projects that use it, add it back in, and then re-compile everything. Also check your all your code for "magic strings" that may be referencing this property or causing it to be referenced by the old name.
If that doesn't work, it might be helpful to see a stack trace to get an idea of what is being called from where.