Jenkins successfully build my job using MSBuild plugin(framework 4.0) with this Command Line Arguments
/p:Configuration=Debug /p:Platform="Any CPU" /p:PackageTempDir=C:\inetpub\wwwroot\Example_Jenkins
The problem is that the solution isn't published in the given directory(C:\inetpub\wwwroot\Example_Jenkins) it only goes in the jenkins workspace folder. I even tried changing the command line arguments to commands like in web publish still files are not being deployed in the given folder.
You doing it not in the correct way. The correct way is described, for example, here: http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild
msbuild Website.csproj "/p:Platform=AnyCPU;Configuration=Debug;PublishDestination=C:\inetpub\wwwroot\Example_Jenkins" /t:PublishToFileSystem
PS I don't think it's so much jenkins related :)
Related
I have Visual studio project solution which has multiple .csproj. Each .csproj has some reference libraries.The project settings are made in such a way the reference libraries are built first and then .csproj is built. This works as expected when i run it in visual studio IDE. But when i try to execute using msbuild i'm getting an error saying target doesn't exist. Gone through many posts related to this issue ,tried possible things.But didn't built.Looks like i might be doing something silly or missing something in the settings.
Also tried using devenv from commandline. With this option i dont see any error but at same time the project doesnt build.I dont see any message after execution of command.Im using visual studio 2015
Here is my project structure
Poject.sln
ProjectA
porjectB
projectC
Libraries
libA
libB
msbuild "project.sln" target:"D:\Projects\Source\Demo\ProjectA\ProjectA.csproj" /t:build
"/p:Configuration=Debug" "/p:platform=x86"
I see the below error
"D:\project.sln" (D:\Projects\Source\Demo\ProjectA\;build target) (1) ->
D:\project.sln.metaproj : error MSB4057: The target "D:\Projects\Source\Demo\ProjectA" does not exist in the project. [D:\project.sln]
Here is the command used using devenv
devenv.exe "project.sln" /build Debug /project `"D:\Projects\source\Demo\Applications\ProjectA\ProjectA.csproj" /projectconfig Debug
After executing the above its doesnt build and i dont see any error too.
error MSB4057: The target "D:\Projects\Source\Demo\ProjectA" does not
exist in the project.
The error indicates your path in command is not valid and project.sln can't recognize the path. So you actually meet one path-related issue. And you should pass the ProjectA to the targets argument instead of ProjectA.csproj! More details see tip3 in For MSBuild.
For MSBuild:
1.If you're only trying to build ProjectA and its reference libraries.
Navigate(cd) to path where ProjectA.csproj exists, and then use command msbuild ProjectA.csproj /t:build /p:Configuration=Debug /p:platform=x86
Also you can directly use command msbuild AbsolutePath\ProjectA.csproj /t:build /p:Configuration=Debug /p:platform=x86. It's not necessary to use " to cover the path and arguments.
(ProjectA.csproj file should have definitions about the reference to those two library projects, so msbuild ProjectA.csproj will build those two projects first. You don't need to specify the xx.sln in your command.)
2.If you're trying to build whole solution(all the projects):
msbuild project.sln /t:build /p:Configuration=xxx /p:platform=xxx
Navigate to solution folder when you run above command, or use absolutepath\project.sln with that command.
3.When you want to build specific projects(more than one) in solution:
Check How to: Build Specific Targets in Solutions By Using MSBuild.exe. Since you're only build ProjectA, you don't need to use this format. For example: Only when you need to build both ProjectA and ProjectB, but not build ProjectC... You can use command like:
msbuild xxx.sln /t:NotInSlnfolder:Build;NewFolder\InSolutionFolder:Build
Pay attention to the path when you use this format. Whether your project is in solution folder can affect the build result a lot ! And, the direct cause of your issue, this command's targets argument needs one ProjectName as input instead of ProjectName.csproj.
For Devenv command:
1.I always use VS2017 and VS2019,so I'm not certainly sure if VS2015's devenv related command has big difference from VS2017's or VS2019's. But according to details from this VS2017 document:
Commands that begin with devenv are handled by the devenv.com utility, which delivers output through standard system streams, such as stdout and stderr.
Alternatively, commands that begin with devenv.exe can use the same switches, but the devenv.com utility is bypassed. Using devenv.exe directly prevents output from appearing on the console.
I think that's why you don't see any message after execution of command. You should use devenv.com command to see the output in console. And it's by design that devenv.exe will prevents output from appearing on the console.
2.The following command builds the project CSharpWinApp, using the Debug project build configuration within MySolution.
devenv "%USERPROFILE%\source\repos\MySolution.sln" /build Debug /project "CSharpWinApp\CSharpWinApp.csproj" /projectconfig Debug
More details about devenv reference please check this document.
In addition:
1.Looks like you have one strange project structure. I checked your error message above and it seems your several projects(xx.csproj) are not under Solution(xx.sln) folder. Just a suggestion, the normal folder structure for VS2015 is always:
Solution folder
xx.sln
ProjectA folder
ProjectA.csproj
ProjectB folder
ProjectB.csproj
2.For most of the projects, build using msbuild is more powerful and convenient than build using devenv. So if you don't have special reason, I recommend using Msbuild, the build engine of VS.
Hope all above helps to resolve your issue and puzzle. Let me know if your issue persists:)
File "/Users/morel893/Desktop/env/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "projects_project" does not exist
LINE 1: ...ct"."technology", "projects_project"."image" FROM "projects_...
I want to build my solution file in azure devops. I have added this to build pipeline, I see this step doesn't succeed. It tells " MSBUILD : error MSB1008: Only one project can be specified." I suspect I am making some mistake in specifyning
msbuild args
msbuild $(Build.SourcesDirectory)\ansysfnonet\ansysfnonet.vs2017.sln /t:$(Build.SourcesDirectory)\ansysfnonet\ansysfnonet.csproj:Rebuild;
I tried specify only proj file as msbuild arg it didn't work for me
I tried without specifying msbuild it throws me whole lot of errors.
Someone please help me , why I am failing in this step and how to solve this error.
Thanks
You don't need to specify an msbuild command line in the MSBuild Arguments field. You need to specify any additional MSBuild parameters beyond the defaults.
Clear that field. That should fix the problem you're encountering.
Good evening,
I am using the .Net Core 2.0 version from here https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild on a 2.1 project in Jenkins with:
withSonarQubeEnv('SonarQubeMain') {
bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll begin /k:\"${globals.SONAR_QUBE_PROJECT}\" /d:sonar.host.url=${globals.SONAR_HOST_URL} /d:sonar.cs.xunit.reportsPaths=\"XUnit.xml\" /d:sonar.cs.opencover.reportsPaths=\"coverage.xml\"
}
bat "dotnet build --version-suffix ${env.BUILD_NUMBER}"
dir('test/mytestprojecthere') {
bat 'D:\\OpenCover\\OpenCover.Console.exe -target:"c:\\Program Files\\dotnet\\dotnet.exe" -targetargs:"xunit --no-build -xml XUnit.xml" -output:coverage.xml -oldStyle -filter:"-[*Tests*]*" -register:user'
}
withSonarQubeEnv('SonarQubeMain') {
bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll end"
}
It works the first build but on the next build it fails with:
Failed to create an empty directory 'D:\Jenkins\workspace\xxxxxxxx\.sonarqube'.
Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions.
Detailed error message: Access to the path 'SonarScanner.MSBuild.Common.dll' is denied.
and checking my windows server I can see multiple .Net Core Host Background process. If I kill these I can build again..
I readed about msbuild /nodereuse:false for MSBuild but seems is not working for the dotnet core version?
We were just faced with this issue, and found out that it's related to dotnet's and msbuild's reuse of nodes that were left running by a previous multi-threaded build.
To avoid the problem, use either /nodereuse:false or /nr:false on your command line as the following:
msbuild /m /nr:false myproject.proj
msbuild /m /nodereuse:false myproject.proj
dotnet restore myproject.sln /nodereuse:false
FYI #Nauzet opened an issue open for this in the Scanner for MSBuild repo: #535.
To summarise:
the begin and end steps seem to run fine, and dotnet.exe shuts down as expected for those processes
when building a complex solution, multiple instances of dotnet.exe are started and are do not shut down immediately when the build completes. The issue does not seem to occur on simpler solutions.
the issue occurs if you trigger the build phase using dotnet build or dotnet msbuild
workarounds: build using msbuild directly, or build using dotnet build /nodereuse:false
FYI the Scanner for MSBuild has a couple of custom tasks that are called during the build phase. These use the assembly that is being locked. There's nothing unusual about the custom tasks; they just read data from a file on disk. At this point, I'm not convinced it's an issue with the Scanner for MSBuild.
I faced same issue and running following command solved the issue.
dotnet build-server shutdown
This happens due to msbuild node re-use. we leave msbuild nodes alive with the intent of saving on startup time when doing consecutive builds.
It can turned off by setting an following environment variable too.
MSBUILDDISABLENODEREUSE=1
Please edit your pipeline script as shown below and it should work properly:
withSonarQubeEnv('SonarQubeMain') {
bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll begin /k:\"${globals.SONAR_QUBE_PROJECT}\" /d:sonar.host.url=${globals.SONAR_HOST_URL} /d:sonar.cs.xunit.reportsPaths=\"XUnit.xml\" /d:sonar.cs.opencover.reportsPaths=\"coverage.xml\"
bat "dotnet build --version-suffix ${env.BUILD_NUMBER}"
dir('test/mytestprojecthere') {
bat 'D:\\OpenCover\\OpenCover.Console.exe -target:"c:\\Program Files\\dotnet\\dotnet.exe" -targetargs:"xunit --no-build -xml XUnit.xml" -output:coverage.xml -oldStyle -filter:"-[*Tests*]*" -register:user'
}
bat "dotnet ${globals.SONAR_QUBE_MSBUILD_PATH}\\SonarScanner.MSBuild.dll end"
}
UPDATE
Here is a dotnet core app pipeline build script that I use, which works well without any issues:
bat "dotnet ${sqScannerMsBuildHome}\\SonarScanner.MSBuild.dll begin /k:yoursonarprojectkey /n:yoursonarprojectname /v:1.0 /d:sonar.host.url=%SONAR_HOST_URL%"
bat 'dotnet build'
bat "dotnet ${sqScannerMsBuildHome}\\SonarScanner.MSBuild.dll end"
I just ran into it myself and "solved" it by running dotnet build-server shutdown as the first task in my build plan. That's not ideal for multiple reasons, one big one being that it'll likely cause issues if I attempt to run multiple .NET Core builds at once on the same machine. This does seem to be a bug in the scanner -- hopefully it'll be fixed soon.
I've been using Jenkins/Hudson CI for deploying my .NET web site project. I've been using the MSbuild plugin to build my project, and then xcopy to copy it out to the server.
I've noticed if I use the publish feature in Visual Studio I get a different set of files. I've got the config transforms working, but I end up with all the .cs files and a winmerge compare shows the binaries being different.
So, I'd like to either get Jenkins working just like the publish feature, or confirm that an xcopy deploy is functionally the same thing.
I've had good experiences with using Web Deploy and as a final build step with Jenkins running a bat file containing:
msdeploy.exe -verb:sync -source:package=%PACKAGE% -dest:auto,ComputerName=%TARGETHOST%
You'll have to install the web deploy package on your build server and the extention on IIS.
I'm using the MSBuild Jenkins plugin to build and then deploy the project. As mentioned in other answers, you need to have Web Deploy installed.
In the project configuration page in Jenkins, you need to add the following to the Command Line Arguments field:
/p:Configuration=Debug /p:DeployOnBuild=true /p:PublishProfile=publishProfileName
Of course, you need to first create the publish profile, either in VS or by exporting it from IIS and you also need to specify the solution file path in the MSBuild Build File field.
I have configured Visual Studio 2010 to debug xUnit.net tests by setting the Project Settings | Debug | Start External Program to run the xUnit.net console runner.
This works OK but only when providing the complete path to the test project dll via the Command Line Arguments eg: "c:\development\TestProject.dll"
I have tried using $(BinDir)$(TargetName)$(TargetExt) as parameters via the Command Line Arguements section but it does not work. Any suggests on how I can avoid the explicit/full path?
This is what I use in my .csproj file to run the xUnit GUI runner as the start action:
<PropertyGroup>
<StartAction>Program</StartAction>
<StartProgram>$(MSBuildProjectDirectory)\..\..\Packages\xunit.runners.1.9.1\tools\xunit.gui.clr4.exe</StartProgram>
<StartArguments>"$(MSBuildProjectDirectory)\$(OutPutPath)$(AssemblyName).dll"</StartArguments>
</PropertyGroup>
For this to work, all you have to do is install the xUnit.net Runners NuGet package:
PM> Install-Package xunit.runners
The only downside so far, is that it's version specific, so every time you update the NuGet package to latest, you should update this configuration to point to the correct runner.
This answer was given before James' and Brad's awesome work with xUnit.net Runners. See michielvoo's answer below.
To avoid the problem of explicitly giving the library name one can use cmd.exe with command line arguements: /C xunit.console.exe $(BinDir)$(TargetName)$(TargetExt)
Check Use Output Window
Use the Tools|Options|Keyboard configuration to assign a hot key.
A alternative route is use a VS plugin as testrunner. For instance ReSharper.
I simply type the full name of the assembly thats all.
Under command line arguments: SharedDataBridge.Tests.dll