I am trying to create a CI Continuous Integration to my project my project structure is as follow.
Solution
|_ WebApi 1
|_ WebApi 2
|_ WebApi 3
|_ Website "Single Page App"
I created a web deploy for each service to deploy it to server automatically each time i need to publish the application with the same name.
I created a batch script to run the publish so this is semi automatically approach.
I want to create a CI Continuous Integration so I create a new Build Definition to my project and add the following configuration
the following error appear to me
What i am missing in configuration of the Build Definition?
According to the error messages, the issue may be caused by Nuget packages not restored correctly.
You can follow steps in this blog to restore the packages: https://docs.nuget.org/consume/package-restore/team-build).
Some key steps are:
Add nuget.config and .tfignore file to the solution.
Add one build.proj file under the root path of the solution folder.
Create one folder named tools under the root path of the solution folder. Create NuGet sub-folder under tools folder, download and save nuget.exe under tools\NuGet path.
Check in nuget.config, .tfignore, build.proj and tools\NuGet\nuget.exe into TFS version control.
Modify the build definition to choose to build the build.proj file.
Then you will have NuGet packages restored successfully during the TFS build process.
Related
I have a project A that references project B in Visual Studio, which works locally. The folder structure of both is below:
C:\code\A
C:\code\B
But on Azure DevOps Repos, each project resides in a separate repo of a separate project, like below:
repo A in Project A
repo B in Project B
The project is the build pipeline throws exception when building project A that cannot find project B.
Is there a solution instead of using Nuget?
The downside of using nuget is that when in debug mode, we cannot step into the assembly.
Azure DevOps build support for referencing separate project directly instead of via Nuget via Visual Studio
There should be some way to do this, but the best solution is to have a single repository.
To resolve this issue, you can:
Add the .dll file of dependent project to a the NuGet package.
upload to a feed, such as Azure Devops feed: Package Management in Azure Devops and
TFS, then restore packages during the build (This is the way we are
using).
For the debugging, you could publish the symbols package to the artifact by the task Publish symbols path. Check this blog for the details.
Add Download Build Artifacts task to build definition to
download the artifact of project B build. You also can call Builds
REST API through PowerShell to get build artifacts of project B.
You can consider to use Git Submodules or Git Subtree if it is Git
repository.
If you are using TFVC repository, you can get the Extensions project
by specify additional Workspace mappings in Get Sources section of
build definition (Specify it directly, can click … to select)
Hope this helps.
I am using Team City to deploy an ASP.NET Website.My Issue is Artifact folder contains .cs and designer files too. How to remove these type of files from Artifact folder. For ASP.NET websites we do not need such files.Need files like ASCX,ASPX,JS,CSS etc only.
Using Publish Profiles and Web Deploy to generate a deployment package, you can specify that only files required to run the application are captured as artifacts in TeamCity.
Update Visual Studio Project Properties:
Choose "Only files needed to run this application" in the Package/Publish Web section
Create a Visual Studio Publish Profile:
Set Web Deploy as the Publish Method
Update TeamCity Build Runner: Add /p:PublishProfile="[name of publish profile created in previous step]" to the Command Line Parameters
Update TeamCity Artifact Path: [your source path]\obj\[VS build configuration]\Package\** => artifacts\[your desired path and file name].zip
Unfortunately I can't add any more screenshots due to rep. Hope this helps!
I have created a VS build definition on Team Services. The build runs successfully when I queue it and it also outputs the dlls for all the projects in the solution except the service layer which I have created using Web Api2.
when I download the artifacts from the drop location, I have folders holding the dlls for the data layer, the business layer and other helper projects. What I don't have is the main service layer dll which I can deploy to my IIS.
Here is a screenshot of my publish settings.
What could I be missing ?
It seems that you are using the default settings for the build definition. With these settings, the contents for "Copy Files" task is "**\bin\$(BuildConfiguration)**" while web api project does not have buildconfiguration folder. So it cannot find the files for web api project. To copy these files, add one more "Copy Files" task and configure the settings as following:
If you want the deployment files for the project, you need to set you build definition as following:
Add arguments /p:DeployOnBuild=true;OutDir="$(build.artifactstagingdirectory)" for Visual Studio Build step.
Remove Copy Files step.
Set Path to Publish to $(build.artifactstagingdirectory)\\_PublishedWebsites for Publish Build Artifacts step.
Then you should get the deployment files in the drop folder.
Open the Configuration Manager in VisualStudio and ensure the WebAPI project is included for the configuration (Debug, Release, etc) that you are building.
I have a Visual Studio 2013 solution with multiple projects in it. (Source code is in SVN)
Here is the project/solution structure
d:\src\Service\MyService\MyService.sln
This above solution contains 2 projects. The file path for both projects are,
d:\src\Service\MyService\MyServiceProject\MyServiceProject.csproj - For simplicity let's call this - Project A
d:\src\Library\MyLibrary\MyLibraryProject\MyLibraryProject.csproj - For simplicity let's call this - Project B
Here, project Project A has a project reference to Project B
I have configured TeamCity to use default Visual Studio build (ie., I have no custom MSBuild scripts) to build the MyService.sln.
When I build the project in TeamCity, the build fails saying that it could not find the .dll file that was supposed to be produced by Project B.
I checked the TeamCity working directory and I don't see Project B's source code at all. What am I missing here?
It looks like you have not set up your vcs roots correctly in TeamCity. Your example gives the folder structure of d:\src\Service\MyService\MyServiceProject\MyServiceProject.csproj and d:\src\Library\MyLibrary\MyLibraryProject\MyLibraryProject.csproj
you need to do one of two things:
If your projects are both help in some common folder which is in source control, then you need to set up your vcs root to checkout the folder containing both projects. In the example above you should checkout \src\ if this is a folder in your source control.
If this is not a folder in your source control then you need to set up 2 vcs roots for your build configuration one to checkout Service and one to checkout Library, then the source for both projects will be available on the build server.
First post on Stack, so please be gentle!
We are just getting into Continuous Integration with TeamCity. We have setup a TeamCity project(s) that looks like so:
Solution Build (builds entire solution) - .Sln file
Debug to Dev Server (builds .csproj in Debug configuration and Deploys to test server using MSDeploy)
Release to Production (builds .csproj in Release configuration and Deploys to production server using MSDeploy)
Within our Umbraco Visual Studio project (which is a Web Application not the standard Website project type) we have the umbraco_client and umbraco folders excluded from the Project, primarily because they are already compiled and don't need to be re-compiled by our process. Both folders are however included in the SVN repo.
The problem we are experiencing is that because these two folders are excluded from the Visual Studio project, TeamCity does not deploy them.
So my question boils down to "how do you include folders in the TeamCity build package where the folders are in the SVN but excluded from the Visual Studio project?".
Any pointers would be really appreciated.
Thanks
dotdev
We've been using TeamCity for umbraco. This is what we've been doing recently on our internal dev servers:
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_site
/p:IgnoreDeployManagedRuntimeVersion=True
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
They key to solving the problem you are having is
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
By default, it is set to something like "AllFilesInProject". Combining FilesToIncludeForPublish with the ExcludeFoldersFromDeployment can give you some control over exactly what TeamCity attempts to deploy
I would suggest using an approach similar to the one described in this blog post: http://blog.iqit.dk/2013/11/using-package-restore-in-umbraco-projects
You don't mention nuget, so assuming you use a zip or web pi to setup Umbraco in your solution, but you should still be able to use the targets listed in msbuild or add to your web applications .csproj when building your solution. It would require that you have the Umbraco and Umbraco_client folders somewhere in Svn repo or on your build server in order to copy it in.
As an alternative I can also recommend that you download the UmbracoCms nuget as that contains an extension to the msdeploy pipeline that includes the two mentioned folders in an msdeploy zip package. But again also based on the nuget install and thus a standard location for the Umbraco folders.
Hope this helps.
I've based my TeamCity builds on Troy Hunt's excellent "You're Deploying it Wrong" series - which is an excellent step by step guide to integrating Visual Studio based projects and TeamCity. http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
As to excluding the umbraco and umbraco_client folders from SVN; a complex Umbraco build will probably have changes in the Umbraco folder to the default build eg adding Umbraco Event Handlers, adding new Umbraco Sections, changes to back-office tabs. I don't think umbraco_client will change unless you get into changing rich text editors and so on - but it is possible. So I'm not sure that excluding those particular folders is correct. Excluding the media folder is often discussed as well - but it does make TeamCity config simpler if everything is there.
But to answer your question you could exclude them from the build and copy them onto your build server; then add a 'Command Line' runner build step that simply copies them back into place before the build step starts.
I usually add a source control change step that fires a rebuild and have two build steps in TeamCity for an Umbraco project. One is a 'Visual Studio (sln)' runner to check that the sln file has every reference and third party product set up correctly (this should eliminate the 'it works on my machine' issues); and the second is a 'MSBuild' runner that replicates the csproj build process. With the second build step with the right permissions (if your ports are open on the machine you're deploying to, or you're deploying to the same machine as you are on) you could test this in Visual Studio or DOS.
These two build steps should be able to deploy to the IIS website on a staging server; and if the right ports are open on your live or UAT server you could then add a third build step and deploy it onwards (if the first two build steps run properly).