Let’s say I have a directory structure like this in an Azure DevOps repo:
Main/
- A/
- *.csproj
- B/
- *.csproj
- C/
- *.csproj
Each subfolder has a .csproj file. I want to compile the Main/A/ folder and save the build results (artifacts?) somewhere, be it a folder or something else. How do I tell Azure to build that precise Main/A/*.csproj file and do I need to use /p:OutputPath inside the VSBuild#1 task, or do I need to use some other Azure task?
How do I tell Azure to build that precise Main/A/*.csproj file and do
I need to use /p:OutputPath inside the VSBuild#1 task
If you're using classic UI, you need to unlink the default solution:
And then choose the A project by the browse option:
If you're using Yaml format, you should use something like solution: A/A.csproj to specify which project to build.
Note:
Since now we're building single project instead of whole solution, we should use Project Configuration instead of Solution Configuration. any cpu is Solution Platform instead of Project Platform(AnyCPU). So we should make sure we're building single project with AnyCPU if we want to build one project with this setting.
If you got error The OutputPath property is not set for project 'A.csproj', that indicates you should use valid project configuration. In your case, if you're using any cpu, change it to AnyCPU.
In addition:
1.To publish the build results as build artifacts for further use. You can use Copy Files task and Publish Build Artifacts task like this:
Copy Files Task.
Publish Build Artifacts
Then you can download the Test.zip in Summary tab from build log page. Also, you can use this artifact in release pipeline by using download artifacts task.
Check this, if you're trying build code project instead of whole solution. You can consider MSBuild Task. They(Msbuild task,VS Build task) both calls msbuild.exe to do the build job.
Hope all above helps :)
Related
I am working with a classic Azure build pipeline which is using the following MsBuild arguments for creating a package and zipping it:
/p:DeployOnBuild=true /p:WebPublishMethod=Package
/p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactstagingdirectory)\"
The above arguments are creating an artifact but with too many nested folders. To avoid that I used this argument: based on this SO question: Avoid nested folders in zipped artifact
/p:OutDir="$(build.artifactstagingdirectory)"
which fixed my one problem but now creating another. The build solution task does not create the bin/release folder for some of the projects inside the solution and for that reason some of the copy tasks are failing.
Build solution Task
Copy task
Copy task failing due to missing bin/release
Copy task working for another project in the solution because bin/release folder exists for it
Nuget task is also failing due to missing bin/release folder
Is there any possibility to not miss the bin/release folders when passing /p:OutDir="$(build.artifactstagingdirectory) argument for avoiding nested folders structure for zipped artifact
The $(OutDir) property is the Output Directory. This is the location where the project will produce its outputs. The value of $(OutDir) may be bin\Release or bin\Debug (based on the current Configuration) within the project's directory.
Specifying
/p:OutDir="$(build.artifactstagingdirectory)"
is overriding the output directory. The project will produce its outputs in the location given by $(build.artifactstagingdirectory). In your examples, because 'bin\Release' is overridden it won't be created by the project.
Because the output directory was changed, the copy task should be changed to match. i.e. the source for the copy task should be $(build.artifactstagingdirectory).
However, $(build.artifactstagingdirectory) is a variable that only exists in the context of the build pipeline. Overriding $(OutDir) with $(build.artifactstagingdirectory) can only be done within the pipeline which means that for a developer building in Visual Studio the build will behave differently. This discrepancy could cause confusion.
If you are comfortable with MSBuild, you could add a custom target that is dependent on $(build.artifactstagingdirectory) having a value and on the packaging target being run (AfterTargets="AfterPublish"). The project will 'know' its packaging folder which, as an example, might be something like 'bin\Release\publish'. The custom target can copy from 'bin\Release\publish' to $(build.artifactstagingdirectory).
I am having trouble figuring out how to use VSTS to deploy an arbitrary directory from my build to an azure web app.
The arbitrary directory is produced during the build step and contains the webpack bundled javascript for my app. Here are the details:
I have an MVC 5 app and I just started using webpack to bundle the output of my typescript files. webpack creates a set of bundles and writes them to $(project_dir)/Scripts/bundles.
All my typescript source are in various other directories under /Scripts as well (App, Api, Lib etc). But from a VS project point of view, bundles is empty, but added to the project.
Everything works great locally. I can do a debug build and webpack-dev-server serves up the bundles. I can do a release build and webpack happily creates the bundles on disk in /Scripts/bundles. And my code happily consumes the bundles.
I have edited the project file to include:
<Content Include="Scripts\Bundles\**" />
and if I do a publish from within visual studio it all works great. But VSTS doesn't seem to recognize this part of the project
We use VSTS to do our building and releasing to azure. I can't for the life of me figure out how to get VSTS to publish this /Scripts/bundles directory.
In my project properties, I created a pre-build step that runs webpack. I know that the files are in the Scripts/bundles directory at the end of the build because the closest I have come to getting this working is to have the VSTS build a second artifact that is the zip file of that bundles directory and the files are in there.
I could solve my problem if I knew one of the following (I think):
how to get an arbitrary directory to show up in the main artifact like the normal build output - I can then use my standard release definition to push it to azure
how to publish a second artifact in a release definition?
If you can solve #2, the issue is that in building the artifact for /Scripts/bundle, it put the contents of the bundle directory in the root of the zip file, rather than having bundle as the root of the zip file. So when I unzip the file, It will have to first create /Scripts/bundle and then unzip.
I must have been entering the wrong search terms when I was first trying to figure out how to do this. Once I hit on the right search terms I found a bunch of articles that talk about how to get "extra files" into the deployment package for Azure.
Here is a good article. I basically followed it and things just worked. I added these lines to my csproj file:
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
WebpackBundles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>
WebpackBundles;
$(CopyAllFilesToSingleFolderForMsdeployDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
<Target Name="WebpackBundles">
<ItemGroup>
<_CustomWebPackFiles Include="Scripts\bundles\*" />
<_CustomWebPackFiles Include="Scripts\bundles\**\*" />
<FilesForPackagingFromProject Include="%(_CustomWebPackFiles.Identity)">
<DestinationRelativePath>Scripts\bundles\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
The PropertyGroup was already there. I just inserted the WebpackBundles; call into those two elements and then defined the WebpackBundles target.
And I ended up removing the
<Content Include="Scripts\Bundles\**" />
line and replaced it with the new Target that the article suggests. I am running webpack as a pre-build step only on the release build. I am using webpack-dev-server for the debug build locally. The only change I had to make to our VSTS build was to add two npm steps:
npm install
npm install webpack -g
this allowed the pre-build step to find the webpack executable and run it.
there was no change to the VSTS release definition because the webpack bundles got put into the deployment zip file in the right location.
I want to deploy my .Net project from GitHub repository to the azure server.
In Deployment options I am getting Building failed error.
Here are screen shots of my Deployment details and Logs
1- Deployment Details:
2- Activity Log:
According to your description and logs, I found you have error in MSbuild step.
The error shows some files not found in your project. I suggest you could exclude the related files in the csproj file or make sure the related files is in your project.
Besides, I suggest you could firstly clone the project to your local and test it , make sure the project could build well without any error then publish to the GitHub and deploy to the azure.
Update:
I also write a test demo on my computer and I reproduce your error.
Error image:
I think in your project you have inclued the bin and obj folder into your project and then you push the project to the github.
Like below:
After you push the project to the github, the csporj file will include all the bin and obj references.
Like below:
This is the reason about your MSBuild fail.
So I suggest you uninclude all the bin and obj folder in the local and push to the github again. Then it will work well.
Azure looks in your site/repository/packages folder for all the packages your app uses. By looking through it you will find that visual studio doesn't deploy all of the files from your local packages folder to the azure one. MSBuild needs these files when you push to git and trigger a build. Ftp into your azure site and look for the packages folder. Upload every missing file (dll) from your local folder to the azure one. This worked for me and now I can trigger a build and deployment from bitbucket to azure app service upon a push.
Additionally, if you have other projects in your VS solution and you are using VS to build those projects and then put the dll into your main projects bin folder, that will cause a missing file error also. I create a folder in my packages folder and link the dll to my main folder from there. That way when you perform the fix above, the file needed by your main project is in the packages folder also.
I hope this helps!
I just started using VSO for one of my project. I have created the built definition and the built was successful. When I tried to create the release definition for that built its failing by throwing the error
System.Management.Automation.RuntimeException: No files were found to deploy with search pattern C:\a\858bddd5b\**\*.zip
Its expecting .zip files. Since I need to deploy the distributed folder created by gulp build, I have given the Web Deploy Package path as
$(System.DefaultWorkingDirectory)/{built name}
Any help is really appreciated
You should add a build step to create an archive with .zip extension for the output folder of the gulp step. Your steps should look like
VSO/VSTS build has a task available with Archive files to achieve the same.
Alternatively, if the standard Archive files step doesn't work for you, you can use a powershell step. The powershell command will look like the following.
[io.compression.zipfile]::CreateFromDirectory($Source, $Destination)
Source should be all the files/folders from gulp output you wish to deploy
Destination here should correspond to input for the webdeploy/ WebApp deployment step.
You can also use this extension to create a ZIP file. I used it for a situation similar to yours:
https://marketplace.visualstudio.com/items?itemName=trackyon.trackyonadvantage
"Azure Web App Deployment" task requires a web deploy zip package. You can either add one more task to create a zip package for the build output as other two answers indicated or add some code in your "gulpfile.js" to generate a zip package during the gulp build and then publish the zip package to artifact.
If you don't want to create a zip package for the build output, then you can use FTP Uploader task to deploy the build to Azure Web App via FTP Deploy.
You can create a zip file with PowerShell, assuming you're running on a Windows agent.
Command Line task
Command: powershell
Arguments: -Command "&{Add-Type -assembly 'system.io.compression.filesystem'; [io.compression.zipfile]::CreateFromDirectory('$(Build.StagingDirectory)\Zip', '$(Build.StagingDirectory)\$(BuildConfiguration)Deploy.zip')}"
Obviously, replace $(Build.StagingDirectory)\Zip with whatever folder you want zipped up and $(Build.StagingDirectory)\$(BuildConfiguration)Deploy.zip with whatever you want the file named.
I have a teamcity (4.something) install that creates .wsp file for deployment to sharepoint. Currently I have to copy the wsp out of the build artifacts directory and into a little deploy folder I have created. In the folder I run a .bat that deploys the new .wsp to our test server.
What steps can I take to automate this?
Either copy the .bat into the artifacts folder and update the paths etc or copy from the artifacts folder into the 'deploy' folder and run the .bat from there.
I am a neophyte when it comes to the intricacies (or basics!) of MSBuild and the like... so hand holding is appreciated!
In more recent versions of TeamCity...
In the build definition you can identify artifacts which can be copied/zipped. Artifacts can then be downloaded manually or referenced from another build (Artifact Dependency).
You can setup a 'build configuration' to do your deployment directly from artifacts produced by your ci build.
Create a build to do your deployment
Build Step
Run: Executable with parameters
Command executable: .bat file (make sure it as part of the ci build artifacts generated)
Command parameters: whatever parameters your patch files needs
Dependencies
Add New Artifact dependency
Depend on: select the ci build you want to deploy
GetArtifacts from: Last successful build
Artifact rules: +:**/*.*
So, given artifacts (like your batch file) are in the CI build... You now have a 'deploy' build. When you run it (manually or setup a Build Trigger) it will copy all the CI build artifacts to it's working directory (Artifact Dependency) and then run your batch file to do the deployment.
Pretty slick.
note: just make sure that the account running the TeamCity BuildAgent has permissions to do all the deployment stuff.
Hope this helps somebody as it took me a while to sort this out ;)
I've done this by creating a nant task, and then having TeamCity execute the nant task. It's more of a pain than it should be. You should be able to do the same as a post-build event with MSBuild.