I have an environment where I'm building several library solutions in TFS. At the end of the build process the script packages them into a NuGet package and pushes them to our local feed.
Now we can include these libraries, which change little day-to-day, in our upstream projects.
These libraries as well as our upstream projects generally are branched at the same version. Basically the trunk is our evolving latest version. Say before branching the trunk is 3.0.0.123, 123 being a running build number. At some point we mark the current trunk as what we're going to release and branch it. The version number of the trunk at the time of the branch becomes the version of that branch and we would increment the version in whatever appropriate manner for the trunk to what we would feel is likely going to be the next release (say 3.1.0.456).
This presents a slight oddity to how we'd like to use NuGet. We would want that the branch, 3.0.0.456, use the lateset library from the branch (perhaps 3.0.0.457) and the trunk to use the latest from the trunk (3.1.0.789)
So what this basically boils down to is can we setup the versions for a solution using NuGet to be similar to the manner NuGet uses when defining dependencies within a package?
Ideally, I'd like to tell the branched upstream application to use [3.0.0.456, 3.1) and the trunk to use latest (no version). In this scenario it would pick up the branch would pick up the next branch build (3.0.0.457) and the trunk would pick up whatever the last NuGet package that was published to the feed.
The only idea that I've come up with as a possible solution is using parameters for the build template and using that to update the package.config file before the NuGet targets are run.
I appologize if this should go on SuperUser or elsewhere...
After doing some digging to have my build do some auto creation of packages for our library projects I came to the (wrong) conclusion that this was a limitation of NuGet. I parsed their source for any XSD documents to describe their XML so that I could see how their nuspec worked.
While I had their source I started looking into how I could modify the package.config file to accept their schema for limiting versions. After some digging I found an attribute that can be added to the package node in package.config: allowedVersions. This is exactly what I was looking to add!
Once I had this piece of information I was able to dig a little deeper into how it was implemented. Turns out that this functionality has been around for a while and is even documented on their docs site: http://docs.nuget.org/docs/reference/versioning
It is in the dependency versioning guide located at the bottom. I must have completely glossed over it or never read that far!
Turns out that this was a non-issue and the only problem was my ignorance. Just a reference for any Googler's out there that land on this page!
SOURCE (LOCATED AT BOTTOM OF PAGE): NuGet Versioning
Related
I appreciate there has been some comment on this, but I am wondering whether my situation is a little different.
I am using MVC3 and VS2012. I have a solution with 2 projects, one for the web app and the other for the DB domain model.
I use TortoiseSVN as well as AnkhSVN within VS2012.
I have created a branch off the trunk where I have made quite a few changes including new DLLs and associated references. One of the big changes is upgrading Entity Framework to 6.1.1 from 5. So new dlls and namespace definitions.
The trunk has been tweaked to address some urgent mods.
I have checked out the trunk and branch into seperate local folders, and work on each seperately.
Normally, as I understand it, when one is ready to remerge the branch to trunk, one uses SVN, but this can be error prone. I am a big fan of Beyond Compare, and used it before SVN. I now use it as my diff tool within SVN. I could use Beyond Compare to copy across the modified code from the branch local folder to the trunk local folder and then "commit" the local changes back to "trunk", but this local copy across, while being robust, is very tedious.
I would be grateful if one could provide a better recommendation.
Thanks.
I want to know which files created by CocoaPods in a given iOS project should be checked into version control. What makes most sense to include and ignore? Should I just add the Podfile? Or should I add the entire pods directory?
This is an ongoing debate even with the CocoaPods core team. https://github.com/CocoaPods/guides.cocoapods.org/issues/3
At some point someone felt that it should be ignored enough to get it into Github's gitignore template for Objective-C.
Some good points were brought up in the linked debate above about longevity of the project where if you check in your pods directory in the future other developers should always be able to build the source regardless of the state of CocoaPods or the specs repository without any dependency on the command line too. But I could see you having this same issues with Git submodules since the remote repositories could be deleted in the future as well. I think this comes down to your preference. Personally I don't like having updates to external dependencies directly in my source control history.
I've been tasked with setting up a new Team Foundation/Build server at my company, with which we'll be starting a new project. Nobody here currently has experience with TFS, so I'm learning all of this on my own. Everything is working so far; The server's been set up, the Repository and Team Project has been created, the Build Server has been created, and I've created a simple hello world application to verify the source control and Continuous Integration builds (on the build server) run properly.
However, I'm having a problem setting up the automatic versioning. I've installed the TfsVersioning project, and it's working fine; I'm able to define a format for my assembly versions. I haven't yet decided what format I'll use; probably something like Major.Minor.Changeset.Revision (I'm aware of the potential problem regarding using the changeset number in the assembly version, so I may decide to switch to Major.Minor.Julian.Revision before we begin development).
The problem:
I don't want assemblies to have new file versions if their source code has NOT changed since the last build. With a continuous Integration build this isn't a problem, as the build server will only grab the source files that have changed, causing an incremental build which produces only updated modules; the existing unchanged modules won't be built, so their version will remain unchanged.
If I set up a nightly build, I'll want to clean the workspace and perform a Build-All. However, this means that ALL assemblies will have new version (assuming the Assembly File Version includes the build number).
A solution?
This has prompted me to consider using the latest changeset number in the Assembly File Version. This way, if nothing has been committed between two successive Build-Alls, the versions won't be incremented. However, this would mean that a change and commit to a single file would force a version increment on ALL assemblies.
I'm looking for one of two things:
A way to only increment Assembly Version Numbers if their source/dependencies have changed since the last build. Successive Build-Alls should not cause changes in version numbers.
OR
A way for testers and non-developers to be able to tell version W.X.Y.Z and version W.X.Y.Z+1 of assembly 'Foo' are identical, even though they have differing file versions.
I've probably read about 20 articles on the subject, and nobody (except this guy) seem to address the issue. If what I'm asking for isn't common practice in the Team Foundation ALM, how do I address the second bullet point above?
Thanks for your time!
This is something I did in the past. The solution has two critical points:
You must use an incremental build, i.e. Clean Workspace = None
The change to AssemblyInfo.cs must be computed at each project
This latter is the most complex and I will just draft the solution here.
In the custom MSBuild properties use CustomAfterMicrosoftCommonTargets to inject an hook in normal Visual Studio compile
/property:CustomAfterMicrosoftCommonTargets=custom.proj
Also forward a value for the version
/property:BuildNumber=1.2.3.4
In custom.proj redefine the target BeforeCompile to something similar
<Target Name="BeforeCompile"
Inputs="$(MSBuildAllProjects);
#(Compile);
#(_CoreCompileResourceInputs);
$(ApplicationIcon);
$(AssemblyOriginatorKeyFile);
#(ReferencePath);
#(CompiledLicenseFile);
#(EmbeddedDocumentation);
$(Win32Resource);
$(Win32Manifest);
#(CustomAdditionalCompileInputs)"
Outputs="#(DocFileItem);
#(IntermediateAssembly);
#(_DebugSymbolsIntermediatePath);
$(NonExistentFile);
#(CustomAdditionalCompileOutputs)"
Condition="'$(BuildNumber)'!=''">
<Message Text="*TRACE* BuildNumber: $(BuildNumber)"/>
<MyTasksThatReplaceAssemblyVersion
BuildNumber="$(BuildNumber)"
File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</Target>
You need to have a task for replacing the AssemblyFileVersion in the AssemblyInfo.cs source. MSBuild Extension Pack has an AssemblyInfo task for this purpose.
I posted the full details at my blog here, here and here.
What's the difference between trunk and branch in jenkins?
It sounds like you're just interested in the terms trunk and branch in general in relation to source control. Trunk generally refers to the "main" version of source for a piece of software, and a branch is a (usually temporary) diversion from this main line, usually to work on a feature which is then merged back in to the trunk.
The details depend on which version control system you are using, but here's a description in relation to SVN:
https://stackoverflow.com/a/16163/206297
Trunk would be the main body of development, originating from the start of the project until the present.
Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
As it relates to Jenkins, you're probably interested in which version of the software the continuous integration process should be building. I'd suggest more often than not it will be the trunk, as this is the canonical version, and the one most likely to be the candidate for release. But you might have branches for legacy version, etc, which might need building too. But it will depend of course on the process for any given company/project.
Our projects in TFS are organized like this:
$\DefaultCollection\ProjectName\Source <-- source code goes here
$\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here
Now that NuGet is on the scene, is there any reason to change our approach and use NuGet's packages folder for dlls that come from NuGet-aware projects? I'm leaning against this because
1) it creates two places one must look for dependencies
2) it leaves us open to one developer updating a package and breaking some dependency
That said, if anyone can report a good reason to start using NuGet in a TFS environment, I will happily present your ideas to my team as if they were my own (joke).
Nuget 1.6 now allows for packages not present to be downloaded dynamically upon build. So you can now check in to source control without the .dlls, but the build itself will pull the correct package.
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages