I have a Referenced Assembly where CopyLocal = True, The file is present in the bin folder, but it is not being copied to Temporary ASP.NET Files when I run the solution from Visual Studio
The error message is the usual:
An error occurred loading a configuration file: Could not load file or assembly 'MyNamespace.Configuration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Solution / Actual Cause
There were a number of problems:
Problem 1: In order to load a configProtectedData Provider, at least in my environment - the assembly must be in the GAC.
The reason for this was revealed by the fusion logs. Although my web app could locate the assembly in the bin folder - the web server (IIS Express) also needs to load it and it was this part that was failing. Since the web server has no knowledge of my bin folder, the only place it can possibly get the file from is the GAC. Fusion shows that IIS Express was having-a-go at looking in Temp ASP .Net folders but I think that this might be some kind of fallback and in my case the shadow copy was indeed copying the assembly but to a different location (Temporary ASP.NET Files\root\4f27e88a\bfcf2f79\assembly\dl3\06324d99\85ff3c73_1943cf01) that IIS Express didn't know to look for.
Problem 2: Once I had the assembly in the GAC properly, (surprise) Typo. I had the class name wrong in the "type" attribute
The thought process to get to the Solution
First: Follow Ivan Niktin's debugging process, Second Fusion Logs are your friend
It makes sense that it is trying to load it from Temporary ASP.Net Files as this is an MVC Web Application.
What doesn't makes sense is that the Temporary ASP.Net Files location that is being searched is empty. If I add the assembly to the GAC then it loads fine, but this is not an option for my deployment scenario.
The Fusion Log shows as the first path searched:
LOG: Attempting download of new URL file:
///C:/Users/Rob/AppData/Local/Temp/Temporary ASP.NET Files/root
/4f27e88a/bfcf2f79/MyNamespace.Configuration.DLL
The other paths are:
.../MyNamespace.Configuration.DLL
.../MyNamespace.Configuration/MyNamespace.Configuration.DLL
.../MyNamespace.Configuration.EXE
.../MyNamespace.Configuration/MyNamespace.Configuration.EXE
When I view the content of the folder that is being searched for the DLL - It is empty!
There is only one namespace involved MyNamespace.Configuration - this is a new / nearly empty assembly with no dependencies other than System.Configuration in the GAC, the host project and referenced assembly are both using .Net Framework 4.0
The part of the application that is trying to load the affected assembly is:
<configProtectedData defaultProvider="DynamicFileConfigurationProvider">
<providers>
<add name="DynamicFileConfigurationProvider"
type="MyNamespace.Configuration.DynamicFileConfigurationProvider,
MyNamespace.Configuration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=aeecd94c462a579a"
SelectorKeyProviderName="HostNameSelectorKeyProvider"/>
</providers>
</configProtectedData>
Update:
Setting shadowCopyBinAssemblies to false had the effect of causing the binder to look at ../Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/... Rather than the previous IIS Express location
Intercepting the exception earlier did not provide any additional information, simply the same message that the file could not be found.
Referencing the assembly in another host, both console and web turned up no info, the assembly loads fine and the methods can be called.
Manually placing the assembly in the location in which the binder is looking for it also works - It seems to me that the assembly binder is looking in the wrong place. i.e. if shadowCopyBinAssemblies is false, then it should only look in the bin folder. if shadowCopyBinAssemblies is true then the shadow copy location should have my app's dll's as well as any that it references - it shouldn't be empty.
Basically, Temporary ASP.NET Files folder contains assembly copies to allow file updates in the bin folder. When the runtime loads an assembly, it becomes locked and thus you cannot update your assemblies on the server. To solve the problem, the runtime copies them into the "Temporary ASP.NET Files" folder.
I'd try to tackle the problem as following:
Try to disable show copying (<hostingEnvironment shadowCopyBinAssemblies="false" /> or http://msdn.microsoft.com/en-us/library/system.appdomainsetup.shadowcopyfiles.aspx) to check if the problem really relates to Temporary ASP.NET Files.
Try to get more details about the exception using "Break on exception" feature in VS or by using an exception handler. Check exception.Data and .FusionLog properties for more detailed information about the exception.
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler((x, y) =>
{
var exception = y.ExceptionObject as System.IO.FileNotFoundException;
if (exception != null)
// Retrieve exception information here
});
Try to load the problematic assembly in a separate project. Even a simple console app will be fine.
These activities will allow you to narrow cause of the problem.
Not sure about the cause in MVC application, but I encountered a similar kind of issue in my web form based web application where Referenced Assembly where we set to CopyLocal = True. My web project was referencing assemblies both from the GAC and a folder located in the relative path inside the solution.
I resolved the issue by
Removing all the assemblies that were referenced form the relative path
Manually deleted the debug and release folders in both bin and obj folders for all projects.
Added back the assemblies from the local path.
Re-build the project
And things started working. You should probably try these steps as well and this might help resolve the issue.
Related
I am currently working on a project which requires the use of a custom dll for authentication.
This dll is registered (so they told me) in the GAC of both the Production and Test environments.
The company policies state that you "shouldn't include the dll reference in your application's web.config file", that is, you shouldn't have something like :
<add assembly="" ....="" mydll=""> etc.
in your web.config, at least for this dll I am talking about. They say, since it's registered in the GAC, the application will load it anyway.
The problem is , if you don't add the assemby reference in your web .config , the application is not going to find it , no matter what they say.
Since I am sure the dll is actually registered in the GAC, my question is :
shouldn't the application be able to load the dll anyway , no matter if you add the reference in the web.config or not ?
I was convinced that, adding the reference to the project, the dll 's GAC location would be stored in the application's assembly so that the application itself would be able to find the assembly in the GAC , no matter what the working system is , given that the dll is actually registered in the working system's GAC .
But I must be wrong.
What is the real way it works ?
I tried deleting the <add assembly ...> entry from the web.config : I have a runtime error everytime I reference a method in the dll , in my test environment ; same thing happens in the Production environment;
shouldn't the application be able to load the dll anyway , no matter if you add the reference in the web.config or not ?
By the logic applications would load every assembly in the GAC when they start up, could you imagine how slow that would be? No, that's not how it works.
When you reference a DLL locally in your project, all you are doing is adding it into the manifest which tells the application to load it as part of your application. When the CLR loads, it would first of all check if there is an equivalent version of your DLL in the GAC, if one exists it will load that version, if not it would attempt to load the local version.
See How the Runtime Locates Assemblies
I am getting this error:
Could not load file or assembly, system could not find the file specified.
Images:
http://s30.postimg.org/4x936f6ch/error2.png
http://s17.postimg.org/41ta9aaj3/errro3.png
I have a solution built in .NET 4.0
In it I have projects that act as plugins. They use dlls and the issue is that one of the solutions projects dlls is being called, and that references the dll that is causing the issue.
I get no error when rebuilding etc just when the program gets to the part where it uses the dll that references this one.
I have also made sure that in the projects bin folder that it has the dll that it is complaining about.
I have opened the dll in reflector and I don't think it has any issues.
COuld someone point me to the next step to try with fixing this issue?
Thanks!
Couple of tips - hard to know if they'll help you:
Open the csproj file(s) in a text editor and see where the dlls are being referenced (GAC possibly)
If it's a signed assembly, make sure you've got a signed copy (if you've built an Open Source project yourself the signing will be lost)
Look at the references in Visual Studio - do you have Copy Local set to True and Specific Version set to False?
Look at you're App.config or Web.config - is there a binding redirect that failing to load
I remember reading a post about assemblies not being able to be unloaded - probably not an issue on this one but I think the trick was
to load the DLL in a separate AppDomain to keep it isolated - loadable
and unloadable.
I have deployed my website to the server and when I try to access it using URL, I am getting the below error
Could not load file or assembly 'Microsoft.Office.Tools.Excel.v9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I even added the reference to the above DLL but still getting the error. When I ran the code which is stored iin server using visual studio, It is working fine but I am getting this error when tried the same with URL
Please help
References only act as paths to DLLs. If you add a reference to a DLL, and the host machine does not have it. You'll get the expected exception.
The DLLs must be present somewhere on your server.
I believe you can install Microsoft Office Tools on your Server.
If not, you can copy the DLL you're referencing to a folder that will be deploed with your application. You'll also need to remove the reference and re-add it using the path local to your application for this to work.
I've created a new Silverlight 3 from template and started a debugging session. However, when I looked to the modules window I saw the following:
The path to my Silverlight3Application.dll was lacking (even though the pdb was found just fine). I made sure that it isn't just a UI issue, indeed I could delete the Silverlight3Application.dll file that was located next to the PDB just fine without any issues.
Questions:
Where is my DLL actually loaded from UPDATE in runtime?
Why isn't it loaded from the expected location?
Is it possible to make it load from the location next to the PDB file, where I actually expected it to load from?
Update 1
What I really need is to find out the location of my Silverlight3Application.dll in runtime, using Reflection, for example.
However, just as the modules window hides the real location, so does reflection:
Assembly: {Silverlight3Application, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null} System.Reflection.Assembly {System.Reflection.RuntimeAssembly}
FullName: "Silverlight3Application, Version=1.0.0.0, Culture=neutral,
publicKeyToken=null" string
ImageRuntimeVersion: "v2.0.50727" string
IsDynamic: false bool
Location: "" string
I've tried located this assembly manually using Prcocess Explorer and its location seemed rather random:
C:\Users\Vitaly\AppData\Local\assembly\dl3\G1KDTYO5.XJ3\6GQ19BER.4OW\5e5cbf28\50366acf_1a3ecc01\Silverlight3Application.dll
Anyone knows how I can find the location of the assembly in runtime? If nothing else works, using external tools is an option, however, I must be able to execute the tool from code. I'll be happy to hear ideas.
Thanks!
By default, Silvelight DLL is located in \Bin\Debug of your Silverlight project.
If you want to see where an actuall DLL is loaded from:
output path is visible in Visual Studio Output Window during build
use ProcessMonitor.
Also see http://msdn.microsoft.com/en-us/library/cc838164%28v=vs.95%29.aspx for detailed description of Silverlight project structure.
To your Update1: see How do I get the path of the assembly the code is in?
Have you considered how the assembly is actually executed in your browser? It comes from a .XAP file, not via any DLLs built/stored under your project folders. More specifically, your project builds a DLL, which is then packaged into the XAP file, which is in turn served to your web browser, which unpacks the XAP file, reads the manifest, and loads the specified DLL entry point.
The path to the DLL from the XAP root is, well, the file name (unless you've done customized the XAP yourself). That's probably why there isn't any path specified.
When I run my project it's just fine and later suddenly when I run I got this error.
Because I no longer use it I remove the reference of all glimpse file and remove them from nuget pacakges too.
I have remove all configure Glimpse have set but I still got the problem. How I can resist this issue.
Could not load file or assembly 'Glimpse.Core' or one of its dependencies. Access is denied.
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Glimpse.Core' or one of its dependencies. Access is denied.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'Glimpse.Core' could not be loaded.
I just had the same issue after removing Glimpse from a web project. The problem was that 2 Glimpse dlls (Glimpse.Ado and Glimpse.EF6) were still in the BIN folder of the website. If you remove them, your website will run again.
You have probably another program running that is using the same assembly.
Edit:
You could try to remove all references manually by opening the .csproj files in a texteditor and removing the Reference tag where the Include is glimpse. It looks like it though that there is still an assembly with a reference to this glimpse. Are you sure you removed all references and rebuild all dependencies?
I run into this problem when there was a common project referencing Glimpse.Ado.dll used by two web projects, and only one of these web projects was configured for glimpse (the web for UI). The other web project (web service project) did not need glimpse, but since it was referencing the same common projects from the solution, it got involved into glimpse as well. What helps is just add the reference to Glimpse.Core.dll also to the second web project that does not need it.