My requirement is to publish the project code to a folder. I have configured the below command in the Post build event. When I build the project the post build event is executing which is rebuilding the project and triggering the post build event again and going into infinite loop. I would want to only publish but not rebuild the code on the post build event.
call "$(MSBuildBinPath)\msbuild.exe" "$(ProjectDir)$(ProjectFileName)" /p:DeployOnBuild=true /p:Configuration=Debug /p:Platform=AnyCPU /p:PublishProfile=ProdPublishProfile.pubxml
Related
When I build a web project from command-line using msbuild and no special parameters, it seems to build just fine, including calling an nswag task to build TS files.
When I build the same web project with the /p:DeployOnBuild=true parameter and the /p:PublishProfile parameter set, nswag is not called at all, and the build fails because none of the TS files were built.
Isn't using the DeployOnBuild parameter additive? Shouldn't any build tasks specified in the csproj file still get executed?
Using the Structured Log Viewer for MSBuild I was able to determine why MSBuild seemed to be skipping the NSwag task specified in my csproj file when DeployOnBuild=true.
Build order matters!
In our project we build a client TS file at build time and then at the end run yarn tsc to build out all of the JS files.
Wnen we add DeployOnBuild=true, early in the build process, it attempts to copy the JS files to the package folder. But because client TS file hadn't been built yet and the JS file created from it, the build was failing and never even getting to the NSwag command.
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 have a Class Library Project which contains t4 templates that execute on build. The output .sql files are set to Content of the .csproj and should be copied on build to the output folder.
I have the following configuration setup on my TeamCity Build Box using MSBuild:
Command line parameters:
/p:OutDir=C:\output\DBMigration
/p:Configuration=Release
/p:DebugSymbols=false
/p:DebugType=None
/p:DeleteExistingFiles=true
/t:rebuild
/verbosity:n
The output of this is that the files are copied to the outputdir but are deleted in the CoreClean step of the rebuild.
To get around this I can run a Build instead of a rebuild, (ie. /t:build).
This will skip the CoreClean step, but why is the CoreClean called on the output dir after the Copy process has taken place? Should the Delete action not be before the Copy?
And why do I only need to do this step for ClassLibrary type projects, web/windows applications do not seem to have this problem with the rebuild.
Also it appears from the build log that the output directory is never cleaned by /p:DeleteExistingFiles=true.
I could do a hack and force a powershell script to run to clean the directory before attempting to build, but there must be a supported MSbuild parameter to do this in the absence of the rebuild preforming correctly?
In Visual Studio, I use the "publish web" feature to do some web.config transforms, and publish a WebAPI project to our server. The publishing is done using Web Deploy.
Now that I'm using Visual Studio Code, I've lost that tooling. But, I'd like to continue publishing the project using Web Deploy. Is there some way to write a VSCode task that will publish my project?
Visual Studio Publish uses a [target].pubxml file. I have "staging.pubxml" and "production.xml". These look like MSBuild files. So, maybe it's just a matter of executing an msbuild task from Code. Not sure where to start with that, though.
Another thought is that I could kick off a Web Deploy command line tool. I've never used that, and it seems like the first idea would be better.
Assuming you are using the latest vscode now (1.7.x). You can use Visual Studio Code's Task Runner.
First, you would need to configure the task runner by pressing <F1> and enter task. Select Tasks: Configure Task Runner.
A new file tasks.json would be created by vscode with following content.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"command": "msbuild",
"args": [
// Ask msbuild to generate full paths for file names.
"/property:GenerateFullPaths=true"
],
"taskSelector": "/t:",
"showOutput": "silent",
"tasks": [
{
"taskName": "build",
// Show the output window only if unrecognized errors occur.
"showOutput": "silent",
// Use the standard MS compiler pattern to detect errors, warnings and infos
"problemMatcher": "$msCompile"
}
]
}
Second, now you would need to add the new publish task. With the answer given by #Rolo, you can add a new task in the tasks array:
{
"taskName": "publish",
// Always show errors from builds.
"showOutput": "always",
"args": [
"/p:DeployOnBuild=true",
"/p:PublishProfile=Test"
]
}
Third, once the tasks.json is completed. You can use the publish task by pressing Ctrl+P (or Cmd+P on Mac), and type task publish.
Visual Studio Code does not have an integrated build system (Web Publish) like Visual Studio does. But it does have command line task running and Git built in.
So you have a couple of options:
1) Use a task runner to kick off your build/publish from the command palette (ctrl+p). Grunt is available in the preview*. This requires that you manually script it out, but once that is done, it is easy to kick off the task from that point.
(UPDATE: the docs mention other compatible task runners including: Make, Ant, Gulp, Jake, Rake or MSBuild -- AND the .settings tasks.json has examples of how to get your MSBuild files working. Press ctrl+p type: "run task" and then click "configure tasks")
2) Setup your source control system for continuous integration so that when you push an update to a specific branch, it will run the MSBuild (or other build system) scripts and publish to the server for you. We use Team Foundation Server (TFS) and Git. We have a specific "release/master" branch that is setup to build and publish when it receives a push. It also takes some initial configuration, but once complete, it is automatic. If you don't have TFS, try TFS online. There are many other options out there, but that's what we use.
I am in the same position as you trying to figure this one out. I would love to know what you find out.
*According to the Deep Dive session at Build 2015. Although looking at the tasks.json file it looks like Gulp and MSBuild examples are available in the Preview.
In order to publish using MSBuild you need to use the following command:
msbuild <Project or Solution Path> /p:DeployOnBuild=true /p:PublishProfile=<Publish Profile Name>
You can point to a solution, this will publish ALL the projects that includes a valid Publish Profile:
msbuild <FullPath>\MySolution.sln /p:DeployOnBuild=true /p:PublishProfile=Test
You can point to a specific project like this:
msbuild <FullPath>\Project1\MyProj.csproj /p:DeployOnBuild=true /p:PublishProfile=Test
In both cases you can also specify use the full path to the .pubxml file:
msbuild <FullPath>\MySolution.sln /p:DeployOnBuild=true /p:PublishProfile=<FullPath>\PublishProfiles\Test.pubxml
In fact the *.pubxml files are MSBuild scripts, so you can interact with it like you do with any other MSBuild script, for example you can replace the properties from the command line like this:
Test.pubxml
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\Deploy\MyProject\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
msbuild <FullPath>\MySolution.sln /p:DeployOnBuild=true /p:PublishProfile=<FullPath>\PublishProfiles\Test.pubxml /p:publishUrl:"D:\DifferentPath\DifferentFolder\"
You can use these commands from your continuous integration server or any other build scripts.
Additional information:
Command Line Deployment
You can use dotnet publish command to deploy it to a local or remote directory.
For local directory
dotnet publish -c Release -o ./publish
For remote directory
dotnet publish -c release -p:PublishDir=//serverName/d$/inetpub/wwwroot/appName
dotnet publish calls MSBuild behind the scene.
-c configName => Defines the build configuration.
-o dirName => Specifies the output directory.
-p:PublishDir=> Specifies the directory where output directory is copied
To learn dotnet publish command, visit link.
You can also use publish profile in VS Code using command line.
I have been playing around with TeamCity to get a CI environment up and running.
I started by following Troy Hunt's 'You're deploying wrong', which was very useful, however I wanted to split the packaging and deployment into 2 seperate steps, for the following reasons:
I wanted to pass some additional flags to msdeploy, which isnt possible (to m,y knowledge) by using the MSBuild Package and Deploy that Troy describes.
I can easily disable the Second Build Step i.e. deployment, if I ever need to build the package but not deploy it.
I wanted to use the -skip flag on msdeploy to prevent it from deleting certain folders, which again I couldn't find any method of doing without passing as an argument to the command line.
So, in my first MSBuild step I just have the parameters:
/P:Configuration=%env.Configuration%
/P:VisualStudioVersion=11.0
/P:IgnoreDeployManagedRuntimeVersion=True
And then I have a second Build Step that uses a command line build runner to execute the following msdeploy command:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="C:\ProgramData\JetBrains\TeamCity\system\artifacts\MyProject\%system.teamcity.buildConfName%\%teamcity.build.id%\MyProject.Web.csproj.zip" -dest:auto,ComputerName='https://devserver:8172/msdeploy.axd?site=MyWebsite',UserName='domain\username',Password='password',IncludeAcls='False',AuthType='Basic' -skip:objectName=dirPath,absolutePath=media$ -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2 -allowuntrusted
The problem with this is that apparently TeamCity doesnt publish the artifacts until all the build steps are complete, so therefore the Command Line process fails because the package zip file doesnt actually exist at that point.
I have read something about publishing artifacts whilst the Build is still in progress but that does seem like a bit of a hack.
Any advice would be greatly appreciated.
You would be better have two builds vs two build steps.
The first (Build A) would have 1 build step that would do the building then the second (Build B) would just do the deployment in one build step using the artifacts from the first.
So under the first configuration tab of build A, you would specify the artifacts that would need to be made available from the first build. You can then run the build and confirm that under the artifacts section everything you need is available. (These will show when build A has completed running).
Then under the dependencies section (Can't remember the exact name, and I'm away from my TC instance) of Build B you can set it up to use the artifacts of build A which would then be used for the deployment.
Once you have all that working, you could add a build trigger to have Build B run after a successfull execution of Build A, then if you at one point just wanted to run Build A, disable the trigger on build B or pause the Build B configuration which will stop the trigger from firing.