We were using TeamCity for our Build server, .Net Framework 4 and ASP.NET MVC2 and NHibernate Our build server recently went offline thanks to Amazon EC2 issue recently. We are setting a new build server up.
However, even though nothing changed recently in our codebase, Teamcity gives following error.
ResGen error RG0000: Could not load referenced assembly "C:\TeamCity\buildAgent\work\1e7706dcd512f467\xxx\Lib\Antlr3.Runtime.dll". Caught a FileLoadException saying "Could not load file or assembly 'C:\TeamCity\buildAgent\work\1e7706dcd512f467\xxx\Lib\Antlr3.Runtime.dll' or one of its dependencies. Provider DLL failed to initialize correctly. (Exception from HRESULT: 0x8009001D)".
Given DLL file exists along with other required DLLs. Any solution?
Sometimes things start going wrong in scope of particular build within a particular build agent. I struggled with such an issue before but in my case MSBuild
owned a lock on one of the DLLs so TeamCity
was not able overwrite it.
So basically:
"C:\TeamCity\buildAgent\work\1e7706dcd512f467"
so at the next build TeamCity will be forced to grab all filesI found a reference to error code 0x8009001D on the Microsoft Support site here.
This problem occurs if you modified the MountedDevices registry value to change the boot drive letter assignment or the system drive letter assignment.
Workaround for error code 0x8009001d
To resolve this problem, you must remove the whole contents of the MountedDevices registry key. This key is located in the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices For more information, click the following article number to view the article in the Microsoft Knowledge Base: 223188 How to change the system/boot drive letter in Windows 2000 You cannot modify the MountedDevices registry key in Windows XP because there are many hard-coded paths to the C:\Windows drive. These hard-coded paths may not load. Then, that behavior provokes the WPA-related error code.
I've never run into this myself, but hopefully this will help.
This helped for me (and I feel pretty comfy with it, because I did not have to change any obscure settings or delete files I really don't know)
<package id="Antlr" version="3.4.1.9004" targetFramework="net45"/>
from the file packages.config.<package id="Antlr" version="3.4.1.9004" targetFramework="net45"/>
active again.That's all folks!
I had the same issue today. In the IIS application pool settings-> advance settings, i changed the "Enable 32-bit application" settings to true
This also occurs when the assemblies listed in the packages.config file are out of sync with the assemblies referenced within the project. If this is the case, then just remove the package(s) from the packages.config that aren't referenced by the project then rebuild the project or solution.
Packages guys...packages. No matter what DLL issue you have like some DLLs it does sometimes help to update them too. Reason: You've probably just ran some Windows updates or (Windows did it itself) and this makes your new patches incompatible with the old DLLs in your project. Step 1So go into Tools > Nuget Package Manager > Manage Nuget Packages for Solution > Updates > Update All (Usually the best option :-) ). And oh wait....if you're hit with this error: Nuget.exe Install — Microsoft.CSharp already has a dependency for System.Dynamic.Runtime then update your NUGET package manager first (Step 2): Tools > Extensions and Updates > Updates > Visual Studio Gallery > Click on Update next to NuGet > Restart VS. Rerun Step 1. Good luck! (VS Studio 2013)
in visual studio --->tools---->
in package manager console type
PM>install-package antlr and hit enter
User contributions licensed under CC BY-SA 3.0