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
Related
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.
I'm trying to get the source of this project to build and run on my computer (64-bit, Visual Studio 2010 Ultimate (though I believe my copy of VS is 32-bit, and the Zune software is, of course, 64-bit)). The solution comes with several projects, but I'm only concerned with ZuneLcdApi and ZuneLcdApiDebug. If I try running the debug program, I get XamlParseException. I Didn't even want to bother with that, so I started my own project in the solution. All my program does is ZuneLcdApi.Launch(), but it doesn't work. I get "Could not load file or assembly 'X, Version=4.8.0.0, Culture=neutral, PublicKeyToken=(some characters)' or one of its dependencies. The system cannot find the file specified." where x is one of the ZuneLcdApi dependencies (UIX, ZuneDbApi, or ZuneShell).
Anyone have any ideas? The project is sort of old so I don't know if I'll be able to reach out to the developer. I'll try, but in the meantime, I'd really like to know how to start using this API, because it's really incredible.
-edit-
I tried a different computer, and now the debug wpf application works fine. But still, my own windows form c# application gives me "Could not load file or assembly 'UIX, Version=4.8.0.0, Culture=neutral, PublicKeyToken=ddd0da4d3e678217' or one of its dependencies. An attempt was made to load a program with an incorrect format." How come it can't be found in my project but it can be found in the debug program? They both get copied to the exact same directory!
Figured it out. It was x86 instead of any cpu. I had to go into build>configuration manager to switch the project over. Once I did that, it was smooth sailing.
I've tried many examples that use Pechkin and Pechkin.Synchronized but can't get it to run, because all the times, I get the following error.
An unhandled exception of type 'System.TypeLoadException' occurred in mscorlib.dll
Additional information: Could not load type 'Pechkin.GlobalConfig' from assembly 'Pechkin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
I'm using x64 Windows 7 Home Basic with VS2012 Express for Desktop and the csproj is configured to build for x86 target and installed Pechkin and Pechkin.Synchronized from using nuget PM.
The last code I tried was from here
It has been a while since you asked this question and you've already fixed your issue, but maybe it'll help someone else.
You should probably try implementing TuesPechkin instead. This is a fork of Pechkin solving many issues (Pechkin issues) and using the latest version of WKHTMLTOPDF. The developer is quite active and will probably solve any bug you may find.
I think the problem was the name of my C# Console project, it was Pechkin. When I changed it to PechkinTest, System.TypeLoadException did not arise.
Anyways, thanks.
I also got the same problem and i changed my project name from Pechkin to some other name and the problem solved !
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.