I have a system that implements several web services in C# 4.0. The solution is being compiled under TFS2010's build mechanism. After the build, some low level tests are run.
These run correctly in developer studio (on Windows 7), but for some reason fail under MSTest on the build machine (Windows Server 2008 R2). Some logging shows that it's caused by a System.IO.FileNotFoundException exception on an assembly at the bottom layer (see exception stack below).
Do you think it's a versioning problem? Is Windows Server 2008 R2 doing something completely different that the Castle asembly doesn't grok?
Type: System.Reflection.TargetInvocationException
Error Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Type: Castle.MicroKernel.SubSystems.Conversion.ConverterException
Error Message: Could not convert from 'MockRepository' to System.Type.
Source: Castle.Windsor
Type: System.IO.FileNotFoundException
Error Message: Could not load file or assembly 'VsWebSite.Interop, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Source: mscorlib
EDIT: I never did find out what the problem was. I had a large amount of refactoring to do and, after that was over, the issue disappeared.
Something is referencing VsWebSite.Interop.dll (definitely not any Castle assembly) which is a Visual Studio assembly, and you probably don't have Visual Studio installed on your build server. Remove that reference.
Related
Errors are returned on builds from a TFS2017 build agent for an MVC website solution with 4 projects as generally described below.
The MVC project
A test project
A class library as the domain layer
A class library as the storage/infrastructure layer
There are about 20 errors in the log output, but the error below with regard to the EntityFramework assembly is the first one (a second error is similar with regard to the EntityFramework.SqlServer assembly). These errors seem to be the source of the overall build problems.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
The code compiles, runs in debug, and operates at the hosting location using VS2017 publishing tools. I am trying to get the build server online. The build server has VS2017 installed.
Why would the entity framework assemblies not be accessible to MSbuild on the build server and how do I correct that?
It looks like System.Data.SqlClient is defined in dnxcore50 when running on Windows, but not on Linux.
Aren't they both corefx?
For example, an app that targets dnxcore50 beta7, or beta8, and references System.Data.SqlClient will build and run fine in Windows, but on Linux will compile fine only to at execution throw this runtime error;
An unhandled exception has occurred: Could not load file or assembly
'System.Data.SqlClient, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified.
With ASP.NET 5 RC1, SqlClient is now cross platform and so you can query Microsoft SQL Server from Linux and Mac too.
More info in the release notes below (look for Cross-platform SQL Client)
http://blogs.msdn.com/b/webdev/archive/2015/11/18/announcing-asp-net-5-release-candidate-1.aspx
In Visual Studio 2012 I created an ASP.NET MVC 4 project where the target framework is the .NET Framework 4.5. When I deployed my project to a web server it gave the following error:
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.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where
it originated in the code.
Exception Details: System.IO.FileNotFoundException: 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.
Source Error:
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34237
I had the same issue today during deployment. I was able to fix it by marking the assembly to be copied to the deployment file.
In order to do this, in my Visual Studio project, select the System.Web.Http.Webhost assembly in your references and alter the 'Copy Local' property to True. I had to repeat this for a few other assemblies that were missing.
Thanks to this website for the tips - http://haacked.com/archive/2008/11/03/bin-deploy-aspnetmvc.aspx/
Check the bin folder of your deployed project. It should contain System.Web.Http.WebHost.dll.
If this dll is in this folder, check it version. If it isn't 4.0.0.0, then you should deploy version 4.0.0.0 or change your web config to use other version (not really good idea because of dependencies)
Try to reinstall Microsoft.AspNet.WebApi package. Open Package Manager Console and type:
Update-Package Microsoft.AspNet.WebApi -reinstall
Be careful, this command will remove all dependencies and you will have to install them manually.
I had this error with an old project that I was going back to do a bit of work on. It turns out the project wasn't actually using WebApi so I uninstalled Microsoft.AspNet.WebApi using NuGet. That solved the problem for me.
If I'd actually have needed WebApi I'm sure installing it again would have fixed the error too.
I ran into this today after setting up a new Team City Build Agent. The new agent didn't have MVC 4 installed, perhaps part of the problem. Fortunately, I found this article which lead me to the solution. In Team City, I just updated the Build Step for the Nuget Restore so that it doesn't use the local cache.
This works because the cache may have been established by build runners with different (MVC) frameworks installed already.
I know this is answered but I thought I'd add something.
Every time I set "copy local" to true on a file causing the error I'd publish it and just get another one. So I just selected all of the files under references and set them all to true. This fixed the issue for me.
Important: This error message can be caused because you are deploying a 4.5 project to a server that doesn't have 4.0 installed. Make sure you have the .NET Framework version installed in IIS for the project you need. Some of these DLLs by default won't copy up, because it uses the core project DLL normally. Check to make sure your production server has the .NET version you're going with. I experienced this myself with a 4.5 project on a 4.0 server.
Ensure ASP.NET MVC 4 is installed on your server. Check it in the following location -
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4
I have a project that works great on my machine (and production servers).
It's a VS2010 project running C#3.5.
When letting my build server build the solution it can't resolve a couple of my third party dll's.
Error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9):
warning MSB3268: The primary reference
"Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" could not
be resolved because it has an indirect
dependency on the framework assembly
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which
could not be resolved in the currently
targeted framework.
".NETFramework,Version=v3.5". To
resolve this problem, either remove
the reference "Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" or
retarget your application to a
framework version which contains
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a".
[d:\Builds\3\mySolution.sln]
Everything compiles and runs great on my machine, but the build server seem to struggle.
I think the Third.Party.Assembly is written in VB.net.
Since the assembly is third party I can't remove the reference to "Microsoft.VisualBasic.Compatibility" and since I don't get any warnings on my computer could it really be that I'm running v3.5?
Any suggestions?
/Jimmy
If you put your project on the build server manually will it run? Based on the error message, I would make sure you have the latest .net framework installed on the build server machine and give it another try. If that does not work try installing VS2010 on the build server just to get the builds running until you find out just exactly what assemblies you are missing.
So, I was having this issue also on a VS2005 project that we upconverted... The issue is that MS has never had a 64-bit version of the VisualStudio.Compatability DLL. Our issue was that we were targeting 'Any' CPU and building on a new W2008R2 server so it was using the 64-bit version of the .NET 4.0 Multi-targeting pack.
In the build properties under the 'Process' tab under the '3. Advanced' there is a 'MSBuild Platform'. Change that value to "X86" and it might work... assuming of course you aren't depending on any 64-bit libs...
I'm facing a the following situation:
I created a simple full trust XBAP application that refers to unmanaged c++ COM server (isolated).
After deployment I expect that XBAP application will discover the COM server dll that is placed in the same directory, but it is not.
I'm getting the following error:
Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {970599E0-2673-11D3-A8A8-00105AA943DF} failed due to the following error: 80040154.
at Generation888.Generation888.Simple(Int32 num1, Int32 num2)
I verified that the folder where the XBAP was deployed contains the DLL and XBAP manifest that contains proper CLSID
If I created a simple C# Windows Form application and refers to the same COM dll, it works fine.
My question is does XBAP support Side-by-Side mechanism.
Thanks
I'm not terribly familiar with XBAPs so these are some general suggestions.
If your XBAP is in fact being launched as a separate executable since it's fulltrust (what does taskmgr say?), try using the "sxstrace.exe" tool from an elevated command line on Windows Vista or later to determine whether the XBAP manifest is actually being interpreted by the system. It's possible that if you first tried your application without a manifest or changed the manifest, the system cached this old information and you'll need to clear this manifest-state cache by touching the timestamp of both the manifest and the executable.
It's also possible that your executable has an embedded manifest, which would mean that the external manifest is being ignored. To check this open the executable up in Visual Studio and see if it has an RT_MANIFEST resource of ID 1.