I'm running MSBuild 4.0 against my .net 4.0 solution and I am getting a lot of error similar to the following:
"E:\Hudson\jobs\HCIM 7.0.0\workspace\7.0.0\HCIM_Dev\BC_HCIM.msbuild" (default target) (1) ->
"E:\Hudson\jobs\HCIM 7.0.0\workspace\7.0.0\HCIM_Dev\BC_HCIM.sln" (Build target) (2:2) ->
"E:\Hudson\jobs\HCIM 7.0.0\workspace\7.0.0\HCIM_Dev\src\Common\HCIM.Distribution.Service\HCIM.Distribution.Service.csproj" (default target) (46:3) ->
(CoreCompile target) ->
DistributionProcessor.cs(6,32): error CS0234: The type or namespace name 'Distribution' does not exist in the namespace 'HCIM.BusinessTransaction' (are you missing an assembly reference?) [E:\Hudson\jobs\HCIM 7.0.0\workspace\7.0.0\HCIM_Dev\src\Common\HCIM.Distribution.Service\HCIM.Distribution.Service.csproj]
When I build this in the IDE, it compiles fine (VS 2015, VS 2013), however on Jenkins and when I locally run my script, these are the errors that comes up.
Looking at the IDE and the .csproj files I see that these assemblies are referenced accordingly.
Thoughts?
This sounds like an msbuild and/or framework version issue. Here's a few things to check:
What framework version are your projects referencing? Maybe one is targeting a higher version than 4.0
Make sure this framework version is installed on build server.
Try adjusting your script to use the same msbuild version as the IDE
Note Msbuild is not part of the framework since VS2013 but a separate download is available for running on your build server.
Related
Project Setup : Mixed framework solution
.Net Framework 4.6.2 projects in solution : 15
.Net Standard 2.0 projects in solution - 1
Development Machine
Visual Studio 2017(15.7.4) : Builds without any errors
Build Server
TeamCity Version 2017.1.3
Build Steps
Nuget Restore(3.4.4)
dotnet Restore
MSBuild( Build Tools 2017), Tools Version 15.0
Build fails with following error in the .net standard 2.0 project : [ResolvePackageAssets] C:\Program Files\dotnet\sdk\2.1.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198, 5): Package System.Security.Cryptography.ProtectedData, version 4.4.0 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
What's interesting is I can't find reference or use of System.Security.Cryptography.ProtectedData anywhere in the project. Any help is greatly appreciated.
P.S - Can't use dotnet build, as the solution needs building of licenses.licx files, and the component which builds it (Microsoft.Build.Tasks.LC) is not ported to .Net Core. The suggestion from various posts was to use MsBuild.exe
After following several blogs detailing how to get xUnit working with Team Services Build vNext:
http://tech.trailmax.info/2014/01/run-xunit-in-hosted-team-foundation-service/
Running unit tests in TFS/VSO Build vNext using xUnit adapter
http://www.donovanbrown.com/post/2015/06/15/how-to-run-xunit-test-with-vnext-build
None of which worked for me. From examining the build logs I get the following warnings for each of my test assemblies.
--------------------
Warning: [xUnit.net 00:00:00.1644156] Exception discovering tests from CHO.SAM.Business.Test: System.BadImageFormatException:
Could not load file or assembly 'c:\_Work\473cef3c\CHO\CHO.ALL\Tests\CHO.SAM.Business.Test\CHO.SAM.Business.Test\bin\Debug\xunit.execution.desktop.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
--------------------
Has anyone seen this before? and if so did you figure out a solution?
My thoughts are; my test projects are compiled using .NET Framework 4.6, I was wondering if this could be causing the problem? If so I would have to move over to nUnit or something as I don't feel it's right to change the compilation just to use a single test framework.
Add "/Framework:Framework45" to "Advanced/Other console options" (to run under .NET 4.5)
or
Add "/Framework:Framework40" to "Advanced/Other console options" (to run under .NET 4.0)
or
Change "Advanced/VSTest version" to "Visual Studio 2013" (to run under .NET 3.5)
This error is normally caused by a x64 compiled assembly running on x86 test runner or vice versa. Check the solution build configuration that is being run.
I had this same issue. Adding a UI test did not fix it for me. I found two alternatives that work:
use .net 4.5
OR
Set the advanced options of the VSTest task to use 2013 instead of 2015.
Hopefully this will be fixed soon.
In the end, I added a Visual Studio Coded UI test project and removed all it's contents (a class), it's empty!
I'm assuming it's added a reference or something that the build server felt it needed.
I am now getting my unit tests discovered, running and with code coverage.
Wierd!
It works, but I don't know why...
I ran into this issue when using a .Net Core class library to run my xUnit tests against a .Net Core Web Project (.Net Framework). What solved the issue for me was to change the default processor for running test to X64 in VS2015 via:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
This solution was posted by #RehanSaeed here https://github.com/dotnet/cli/issues/3103
I created a new ASP.NET 5 preview project in VS 2015 RTM (fully updated). When I try to debug it, it fails with the following exception:
The current runtime target framework is not compatible with
'ProjectName'.
Current runtime Target Framework: 'DNX,Version=v4.5 (dnx45)' Type:
CLR Architecture: x86 Version: 1.0.0-beta6-12256
Please make sure the runtime matches a framework specified in
project.json
I went with the default settings in the new project dialog, which I believe included a dependency on .NET 4.5.1 (though there's no mention of that dependency in the project.json file - contrary to what the exception message claims). I tried the solution offered here (defining the DNX_IIS_RUNTIME_FRAMEWORK environment variable in the project's debug settings) without success.
Install latest tools and try again. Beta 6 isn't apt to be supported and lots changed since then. You can get the tools here: http://www.microsoft.com/en-us/download/details.aspx?id=49442
I wanted to have a look at monodevelop, thinking about possible moving in-house projects written in .Net from Windows to Linux.
I installed mono-complete 4.0.2 and monodevelop 5.9.4 on a clean Ubuntu 14.04 VM, I assume those are the latest/current versions.
Now C# works, but I can't get it to compile any VB code.
Any new VB project I create first refuses to load.
Quickly found (Google) that the mono VB compiler doesn't support framework 4 or higher yet, but the project template generates projects targeted at 4.5.
After I manually edit the project file to target 3.5, 3.0 or 2.0, the projects load (this works for console as well as GTK projects).
But when I try to compile it then, no own code added yet, just the auto-generated base code, it just fails without any error messages.
Build output:
Building: VbHelloConsoleWorld (Debug|x86)
Build started 7/3/2015 10:42:20 AM.
__________________________________________________
Project "/home/luc/projects/VbHelloConsoleWorld/VbHelloConsoleWorld.vbproj" (Build target(s)):
Target PrepareForBuild:
Configuration: Debug Platform: x86
Target GenerateSatelliteAssemblies:
No input files were specified for target GenerateSatelliteAssemblies, skipping.
Done building project "/home/luc/projects/VbHelloConsoleWorld/VbHelloConsoleWorld.vbproj".-- FAILED
Build FAILED.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.0438100
---------------------- Done ----------------------
Build successful.
Am I still missing some dependencies? Other stuff that must be fixed before a VB project will work?
For some reason building VB.NET with MSBuild does not work.
To workaround this you can disable the use of the MSBuild build engine. Go into project options, Build - General and uncheck Use MSBuild build engine. Then the project should compile and generate an output assembly.
We're using Cruse Control to manage our build process.
AS we convert vs2008 projects to vs2010, we're leaving the target framework set at 3.5 for web and class library projects.
At this point we're not going through and converting all our solutions to vs2010; not if we don't have to.
I recently updated the MSbuild project files that cruise control uses to point at MSBuild 4.0 so our build process would be able to build vs2010 projects.
C:\windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
All was well until a web project that was targeting the 4.0 framework was committed.
At which point this error popped up:
CS0433: The type 'System.Web.Routing.RouteCollection' exists in both c:\Windows\Microsoft.NET\assembly\GAC_32\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll and c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Web.Routing.dll in Global.asax.cs(15, 43)
At which point I became aware of the Windows/Microsoft.NET/Assembly folders.
Now... All the MSBuild projects, even though they were using MSBuild 4.0, still had the tools version set at 3.5.
So why was a 3.5 targeted build looking at the new 4.0 assembly folders and finding this conflict? Probably because I was using MSBuild 4.0. But if I can change the toolVersion that MSBuild uses, you'd think I can tell it to target 3.5 without worrying about these potential conflicts.
To resolve this issue, I went to the relevant MSBuild project files that cruise control uses and changed their toolsVersion to 4.0. This got passed that conflict error. But now everytime it tries to build a project that's in a solution that we haven't yet converted to a vs2010 project, it breaks with an error like this:
MyProject.csproj in SomeFilePath:
LC0000: 'Could not load file or assembly or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.' in LC(0, 0)
If I open the solution that contains that project in Visual Studio 2010 and do the conversion, build it and commit that and force another build, I get passed that error only to find that another not yet converted project is tossing that same error.
So now I am for sure using MSBuild 4.0 and for real targeting the 4.0 framework. Why can't 4.0 build 3.5 projects or vs2008 solution projects?
The issue is that you have migrated part of your projects to to visual studio 2010. Any 2008 project that references a 2010 project (by project reference) will give you this compile time error. Try updating all .csproj files to 2010 and try rebuilding again.