We are trying to port our build on VSTS hosted agent. We have bunch of DLLs pushed through git lfs to remote. These DLLs work fine on local machine. But when I tried to run build on VSTS hosted agent, one of the DLL got warning MSB3246
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): Warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'FooBar.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format
There are 2 DLLs in our git lfs. I don't see other DLLs success/failure message in log so not sure whether it is working fine or it might also have same issue(this DLL might be breeaking things first).
Obviously, I got errors refering to code from this DLL.
Error CS0234: The type or namespace name 'Foo' does not exist in the namespace 'Bar' (are you missing an assembly reference?)
I found similar issue on https://social.msdn.microsoft.com/Forums/vstudio/en-US/f2d8d30f-62b0-476f-a28e-17e372b6c557/issues-with-build-on-hosted-build-controller?forum=TFService but we already have our gitattributes file set correctly.
What might be going wrong here? Have anyone solved this already?
In the Get Sources step there is a specific checkbox to enable git-lfs support. Without it the file will be replaced with a placeholder to the lfs download location. Of course you can't compile against those.
Related
We have a C# ASP.NET Web Application that uses the System.Transactions namespace.
using System.Transactions;
This works fine when developing locally - we just had to add the reference first by going to Website --> Add Reference...
The problem is that after deploying to the web host (copying over FTP), the host doesn't know this reference.
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0234: The type or namespace name 'Transactions' does not exist in the namespace 'System' (are you missing an assembly reference?)
Working in Visual Web Developer Express 2010, we don't have the References folder built in. I saw this solution: https://stackoverflow.com/a/13035466/2178080 that suggests (but doesn't recommend) copying a dll to the application folder.
I'm a bit new to deploying with ASP and not sure how to include the System.Transactions library so the host can find the reference. Has anyone run into this issue?
Edit: We went with the route of copying the dll to the site along with the application. The steps to do this:
Copy the System.Transactions.dll from the local system.
Paste into the Bin folder.
The objects referenced in this assembly must now use the fully qualified name.
As this solution is listed as not recommended, I am still open to other solutions.
Edit2: Grant and Chris helped me understand that I was working with a Web Site and not a Web Application. Grant helped with the specifics of the Web Site problem.
Your problem is due to the published site is not bringing the System.Transactions.dll along with it, this points to "Copy Local" being set to False and thus the DLL not copying to the bin folder.
Go to References -> System.Transactions and make sure on the properties for this reference that "Copy Local" is set to True.
Check the target framework in IIS, make sure it's set to the same version of .Net that you are compiling your code in. If you are using IIS 7+, which have Application Pools, make sure the pool the application is running on is the same version of .Net.
I would first like to admit that I am an extremely novice developer, so I'm doing my best to give all of the relevant information to make this question answerable:
So I'm trying to do some unit tests for NxBRE before I start attempting further work with the engine. I've downloaded both NxBRE and NUnit (version 3.2 and 2.6 respectively) and I've tested NUnit to make sure that it is working properly using a simple example that I could post here, but seems irrelevant to do so. What's important was that I was easily able to reference the nunit.framework.dll in the example, and the tested attributes compiled and the GUI ran the tests perfectly. I'm using SharpDevelop by the way.
I then opened up the provided NxBRE solution, which has two projects (NxBRE and NxBRE-UnitTest), added the same reference in the Unit-Test project to the nunit.framework.dll, and attempted to build the solution. I got a compiler error (along with the host of associated errors) stating that:
CS0246: The type or namespace name 'nunit' could not be found (are you missing a using directive or an assembly reference?)
Well, I was pretty sure I wasn't missing either, so I double checked the reference, and it seemed good (in that I re-added it in the way that I had for my test example). I even manually copied the .dll to the directories that were being accessed. I don't think it was an issue with NUnit itself, because I went back to my crafted example and it still ran fine.
Do you have any suggestions for trouble-shooting ideas or techniques that I should try?
I examined the .csproj file of the NxBRE 3 test project, and there is no directory path associated with nunit.framework.
In other words, the test project expects NUnit to be installed in the Global Assembly Cache. Could it be that you have not installed NUnit via its .msi file but rather unpacked it from a .zip file?
My recommendation is that you remove the nunit.framework reference from the test project and then add the reference again by browsing for the actual DLL file in the file system.
Inherited C# win form application - VS .NET 2008.
Project builds with no error.
Navigate to display main dialog in the IDE and error screen displays with the error.
The .dll is in the bin directory. Also, under the "References" tree in project viewer with correct path.
(All supporting files/dlls should be here.)
Any ideas how to fix this?
EDIT 1 started Fuslogvw.exe does not have anything listed. Is there something else I need to do to get this error to display here?
EDIT 2
Running "Dependency Walker" and it comes up with the error:
Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
unable to open 2 windows system32 dlls....
I decided to answer this question because
I'm looking for the anwser myself and this ranks high in google search yet it is unanswered, and
The "possible duplicate" do not help solving my problem.
OK, here is a recap of my situation, which you can see almost identical to OP:
C# project/solution - VS .NET 2013.
Project builds with no error.
The reference .dlls are in the pre-defined directory.
Also, under the "References" tree in project viewer, it shows the correct path.
Yet, Visual Studio complains (at run time):
Could not load file or assembly xxxxxx, Version=x.x.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxx or one of its dependencies. The system cannot find the file specified.
I found the solution from here,
http://blogs.msdn.com/b/asiatech/archive/2013/01/09/how-to-resolve-the-could-not-load-file-or-assembly-issues-on-windows-azure-web-sites.aspx
I.e., In Visual Studio,
Find the referenced assembly in “Solution Explorer”, e.g.,
Microsoft.WindowsAzure.StorageClient
In the “Properties” window, set the “Copy Local” to “True”.
It might not be the ideal fix but it solved my problem. If it helps you as well, please +1 (vote up). Thanks.
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.
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.