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.
Related
I have a Visual Studio 2015 solution which consists of an executable and a series of DLL projects. All code is managed C# and running on Windows 10 64-bit.
One of the DLLs needs to load a resource specified by the application. The app provides the full manifest resource path and the DLL uses this to load it.
The resources are set as "Embedded Resource" in solution explorer. An example path would be something like "The.DLL.Assembly.subdir.resources.image.png".
The DLL uses the below code to load the resource.
var asm = Assembly.GetExecutingAssembly();
var resStream = asm.GetManifestResourceStream(path);
This works great! Well, that is if the resource in question is stored inside the DLL assembly which is trying to load it. We'd prefer, though, not to have to locate all the resources in this DLL assembly. We'd like the freedom to let the application locate them in any of the projects and just provide the path letting the loading DLL know how to find them. This would allow the app to better organize the resources based on which project "owns" them as opposed to being forced to put them all in the assembly which will actually load them.
Where I'm stuck is being able to load the resource if it lives in another assembly.
I've tried:
GetEntryAssembly(), this returns the executable assembly, but loading the resource fails even with the full path, it appears GetManifestResourceStream() will only look in that assembly
GetEntryAssembly().GetModules(), thinking I could somehow find the other assembly this way, but this returns a single entry, just the exe itself
Any ideas? I'm thinking there must be a way to load an embedded resource which lives in another assembly, but I haven't yet found it.
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.
I have a solution that includes several projects. A few are libs that are building dll's used in my main project in this solution.
My main project builds with output type console application.
This all works fine.
When i change the build output type to a class library (since i want to use this project as a plugin eventually). The project will still build, this time to a dll.
When i use this plugin in an application where i use it as a dll however, it will run up to a certain point where it's trying to load a type defined in an external dll (so NOT built by my solution) and throw the exception:
Could not load type 'externalinterface' from assembly 'externallib, version=3.0.0.0, Culture=neutral, PublicKeyToken=null'.
The dll's are all in the correct folder,etc.
Also worth noting, the plugin is tested in another location than where i built it. The executable still works on this location, the dll/plugin does not. Same amount of dll's in their folders etc.
EDIT: I already used ILSpy (dll inspector) to open the actual dll that is being referenced (so externallib in the errormessage) and checked if 'externalinterface' was present and it is.
EDIT2: RESOLVED! The program that loaded my plugin was loading the same dll that caused the exception. The dll it loaded was of another version than the one i loaded.
Check whether the type externalinterface is present in the referred dll.
You didn't include the details of the exception the application is throwing. However, based on the message you gave, it appears your assembly does not have a strong name. If the application attempting to load your assembly as a plugin does have a strong name, then .NET will require all assemblies loaded by it also have a strong name, so you need to configure your assembly to have a strong name before continuing.
Maybe some supported dll's which is used by the 'externalinterface' is missing in the target machine. In the target machine, check is all the necessary dll's are present in the output folder.
Or blindly copy paste all the dlls in the output folder from the machine where the code is working to the target machine where you have the problem. After this, if the code is working in the target machine, then try to analyze which supporting dll you are missed to copy.
I'm writing a WebService that references another managed DLL which then uses a third-party DLL. When I start debugging my WebService I get the following error:
Could not load file or assembly 'AForge.Video.FFMPEG.DLL' or one of
its dependencies.
As recommended in many other posts, I tried these steps:
Changed from AnyCPU to x86
Copied all DLLs to %system32% directory
But had no success so far. Any ideas?
Thanks, Matthias
Could not load file or assembly 'AForge.Video.FFMPEG.DLL' or one of its dependencies.
You are either copying the file(s) to the wrong place or not copying the correct files.
Get to the bottom of this by downloading Dependency Walker
You can then drag AForge.Video.FFMPEG.DLL into the application and it will tell you what is missing.
Also, determine the base directory for your application to ensure you are copying the files to the correct folder at runtime. You can do this by writing System.AppDomain.CurrentDomain.BaseDirectory to the console (or add it to your watch)
Also see this
I re-engineered the project structure in VisualStudio to get rid of the dependency to AForder.Video.FFMPEG.DLL. That helped. I found no other solution so far.
this may be a stupid question but when I add a reference to my project and set Copy Local to false (so it doesn't copy the dll to the working directory) I get this error:
Could not load file or assembly 'HtmlAgilityPack, Version=1.4.0.0, Culture=neutral, PublicKeyToken=bd319b19eaf3b43a' or one of its dependencies. The system cannot find the file specified.
All I want is to load the dlls from "(working directory)/dlls"
Is this even possible? And what am I doing wrong?
Thanks in advance!
References simply aren't resolved relative to the working directory of the process - they're resolved relative to the assembly which is trying to load them (or from the GAC of course).
It's not clear why you want to do this, but basically you should make sure the DLL is available in the same location as the executable.