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.
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.
We have a VS 2017 Solution with a main web project in it. We also have 3 other web projects - these are modules that depend on the main web project. However, the main web project doesn't reference or known anything about that modules. When the solution builds the modules copy their output to the bin folder of the primary web project. The modules must depend on the latest version of the main project, so it needs to build main first and then the modules. This all works great locally - the site loads the modules work etc.
We are currently using Octopus and its Octopack step runs after Solution and gets all the files. We are trying to move to just using VSTS and are having problems getting the module files into a standard web deploy zip.
When MSBbuild runs on Solution it creates a zip file per web project. The zip file for the main project doesn't contain the Dll files for the modules (even though they are in bin folder). Therefore when we deploy via VSTS site is missing the modules. How do we tell MSBuild to create a single webdeploy package for the solution including the built modules?
The MSBuild command is basically the out the box one from VSTS:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:PackageLocation="C:\temp\web.zip"
As far as I can see MsBuild is making the webdeploy zip before the other solution items copy their contents into the bin folder. MSBuild is a bit of a mystery to me at the best of times.
Largely this is just a case of making MSBuild include extra files that aren't part of the project. The pack web project publish only cares about files that are included in the project.
I updated main web project Csproj file following the guide in this question How do you include additional files using VS2010 web deployment packages?. I ran MSBuild once to build Solution so module dll files were available and I then ran MSBuild again with main web project to create the WebDeploy output with the extra included files.
Not sure this is the best way - seems a bit convoluted just to add some files but it works.
I have a solution which has several VC++ projects. I am trying to make TFS do weekly builds. I have set up TFS Build controller and agent. I created a build definition using DefaultTemplate.xaml file and I can successfully build some of the projects.
The problem is my projects depend on some libraries that are already checked in to debug/release folders. TFS is trying to put project outputs (dlls and exes) to $(SolutionDir)\Binaries directory. Since dependent libraries don't exist on this location, TFS build fails.
What I would like to do is use my own project output locations and somehow copy the output files to somewhere in server.
How can I do that?
Thanks
It's not recommended checking in the libraries to TFS, you can use Nuget to restore the packages.
For the build outputs, you can specify the drop folder in your build definition and copy the outputs to the drop folder.
You can also check in a script that copy the outputs, and specify a post-build script path in your XAML build definition. This script gathers some of the typical binary types from the typical locations and copies them to the folder from which TFBuild copies and drops to your staging location. Check more information about Run a script in your XAML build process at website:
https://msdn.microsoft.com/library/dn376353%28v=vs.120%29.aspx
I would suggest to edit your build definition. Under Process section, set MSBuild arguments to
/p:GenerateProjectSpecificOutputFolder=true
As follows:
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 3 .net projects.
Project1.dll is generated by a VS2008 project.
Project2.dll is generated by a VS2005 project that references Project1.dll.
Project3.dll is generated by a VS2008 project that references both Project1.dll and Project2.dll.
Right now, I build Project1.dll, and manually copy it to the place where Project 2 can pick it up.
Then I build Project2.dll and manually copy it and Project1.dll to the place where Project 3 can pick them up.
Obviously I'm doing something wrong (manual). What is the correct way to keep my projects' references up to date?
Updating Project2 to VS2008 and then creating one solution containing all 3 projects is not an option at this time. We have a 3rd party visualstudio plugin that does not yet work in VS2008. Project2 must stay in VS2005
De-updating Project1 and Project3 to VS2005 and then creating one solution is not an option either. We're relying on C# 3.0 and .net 3.5 features in those projects.
Probably the best option would be to have a common build folder for all three projects. This can be done in the Project Properties-> Build -> Output path. Then point the references to the output folder. That way anytime you build any of the lower projects, the higher projects would have the latest versions. You can set the path per configurations (Debug, Release) as well, so you won't need to change that for each type of build.
How about a pre-build event for Project3, that goes out and uses a batch file to build Project1 copy it to Project2 folder and then build project2 and copy it to project3 folder.
I would recommend sharing the csproj/vbproj files between the solutions. The format of the project files is compatible between the two versions of studio (solution files are not, however), and as long as your VS2008 projects are targeting the 2.0 runtime you should have no trouble compiling them. This will allow you to reference the projects, which will take care of dependencies.
The only place where this gets hairy is if you have a web project that needs to work between the two versions of studio. In that case there are some modifications to the project files which will point to the correct MSBuild target files.
We use a build script that handles the dependencies, builds the DLLs and does what you're doing manually.
A trick I have used in the past is to move everything to 2008. Then I setup a special solution in 2005 for project two and use it to work with the addin. Getting this to work just depends on how bad project two behaves in 2008.