Related
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 have been scouring the internet for an answer on this and could really use the help.
I've already looked at other posts regarding this error and none of those answers helped me.
The full error is,
The type 'xxx' is defined in an assembly that is not referenced. You must add a reference to assembly 'xxx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
The solution builds fine locally, but the error occurs when I trigger a build on the build server.
Here's what I've done so far in an attempt to resolve this:
Ensured all project references are correct(Had an Architect review it
with me)
Changed the 'SpecificVersion' property to true
Removed the reference and added it back(In VS2012 and edited
the .csproj file itself)
Built solution locally on the build server, it passes
EDIT - I should also mention I have built this solution on two different build servers and still get the same error
I'm using VS2012 and TFS2012 to do this.
I would really appreciate any help, thanks.
*UPDATE:*I just did an MSBuild on the build server but changed the configuration to "Release" and was able to reproduce parts of the error. Some key differences though is that the version it's looking for is suddenly 1.3.1.15 instead of 0.0.0.0 and the PublicKeyToken is no longer null. Does anyone know what this could mean? The assembly's version is supposed to be 0.0.0.0.
So after putting in a few more hours with my Architect, we found the issue. Our developers had multiple copies of the same dll buried in various folders in our Source Control. One of the projects was referencing the incorrect .dll.
After fixing the references and removing the extra uneeded .dlls, the error is gone and our builds are finally working! :)
You mentioned that you tried building solution on the test server. Did you use visual studio 2012 to build the solution or did you actually run msbuild?
The accurate test would be to use msbuild similar to this:
MSBuild MySolution.sln /p:Configuration="Debug" /p:Platform="CPU Any"
You can actually get the exact command by looking at the build logs for TFS Build, it will list the build command it executed and simply run it yourself (you'll need to remove extra stuff TFS Build adds for logging)
After that you can run the same command on your local machine and see if it passes.
Another thing to try is to set "copy local" for all assemblies in the project.
Hope this helps!
The program worked fine until I did this:
Added a new class under an existing file and an existing namespace.
Added settings to that project the new class belongs to.
Build the solution.
Build the setup project.
Installed the new version on a machine.
When I start the new version on the machine, then I get:
Unhandled Exception:
System.TypeLoadException: Could not
load type
'SI.AS.CommonLogic.Utils.ErrorLog'
from assembly
'SI.AS.CommonLogic.ErrorUtils,
Versions=1.0.0.0, Culture=neutral,
PublicKeyToken=925c8734ae397609'. at
RSMonitor.RSMonitorMain.Main(String[]
args)
ErrorUtils is the new class I have added. There was a file with a static class in it. I added another static class under it and added settings to the project. It runs smoothly on my developer machine in debug mode. But I can't install and run it on another machine. The program can call the other static class from the same file. What am I missing here?
** update **
I tried to install it for a 2nd time and checked the DLL. The timestamp matched the latest compiled version and now it works. I have no idea why it didn't work last time, because it is the same package I installed again. But if I get same error, then I'll try out your suggestions.
Your program looks like it is having trouble locating another assembly, probably called SI.AS.CommonLogic.ErrorUtils.dll. Either that, or it can only find the wrong version of this assembly.
Is this an assembly that is part of your solution?
If so, is it in the "bin" directory on the machines that it is failing to run on (in other words, is this assembly being deployed correctly with your app)?
If not, is this a part of a seperately installed component or application that is installed on your machine but not on the others (ie is this an external dependency that is missing on the other machines)?
One thing that may help here, is to use the Assembly Binding Log Viewer on both the miachine this does work on, and the machine it doesn't to see where it gets loaded from in the working case, and where it is trying to load it from in the failing case.
Note you may need to make a registry change to get this to log all assembly bin info:
Set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 (the value is a DWORD).
It sounds like your DLLs aren't being deployed/overwritten correctly. Try copying your CommonLogic DLL from your development machine to the installation directory and see if it can load it then - and then figure out why!
The other assembly wasn't updated correctly, it is still the old version. Try replacing the assembly by hand with the current version and check if the problem persists; it should go away though.
It sounds like an old version of your assembly is being loaded from somewhere.
A few things to check:
Firstly, have you incorrectly set up a reference to an assembly instead of a project? This can result in subtle, order-dependent build problems. Ensure that the reference type is "project", not "assembly".
Secondly, is the culprit assembly in the GAC on the developer machine? Even if the assembly is a dependency of your build, if it's in the GAC, it may not be copied to your output directory. This problem manifests itself in a very pernicious fashion -- everything looks fine on the developer machine (as it has the assembly in the GAC) despite the build output being wrong, and the customer machine will blow up because the assembly is neither in the GAC nor the install directory. I can't remember if this only applies to assembly references or whether project references will pick it up, too. It's easy to test if it's a problem, though -- just do a clean build, then build your project and examine the assemblies copied to the output directory. They should all be there. If your culprit .dll is missing then you know it's a problem.
I worked at a company that (briefly) built installers for internal releases without using proper assembly versioning, resulting in absolutely terrible problems of this ilk (developer machines would be riddled with assemblies in the GAC).
Check the GAC on both the developer and customer machines. Also try what Josh suggested: Copy the culprit DLL from the developer machine to the customer machine's install directory to see if that fixes it, then work from there.
I have developed an application using Entity Framework, SQL Server 2000, Visual Studio 2008 and Enterprise Library.
It works absolutely fine locally, but when I deploy the project to our test environment, I am getting the following error:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information
Stack trace: at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
at System.Reflection.Assembly.GetTypes()
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary2& typesInLoading, List`1& errors)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)
at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)
at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)
Entity Framework seems to have issue, any clue how to fix it?
This error has no true magic bullet answer. The key is to have all the information to understand the problem. Most likely a dynamically loaded assembly is missing a referenced assembly. That assembly needs to be in the bin directory of your application.
Use this code to determine what is missing.
using System.IO;
using System.Reflection;
using System.Text;
try
{
//The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
StringBuilder sb = new StringBuilder();
foreach (Exception exSub in ex.LoaderExceptions)
{
sb.AppendLine(exSub.Message);
FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
if (exFileNotFound != null)
{
if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
{
sb.AppendLine("Fusion Log:");
sb.AppendLine(exFileNotFound.FusionLog);
}
}
sb.AppendLine();
}
string errorMessage = sb.ToString();
//Display or log the error based on your application.
}
I solved this issue by setting the Copy Local attribute of my project's references to true.
One solution that worked for me was to delete the bin/ and obj/ folders and rebuild the solution.
Update:
Or you can try to right-click the Solution node in the "Solution Explorer" and click "Clean Solution", then click "Rebuild Solution" (thanks Emre Guldogan)
Two possible solutions:
You are compiling in Release mode but deploying an older compiled version from your Debug directory (or vise versa).
You don't have the correct version of the .NET Framework installed in your test environment.
As it has been mentioned before, it's usually the case of an assembly not being there.
To know exactly what assembly you're missing, attach your debugger, set a breakpoint and when you see the exception object, drill down to the 'LoaderExceptions' property. The missing assembly should be there.
Hope it helps!
The solution was to check the LoaderException: In my case, some of the DLL files were missing.
Make sure you allow 32 bits applications on IIS if you did deploy to IIS. You can define this on the settings of your current Application Pool.
I encountered this error with an ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4 application.
It would work fine on my development machine (Windows Vista 64-bit). Then when deployed to the server (Windows Server 2008 R2 SP1), it would work until the session timed out. So we'd deploy the application and everything looked fine and then leave it for more than the 20 minute session timeout and then this error would be thrown.
To solve it, I used this code on Ken Cox's blog to retrieve the LoaderExceptions property.
For my situation the missing DLL was Microsoft.ReportViewer.ProcessingObjectModel (version 10). This DLL needs to be installed in the GAC of the machine the application runs on. You can find it in the Microsoft Report Viewer 2010 Redistributable Package available on the Microsoft download site.
My instance of this problem ended up being a missing reference. An assembly was referred to in the app.config but didn't have a reference in the project.
Initially I tried the Fusion log viewer, but that didn't help
so I ended up using WinDbg with the SOS extension.
!dumpheap -stat -type Exception /D
Then I examined the FileNotFoundExceptions. The message in the exception contained the name of the DLL that wasn't loading.
N.B., the /D give you hyperlinked results, so click on the link in the summary for FileNotFoundException. That will bring up a list of the exceptions. Then click on the link for one of the exceptions. That will !dumpobject that exceptions. Then you should just be able to click on the link for Message in the exception object, and you'll see the text.
If you're using the EntityDataSource in your project, the solution is in Fix: 'Unable to load one or more of the requested types' Errors. You should set the ContextTypeName="ProjectNameNameSpace.EntityContainerName" '
This solved my problems...
Another solution to know why exactly nothing works (from Microsoft connect):
Add this code to the project:
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
asm.GetTypes();
}
Turn off generation serialization assemblies.
Build and execute.
If you are using Entity Framework, try copying the following references locally.
System.Data.Entity
System.Web.Entity
Change the property "Copy Local" to "True" for these references and publish.
I had a .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 web application developed in Visual Studio 2010. I had the same problem, that it worked on one Windows Server 2008 R2 server but not on another Windows Server 2008 R2 server, even though the versions of .NET and ASP.NET MVC were the same, throwing this same error as yours.
I went to follow miko's suggestion, so I installed Windows SDK v7.1 (x64) on the failing server, so I could run !dumpheap.
Well, it turns out that installing Windows SDK v7.1 (x64) resolved the issue. Whatever dependency was missing must have been included in the SDK. It can be downloaded from Microsoft Windows SDK for Windows 7 and .NET Framework 4.
Adding my specific problem/solution to this as this is the first result for this error message. In my case, the error was received when I deployed a second application within the folder of my first application in IIS. Both were defining connection string with the same name resulting in the child application having a conflict and in turn generating this (to me) non-obvious error message. It was solved by adding:
<clear/>
in the connection string block of the child web application which prevented it from inheriting the connection strings of web.config files higher in the hierarchy, so it looks like:
<connectionStrings>
<clear/>
<add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>
A reference Stack Overflow question which helped once I determined what was
going on was Will a child application inherit from its parent web.config?.
This worked for me. Add it in your web.config
<system.web>
<trust level="Full" />
My issue has been resolved after I deleted the redundant assembly files from the bin folder.
In case none of the other answers help you:
When I had this problem, it turned out my Windows service was built for an x64 platform, and I was inadvertently running the 32-bit version of InstallUtil.exe. So make sure you're using the right version of InstallUtil for the platform you built for.
Other suggestions are all good. In my case, the problem was that the developer box was a 64-bit machine using the x86 location of various APIs, including Silverlight.
By changing the target platform to match the 32-bit server where the web application was being deployed removed the majority of the errors related to not being able to load one or more of the requested types.
I changed the Specific Version Property of the Refrences to false and that helped.
I had the same error message reported when compiling a Visual Studio package (VSPackage). The whole solution compiles and the error is thrown when the package is being created by CreatePkgDef. Having said that, it is clear that I cannot catch the LoaderExceptions as it is not my application that throws it, but Microsoft's own tool. (Though I am responsible for the confusion of CreatePkgDef.)
In my case the root cause was that my solution creates a MyDll.dll that has already been registered to the GAC (and they are different), so the CreatePgkDef got confused which one to use and it decided just to throw an error which isn't really helpful. The MyDll.dll in the GAC was registered by the installer of the same product (obviously an earlier version, with /slightly/ different content).
How to fix it
Preferred way: Make sure you use the correct version of MyDll.dll
When compiling your project make sure you use a different version number than you used in the previous version located in the GAC. Make sure the following attributes are correct:
[assembly: AssemblyVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
[assembly: AssemblyFileVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
If needed, specify the fully qualified assembly name (for example, "MyDll.dll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=1234567890abcdef") when you reference it in your other projects.
If the above failed: You can uninstall the old MyDll.dll from GAC
How to Uninstall an Assembly from the GAC
Uninstall the application that includes MyDll.dll
Changing the AssemblyVersion was good enough for me. :)
I hope this was helpful.
I had the same issue (but on my local) when I was trying to add Entity Framework migration with Package Manager Console.
The way I solved it was by creating a console application where Main() had the following code:
var dbConfig = new Configuration();
var dbMigrator = new DbMigrator(dbConfig);
dbMigrator.Update();
Make sure the Configuration class is the migration Configuration of your failing project. You will need System.Data.Entity.Migrations to use DbMigrator.
Set a breakpoint in your application, and run it. The exception should be caught by Visual Studio (unless you have that exception type set to not break the debug session), and you should be able to find the info you are looking for.
The missing reference in my case was EFProviderWrapperToolkit.
I got this problem when I installed a NuGet package on one of the projects and forgot to update the other project.
I solved this by just making both projects having the same reference assembly.
It happened for me also. I solved the problem as follows:
Right click Solution, Manage NuGet Packages for Solution...
Consolidate packages and upgraded the packages to be in the same version.
I had this issue while referencing a nuget package and later on using the remove option to delete it from my project. I had to clear the bin folder after battling with the issue for hours. To avoid this its advisable to use nuget to uninstall unwanted packages rather than the usual delete
Set 32 bit IIS mode to true, debug mode to true in the configuration file, deleting the temp directory and resetting IIS fixes the issue temporally and it comes back after some time.
Verify that each of your projects is setup correctly in the Configuration Manager.
Similar to William Edmondson's reason for this issue, I switched my Configuration Manager setting from "Debug" "Any CPU" to "Debug" ".NET". The problem was that the ".NET" version was NOT configured to build ALL of the projects, so some of my DLLs were out of date (while others were current). This caused numerous problems with starting the application.
The temporary fix was to do Kenny Eliasson's suggestion to clean out the \bin and \obj directories. However, as soon as I made more changes to the non-compiling projects, everything would fail again.
I also got this issue when create new Microsoft Word add-in with Visual Studio 2015. The issue is about I have 2 versions of MS Office, 2013 and 2016. I uninstall MS Office 2013 and then it works.
I build a few projects for SharePoint and, of course, deployed them. One time it happened.
I found an old assembly in C:\Windows\assembly\temp\xxx (with FarManager), removed it after reboot, and all projects built.
I have question for MSBuild, because in project assemblies linked like projects and every assembly is marked "Copy local", but not from the GAC.
I am able to fix this issue by marking "Copy Local=True" on all referenced DLL files in the project, rebuilding and deploying on a testing server.
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.