I am trying to build, package and deploy a web application using Teamcity but for some reason Teamcity is ignoring the properties that I am passing to MsBuild.exe.
I have created a step in the build configuration to build, package and deploy teh application to the local server. Here are the properties:
/P:Configuration=Release
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:DeployIISAppPath=MyDeployedWebsitePath
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=Administrator
/P:Password=******
/P:MsDeployServiceUrl=MyServerName
Passing them as command line parameters to MSBuild step or declaring them as System Properties in Parameters tabs doesn't seem to work. Teamcity builds the application but ignores the package and deployment steps!
If I execute MSBuild through command line on the same server (with the same params) the package and deployment works.
I am following the steps mentioned in Troy Hunt's series: https://www.troyhunt.com/you-deploying-it-wrong-teamcity_26/
I have read a lot of stack overflow questions and it seems to work seamlessly for others. I am not sure what's going wrong.
I would really appreciate any help.
Update - Build log
> Step 2/2: Build (MSBuild) (51s)
[18:32:48][Step 2/2] ##teamcity[buildStatisticValue key='buildStageDuration:buildStepRUNNER_18' value='0.0']
[18:32:48][Step 2/2] Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\b12fe165603f4f19 /msbuildPath:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
[18:32:48][Step 2/2] in directory: C:\TeamCity\buildAgent\work\b12fe165603f4f19
[18:32:56][Step 2/2] Targets were not defined in the build configuration.
[18:32:56][Step 2/2] MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead.
[18:33:02][Step 2/2] EnsembleID.Web\EnsembleID.Web.csproj.teamcity: Build target: Build (37s)
[18:33:40][Step 2/2] Process exited with code 0
It turned out to be a version issue :/
I tried different options for MSBuild version - Microsoft .Net Framework 4.5, 4.0 etc.
Finally, Microsoft Build Tools 2015 option worked.
For the past week I have been banging my head on this and I lost track of what all different permutations I tried. I had installed all the different versions of framework tools and web deployment tools, I am not sure why the other options didn't work for me. So if someone is facing a similar problem, make sure to try out different MSBuild version.
Related
The CI pipeline works well if I remove the nobuild:true option from the DotNetCoreCLI#2 task to pack the Project (ie to create a NuGet package) but I am not able to understand what special except not building the project does the nobuild option brings.
I need not want to build the Project again as the Previous task have already build the Project and locked the Assembly version of DLLs generated. I want to use the same build to create the NuGet package and to do the same I need to pass the NoBuild option but doing the same breaks the pipeline.
The pipeline gives the error that the DLLs to be packed are not present at the specified location but I tried to look at the location and I could find the DLLs.One thing that confuses me is that though I have given nobuild to be true but still the tasks shows as Building the Project.
- task: DotNetCoreCLI#2
displayName: ".NET pack"
inputs:
command: pack
packagesToPack: ${{ parameters.packagesToPack }}
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: CI_Version
packDirectory: $(build.artifactStagingDirectory)\${{ parameters.packTo }}
verbosityPack: 'Normal'
Its also important to note that the same thing( nobuild:true) works on Windows Agent but it fails on Ubuntu Agent.
PS: It could be a case where windows has upgraded the agent and has caused the issue. I searched over the issue and found that one has to lock the .net SDK in the build pipeline
Thanks for the other answers that may be related to the issue but things were already taken care.
The issue was only on the Linux Environment because of an issue in .NET SDK. Refer here
The error(DLLs could not be found in the path specified ) that was being generated was correct in somehow but also it was misleading. The DLLs were being generated in Release folder at the build stage and when I was packing the DLLs they were being searched in release folder.
Though Release and release remains the same in Windows Environment but Ubuntu being case sensitive generates the Error.
The SDK implementation of .Net Core missed the IgnoreCase in the Regex option and that caused the build to break on switchin to a Linux Agent.
DotnetBuild:
Dotnet Pack:
Solution: Define the folder where to generate the DLLs in the .csproj and the automatically build and pack step would pick the DLLs from there.
For this error NU5026 ,it refers to the project being packed has not been built yet and hence cannot be packed. Please view this reference.
The file ''F:\project\bin\Debug\net461\project.exe' to be packed was not found on disk.
According to your description, you canceled the automatic build before pack. There's possibility that your build task and pack task did't run with same configuration. For example, In dotnet build task, the project is automatically built with Debug configuration, and in the pack task you set the configuration as Release.
In dotnet build task, the project is automatically built with Debug configuration.
In the dotnet pack task , the default Configuration to Package is Release
If you do not cancel the automatic build before pack, in the .net pack task the project is built in Release configuration.
So please check the log of your build task and pack task, make sure the dotnet build command and dotnet pack command use the same configuration.
I have a ClickOnce project that I'm publishing on DevOps. I've set the MSBuild Arguments property for the WinForm solution's build stage in DevOps to /target:Publish in order to trigger the creation of all the ClickOnce files:
However, that solution also contains an SSDT project, and adding the /target:Publish setting appears to then cause the build process to try publish the SSDT too. That then fails with the error:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1808,5):
error MSB4044: The "SqlPublishTask" task was not given a value for the
required parameter "SqlPublishProfilePath"
Presumably it's failing because there's no publish profile specified in a build parameter for the SSDT to use.
I don't want MSBuild to publish the DacPac to a server, I just want it to create the DacPac. How can I stop the /target:Publish triggering the SSDT publish, is there another build argument I can add to stop that happening?
Notes on what I tried so far to solve this, none of which has worked:
Read about the -target switch in the MS Build official docs in the MSBuild command-line reference and in the MSBuild targets section.
Looked at the code in the .csproj file to try and identify the 'Publish' sections - think Publish must also call Build.
Unticking Deploy for the SSDTs in the solution configuration in VS
Adding entries for False in the Release and Deployment configurations in the SSDT's .csproj file, and also setting that to false for the Debug configuration (as per this question)
Setting MSBuild to only publish one project using the MS Build arguments on DevOps (as per this answer)
Considered pulling the ClickOnce publish out into an entirely separate stage using Mage.exe as per this Walkthrough: Manually deploy a ClickOnce application
Tried to create a publish profile that doesn't actually publish, so that the publish stage can complete (was looking at this question for ideas on that and also the official documentation for SqlPackage.exe)
Eventually I solved the issue above a completely different way. Instead of getting MSBuild to do what I wanted it to, I instead split the solution configuration in two, with one stage for the databases and one for the WinForms project without the databases.
I then used two separate VS Build stages on DevOps with only the WinForms stage still having /target:Publish set.
I've written that up here, but would still like to know the answer to whether it's possible to tell MSBuild not to build the SSDTs when the target is set to Publish?
I'm at a total loss. We have TeamCity installed (TeamCity Professional 2017.2.3 (build 51047)). We run the MSBuild step with:
MSBuildVersion: Microsoft Build Tools 2017
MSBuild Tools Version:
15.0
and Command Parameters:
/t:Clean /p:DeployOnBuild=true /t:build /t:publish /p:PublishProfile=Properties\PublishProfiles\Deploy.pubxml /p:PublishDirectory=Deployment /p:Configuration=Release /p:VisualStudioVersion=15.0
When we run the build t shows:
_DeploymentUnpublishable [11:16:53][_DeploymentUnpublishable] Skipping unpublishable project.
TeamCity outputs at the start:
Starting:
C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe
/workdir:C:\TeamCity\buildAgent\work\c36dd5b119aec7b
"/msbuildPath:C:\Program Files (x86)\Microsoft Visual
Studio\2017\BuildTools\MSBuild\15.0\bin\MSBuild.exe"
If I navigate to the msbuildPath in the CommandLine and run the same command it builds and publishes without issue.
Any help would be greatly appreciated.
MSBuild Step In TeamCity:
I had this issue and resolved it by setting a Parameter towards the publishing profile.
This is what i had:
- *.csproj would build and publish in visual studio locally.
- TeamCity builds fine but when asked to Publish sends me the not helpful _deploymentunpublishable
I tried all the commands in the msbuild line but only the following setup works:
pre-step: Create a Publishing profile (*.pubxml) which outputs to a folder within your build. This should be saved in your /Properties folder of the build.
inside your configuration page, go to Parameters.
Add a new Parameter for "System". Call it PublishProfile (system.PublishProfile). Give it a vaule which is the name of your publish profile file or *.pubxml
enter image description here
create a new step (or amend existing publish step), runner type "MSBuild" and in the Targets box type WebPublish
enter image description here
You dont need any command line parameters as your pubxml will handle all this.
Thats it, give it a try and your code should now publish to the folder you set in the publishing profile.
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.