I just solved the following error:
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Strange thing - it only seemed to be a problem when I made a release build although was a little intermittent - I could create a debug build and the issue could sometimes temporarily go away.
Turned out that I had an enterprise library dll in the project Microsoft.Practices.EnterpriseLibrary.Data.dll that wasn't being used, was version 5.0.505.0, and looks like it was trying to pull in v. 5.0.505.0 of Microsoft.Practices.EnterpriseLibrary.Common, when v. 5.0.414.0 of this 'Common' dll was already in the project. Didn't pin down why this was mainly happening in release mode.
Something that would've helped to track this down and clearly identify the cause would have been to find out for certain which dll is pulling another dll into my Visual Studio project? I want to be able to go from the dll that's causing the problem, and see what dll is including it. This answer:
Find out why Visual Studio decides to copy DLLs into a bin directory
says that ildasm or reflector can be used, but what do you need to look for using these tools and how? I've Googled this but didn't see anything.
As a side note, any ideas on why switching to release mode would cause my issue? I've wondered if doing this caused Visual Studio to attempt to pull a release version of Microsoft.Practices.EnterpriseLibrary.Common from somewhere and it's the wrong version, but this makes no sense to me as this is a '3rd party' (Microsoft) library that is already in release mode, it doesn't explain the intermittency, and I don't see why switching an individual project to release mode would affect a reference to an external library.
Related
I'm hoping I've overlooked something here but I've hit a problem, for which I can't find a happy work-around.
I'm using VSTS for my CI solution. Each commit, the BizTalk apps are fetched to a dedicated build server, compiled and the unit tests are executed.
I don't want any of my BizTalk solution assemblies to find their way into the GAC on the build server because Visual Studio will compile with these, rather than project references.
The problem comes when the build agent attempts to build a solution that contain a custom functoids project, I get the following error:
Functoid not found: guid (1d5de785-c639-4040-9704-c65a11127115) with functoid id (6003). Check if the assembly implementing this functoid is present in D:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Developer Tools\Mapper Extensions. If the functoid does not expose any inline code, make sure its assembly is made available in the GAC also
So, the functoid assembly needs to be in the GAC? Trouble is, that references a common.components assembly which means that will also need to be GAC'd, which puts me right back in the place I don't want to be! This is a problem because the next time the build agent tries to build a project with a reference to common.components, it will use the "old" version that happens to be kicking around in the GAC, rather that the latest version just pulled from the repo and sat alongside the dependent project in the same solution.
If anyone else has hit the same problem, I'd love to hear from you.
I typically put something like the following in my BizTalk related projects as a post-build step:
call "$(DevEnvDir)..\tools\vsvars32.bat"
gacutil.exe /if "$(TargetPath)"
I'm fairly sure that $(DevEnvDir) won't resolve on the build server though. There are a few work arounds - you can make sure to install the Windows SDK and set the proper registry key (like here Running MSBuild fails to read SDKToolsPath), or you could just otherwise set an environment varaible on the build server that has the path to gacutil, or you could use something like the MSBuild community tasks (https://github.com/loresoft/msbuildtasks) which has a GacUtil task, or perhaps even run a powershell script like so:
#Note that you should be running PowerShell as an Administrator
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Path\To\DLL.dll")
(from https://www.andrewcbancroft.com/2015/12/16/using-powershell-to-install-a-dll-into-the-gac/).
Do note that the build process will need to run with (local) administrative privileges to successfully GAC the library.
Edit: Since I've run into this problem locally, I've used this and it works in every environment I've tested (regardless of which windows SDK is installed or whether the admin of the machine put it on the C, D, or other drive...):
powershell -c "[System.Reflection.Assembly]::Load('System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'); $publish = New-Object System.EnterpriseServices.Internal.Publish; $publish.GacInstall('$(TargetPath)');"
Thanks to #Johns-305 for the answer - I was overthinking this one!
I added the following as a post build event for the Common.Components project:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\gacutil.exe" /i "$(TargetPath)"
I'm new here to go easy.
I'm trying to publish my first asp.net 4.5 mvc 4 site to windows azure and I've got dependency issues. I can see that there are a plethora of existing posts and each one contains slightly different advice so I would appreciate general advice for troubleshooting these dependency issues. I'd be hugely grateful if you treated me like a layman in all regards.
For e.g.: my first publish error was:
Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
This is not referenced anywhere in my project in code, but has a reference to the assembely when I manually check (and the same version that the errors throws up, 4.0.0.0)
Now that I've tried to publish, I get an Oath error when I try to run locally that I did not get before:
Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies. The system cannot find the file specified.
As per this post Could not load file or assembly 'DotNetOpenAuth.Core I've since solved that particular issue which seemed to have arised post-publish by deleting the bin/obj folders, cleaning solution and changing some publish file settings.
Since then I get just another dependency issue:
Could not load file or assembly 'System.Web.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
(Again in my references list with the "runtime version" as v4.0.30319 and "version as 2.0.0.0 in the properties tab, so I have no idea what to do with it)
So my final question is thus: what is the general process behind resolving these? I cannot google each one in sequence as they are slightly different each time and perhaps sometimes they may be referenced in packages.config and perhaps others not.
Is the process for example: check reference to assembly, if it exists then uninstall and re-install manually from nuget? Is there no automated way of doing this? And why can't I run locally anymore since I attempted to publish? I expected publishing to azure to be seamless and I'm a little disappointed.
Needing desperate help and thank you all,
Lani
EDIT1: to answer cory's question, here's a file explorer screenie and files showing up in VS with 'show all files' selected: https://www.dropbox.com/s/f8qguuwicxz71ws/Screenshot%202014-10-19%2020.31.25.png?dl=0
I honestly don't know if that answers your question.
EDIT2: I've tried pointing the packages.config file to 4.0.0.0 for dotnetopenauth.core as per the error but the system cannot find any prior packages. I've also gone to http://www.nuget.org/packages/DotNetOpenAuth.Core/5.0.0-alpha3 but it displays a list from 4.3.2 to 5.. I really think something is wrong in the project rather than for e.g. dotnetopenauth.core version... (or any other dependency issue that will inevitably arise after I resolve this one..)
These dependencies are done on the Web.Config file apparently on the <assemblyBinding> portion. You may also reinstall Nuget package.
Like many others I am getting the "Could not load file or assembly ... .dll". This problem happens when I try to compile as there is then a single error. I have tried adding a reference to System.Data.Entity and rebuilding, as well as also trying various things out from this stackoverflow answered question:
Could not load file or assembly 'System.Net.Http, Version=2.0.0.0 in MVC4 Web API
I have tried the "Copy Local = True" under properties under References for the particular .dll (It was already set to True), as well as "Always Copy" the .dll in question which is in the bin folder.
I have also tried to find the "runtime" code in the Web.Config file, there however is none in either that or the sub-files (web.debug.config and web.release.config). I thought that perhaps I could modify the version. There are about 10 other .dll references which seem to be working. I also did get the compilation and part of the first page to run the first time, but not after that. Error information is at the bottom.
I have read that there seems to be a problem with NuGet but I don't know if I should remove it as I don't know what it does and might find it useful later. I am using Visual Web Developer Express 2012.
'Could not load file or assembly 'ComponentArt.Web.UI, Version=2008.1.1202.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)' C:\Users\Brian\Desktop
I think you might be using the ComponentArt dll that depends on WebForms in MVC4 project. You need to create a WebForms project and then you will be able to add that DLL.
I am using aspnet___compiler.exe to compile my asp.net 3.5SP1 websites,
then aspnet_merge.exe to merge the assemblies into a single one.
The assembly is then uploaded to the production server. This usually works pretty well but sometimes when testing on the staging server I get the
following message:
Parser Error Message: Could not load
file or assembly 'App_global.asax,
Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its
dependencies. The system cannot find
the file specified.
When looking at the assembly with Reflector and comparing it with a working version of the same assembly I see that the type ASP.global_asax is indeed missing.
When changing something on the site and compiling it again, I get a working version that includes 'ASP.global_asax'.
This is kind of annoying, I am wondering whether this is a bug in the compiler in some special circumstances?
Anybody else encountered this and found out how to fix it?
I've been running into this issue today and found this:
http://blogs.msdn.com/b/isha/archive/2009/04/04/issues-with-wcf-service-when-the-asp-net-website-is-deployed-using-the-web-deployment-project-and-as-non-updatable-project.aspx
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
grep -d 9\.0\.2\.7 *.xml
Other places you might search:
search the project files for 9.0.2.7
registry search for 9.0.2.7, and a search using the public token
If this app uses the BDP you might also search the BDP config files
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!