I would like to automate the deployment of Postsharp that's why I would like to have a text file that would preserve the necessary deployment settings.
Well there is a solution although not very elegant. The instalation folder was copied to the repository and there was added an post-build action in project settings that would run Postsharp.exe with necessary parameters from the location that is in repository.
I dont think so. We use it at business and we all need to install package.
Related
I have a Teamy City Build Server and wanted to migrate my solution piece by piece to Package Reference. Unfortunately it seems that it doesn't find the references / packages for those project I already moved or reacreated with package reference. The packages are restored correctly as I see them in the global .nuget\packages folder. Also I can build locally without any issues.
Funny enough, I have some other smaller projects which do work correctly with package reference on teamcity.
TeamCity Version: 2019.2
NuGet: 5.4
I also tried to add a .NET CLI Task with a restore command, but that didn't change anything aswell.
NuGet Installer Step:
dotnet restore step:
In the end I create a new pipeline and reconfigured all the steps from scratch instead of copy an existing pipline and now it works. seems there was some issue somewhere attached to those existing pipelines.
After an entire day of trying to fix this problem I finally found the cause.
In the parameters of the build configuration in TeamCity there was a parameter called "system.VisualStudioVersion" with its value set to "11.0". I changed the value to "16.0", and this fixed the problem for me.
This might explain the solution of NPadrutt, assuming he had the variable set in that particular build configuration. Recreating his build configuration would then result in a new build configuration without the bad parameter, fixing the problem for him. But in my situation the parameter was inherited from the root project, so recreating the build configuration wouldn't have fixed it for me.
I am deploying a nuget package that comes to Octopus Deploy from TeamCity. What I need to do is to apply config transforms and deploy the zip archive of that package content (Windows Application binaries) to a specific folder of the tentacle. I even don't need to publish the package itself. Is there a way to achieve that?
If I understand you correctly, you should be able to achieve this fairly easily.
Have a standard step type of Deploy NuGet Package to install the nuget package onto the tentacle for the correct environment and role, ensuring that Configuration Variables and Xml Transforms are enabled - This will ensure your configs are transformed OOTB with no effort.
In order to then deploy the binaries I would use some custom powershell as this doesn't appear to be an "application type" that Octopus treats as a first class citizen. You could write the powershell inline as a second step by adding a step type of Run a PowerShell script and writing the code in the Octopus UI. Not knowing if the are going over a network share or any specifics I've not attempted to write any code.
My personal preference would be to write this as a powershell script that is included in the .nuget package. Octopus Deploy supports a naming convention on certain PowerShell files it finds in the .nuget package (PreDeploy.ps1, Deploy.ps1, PostDeploy.ps1). I'd write a PostDeploy.ps1 and package that up. I'd then have that script under source control and could easily make changes to it.
The caveat with this if you aren't careful is that you then start to move deployment implementations away from Octopus. However, written carefully and generically you could bootstrap the script with Variables (such as path to directory / network share etc) which makes it reusable should the need arise, and you can have it work differently in different environments.
Please pardon my ignorance if I've still not understood what you mean by the binaries "being in zipped form"
Further details on the Octopus Deploy PowerShell Scripts
Hope this help.
You could add a post-deployment powershell script to your deployment step to zip the contents of the deployment folder after the configs have been transformed.
https://blogs.technet.microsoft.com/heyscriptingguy/2015/03/09/use-powershell-to-create-zip-archive-of-folder/
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
I have created a Visual Studio Deployment Project for my application. We are a using subversion to manage version numbers and I've got versionInfo.cs file which contains the version number. I want to give the version number I have in my application (versionInfo.cs) to the Version Property of the setup project. I am not sure how to it... Do I need to create a custom action? Or what's the best way to do that.
Thank you!
As for me, setting version is a responsibility of build process. So, you don't need a custom action - it is a part of installation logic and runs at install time. Instead, teach your build engine to put correct version to your installation package (e.g. read it from VersionInfo.cs and put to vdproj file).
Finally I fixed the issue.
I've setup Cruise Control build server and added Nant script to change the version in the setup project.
Thanks,
Charith
I am setting up a Continuous Integration server.
I have one issue that doesn't seem to be mentioned in the tutorials.
I have a ASP.net Web Application that I need to compile and them publish.
My Problem is that I seem to be able to compile the app but when I attempt to use a buildPublisher this copies every thing including .svn files & folders and ms CS files.
I am using an MSBuild task to compile my source. I tried setting my MSBuild Output Directory to directory but this didn't seem to have any effect.
What am I not understanding?
Thanks
You're probably looking for the _CopyWebApplication directive:
http://blogs.msdn.com/nmoreau/archive/2007/01/26/deploying-web-application-projects.aspx
We use CruiseControl.NET to deploy our ASP.NET applications to our test servers for the QA department so this is indeed possible.
In each project we created an additional build configuration called 'Deployer' which is identical to the Debug configuration with the exception of building an additional Web Deployment Project. So by running MSBuild in the Deployer configuration we can generate our compiled output in a known location.
We then use NAnt to perform a simple copy operation to the required location, i.e. into a folder where our IIS server is configured to look for the applications.
I know you don't mention NAnt in your question but it's well worth getting familiar with it if you want to get the most out of CCNet.
I'm not at work at the moment but if this makes any sense and you want some additional information then let me know and I'll pull some more information together.
Hope this helps
Are your bin or obj folders checked into svn? if so that would contribute or possibly cause this issue.
Because those folders shouldn't have any svn folders/files
You can configure SVN to call the .svn folders _svn instead.
Set the SVN_ASP_DOT_NET_HACK environment variable.