The build for my solution, which contains multiple projects, suddenly appears to be broken and the cause of the issue isn't clear. All of the projects in the solution target the same framework (4.5.1), however, some of the projects' dependencies might be targeting an earlier version of the framework. As of last week, we were able to successfully build solutions that fall under this scenario. Starting last Thursday, the builds appear to be broken without any changes to the build server or the solution.
To illustrate and remove some of the complexities with our production setup, I created a sample solution which mimics the behavior.
Project structure:
CBI Solution
CBI website
CBI Implementation Library
CBI Core library, defining the interfaces
Target Framework Version for the website and class libraries is 4.5.1
Replication Steps
Solution 1
Github repo: https://github.com/NikitaGolovko/Solution1.git
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION1PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
Done executing task "AspNetCompiler".
Task "Message" skipped, due to false condition; (!((false) or ('$(AspNetConfiguration)' == 'Debug') or ('$(AspNetConfig
uration)' == 'Release'))) was evaluated as (!((false) or ('Release' == 'Debug') or ('Release' == 'Release'))).
Done building target "Build" in project "cbi.metaproj".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\cbi.metaproj" (default targets).
Done executing task "MSBuild".
Done building target "Build" in project "CBILite.sln".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\CBILite.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:03.10
Full output is located here: https://github.com/NikitaGolovko/Solution1/blob/master/MSBuild_Output.txt
Solution 2
Github Repo: https://github.com/NikitaGolovko/Solution2.git
The solution is nearly identical to the Solution1, with the only exception being a dependency for Unity in CBI Implementation library. To simplify the process and eliminate the nuget restore step, I have included nuget packages with the solution.
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION2PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
D:\Work\DotNet\Nikita\Solution2\cbi\Index.aspx.vb(5): error BC30002: Type 'CBILite.Calculator' is not defined. [D:\Work
\DotNet\Nikita\Solution2\cbi.metaproj]
The command exited with code 1.
Done executing task "AspNetCompiler" -- FAILED.
Done building target "Build" in project "cbi.metaproj" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\cbi.metaproj" (default targets) -- FAILED.
Done executing task "MSBuild" -- FAILED.
Done building target "Build" in project "CBILite.sln" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\CBILite.sln" (default targets) -- FAILED.
Build FAILED.
Full output is located here: https://github.com/NikitaGolovko/Solution2/blob/master/MSBuild_Output.txt
Observations
Bin folder
When looking in the bin folder of the website, I notice that CBILite.dll is missing after the build for Solution2, but present in Solution1.
TargetFrameworkVersion
Passing TargetFrameworkVersion in the MSBuild arguments does not appear to influence the build. I have attempted to pass 4.5, 4.5.1 to no avail. HOWEVER passing 3.5 results in the successful build. This is extremely strange.
Metaproj
When comparing Metaproj files generated for both solutions, the only observable and seemingly important difference is the lack of the TargetFrameworkVersion element. Solution1 (without dependencies), contains v.4.0 element. Solution2 (with the dependency) does not.
I didn't include metaproj files in the repo but can share them if needed.
Visual Studio
Building the solution in Visual Studio works just fine.
Additional thoughts
The issue manifested itself rather suddenly and seems to be affecting most of our solutions that have mixed projects (C#/VB + website). Web Projects continue to function normally.
I've attempted to use MSBuild 15, but it resulted in the same behavior.
There are a few workarounds
Retaining the metaproj file with the solution and modifying it manually by adding v4.5.1 element.
Adding an additional build step to manually copy CBILib.dll into the website project (via the batch file or other means).
Adding a refresh file for the website pointing to CBILib/bin/Release folder
While all of these solutions might work, they're certainly hacks and will present problems in the future.
I'm hoping someone else has a better suggestion on how to handle this.
Make sure you have installed the following NuGet packages:
Microsoft.NET.Test.Sdk
MSTest.TestAdapter
MSTest.TestFramework
Microsoft.NETCore.App (if you use .NET Core)
Related
I am doing automation using selenium and c#. Everything is running file when I run from visual studio but getting issue in file path then run via jenkins.
Batch command I am trying :
"nuget.exe" restore UnitTestProject1.sln
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" UnitTestProject1.sln
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\MSTest.exe" /testcontainer:UnitTestProject1\bin\Debug\UnitTestProject1.dll
Output from Jenkins :
Building in workspace C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1
[UnitTestProject1] $ cmd /c call C:\Users\developer\AppData\Local\Temp\jenkins934555759751738078.bat
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"nuget.exe" restore UnitTestProject1.sln
MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\bin'.
All packages listed in packages.config are already installed.
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" UnitTestProject1.sln
Microsoft (R) Build Engine version 4.6.1055.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 3/5/2018 6:38:36 PM.
Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" on node 1 (default targets).
ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" (1) is building "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\UnitTestProject1.csproj" (2) on node 1 (default targets).
Project file contains ToolsVersion="15.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="4.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=291333.
GenerateTargetFrameworkMonikerAttribute:
Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
CoreCompile:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
_CopyOutOfDateSourceItemsToOutputDirectory:
Skipping target "_CopyOutOfDateSourceItemsToOutputDirectory" because all output files are up-to-date with respect to the input files.
_CopyAppConfigFile:
Skipping target "_CopyAppConfigFile" because all output files are up-to-date with respect to the input files.
CopyFilesToOutputDirectory:
UnitTestProject1 -> C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\bin\Debug\UnitTestProject1.dll
Done Building Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1\UnitTestProject1.csproj" (default targets).
Done Building Project "C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1\UnitTestProject1.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.03
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\MSTest.exe"
Microsoft (R) Test Execution Command Line Tool Version 15.0.27019.1
Copyright (c) Microsoft Corporation. All rights reserved.
Please specify tests to run, or specify the /publish switch to publish results.
For switch syntax, type "MSTest /help"
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>/testcontainer:UnitTestProject1.dll
The filename, directory name, or volume label syntax is incorrect.
C:\Users\developer\.jenkins\workspace\LinkedinAutomation\UnitTestProject1>exit 123
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
It seems everything is fine till end. It has issue in finding project dll file at end with test container.
I have the following set as a Windows Batch command:
. This is one long line that runs the individual project Test DLLs of our components. Each DLL is from a Unit Test Project.
It appears that your command line has forward slashes, and not the Windows directory separator, the backslash.
I have also found that I needed a different command line to get my tests running properly. I had to use the vstest.console.exe to run the tests.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" Application_Tests\bin\Release\Application_Tests.dll AppLib_Tests\bin\Release\AppLib_Tests.dll
For the full command line: vstest.console.exe command line
We have over 20 solutions in our main product portfolio (over 880 projects), and we have a complex set of build scripts that work well, but we are trying to automate the restore of nuget packages from within the msbuild pipeline. Currently this is done with a manual call out to nuget to restore the packages.
According to https://learn.microsoft.com/en-us/nuget/schema/msbuild-targets I should be able to run this command and have the restore run:
# works
& $script:msBuildPath $solutionName /t:build /v:q /clp:ErrorsOnly /nologo /p:...
# doesn't works
& $script:msBuildPath $solutionName /t:restore,build /v:q /clp:ErrorsOnly /nologo /p:...
However, when I add the restore, to the above it throws an error
MSB4057: The target "restore" does not exist in the project
Where do I start researching to understand why it can't find this target? We are predominantly on VS 2015 and .NET 4.6.2, so anything specific to VS2017 is not an option for me at this time.
If I omit the /v:q and /clp:ErrorsOnly flags I do get this (slightly sanitized solution/project names and paths)
PS Z:\git\company> build c
building Common\Common.sln
Build started 11/15/2017 11:08:54 AM.
1>Project "Z:\git\company\Common\Common.sln" on node 1 (restore;build target(s)).
1>ValidateSolutionConfiguration:
Building solution configuration "DEBUG|Any CPU".
1>Z:\git\company\Common\Common.sln.metaproj : error MSB4057: The target "restore" does not exist in the project. [Z:\git\company\Common\Common.sln]
1>Done Building Project "Z:\git\company\Common\Common.sln" (restore;build target(s)) -- FAILED.
Build FAILED.
"Z:\git\company\Common\Common.sln" (restore;build target) (1) ->
Z:\git\company\Common\Common.sln.metaproj : error MSB4057: The target "restore" does not exist in the project. [Z:\git\company\Common\Common.sln]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.03
runBuildPackage : ... failed
At Z:\git\company\psincludes\buildFunctions.ps1:11 char:5
+ runBuildPackage "Common\Common.sln"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,runBuildPackage
msbuild failed
At Z:\git\company\psincludes\buildInternals.ps1:63 char:21
+ throw "msbuild failed";
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (msbuild failed:String) [], RuntimeException
+ FullyQualifiedErrorId : msbuild failed
I realize some of this around is our internal tooling, I just didn't feel the need to obscure that part.
According to "the internet" this should just be "free" as part of the build process, and I'm not sure what we are missing in the csproj files here.
The msbuild-integrated NuGet functionality is available in NuGet 4.0+ in conjunction with MSBuild 15, which means only in VS 2017. There is no support for the restore target for VS 2015.
The integrated restore in VS 2017 / NuGet 4 only works for projects using the new PackageReference style of referencing NuGet packages. It does not work for projects using packages.config. This new way of referencing packages is the default option for ASP.NET Core (both on .NET Framework / .NET Core), .NET Core and .NET Standard projects. It is opt-in for all other project types by selecting the style before the first install in the NuGet properties (Tools->Options->NuGet).
Note that calling /t:Restore,Build is not a good way to call this target, since restore may generate or change files that msbuild then doesn't reload. MSBuild 15.5 (upcoming update to VS 2017) introduces a /restore option instead that will call the restore target, then clear all caches which could not be cleared before and execute the normal build as requested. Before 15.5, it is best to make two distinct calls to msbuild.
I have a C# solution with 3 projects.
App.Console\App.Console.csproj
App.Web\App.Web.csproj
App.Shared\App.Shared.csproj
Both App.Console and App.Web reference App.Shared. Currently, I build each project separately as they have slightly different MSBuild arguments.
My current build process is as follows
MSBuild.SonarQube.Runner.exe begin /k:"MyApp" /n:"My App" /v:"1.0"
msbuild.exe msbuild App.Console\App.Console.csproj /t:'Rebuild' /p:Configuration=Release /p:OutDir=C:\Out\Console
msbuild.exe msbuild App.Web\App.Web.csproj /p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=C:\Out\Web
MSBuild.SonarQube.Runner.exe end
I see statistics for both App.Console and App.Web, however, statistics for App.Shared is missing. Instead, I notice a warning in the SonarQube runner output.
WARNING: Duplicate project GUID: "21889c3d-d9c4-40d6-a4e4-971735d19ee2". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. Project file: C:\Projects\MyApp\App.Shared\App.Shared.csproj
I believe this warning is the root of my problem.
If I do the following:
MSBuild.SonarQube.Runner.exe begin /k:"MyConsoleApp" /n:"My Console App" /v:"1.0"
msbuild.exe msbuild App.Console\App.Console.csproj /t:'Rebuild' /p:Configuration=Release /p:OutDir=C:\Out\Console
MSBuild.SonarQube.Runner.exe end
MSBuild.SonarQube.Runner.exe begin /k:"MyWebApp" /n:"My Web App" /v:"1.0"
msbuild.exe msbuild App.Web\App.Web.csproj /p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=C:\Out\Web
MSBuild.SonarQube.Runner.exe end
I now have 2 separate projects in SonarQube which both contain statistics for App.Shared. This is bad because this information is duplicated between the two projects and does not accurately give me an overall technical debt for my solution.
I have been able to get all three set of statistics in one project by building the solution only:
MSBuild.SonarQube.Runner.exe begin /k:"MyApp" /n:"My App" /v:"1.0"
msbuild.exe msbuild App.sln /t:'Rebuild' /p:Configuration=Release
MSBuild.SonarQube.Runner.exe end
This is not ideal because building the solution does not build the web project the way I need, thus I must do a 2nd build after SonarQube completes (build the way I need it, not the way SonarQube wants it).
Is it possible to run msbuild multiple times in-conjunction with the SonarQube MSBuild runner and get one set of complete statistics?
In the shared app, you can conditionally set a <SonarQubeExclude>true</SonarQubeExclude> property, such that it will be set only when building either App.Web or App.Console.
You can find a proposal on how to achieve this in the Microsoft ALM Rangers guide to SonarQube under Appendix 3, "Explicitly associating an MSBuild project with a SonarQube project": http://redirect.sonarsource.com/doc/sq-setup-guide-for-dotnet-users.html
The issue might be that you have an extra *.sln file in your solution. I encountered this when there was an old, dormant .sln file in a project folder. Deleting it resolved the issue.
I'm running VS 2010 and I have a project which was originally set to build to .NET 4.0. This rev of .NET is too high for many of the windows platforms this app is expected to run and so I switched it from .NET 4.0 to .NET 2.0. Now, the project doesn't build.
At first I was getting null reference exceptions with the project resources. I found this link on MSDN forums which proved helpful in fixing that issue. Essentially, the answer (among the many) that worked was to change all instances of:
Version=4.0.0.0
to
Version=2.0.0.0
... in the *.resx files. I did this to all *.resx files I could find in the project directory. Walla, no more null reference exceptions during the build. However, now the project simply fails to build and the build window offers nothing in way of help to resolve. This is literally what's there:
2>CoreCompile:
2> C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /platform:x86 /errorreport:prompt /warn:4 /define:TRACE /reference:C:\Users\afalanga\Dev\Tools\Program\FrontEnd\Resources\WrapNativeLibrary.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Management.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /debug:pdbonly /filealign:512 /optimize+ /out:obj\x86\Release\FrontEnd.exe /resource:obj\x86\Release\FrontEnd.Panel.resources /resource:obj\x86\Release\FrontEnd.PrivilegesForm.resources /resource:obj\x86\Release\FrontEnd.Main.resources /resource:obj\x86\Release\FrontEnd.Properties.Resources.resources /resource:obj\x86\Release\FrontEnd.SoftwareLicense.resources /resource:Resources\WrapNativeLibrary.dll,WindowsUpdateTool.Resources.WrapNativeLibrary.dll /resource:Resources\INativeLibrary.dll,FrontEnd.Resources.INativeLibrary.dll /target:exe /win32icon:Resources\FrontEnd.ico /win32manifest:Resources\app.manifest Environment.cs Check.cs Exceptions.cs Updater.cs LibAccess.cs PrivilegesForm.cs Form1.Designer.cs OSInfo.cs Constants.cs PersonalizationManager.cs Silent.cs drivePanel.cs drivePanel.Designer.cs Main.cs Main.Designer.cs Program.cs Properties\AssemblyInfo.cs SoftwareLicense.cs SoftwareLicense.designer.cs VerticalProgressBar.cs Properties\Resources.Designer.cs Properties\Settings.Designer.cs
2>
2>Build FAILED.
Is it due to the fact that the C# compiler being referenced is the 4.0 version? At this point, I'm completely at a loss for what to check. I'm considering a fresh checkout of the branch for this code from TFS and trying there but haven't gone that route yet. I would appreciate any insight as everything I can see from the project properties says it should be targeting .NET 2.0 and it "should" build.
Thanks,
Andy
When you're downgrading your build target, you might be better off to start with a new project, change the build target then import your code into it. This way all your core dependencies start out right, and you'll only have to worry about the code being able to work.
I have a .net application built on .net framework 3.5, I am trying to build this application on Jenkins CI server. I've added MSBuild plugin and and have added path to the .exe file of 2.0, 3.5 and 4.0 versions of MSBuild. But my building processes are failing by showing the below error message.
Path To MSBuild.exe: msbuild.exe
Executing command: cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
[Test project] $ cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
'msbuild.exe' is not recognized as an internal or external command,
operable program or batch file.
Build step 'Build a Visual Studio project or solution using MSBuild.' marked uild as failure
Finished: FAILURE
Could anyone plz help me out..??
To make the MSBuild plugin work, you need to configure the plugin in the Jenkins management screen.
NOTE: in the newer Jenkins versions you find the MSBuild configuration in the Global Tool Configuration:
Note the "Name" field, where I've called this particular configuration v4.0.30319. You could call it anything you like, but ideally the name will somehow refer to the version.
You'll need to refer to this name later in the Jenkins PROJECT that's failing.
Note: The yellow warning implies that the Path to MSBuild field should be populated with a directory name rather than a file name. In practice you do need to enter the filename here too (ie. msbuild.exe) or the build step will fail.
In the Jenkins project that's failing, go to the MSBuild build step.
The first field in the build step is "MSBuild Version". If you created the build step before configuring any MSBuild versions, the value here will be (default).
After configuring one or more MSBuild versions, the drop down will be populated with the available configurations. Select the one you require.
You can see here that I've now selected the named configuration that matches the installation above.
Jenkins | Manage Jenkins | Configure System
scroll down to the MSBuild section and click MSBuild installations
define the full path to msbuild.exe, on my system I have 3.5 and v4.0.30319
Note - specify the path to 32-bit tools even on a 64-bit system, otherwise you might get an error message:
Building Windows Phone application using MSBuild 64 bit is not supported.
So in Jenkins - it could be for example:
Name: Version 3.5
Path: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Name: Version 4.0
Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSbuild.exe
I think you should set an absolute path for "msbuild.exe" in your Jenkins configuration,
for example:
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
You can also add the path where the msbuild.exe is, to the PATH system environment variable of the node (or nodes) that is running that specific job.
You could try executing the
%comspec% /k ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
command, which will temporarily update your environment path variables to reflect the VS2010 build environment. Execute this before you call MSBUILD and see what happens. I use this in my own build scripts with no issues.
Side note; it's very likely counterproductive to have multiple versions of MSBUILD on your PATH. Concentrate on getting one version working and go from there.