I have an Azure Function (.netstandard 2.0) that fails to run because of FileLoadException. Normally I would use Fuslog to find out which dependency is missing but I have not found a way to RDP the machine running my Azure Function. Right now, through various logs, I only get the following information:
System.IO.FileLoadException : Could not load file or assembly
'Microsoft.WindowsAzure.Storage, Version=9.1.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific
file.
I can see that the right version of the file is actually there via Server Explorer. So it seems to be a dependency issue.
How can I debug this?
Basically your Function App is a plug-in which gets loaded into runtime. Runtime has its own dependencies, and if you happen to use the same dependency but of higher version, you get a runtime error.
WindowsAzure.Storage is definitely in this list.
For runtime v1 the most reliable way to figure out the exact versions is to look into this file, just search for the package in question.
Runtime v2 doesn't have it yet.
Then downgrade your reference to the same version.
A better solution is discussed in this issue.
Related
I've been struggling with a problem in Unity and I would appreciate it if anyone can help me.
I'm using a package called DarkRift, which is used for networking and connecting clients with a server (provided by DarkRift). In order to work with the DarkRift server, I need to write plugins. A plugin is basically a visual studio project, compiled to .dll file, then that file is copied to a certain directory on the server-side.
I've been working with DarkRift for some time now and have done so much with it. It was working perfectly! However, I needed to work with Firestore package from Google.
Hence, I created another plugin, installed Firestore (and every package needed), wrote some simple code using one of Firestore's functions, compiled the project, copied .dll to the server, then ran the server. The problem is whenever I run the server (.exe file), I get an error that says: "Could not load file or assembly 'Google.Cloud.Firestore, Version=1.0.0.0, ...' or one of its dependencies."
I get this error when I use any of Firestore's functions. However, if I just include the package (using Google.Cloud.Firestore;) without using any of its functions, I don't get any error. I googled this problem and looked everywhere and could not solve it.
Thanks!
Firestore is distributed as a Nuget package, which indeed has dependencies.
Have you also copied all those dependencies to the server?
It might also be a framework incompatibility.
To get more details about this kind of problem, you can register a logging event handler on AppDomain.AssemblyResolve, which fires when assembly resolution fails.
You can also use tools like dnSpy to dig into the problematic assembly - it shows you all sorts of metadata and it can decompile the CIL, which is invaluable for debugging strange behavior in third party code.
Assembly loading is kind of slow in .Net, so it only loads them when needed.
Hence the resolution does not fail when no code references the assembly.
I have a project which ran fine as an Azure Function in v1 of the Functions runtime, but I'm busy rewriting it for v2 and I'm stuck.
My Azure Function relies on a library of mine, which in turn depends on another library. Both libraries depend on the Open XML SDK, which I've installed in those projects via NuGet. They both also have System.IO.Packaging installed via NuGet.
If I run my code through a console app, it runs fine. When I try to run it as an Azure Function, it gets partway through my library code but then the functions runtime falls over with the error:
System.Private.CoreLib: Exception while executing function: getWorkbook. ExcelGenerator: Could not load file or assembly
'System.IO.Packaging, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file
specified.
I've tried adding System.IO.Packaging to the Azure Function project (which I realise I ought not to need to do) but it then falls over with a new error:
System.Private.CoreLib: Exception while executing function:
getWorkbook. ExcelGenerator: Could not load type
'System.IO.Packaging.CompressionOption' from assembly 'WindowsBase,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
I'm suspicious about the 0.0.0.0 version number in the first error, and I really don't understand the second one (or honestly why adding System.IO.Packaging to the Azure Function makes any difference at all, given that this is just running compiled library code).
One other curious thing is that WindowsBase does not show up in the "Assemblies" dependency list for my Azure Function, but it does show up checked in the "add reference" dialog box. If I uncheck it, I get a mysterious error saying "No assembly reference with the name "{0}" could be found in the project".
I'm pretty sure somehow System.IO.Packaging or WindowsBase just isn't making it through to the Azure deployment, but I'm not sure how. I'm rapidly discovering that I don't know very much about how DLL dependencies work at all let alone in Azure - any ideas?
To rewrite v1 function to v2, right click on Function project, and Edit FunctionProjectName.csproj, change TargetFramework of Function project to netcoreapp2.1, AzureFunctionsVersion to v2.
And we may have to install packages for v2 function as they are not built-in any more as in v1.
Code refactoring is necessary, if we meet any assembly problem then, try the code in .Net Core console app to see whether it's a .net core problem or related to Function runtime.
If there're some configurations in host.json, need pay attention as some of their format has been changed.
Usually, creating a template v2 function and compare old content with new v2 template is recommended.
i made a while back an console application(in c#) which does a few powershell commands.
i connect to the (exchange)powershell with remote powershell.
but when the application runs;
RunspaceFactory.CreateRunspace(connectioninfo)
i get the following exception:
Could not load file or assembly 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
the only thing i cannot figure out is why it was working before perfectly. i searched my solution, nowhere i could find a reference to that dll. i also searched my c# drive it was nowhere to be found either.
i restored my solution from my backup of 2-3 months old and the same error.
Can someone give me some pointers to what is going wrong ?
Found the problem.
apparently something is wrong on my computer(I'm guessing after installing the Beta of VS11)
anyhow, after using the project on a different machine where VS2010 is installed it worked just fine.
The error message is misleading.
I had got the error, as I used the reference to the System.Management.Automation.dll Version 3.0.0.0 (which means PowerShell 3.0).
The issue is, the Exchange Server 2007/2010 isn't compatible with PowerShell 3.0, so you must bind the reference to the System.Management.Automation.dll version 1.0.0.0 (Windows PowerShell 2.0).
Check all project references
Check app.config
Have a look here
UPDATES
Have a look here
I'm just trying to get started with NDjango but am having issues running a basic test app. When running the page in either debug or release the following exception is thrown:
Could not load type 'Microsoft.FSharp.Core.CompilerMessageAttribute' from assembly 'FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
This is thrown when the NDjangoHandle is created in the HttpApplication ctor. The fsharp assemblies are definitely all there in the gac (and they seem to be distributed with NDjango too) so I'm a bit confused about this one. Googling this turns up zip.
I'm using NDjango 0.9.7.0 for .NET 4.0 in vis studio 2010
Cheers
Did you install FSharpPowerPack? I am not sure if it was stated clear enough in the installation package but it is required and it does not come with the standard installation.
Also - by any chance do you have a side by side installation of VS2010/VS2008? The FSharp installation package has a bug which can cause similar problems
Let me know if you need further help. You can communicate with us directly through bug tracker and/or mailing list
We code in C# using VS2008 SP1. We have a server that runs Team System Server 2008 which we use for source control, tasks etc. The server is also our build machine for Team Build. This has been working just fine for a long time. Untill now. We get these error messages when trying to build one of our projects that has a reference to one external assembly (this happens both via Team Build, and when logging on physically and doing a regular build via Visual Studio):
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
: warning MSB3246: Resolved file has a
bad image, no metadata, or is
otherwise inaccessible. Could not load
file or assembly 'C:\Program
Files\Syncfusion\Essential
Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'
or one of its dependencies. The module
was expected to contain an assembly
manifest.
C:\Program
Files\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2):
error MSB4062: The
"Microsoft.Reporting.RdlCompile" task
could not be loaded from the assembly
Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a. Could
not load file or assembly
'Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The module
was expected to contain an assembly
manifest. Confirm that the
declaration is correct, and that the
assembly and all its dependencies are
available.
The referenced component
'Syncfusion.XlsIO.Base' could not be
found.
These errors are for one project with one problematic assembly reference. When I try to build the entire solution there are of course many more errors because of this one. And there are two other projects that has the same problem with other assembly references. I have a list of the referenced assemblies that VS can't seem to resolve:
Microsoft.ReportViewer.Common
Microsoft.ReportViewer.WinForms
Syncfusion.Compression.Base
Syncfusion.Core
Syncfusion.XlsIO.Base
The Syncfusion assemblies are from a 3rd-party component package. The other two are related to the Microsoft ReportViewer component.
The references has been added via the Add Reference window, in the .NET tab, so I don't think there is anything suspicious about that. In the properties window for the assembly reference, there is no value in Culture, Description, Path, Runtime Version or Strong Name. Version says 0.0.0.0 and Resolved is False. I guess it is pretty obvious that VS cant resolve the reference. My question is why??? I've scratched my head a lot over this one. This only occurs on the server, the solution builds just fine on both my machine, and my coworkers machine. The assembly reference properties are fine on our machines.
I have tried uninstalling the 3rd-party component (on the server of course), and then reinstalling it again. Didn't help. I tried to repair the VS2008 installation. Didn't help. Tried to retrieve an earlier version from source control (that I know has buildt on the server before), and I got the same error messages. I have checked file permissions, and everything appears to be in order. I am running out of ideas...
How do I solve this?
Update 16.02.2009:
I have tried to compare ildasm output of the dll on my pc and on the server (see the comment I wrote about that), and there is one small difference in a line that to me appears to be a comment. I must admit that I don't understand why there is a difference at all, so maybe someone could explain that to me?
I also tried running a virus scan on the server. Didn't help. Tried to remove the reference and then readd it by browsing to the dll on disk. Didn't work.
Update 17.03.2009:
I've found the solution! The culprit was the TruPrevent module of Panda Antivirus. After disabling the module, everything works! =)
I discovered this with the help of fuslogvw.exe and the log it generated. Googled the result, and stumbled upon this blog entry.. Hope this can help somebody else to.
Almost certainly the problem is environmental - not source related.
Some ideas ...
(i) Try disabling your anti-virus/anti-malware tools - I've seen cases where these tools (particularly Trend Micro Antivirus, for some reason) can keep a DLL file locked after (during?) scanning, interfering with compilers.
(ii) Check your PATH environment variable. Even in these modern days, the PATH variable is used to resolve some things - if this is messed up (too long, maximum length is 2048 characters IIRC) then things can be odd.
(iii) You've checked File permissions - have you checked permissions in the registry? For example, SyncFusion installs its license key in both the User and Machine hives - if the build server can't read one or the other, could cause issues.
Good luck!
It could also be that the referenced assemblies are in the GAC on the dev machine, but not on the build machine. Get it out of the GAC, into your source repository, and reference it by path.
We've had the same problem, turns out the C drive was full (only had 28MB).
Freeing space resolved the issue, even though the build happens on D.
Do you see any differences between ildasm of this file
'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'
on your machine versus on the server?
My suspicion is that the user that the build process is under does not have access to the folder that your 3rd party control is in. Since this functions properly on your machines, it is almost certainly user/permission specific.
Your 3rd party dll may depend on unmanaged dlls. Often it's because a specific version of the VC++ Runtime Dlls are missing.
Open the Dll with the Dependency Walker http://www.dependencywalker.com/ on your server and check for missing references.
Not sure if this'll help in your case, but I did have something similar before where a dll apparently got unregistered somehow, and running regsvr32 on the dll did the trick.