I am using single SharedAssemblyInfo.cs file to share AssemblyVersion for all projects in the solution.
Is there a way to pull that info and update the Deployment project's Version property with the same value?
Related
I am using dbup for my database migration and my dbup project in visual studio solution definitely produces required exe and exe.config file. Now when I deploy my project through octopus deploy I have no exe.confog file in nupkg generated by octo however I can confirm that exe.config is in the release folder on the server.
I found that octopus had a bug with similar issue https://github.com/OctopusDeploy/Issues/issues/970 which is resolved now. in version 2.5.1 (https://octopus.com/downloads/compare?from=2.2.1&to=3.4.10) and I am using octopus version 3.3.17 , however I am facing same behaviour..
Can anyone please point me in the right direction?
Many thanks.
If you run MSBuild myProjectFile.csproj /p:RunOctoPack=true inside the project folder, you will see some OctoPack logging showing you what it did exactly. It will tell you where it put all the files, which .nuspec file was used, etc. Maybe that'll clear some things up.
I am using TeamCity with a Visual Studio (.sln) build step. In this build step I have the "Run Octopack" setting enabled and the package version set to my team city build number.
I would like to include a specific string in each produced package id and it would seem the 'Append to package ID' setting available in the build step would be the best/easiest way to achieve this. However any string I include here never shows up in the produced .nupkg files.
Am I misunderstanding the purpose of this setting or is there additional requirements to use this field?
In order to use this functionality you'll need to upgrade the OctoPack version to at least 3.0.6
Install-Package OctoPack -Version 3.0.6
Hope this helps
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).
Every time I publish the application in ClickOnce I get get it to update the revision number by one. Is there a way to get this change automatically to change the version number in AssemblyInfo.cs file (all our error reporting looks at the Assembly Version)?
We use Team Foundation Server Team Build and have added a block to the TFSBuild.proj's AfterCompile target to trigger the ClickOnce publish with our preferred version number:
<MSBuild Projects="$(SolutionRoot)\MyProject\Myproject.csproj"
Properties="PublishDir=$(OutDir)\myProjectPublish\;
ApplicationVersion=$(PublishApplicationVersion);
Configuration=$(Configuration);Platform=$(Platform)"
Targets="Publish" />
The PublishApplicationVersion variable is generated by a custom MSBuild task to use the TFS Changeset number, but you could use your own custom task or an existing solution to get the version number from the AssemblyInfo file.
This could theoretically be done in your project file (which is just an MSBuild script anyway), but I'd recommend against deploying from a developer machine.
I'm sure other continuous integration (CI) solutions can handle this similarly.
Edit: Sorry, got your question backwards. Going from the ClickOnce version number to the AssemblyInfo file should be doable. I'm sure the MSBuild Community Tasks (link above) have a task for updating the AssemblyInfo file, so you'd just need a custom task to pull the version number from the ClickOnce configuration XML.
However, you may also consider changing your error reporting to include the ClickOnce publish version too:
if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
Debug.WriteLine(System.Deployment.Application.ApplicationDeployment.
CurrentDeployment.CurrentVersion);
}
I implemented this recently using some custom tasks. An issue I found with implementing this with ClickOnce is that all your DLL files are updated. This causes the ClickOnce update to download all the application files every update. This bypasses on of the nice features of the ClickOnce deployment where only the modified files are re-downloaded in an update.
Just something to think about when implementing something like this with ClickOnce.
Steps:
Use external incrementing version number (if you leverage a continuous integration server like CruiseControl.NET, then it comes from the build label).
Use GlobalVersionInfo.cs (file link-referenced by all projects in your solution) to hold the current version and update it on the build with the AssemblyInfo task from the MSBuild Community tasks.
Script Mage command-line tool from the .NET SDK to update the ClickOnce manifest, using the same version (see the -v and -mv switches).
BTW, a nice bonus is that, whenever you automatically publish a newer ClickOnce deployment version via the integration script, if you also specify the minimal version to mage.exe (same as version), then every user will be updated automatically on the next application launch.
You'll probably need to create a piece of code that updates AssemblyInfo.cs according to the version number stored in the .csproj file. (The ClickOnce deploy version is stored inside an XML tag.)
You'd then change your .csproj file to run this bit of code when Publish|Release build is performed. The MSBuild folks have blogged about how to perform custom actions during certain build types; check the MSBuild team blog.