My Visual Studio 2019 solution contains several projects, some of which I don't want to be built as part of continuous integration. Specifically, I'm trying to exclude tooling and unit tests.
In Visual Studio, I have created a new solution configuration and unchecked the "Build" box for each project I don't want to be built.
In TeamCity, I have specified the name of the new solution configuration to use. However, TeamCity continues to attempt to build all projects within the solution.
[I had included screenshots of my solution configuration, TeamCity build configuration, and resulting TeamCity log but I do not have enough reputation to post images apparently.]
From everything I could find so far, unchecking "Build" from the solution configuration used by TeamCity is supposed to exclude that project from building.
I figured it out by finally noticing that the TeamCity log was showing the build configuration as "ReleaseCI|Mixed Platforms" instead of "ReleaseCI|Any CPU". On other projects, I only needed to specify the configuration. For this project, I apparently have to specify the platform as well.
Related
I have a solution which I have a number of unloaded projects. When I build the solution locally the unloaded projects are obviously not built. In Configuration Manager, I can't even select configuration, platform, build and deploy options for the unloaded projects.
Now I have created an Azure Pipeline which also builds the solution. But the unloaded projects are still being built.
How can I exclude building projects in my pipeline?
Now I have created an Azure Pipeline which also builds the solution.
But the unloaded projects are still being built.
Both Azure Devops Pipeline and VS IDE would call msbuild.exe to build. When building a solution using msbuild, it actually is running command msbuild xx.sln /t:build ....
Check the content of xx.sln file (solution file) we can find it defines definitions about the projects within the solution. That's why if you build the solution, all these projects will be built. This is expected behavior when building whole solution. Sample .sln file:
And it's VS IDE's magic to exclude unloaded projects when building whole solution. The IDE will check the unloaded projects and skip them when building whole solution, it has advantage that the unloading project behavior in IDE won't modify your solution file. (It's important for solution under Git version control).
To sum up: It's expected that building solution will build all projects. When we unload the projects in VS, this action won't affect our source solution file or project file. VS will automatically skip the unloaded projects, which is the unique feature of IDE. (Unload is a UI action in VS, it has no effect on .sln/.xxproj file)
To exclude projects to build in Azure Devops:
1.Specify projects to build when building whole solution. (It doesn't change any file, so that it won't affect Version control)
You can check this answer and corresponding document. My devops task setting (no need to specify Build target):
2.Exclude projects from solution configuration (Not recommended) or create a new configuration that excludes specific projects (Recommended). The solution configuration is defined in solution file (sln), so this way would makes effect on Source control.
Exclude projects from solution configuration(Not recommended):
Create a new configuration that excludes specific projects:
Related document here. I suggest you can do the changes via VS IDE, and then push the commits to remote repo. It's complex if you're not familiar with msbuild and sln file, so I doesn't suggest doing that yourself. Let IDE do the job for you.
Once the remote repo get the changes:
We can build the solution in devops with customrelease configuration which excludes ProjectA and ProjectB instead of release configuration which contains all projects.
All these workarounds had been tested on my side before posting them.
In VSTS (hosted TFS) I have a build definition which uses MSBuild. What I would really like is to have pull requests annotated with any rule violation detections. However I can't get the analysers to work at all. What I've done so far;
Installed Microsoft.CodeAnalysis.FxCopAnalyzers in one of the projects that gets build
Verified that running "Analyze Code" in Visual Studio does output rule violations
All the *.ruleset files are not available on the self-hosted build agent, as it only has MSBuild installed (no full-fledged Visual Studio). For the same project as in point 1, I've also used a custom ruleset.
I have also build the project on a hosted build agent (which has VS2017 installed), but also to no avail.
With all of the above, the build log / build overview in VSTS doesn't list any rule violations. It's my understanding that the code analysis should be run automatically and the output should appear on the build overview page (i.e. https://MYSITE.visualstudio.com/MYPROJECT/_build/index?buildId=XXX&_a=summary&tab=details).
The Code Analysis setting is based on the configuration and platform, so you need to make sure you build the project with the same configuration and platform that enabled code analysis on build.
You also could specify it in MSBuild Arguments of MSBuild task:
/p:RunCodeAnalysis=true;CodeAnalysisRuleSet=..\RuleSets\MyMixedRecommendedRules.ruleset
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).
I have a c# solution with multiple projects. I have a .sln file I build the solution with in VS2012.
I am looking to set up TFS Build and want to include some custom msbuild actions, such as running stylecop and fxcop rules. I want these tasks to fire when building the solution locally and within tfs build.
I have looked at creating a .proj file for the solution. However, I am not sure how this can be setup locally and to run the tasks locally.
What is the correct setup for tasks to be run within tfs build and visual studio?
My best guess is to set the flag "Enable Code Analysis on Build" in the project settings "Code Analysis". More on that here.
I suppose that running StyleCop is better fitted in the IDE (check R#) or the VCS (check SVNStyleCop) on commit. I am not sure if the same exists for GIT or other repositories.
Allow me to start by saying that this is a new and first time TFS deployment with 0 experience in Visual Studio as an added bonus. I've managed to get everything installed and am excited to say that I can even deploy as part of the build process to our different staging environments, but this is where things have gone south.
I'm trying to set up separate build definitions for each stage of development so that I can take advantage of config transforms and use granular permissions for who gets to promote where. In the configuration manager I have it set up so each solution configuration has a 1-1 mapping to a project context and always building 'Any CPU'. The problem is that when I use the /p:Configuration=QA switch in the MSBuild Arguments or just specify it in the 'Items to Build; section of the Build process parameters the build fails with a warning and it doesn't seem to get as far as MSDeploy.
Using the following arguments to MSBuild I am deploying with a default configuration, but again, no love on specifying a configuration.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=10.31.60.109 /p:username=tfsdeploy /p:password=lulz /p:DeployIISAppPath=Bob /p:AllowUntrustedCertificate=True
Here is the warning I get in the TFS Build Explorer when specifying the configuration to use.
C:\Builds\2\Bob\Bob - Final Test\Sources\Bob\Bob.sln.metaproj: The specified solution configuration "QA|Any CPU" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
The solution originally was created in VS2008 and a local copy from VSS was pulled down with VS2008 and then pushed into TFS2010 using VS2010 pretty much letting MS work its magic to convert/update.
Any help is greatly appreciated.
The issue I ran into here was that the names of the build configurations were different in the .sln and .csproj files and these can't be mapped to each other as I thought I was doing from within the VS2010 ide.
This is actually a pretty simple error. If you get it, check your spelling in the build definition then verify against the .sln and .csproj files using a text editor like vim/notepad.
Did you get this fixed? I've noticed some of our builds are "AnyCPU" and others are "Any CPU", makes reports a little more interesting!