I have created a new Service Fabric application in Visual Studio 2017 (version 15.7.1) and added a new service using the .Net Core 2.0 Stateful Service template.
When I try to run the service it fails to start correctly and I can see the following exception in the Diagnostic Events:
Description='Replica had multiple failures during open on _Node_0.
API call: IStatefulServiceReplica.ChangeRole(P);
Error =
System.IO.FileNotFoundException (-2147024894)
Could not load file or assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
The system cannot find the file specified.
I fixed this by installing the Nuget package System.ServiceModel.Primitives:
PM> Install-Package System.ServiceModel.Primitives
An answer which may be useful after a Windows 11 update.
In my case, after an update of Windows 11, the application wasn't working because of this error. I had the error Could not load file or assembly System.ServiceModel, version 3.0.0.0.
After long research, I uninstalled the .net framework and re-installed it and it worked.
For this, I used the programs/Uninstall a program/Add remove windows features.
Unchecked all .net framework cases and click on the Okay button.
After the uninstall process, I checked the same cases and click on the Okay button.
Bingo!
The System.ServiceModel.Primitives has what I think is a rather odd bug. If you are using a DLL with a System.ServiceModel.Primatives dependency, then you must also install it as a reference in the project that is using that DLL. If you do not the DLL will not know where to find it and you get the dreaded "could not load file or assembly..."
As Ragtimewilly indicated you can easily add the reference through Nuget.
There may be a better way to do this - but adding it through Nuget will do the trick.
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.
We're trying to set up a Jenkins (build server) job to build our Office add-in based on VSTO. However, I keep getting a strange error that fails the build process after the DLL is copied to the bin directory of the project:
Error 11 The "FindRibbons" task failed unexpectedly.
System.IO.FileNotFoundException:
Could not load file or assembly 'MyAddIn, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies.
The system cannot find the file specified.
File name: 'MyAddIn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
So the problem is that the "FindRibbons" task, triggered by the Office add-in build target, has successfully identified the MyAddIn DLL as being an Office Add-In, but is not able to locate and load it!
Any ideas? I'd love to be able to debug the FindRibbons task directly but hooking into and debugging the compile process seems a little extreme...
Here are some observations:
In our build server's Fusion logs for binding the MyAddIn assembly it looks like it's looking in the folder where MSBuild.exe lives (C:\Windows\Microsoft.NET\Framework\v4.0.30319\) and nowhere else.
On my dev machine, there is no Fusion log entry for MyAddIn! But the build process succeeds and Kivo works fine.
On both my dev and build machines I also have Fusion log entries for WhereRefBind!Host=(LocalMachine)!FileName=(PresentationCore.dll) and ExplicitBind!FileName=(MyAddIn.dll) which show the binding succeeding.
This error comes up on the build server whether I use Visual Studio or MSBuild from the command line to build the project.
I've ensured that the .NET/MSBuild/VS2012 versions are identical on both my dev machine and the build server and the error still occurs. The only difference seems to be that the build server is running Windows Server 2012 (since it's Azure, and we can't spin up a Windows 7 image).
This has worked for me every time I upgrade Visual Studio - I don't use ribbons.
This worked for my solution, but use at your own risk:
Open the following file in an XML editor (make a backup first): C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets (the v10.0 part may be different for you, e.g., it might be v14.0)
Remove the following section:
<FindRibbons AssemblyName="$(AbsolutePathToCustomization)" TargetFramework="$(TargetFrameworkVersion)">
<Output TaskParameter="RibbonTypes" ItemName="RibbonTypesCollection"/>
</FindRibbons>
Replace all occurrences of "#(RibbonTypesCollection)" with the empty string ""
Save the file and restart the visual studio
If you migrated the project from a previous version of Visual Studio, be sure to remove the ExcelLocale1033 and SecurityTransparent attributes from the AssemblyInfo.cs file (as answered by Swati in this other question)
If the project still fails to build, it may be because your .csproj file has some references to msbuild's tasks of previous versions of Visual Studio. I suggest you to create a new empty Excel AddIn project, and uses the msbuild structure of the new project file as base for your project.
I had this problem. It was apparently caused because I changed the "Copy Local" setting on reference "Microsoft.Office.Tools.Common.v4.0.Utilities" from True to False. ISYN. (I sh*t you not)
I had upgraded a project from VS2012 to VS2013 and noticed that that reference was the only one set to "Copy Local = True". So I set it to false, because it was different. This caused the error. Changing it back to True solved it.
I had the same error message and finally found a fix. The problem stemmed from the VSTO project being targeted for .NET 4.0 (it seems this is the minimum for VSTO4), while also referencing an assembly built for .NET 3.5. The real culprit was that I had a class in the VSTO project deriving from an interface defined in the .NET 3.5 assembly that in turn derived from a .NET 3.5 library interface. i.e.,
using System.Xml;
class MyVSTOClass : IMy35AssembyInterface // This caused the error
class MyVSTOClass : IXmlSerializable // This compiled OK
using System.Xml;
interface IMy35AssembyInterface : IXmlSerializable
The fix was to update the .csproj to explicitly reference the older version of System.Xml.dll and System.Data.dll which would otherwise default to 4.0 and conflict with the 3.5 assembly references.
<Reference Include="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Data2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
<Reference Include="System.XML, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<!--<Aliases>Xml2</Aliases>-->
<HintPath>C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
<Private>False</Private>
</Reference>
For those who need to simultaneously reference both the newer and older versions of a DLL, note that it is in theory possible using:
extern alias XmlDll1
using XmlDll1::System.Xml
See http://geekswithblogs.net/narent/archive/2008/11/11/126940.aspx for more info.
This problem can also be caused by adding a reference to an unsigned assembly to a signed/strong named add-in project. In my case I added the RestSharp Nuget package and started receiving this error on build as soon as I referenced RestSharp in code. After some digging I noticed that RestSharp was the only unsigned assembly in the project references. If you have this problem, there are 3 possible solutions:
In the case of RestSharp, I found that there was a signed version available on Nuget - searched for "restsharp signed" and installing that solved the problem.
If you have access to the source code, you can configure Visual Studio to build a signed version of the assembly in the Project Properties page.
If you do not have access to the source code, you can sign the assembly with your own key by following these instructions.
I had the same error and none of the answers from the internet help me fix this problem. The reason why I was getting that error is because I was referencing an assembly of type Console Application. I changed that assembly to be of type ClassLibrary and I did not got that exception any more.
Also I would only get that exception when inheriting from a class that was located on my ConsoleApplication. It took me forever to figure it out.
May be a little late here, but I just resolved this for myself - after following numerous suggestions (via google) all of which did not solve my problem I manually went down the line. Turns out I had compiled a set of libraries with a dependent assembly with a lower version (not the latest). In my main project I also had a reference to this dependency but it was pulled via nuget and was at the latest & greatest version. For some reason VS.NET couldn't figure that out and would completely trip out and drop the error you posted. Once I updated the set of libraries to the latest version of the dependency all worked as normal.
The crazy part is - it worked fine initially and then out of nowhere the issue came about. Hope this helps someone along the way.
After enabling Fusion the output showed that it was looking for the assembly in the msbuild/ folder.
I just encountered this same situation today, futzing around for a bit, restarting VS and then rebooting my machine without any success. Than one warning popped out at me - One of my dependent assemblies was not strong named. Setting that assembly to be strong-named solved the problem.
I had the same issue, and even after reading KKG's answer I could not resolve mine.
It turned out to be much simpler for me, but not less frustrating and time consuming. I was working in a Win8.1 VM which does not ship with .net3.5 by default. My .net4 VSTO4 project was referencing an assembly that requires 3.5 somewhere. The same project compiled find on my other VM which was Server2008 and had 3.5 enabled.
In my case, the cause for this error was the mere existence of a field of a generic value type in the assembly (not kidding), e.g.:
class Foo
{
ImmutableArray<int> foo;
}
Workaround (if the additional indirection is acceptable performance-wise):
Wrap the value type in a reference type. This can be done generically with something like
public sealed class Box<T>
{
public readonly T value;
public Box(T value)
{
this.value = value;
}
}
then foo can be of type Box<ImmutableArray<int>>.
I have experienced this same issue with an add-in for Outlook.
The solution for me was to set Embed Interop Types to True on my reference to Office.dll.
This however caused the add-in to crash during startup with an Access Denied on Microsoft.Office.Interop.Outlook. I fixed that issue by setting Embed Interop Types to True on all references to Microsoft.Office.Interop.Outlook.dll as well.
This error can be caused by a clash of dependency versions. For example:
YourAddIn
-- OtherLibrary v1.3
-- BaseLibrary v1.0
-- BaseLibrary v2.0
If a newer version of BaseLibrary v2.0 is released and updated in your project, however this version introduce a breaking change in your other dependency OtherLibrary, you will see this exception because OtherLibrary is still trying to find the old methods that doesn't exist in newer assembly.
Update OtherLibrary with the latest packages will resolve this clash of dependency versions.
This can also happen if the Microsoft.Office.Tools.Outlook.v4.0.Utilities reference is set to <Private>False</Private>.
<Reference Include="Microsoft.Office.Tools.Outlook.v4.0.Utilities">
<!-- Required for FindRibbons task -->
<Private>True</Private>
</Reference>
I am using SAP crystal reports in my wpf application, I am getting this exception at the time of initialization
ExportOptions _ExportOptions = new ExportOptions();
this is the error I am getting "The type initializer for 'CrystalDecisions.Shared.ExportOptions' threw an exception."
and this is inner exception says
{"Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.":"log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"}
total inner exception including message is in this link
I tried to add the dll reference of the particular version, even though it is still showing the same issue. I am very worrying about this issue as I could not figure out the solution for a long time.
any help highly appreciated.
Thanks
Ganesh
My suspicion is that you don't have the runtime for CR installed correctly. A lot of people make the mistake and install the runtime using the msi installer instead of the exe. The msi does not integrate CR with VS, the exe does. As Raphael pointed out in his comment, this post has a very good thread and explanation by Ludek, who is one of the sharpest minds at SAP. You can download the exe here.
Hope that helps,
Chris
I had also faced same issue , i had change my projects Target framework to .NET Framwork 4 . you can change the same from project property->Application tab ->Target framework.
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