I have REST project, which I want to commit to repo, with the goal of possible contributions from some team members.
But there can be troubles during resolving conflicts, because of one huge XML project file.
2 known recipes:
Use Pro version of SoapUI, and set "Composite Proj" parameter to True. In result project will decomposited, and(lesser) troubles with merging
Set True to property WSDL>PrettyPrintProjects
But how to pretty print/composite REST projects in SOAPUI Free? That WSDL property does not impact on saving such projs.
Cheers.
Related
I'd like to automatically increment my assembly versions based on this ruleset:
Revision is always 0
Build is incremented when the only WIT in the release is a Bug fix
Minor is incremented when the release contains any WIT other than a Bug fix; Build is then always set to 0
Major is never automatically incremented
Naturally this will require a build step that can interact in some way with the project.
My first thought was to build a small Windows Service that utilizes the TFS SDK to construct the version number based on these rules and return it via a WCF call, etc. But I run into a problem there with a business requirement that all code and functionality must be replicated into a VSTS project as well (the customer owns the code and must be able to proceed without me). There's no installing such a service there, of course.
I then considered installing the service on his server, in turn making it available to VSTS. This would pass the Rube Goldberg test with flying colors.
Is there an easier way of accomplishing this task? One that can work in both environments?
EDIT
I found this, but it's doubtful that the TFS SDK is registered in the GAC for VSTS.
Can someone confirm? Is the TFS SDK available to build scripts running on VSTS?
Well now that didn't take long.
I found this and this for using PowerShell to query the REST API. No GAC/SDK needed.
-- EDIT -----------------
I've intentionally excluded content from the pages behind these links as the solutions provided are exceedingly complex; it's not possible to cover the concepts here in a single post. In case the pages disappear or the URLs change, here are the links at archive.org:
1. PowerShell and vNext Builds
2. VSTS/TFS REST API: The basics and working with builds and releases
In any case, the concept is popular and well-covered—in the event these two become inaccessible, there are many others available on the same subject matter. As quickly as I found these, someone could find more.
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.
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
I'm building a tool to integrate with TFS and it needs to properly parse TFS logs (from the tf.exe history command) and checkout different revisions (again using tf.exe). It works great on the test TFS server I have, but I want to test it on a broad range of large repositories to make sure my parsing works properly.
I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member.
Are there any collections of open source code hosted on public TFS servers? Are there any other publicly available servers I could use for testing?
I would suggest using svn2tfs and choose any relatively active project on SourceForge. There are plenty of projects on SF to choose from that use SVN and not CVS. You might even get a bonus out of it and help the svn2tfs project work out any kinks.
Since you mention tf history command, I assume you want to collect/parse logs on the project's (and its files) history of checkins.
So in addition to large repository, you also need a good amount of history, am I right? If yes, then here's your set of problems:
Most projects on codeplex use Mercurial, not TFS. So even if you get access, you cannot use TFS with them.
As you mentioned, they require you to a be a member for you to access the source.
Even if you get access or find a public server (unlikely), you still would need good amount of history.
If I'm correct in my assumptions so far, here's the easiest (bit tedious though) way out:
Go to any large projects's such as Nuget or Wix
revisions
Download any old revision (go back as far as you want the history for). You can download zipped src files without being a member.
In your test server, checkin the code (src) to create the baseline.
Download the next revision.
Checkout files in your server and overwrite them with the newer revision's files.
While checkin, use the history.txt (sample) to create checkin comments
Repeat this process few times.
Voila!! You now have a large repository with lot of history!
Hope this helps.
Have you tried some of the larger projects on Codeplex?
http://www.codeplex.com
If you only need read access you should be able to play around with the various repositories.
I don't have a huge amount of tfs experience, but I would assume there are migration tools that let you ingest code repositories from other products (e.g svn or hit).
If so, you might want to find a svn/git repo for a sizable foss project, and try importing that.
"I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member."
This solution appears to be the general consensus amoung SO'rs. I've read some of the Codeplex TFS connection problem threads (you linked to below) and I hope the comments in this thread resolves the issue:
Connecting to Codeplex TFS as a Coordinator or Developer.
I'm wondering if you can use git-tfs project to import an existing Git project into TFS.
Download and install git-tfs
Create a new TFS project
Clone the TFS project to a Git project using git-tfs ("git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project")
Import a existing Git project of your choice into your fresh new Git project (I don't know the command but I think it's possible).
Use git-tfs to checkin to TFS Server ("git tfs checkintool")
=> Do it makes sense ? And works ?
For more information:
http://lostechies.com/jimmybogard/2011/09/20/git-workflows-with-git-tfs/
I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)