I want to obtain the assembly version from my solution and apply that to a cc.net label. I think I'm doing it backwards since all the info out there have the CI server set the version. But I'm not sure how to integrate different release versions and the development branch into CI. Every time we release we up the revision number. Would/should I add a new project in cc.net for every branch? Is there a way to automatically get the latest branch? Sorry for so many different questions in one...question. I'm new to this CI stuff.
FinalBuilder and the AssemblyInfo Updater
[Update : Cool, can't add hyperlinks. Put FinalBuilder and 3xw en dotcom in the end in front of the following url:)
/Products/FinalBuilder/FeatureMatrix/FeaturesCompilerActions/tabid/98/Default.aspx
Use "PropertySet Define" based on .NET Assembly Numbers
Use "PropertySet Load"
Use "PropertySet Incremement"
Use "AssemblyInfo Updater" to save it again
And you're done. :)
You will find this all much easier if you switch to TeamCity. I've wrestled with so many nant scripts/cruisecontrol config files in the past I'm almost blind from angle brackets.
I cried like the accountant who was shown the first spreadsheet program when I started messing with TeamCity. It will make your life 1000% easier.
Related
We have a web application and occasionally a bug will creep up that needs to be taken care of and fixed. We are using subversion as our code repository. What I am wrestling with is at what point do you create a new branch or tag. We were thinking that if the application needed to be rebuilt or the MSI needed to be rebuilt then we would create a branch. In the case of something simple like a typo, we would just distribute out the offending .aspx page.
What are some of your strategies for branching and building strategies?
Currently, ours looks like this. We have a class library, and Web application. We make our corrections, copy over the changed pages/DLLs to the MSI Creator (Advanced Installer) then rebuild our MSI. We are debating on whether or not to use a web deployment project/MSbuild or something similar. We need it to be reproducible, reliable and simple.
When you release your code, you would "tag" it. Let's say you tag it with "ReleaseVersion_1.2.3.4"
The "trunk" would be your main branch. And you continue to develop there.
If a bug comes along for a customer who has the released code, you would branch from the "tag" ( "ReleaseVersion_1.2.3.4" ), and would hotfix something there.
Then you would most likely merge code from this HotFix back to "trunk".
That's the simplest way.
There are many options for branch strategies.
But if your code hotfixes are occasional, this one will work.
I'm using the N2 CMS system for ASP.NET. Well I say 'using', I'm really just trying to develop a tiny understanding of it.
One of the things that's obstructing me is that it's set up in a way I've not seen before. Where are the codebehind files for the pages?
Can anyone tell me for example, where is the code for /Edit/default.aspx? How on earth do I debug what it is doing?
Thanks
David
It always used to be in N2.Edit.dll, but by the look of it they've rearranged this in more recent builds - I'm not 100% if it's now in N2.Management.dll or in N2.dll itself.
As usual the easist thing to do is to get hold of the source code (or an SVN checkout of the correct version), build it yourself and then replace the DLLs you were using with your built versions and their PDBs - you can then step into these correctly. You might want to go back to the regular releases for deployment, though.
If it's still Edit/default.aspx for you then I guess you're on the 1.5 code or thereabouts? In that case N2.Edit is built from src/wwwroot in the source code. You can just drop the entire src/wwwroot/Edit directory into place in your app and run it from the codebehind files there, not a compiled N2.Edit - that's easier to tweak, although I think it was easier to step through using a built DLL.
You may have to hunt around the build tree for all of the DLLs - I don't think they all get copied into one place. I used to take the DLLs from the N2.Edit.Tests project bin directory, and N2.Extensions and N2.Security from the N2.Extensions.Tests bin directory.
So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
What are the strategies for versioning of a web application/ website?
I notice that here in the Beta there is an svn revision number in the footer and that's ideal for an application that uses svn over one repository. But what if you use externals or a different source control application that versions separate files?
It seems easy for a Desktop app, but I can't seem to find a suitable way of versioning for an asp.net web application.
NB I'm not sure that I have been totally clear with my question.
What I want to know is how to build and auto increment a version number for an asp.net application.
I'm not interested in how to link it with svn.
I think what you are looking for is something like this: How to auto-increment assembly version using a custom MSBuild task. It's a little old but I think it will work.
For my big apps I just use a incrementing version number id (1.0, 1.1, ...) that i store in a comment of the main file (usually index.php).
For just websites I usually just have a revision number (1,2,3,...).
I have a tendency to stick with basic integers at first (1,2,3), moving onto rational numbers (2.1, 3.13) when things get bigger...
Tried using fruit at one point, that works well for a small office. Oh, the 'banana' release? looks over in the corner "yeah... that's getting pretty old now..."
Unfortunately, confusion started to set in when the development team grew, is it an Orange, or Mandarin, or Tangelo? It looks ok. What do you mean "rotten on the inside?"
... but in all honesty. Setup a separate repository as a master, development goes on in various repositories. For every scheduled release everything is checked into the master repository so that you can quickly roll back when something goes wrong.
(I'm assuming dev/test/production are all separate servers, and dev is never allowed to touch production or the master repository....)
I maintain a system of web applications with various components that live in separate SVN repos. To be able to version track the system as a whole, I have another SVN repo which contains all other repos as external references. It also contains install / setup script(s) to deploy the whole thing. With that setup, the SVN revision number of the "metarepository" could possibly be used for versioning the complete system.
In another case, I include the SVN revision via SVN keywords in a class file that serves no other purpose (to avoid the risk of keyword substitution breaking my code). The class in that file contains a string variable that is manipulated by SVN and parsed by a class method.
An inconvenience with both approaches is that the revision number is not automatically updated by changes in the externals (approach 1) or the rest of the code (approach 2).
During internal development, I'm using milestone numbers (M1, M2, M3...). After release, I'll probably just update dates ("the January 2009 update").