We have a large solution, 40 projects and there are a series of interdependencies. When we build the solution with MsBuild we are getting the following error:
EXEC : The remote server returned an error : (400) Bad Request…
Further investigation shows the internal error is that the id already exists as it is building some projects twice and attempting to deploy them twice with the same version number. Looking at the cause we have installed OctoPack into our main website but we also have an Azure Cloud project which references the main web project so when the solution is built it is building the web project twice, on the first run it succeeds and the package is pushed successfully, on the second it fails.
Is there a way when building the solution to control how often the OctoPack is deployed, or to allow overwrites, or is the only solution to say create an Octopus Deployment configuration that doesn’t build the azure cloud service. The problem there is that we are trying to get Octopus to deploy the azure cloud service as well as maintaining the deployment of dedicated server instances as well.
Many thanks for any help.
Hi Richard,
Thanks for getting in touch! Can you explain a bit about what build process you use? Do you use TeamCity or some other tool?
You are correct the error is because Octopus does not allow for the same package version to be uploaded a second time.
Once we understand more about your build process we can better help you here.
Vanessa
Hi Vanessa
Thanks for getting back to me. For the record we are just starting down this road and so we are happy to go with your best recommendation. At the moment we have our source code in TFS using Visual Studio Online so we do not have our own build server. We have approximately 40 projects in our solution of which the main 3 are a web application, a windows service and a database migration application.
I have setup an Azure virtual machine with the octopus deployment application on and a tentacle. I am using the following build command in a batch file to test at the moment:
set msBuildDir=%WINDIR%\Microsoft.NET\Framework64\v4.0.30319
call %msBuildDir%\msbuild.exe “{SolutionFile}” /p:Configuration=Deployment-OctopusDeploy /p:RunOctoPack=true /p:OctoPackPackageVersion=%1 /p:OctoPackPublishPackageToHttp=http://localhost/OctopusDeploy/nuget/packages /p:OctoPackPublishApiKey={OURAPIKEY}
I had to create a new configuration that did not build the Azure Cloud Services project to prevent the double build on the main web application which tried to deploy the NuGet package twice. I also had to pass in the version number as in our assembly file we have the version number as follows:
[assembly: AssemblyVersion(“2.62.*”)]
And we were getting an error saying 2.62.* is not a valid version number, so we put the batch file in a console app, loaded the version number from there and passed it into the batch file in a process.
We also have a dev and main branch and our end goal is the following:
We wanted to have our TFS online build on check-in to either dev or main and pass the OctoPack parameters to the MsBuild agent and if the NuGet packages are from the dev branch append them with dev and if they are from the main branch append them with main. Also we wanted the version read correctly out rather than having to fire from a console application which I do not believe we can do with the online version of TFS build.
Is this possible with OctoPack or should we start looking at also integrating TeamCity? I am completely unfamiliar with TeamCity but I am starting to look at that today.
Many thanks for any help/advice
Richard
Having said that if there is anyway to do that without TeamCity it would certainly simplify things.
Hi Richard,
Sorry for the delay in getting back to you. There is a solution but it is going to take a bit of an explanation and it does not need TeamCity.
I just wanted to let you know that we will get back to you about this, and you don’t have to learn TeamCity in the mean time.
Vanessa
Hi Richard,
I am very sorry for the delay in getting back to you. One of our customers who uses TFS and VSO pointed us to this blog post, and I wonder if it would be a help for you?
http://geekswithblogs.net/michelotti/archive/2010/05/15/version-assemblies-with-tfs-2010-continuous-integration.aspx
It means you can still avoid learning another product like TeamCity as you already have a TFS, and should hopefully give you what you need with versioning and branching.
Let me know what you think and if I should track down some more resources.
Vanessa
Hi Vanessa
Thank you for your help with this, in the end I bit the bullet and installed teamcity on our build server and it was actually very easy to figure out and integrate with octopus deploy.
This allowed us to set the version number for the build very easily.
Richard
Hi Richard,
I can’t say I am unhappy about this. We have much better support for TeamCity currently, and we agree it’s much easier to use!
Vanessa