For a sql script file in a database project, is there anything to be gained by using a Build Action of Build or Compile? I usually just use None, but wonder if Build or Compile do anything for a sql script e.g. perhaps some sort of additional syntax checking?
(We use our own custom deployment for scripts, so deployment options are not required.)
When performing a schema compare, only .sql files with their build action set to Build are included.
If you are building the project, creating a dacpac and then using sqlpackage.exe to deploy the dacpac to the server. Then setting the build action to none on a script will ensure that the script is not included in the update to the server. It give you8 a way to control what updates are carried out thru this tooling.
Nope, there is nothing to compile, just use None...
Related
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 would like a module to be run by all agents when a VCS trigger condition is met.
Is this possible?
One way you can do this is by adding a Schedule Trigger which has an option to run on all agents.
Having looked into it, as far as I can see, not directly,
the behaviour could potentially be achieved by using the command line remote runner plugin,(http://confluence.jetbrains.net/display/TW/Command+Line+Remote+Run+Tool) through a seperate build configuration linked to the VCS to detect the changes, calling the Remote Run tool from a command line build step to build the project on each required agent.
Further research into the Command Line Remote Run tool would be required to confirm this is possible.
There may also be some functionality allowing this in the REST API, although my look through the documentation didn't show anything up.
Have you had much luck working on alternative solutions?
I've created a build configuration to update our source managed third party referenced assemblies directory and this is a snapshot dependency on most if not all build configurations. When I update this directory with a new or more recent assembly, I'll too would like this configuration to be run on all build agents.
At the moment, I've simply duplicated the configuration and bound each to a specific agent. It adds management overhead, but has temporarily resolved the issue.
You could install this plugin and specify the list of agent names and it will run once per "value" in the matrix.
https://github.com/presidentio/teamcity-matrix-build-plugin
I know that you can create a template project to ensure that certain required settings (for ex: code analysis, treat warnings as errors, platforms, etc.) are set in a new project.
I want to enforce this as a part of the CI process i.e. in the build I want to validate the C# project files against a template (or an XML file) and cause a build failure if the project files don't conform to it. I need suggestions and ideas on how this can be achieved.
I want to try this with TFS 2010 and VS 2010.
I am writing a custom task to search for all the C# project files and compare the Xml structure of the Template project file with the Actual project file and report any difference as error.
I usually tackle this by customizing my build process to run Code Analysis/StyleCop/etc against all projects regardless of project settings.
Likewise for Treat Warnings as Errors. I just override the proejct settings at the build-level so that no matter what people do to the projects I know that everything I want to run is being run at build time.
I'm using the method outlined in this question to automate the database deploy with Hudson. When I deploy the project from within Visual Studio, everything works fine and it updates the target database. When it runs in Hudson, I get this warning: "Deploy warning TSD01266: The source's object [DBName] is different than the target's version of the object but the target object will not be updated."
Has anyone else run into this?
Thanks!
Is it in both cases the same database? Can you run the commands from command line with the Hudson user?
I'm having trouble with an MSBuild script as it's executing correctly, but in TFS Build Explorer it reports a Fail (red X icon). However, despite all the builds reporting failed, if I examine the logs, they look fine, and end with :
Done building target "EndToEndIteration" in project "TFSBuild.proj".
Done Building Project "C:\Builds\EDRM Development\CI_Development_IW471_UserGroup_CG3\BuildType\TFSBuild.proj" (EndToEndIteration target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
What exactly is Build Explorer using to determine the success of the build script ?
The script itself is using the MSBuild Extension Pack (from CodePlex) to build a solution containing 40+ VB6 projects. So that it can be run by team build, i've implemented target EndToEndIteration, with the build target as a 'DependsOnTargets'. EndToEndIteration is the only one of team build's targets that I have implemented in the script (it appears to be the only mandatory one ?).
When i run the script from the command line it reports success also, so it's only Build Explorer that's indicating a failure.
Any ideas why this is happening ?
The success of the build is determined by ALL Tasks ended with success pattern (if one fails it may be consider as partially succeed build, but the icon will still remain as a failure icon with small green success icon:)
Try to look at build log's, because it seems, that some pre or past run steps are failing (unable to copy sth, etc). The easiest way is to determine where the problem is, is to schedule the build from Visual Studio with maximum verbosity level for each Task.
Thanks for the reply. All tasks were ending with success.
I've just found out the solution though, so I'll add it here.
As I'm building a VB6 solution (comprising 40+ projects), I'd created a pure msbuild script, that i'd originally been running from the command line. To use it with team build for CI, i'd added a target "EndToEndIteration" as this is the only mandatory target for a new msbuild script in team build (i.e. a script not created via TFS's create build script wizard). This results in the problem above, where even if the script executes perfectly, build explorer still reports failure.
The solution is to create a build script using the TFS wizard (for any .Net .sln file - it doesn't matter - the reference to it will be deleted). Then take a copy of this tfsbuild.proj file and strip out the details relating to the .Net project and paste in your msbuild targets. Then implement target "CoreCompile" to initiate the targets you pasted in.