I have a very small, simple ASP.NET MVC app (MVC 4 I think. .NET Framework 4) it consists of one controller with one action serving one page.
I'm deploying it on AppHarbor, pushing it with git on my local machine, I've never had problems running it locally and it has never had build issues/errors on AppHarbour but every now and then a new build (with no relevant change in my mind) will start throwing the following error:
Could not load file or assembly 'Microsoft.Threading.Tasks,
Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Looking into this the top answer here sorted it, I removed the dependent assemblies listed and it worked again. But then it came back. Tried a lot of different suggestions, it has always used nuget, tried removing everything and re-installing, it started working again when I wasn't even sure what I'd changed and now it isn't working again. Today I switched it to NuGet Package Restore as outlined here but that hasn't made any difference.
I can re-deploy the last working build, what I notice comparing working/not working builds downloaded from AppHarbor is that the Web/App.configs are identical (no dependent assembly entriy for this) but the Microsoft.Threading.Tasks dlls and xmls (including Extensions and Extensions.Desktop) are not in the broken build (in the working build they appear in the root and in the bin)?
In the project the dlls are linked from the packages folder for the app and Copy Local is True, they aren't a direct dependency of the Web App but of the Google Calendar API its using.
Update
On the back of writing the answer I've looked more closely at the build logs and noticed a distinct difference between a working and not-working build.
The Microsoft.Threading.Tasks.dll is not a direct dependency, its required by Google.Apis.Gmail.v1.dll, in a working build the build log will contain (see the bottom line copying Microsoft.Threading.Tasks.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\voz3srsa.vhb\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\voz3srsa.vhb\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\voz3srsa.vhb\output\log4net.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.dll"
to "D:\temp\voz3srsa.vhb\output\Microsoft.Threading.Tasks.dll".
A not-working build will have a different dll in its place (see the bottom line again, Microsoft.Web.Infrastructure.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\0kzqakoc.4jo\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\0kzqakoc.4jo\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\0kzqakoc.4jo\output\log4net.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll"
to "D:\temp\0kzqakoc.4jo\output\Microsoft.Web.Infrastructure.dll".
Looking into dlls missing in the build I found this answer but I have tried a command prompt build locally and it works fine.
Update 2
Also in trying to solve this I had noticed a comment on the build (not a warning) around reference versions:
1> Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Users...\packages\TweetSharp.2.3.1\lib\4.0\Newtonsoft.Json.dll] to Version "6.0.0.0" [C:\Users...\packages\Newtonsoft.Json.6.0.6\lib\net40\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Couldn't get a remapping that sorted it but did get this where adding an app.config (which makes no sense for a web app) redirect fixed it where the redirect in the web.config didn't. This did stop the build issue but made little sense.
I took this to the AppHarbor support forum as this didn't get any response here, Build succeeding but missing dll and they were very helpful and it now looks like it is resolved.
Although in Visual Studio 2012 Professional all references were marked as Copy Local True, they did not have the True tag so I added these by hand for the three libraries in question. And that was it, DLLs copied.
There are a lot of links around this discrepancy, that MSBuild needs them (although I had tried an MSBuild build and it was fine), Visual Studio doesn't insert them by default (may appear if you toggle the setting false and then true) and it manifests in not copying references-of-references.
Stack Overflow question, see highest voted answer not accepted hack
Raised with Microsoft and closed as not reproducible
Related
Greetings people who are smarter than I.
After publishing a project which utilises SQLite, when the part of the program runs that accesses the DB commands, I get this error.
Unable to load DLL 'SQLite.Interop.dll': The specified module could
not be found
Now I have spent hours, going through the many similar threads, trying all the suggestions to see if I can fix this, however as of yet I have had no luck.
I have done the following.
Ensured the SQLite.Core is included on the main project and all sub project areas.
Ensured the .dll is available in the debug bin.
Ensured dependencies are set correctly.
Publish specifically to x64 platform.
Publish specifically to x86 platform.
Disabled "Prefer 32-bit".
Copied some specific references to csproj.
All to no avail. If anyone has any experience with this who might be able to suggest something new that I haven't tried in an attempt to solve this I would be most grateful.
So after much research i finally found the solution.
It seems there are a great many potential causes for this error, however this resolved the issue for me in this instance.
Revert everything back to how it was, ensure System.Data.SQLite.Core is referenced in your assemblies.
Close VS / solution and open the csproj file in the repo. Copy the following into the file.
<PropertyGroup>
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
<CopySQLiteInteropFiles>false</CopySQLiteInteropFiles>
<CleanSQLiteInteropFiles>false</CleanSQLiteInteropFiles>
<CollectSQLiteInteropFiles>false</CollectSQLiteInteropFiles>
</PropertyGroup>
Save the file, (probably would create a copy of it beforehand to ensure you can replace it if it doesnt work for you).
Ensure that interop.dll is not anywhere in your repo except bin/debug/x86 and x64.
Then proceed to test your project, then publish it.
Reason:
Because the Interop is included in the nuget installation, but not copied down, this bit of code ensures that its copied through during the publishing.
Thank you internet.
I am working on a C# program that utilizes EntityFramework, I've cloned the program from git repo, but now it is having that dreadful Metadata file 'EntityFramework.dll' could not be found error. I have searched and tried countless suggestions for this kind of problem, but none worked. I've already checked that the reference to EntityFramework.dll in the .csproj files are correct and it is definitely there under the packages\EntityFramework.6.2.0\lib\net45\ folder. So I am not sure what else to try.
Ok, I've resolved this problem. Here is what happened. Apparently, when cloning into local directory, one of the folder on the path has a space in its name (like My DSS), and this nuget issue seems to indicate the inability of nuget to find package with space in path. So, once I changed that folder's name to MyDSS, it compiled successfully.
please have a look on the bin folder ,sometimes the dlls do not exist there .
This typically happens when teams check in files that should not be checked in (such as the .suo file) or have "optimized" their builds to exclude rarely changed projects. (unticking projects in the configuration manager.)
Another common cause for missing references is when devs reference a dependency from a /bin folder instead of the packages folder, but it sounds like you've confirmed that isn't the case.
Other questions such as Metadata file '.dll' could not be found list a number of things to check, so your problem will surely be one of these. Try building each project individually, working from projects that have no project dependencies upwards to the main application project(s). Ensure they're running the same .Net versions, check the solution NuGet packages for dependencies with "multiple versions" and consolidate these so that the solution is using a single version of each dependency. (generally good for cleaning up) Also look at .config files for version re-directs that sometimes get zombified in source control.
In Visual Studio, on top, click on Build -> Configuration Manager. Make sure that the build checkbox next to your project is checked. In case it already is, uncheck it and then make it checked again. Clean your Solution and Build it again after this.
I downloaded a package from SourceForge, PlanEph, which has 64 and 32 bit DLLs for C#. I got the 32 bit included C# demo to work by putting the DLL in my bin/Debug directory (I'm using Visual Studio 2015 Community) and adding the DLL as a reference.
Then I tried to make my own version of the demo in a separate solution, and got the System.DllNotFoundException. Various experimentation lead me to believe I can't have two identical namespace names anywhere in my Visual Studio installation, so I erased everything and started over.
I made a directory C\GJAbin, put the DLL in it, and added it to the system Path variable. I also put a helloWorld type program in that dir and executed it from the command line to verify the directory really was in the path. Then I recreated the demo solution, added the DLL as a resource, and built the solution "successfully". Then I ran it and got the System.DllNotFoundException.
So I can't understand why the DLL is being found when compiling but not at run time.
Go to project settings, go to "publish" tab and on the top most button (labeled something like "application files"). Chose "Show all files" checkbox if you don't see your DLL. Set the DLL's publish status to "Include" (NOT "Include (Auto)"!!) and publish it again.
Now the DLL should be inside the publish folder.
So I can't understand why the DLL is being found when compiling but not at run time.
Locating the assembly at compile time is done differently (by MSBuild) than at runtime (by the CLR).
At compile time, MSBuild has specific search paths that it knows about, or in most cases like this, there will be something in your project file telling MSBuild where to look for the file. Usually the <Reference> has a <HintPath>.
At runtime, the CLR will attempt to find the assembly from its own set of well-known paths. It will look in your app's config file (if applicable), then in the Global Assembly Cache (GAC), then in your app's root directory. Much more detail on this is available here.
You can tell MSBuild to copy the reference to your build output directory (usually the same as your app root directory when running). In VS, you can do this by selecting the reference and looking at the Properties tool window (or press F4 by default). Set the CopyLocal state to True. In the project file, this will add a <Private>True</Private> on the <Reference>.
You can also add the assembly to the GAC using the gacutil tool, but this does make it harder if you want to share your app with others. Usually it's preferable to keep a copy in your app root directory.
If it's still not working, you can also see the log for how the runtime is trying to find this assembly. The fuslogvw.exe tool in the Windows SDK (you can run it from the VS command prompt and it will be on the %PATH%) allows you to enable logging for assembly loads. You do need to be able to run this as an administrator to configure the setting.
As you can see in the screenshot, you can either log the results in the exception (so that you can see it while debugging), or you can log it to a file on disk (so you can see it whenenver).
The problem turned out to be an unfortunate interaction among the way the author chose names and the way Visual Studio displays information and error messages. The author created a c# dll Astronomy.PlanEph32.dll containing a namespace PlanEph32, which which was really just a wrapper for the c dll PlanEph32.dll. So all the error messages about not being able to load PlanEph32.dll were referring to not finding the c dll; the c# dll was being found just fine.
I am running a project that had been running without issue for some time but recently started throwing an error stating,
"Could not load file or assembly 'Microsoft.Practices.Unity,
Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
or one of its dependencies. The system cannot find the file
specified."
I see that this assembly is for IoC/Dependency Injection support however I never explicitly added it to the solution; although I do see that it is in fact there.
When I check the version of the assembly it is showing the same version that is being referenced in the above error; so I cannot figure out why the file cannot be found by the project.
In effort of resolving the issue I've cleaned the solution, deleted my obj folder, rebuilt, removed and even reinstalled the assembly via nuget but the issue persists.
I've found somewhat similar issues reported here on SO but the proposed resolutions were either not applicable because it was not the same assembly reference as the one I'm having issue with OR it involved configuration of a XAML based application. This is ASP.NET.
The only other clue that I could find as to why I'm having the problem is that the targeted runtime framework of the assembly is v2.0.50727 and this application is .NET 4.5
Which would seem a reasonable explanation for the problem from my limited perspective except that the app was previously running without the problem.
I'd also mention that the assembly isn't explicitly being called from the block of code throwing the error; which is simply creating a web service client and calling a method.
long memberId = 1326728123;
ServiceClient sc = new ServiceClient("ServiceClientEndPoint");
var leadPackage = smc.GetLeadPackages(memberId);
So there could be other variables of this equation that may be attributing to the problem (e.g. Network blocking and etc)
I just wanted to make certain that I may not be missing something by running it past SO before wasting time going in the wrong direction for an answer.
Note that this could mean a number of things, including that one of the dependent assemblies of Microsoft.Practices.Unity could be loaded.
The first place searched is the GAC, if you are building and running on the same machine, this probably won't cause a problem because the runtime will also find the same library but if you are deploying, the project will sometimes bind to the GAC library whereas the production server might not have it installed and it will fail to run. CopyLocal=true should fix that but if you are deploying, you should check that the library is copied into the bin directory.
Secondly, you should open Microsoft.Practices.Unity.dll using reflector or ilspy.exe and see what other dependencies it has (other than the System.* libraries) since any other ones will need the same treatment as Microsoft.Practices.Unity i.e. adding to the project and copy local set to true.
I'm trying to get set up with ImageMagick.NET with Visual Studio 2012. I've done much research into what seems to be a common issue whereby Visual Studio is not recognizing the dependencies of ImageMagick.NET (it recognizes the .NET DLL just fine judging by the auto complete). I took steps suggested in threads such as this:
http://imagemagick.codeplex.com/discussions/66874
whereby the .NET DLL is referenced within the project, making sure I take note I chose the 16-numbered build, then downloading the 6.5.3-10 versioned dependencies from the following link:
http://image_magick.veidrodis.com/image_magick/binaries/
which installs the DLLs and places them automatically on the system path so I shouldn't theoretically have to copy the DLL's from the install directory into my project.... but this I also have done, in several different locations, including the project root, bin, the Debug and x86 directories, etc. I also made sure I was building for x86 machines, as that seems to be the only architecture supported by the DLL. Yet despite my measures, no dice! I would greatly appreciate if someone has any further insight into why this might be happening the way it is. I'm building a C# project and trying to just initialize the project within a Windows 8 grid app template.
Thanks in advance!
EDIT: I apologize in not being explicit about the error message I am receiving:
Exception: Thrown: "Could not load file or assembly 'ImageMagickNET.DLL' or one of its dependencies. The specified module could not be found."