We Keep Coding

Automatic patch building and deployment of .NET application

The question in short form and then the explanation
We want to create patches and include only files which have changed in the build due to some bugfixes for a dotnet application. The patches should get automatically built in the Continuous Integration process involving SVN, Cruisecontrol.net and msbuild.
We have a scenario here:
We want to maintain a .net application which runs on remote servers using continuous integration. The source code is in a SVN and has 3 different repositories for DEV, QA and PROD.
Our developers do new bug fixes almost everyday and merge the changes into the dev repository after their initial testing and satisfaction.
The code after a certain problem is solved or a feature has been added is then merged into the QA repository.
The QA code is built and tested on QA machines manually.
After the QA testing we merge it into PROD. With it the QA also makes new patches for the files which have to be replaced or changed manually. Then the patches are deployed on a staging server. On which it is tested until perfect and then the patches are deployed on actual remote servers.
In search of continuous integration we are now trying to use a mix of CruiseControl.net and msbuild to do the process. The process is good until the stage where we have to generate patches from the QA builds automatically. After the patches are generated we will put them on a ftp server and from their they will be downloaded to the staging server to be tested.
The problem i.e. the generation of patches from the new build has a few aspects. The solution file for the application has many projects and the dlls are copied using postbuild events to the startup app bin folder. So we have a specific directory structure in the actual application which itself is a combination of 6 solutions which are more or less independent of each other.
The way we are trying to create the patches is we are searching the logs of svn to find which files have changed. Then we are parsing it finding the project name. Then we are copying all the files from the bin directory of that project to the patch folder in the specific manner in which the release has them by using a mapping file which has all the files of the application in it.
So can anyone please suggest a much better or easier way to make a patch provided we have svn and the cruisecontrol.net. Or any other opensource tool to do that.
hope the problem is clear

This whole process, in general, goes against established best practices. This is not necessarily a bad thing if you have good reasons for it, but I don't see them here.
In essence, you are not using QA and DEV environments to secure the stability of production. Worse, you use different source trees to build code for them. This introduces new points of possible failures into the deployment process.
A standard way of approaching this would be to have a single SVN code tree - tag a version when it is released to QA (using already built binaries!), possibly tag it again when releasing to PROD. Don't re-build the binaries, use the ones that you actually tested!

If your Msbuild task is performing a build instead of a rebuild then the date/time of unaffected dlls will not have their modified date changed.
I would suggest this for the following reasons:
Msbuild will update the modified date for any assembly which has been affected by a change - I.e. an interface change?
the assembly is what you want to deploy, so check this rather than the source for modifications. Otherwise you need to know the build process (won't change) - I.e. Souce file locations, references etc.
Your deployment would just include the dlls from the build directories where the modified date >= BuildDate.

I agree with skolima about the recommanded build & patch process. You should create your patches from your initial tags plus the modifications and then create a new version which have to be deployed in all environments.
In my company, we are using this method :
Each successfull build are automatically tagged by our CI Server
When a patch is needed for a specific version, the programmers copy
& check-out the tagged version and apply fixes on it
Then we have a specific "Patch" build on our CI Server which do
exactly the same thing as a normal build with a "Patch" flag and point to the patched sources
The deployment target is the same, the build process is the same, only sources changes.
The plus is the patches have their own build history on the CI because they are builded separately but are treated as normal builds.
Anyway, if you want to automate a patching processes between two repositories via your CI, ihmo you have to create specific MSBuild tasks to do this. You can either try to merge the changes between them or check the SVN diff & patch commands.

Implementing development processes - versioning and installers

In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment - version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I'd prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn't update automatically, and I'm wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don't want. I assume I can create this as a patch somehow, but I've not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I'd really rather approach one at a time.
Any thoughts for the best way to get over these two issues?

I don't have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I'll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it's a horrible road to go down. Even Microsoft knows it sucks and that's why it won't be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it's critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn't what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.

If these are released applications, then the installer method is fine. If you are adding libraries through this method, and not necessarily the actual application, then something like NuGet (package manager) is an option. NuGet itself is a bit infant and needs to grow up a bit, but I think it should fit your basic scenario.
If you have published software, a bootstrap on the client that calls for updates and then runs the update installer is a good pattern.
The basic answer is you have options, depending what bits you are employing and should take advantage of the one(s) that fit your needs.

Documentation and Build system for Mono/C#

I'm starting out on a new project and a team member has decided to use C# as the implementation language. I don't have a lot of experience in C#, but a brief reading shows that it's very capable of being a complete cross-platform vm. Beyond the language, I've been having trouble selecting tools and workflows for managing the code as the project grows. It should be fairly small (<10K lines) but I would like to have the ability to generate documentation as the project grows, manage any external dependencies that we decide to use, and automate builds and testing. I am wondering what tools are commonly used or considered best practices for this language.
I am mainly concerned with how would a build system potentially work on *nix as well as windows? Are there C# specific tools or is Make more common? In addition, I'd like to use a dvcs, but it doesn't look like Visual Studio and MonoDevelop support the same ones. What's the common vcs of choice for C#? For testing sort of Unit testing is available for C#/Mono? Finally, I know that there are good doc generators, but with the question of the build system, I would really like to have that just be a single step in the build similar to how testing is a step. Normally I'd automate with Hudson, but I am wondering if there is something more specific to the platform.
Overall, I'd love to see a solution that provides a decent workflow on both windows and *nix without a heavy admin burden. I am pretty sure this is the holy grail of project management, so anything that puts me on that path is awesome.

In a project I work on, we use Visual Studio 2010, MonoDevelop/XBuild, Git, and monodoc. Project files created by Visual Studio 2010 can easily be read by MonoDevelop and XBuild. Also, Git is an excellent VCS for distributed development (I especially like its branching). Monodoc, with some tweaking of command line parameters, can generate documentation from XML comments in code.

You can use any dvcs you'd like with it. MonoDevelop (at least in the trunk, not sure if it has been released yet) as Git support built in. There are some plugins for Visual Studio that give you Git too.
Either way though, you don't need your source control to be integrated within the IDE, infact I prefer it not to be and use Git from TortoiseGit if I'm in windows, or from the command line on OS X (although I'm looking at Gitti for the OS X side).
For build, I would suggest TeamCity, since it supports up to three remote agents allowing you to build on Windows/Linux/Mac with the free version.
For build I'd use NAnt, although xbuild under mono works with solution files so that might be easier rather than maintaining two build scripts. I like NAnt for CI simply because I find it easier to break apart into build, test, cover, package, deploy etc.
I've found that the combination of MonoDevelop, Git, TeamCity and NAnt gives you a few nice cross-platform development setup.

I suggest you try to use one IDE mainly. Most Mono IDEs support Visual Studio formats I guess. At least SharpDeveblop does.
http://mono-tools.com seems the correct way to develop for .NET and Mono only in Windows (not free). I think this is the best option if I ever take developing for mono seriously ina commercial environment, but not 1005 sure.
http://sharpdevelop.com looks promising too, but still fells like the poor man option.
http://monodevelop.com/ is the way to go for developing for Mono in Linux.
For DVCS you can always use Tortoise stuff and be IDE independent. git works great in Linux and TortoiseGit on Windows is very nice. However, it terms of fame, SVN (not DVCS of course) is still dominant, especially it's client can connect to TFS via bridge. Mercurial and Git are starting to take place in C# community though.

CruiseControl.Net is a pretty good build / continuous integration system. It can integrate a load of applications into the build process; we use NAnt for builds, NUnit unit tests and FXCop for code analysis.

Cake (C# Make) is an open source build automation system with a C# based domain specific language that can do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages. It has tons of other built-in functionality and can easily be extended with custom code. It's available for Windows, Linux and OS X and can be used with several continuous integration systems such as AppVeyor, TeamCity, TFS, VSTS or Jenkins.

C# .Net - deployment "very" custom application

We are working on deploying a very custom application.
The application is the main program (and only program) that will run on the PC, but it depends on multiple 3rd party installers that must be installed via separate setup programs. Some of these are standard MSI, install shield, other outdated setups, etc.
On top of that we must deploy SQL Server Express 2005, install IIS if it is not found and setup a website.
Our final end user deploying this will be a person with technical experience on a new "out of the box" PC with XP SP3.
What is a good option for developing this? WiX? Visual Studio setup projects may not cut it. There is also the issue of somehow running other MSI's while an MSI is already running.
Would it function better as a standard C# application that requires .Net to be preinstalled? Then it would merely prompt for a few options then run several installers I suppose.
Any thoughts? We'd prefer to stick to C# .Net.

Doesn't XP SP3 already have a .NET runtime installed?
If your end user is someone with technical experience then it seems reasonable to sacrifice some of the "wizardness" of an MSI package for the flexibility of something a little more raw, such as a Ruby script, Powershell script, or .NET console or Winforms app.

This comes down to the benefit vs. cost.
If this is only to be run on a single or small number of target PCs and you have the ability to support the install (even remotely), I would recommend going to a manual install for any 3rd party dependencies.
It will be much easier to provide each package's installer with written instructions and provide than to write/test/debug (and probably still support) a complex, fully automated installer that will only be used once or thrice.
If there will be many installations, the automation will give more benefit.

There is an installer product called Inno Setup that might suit your needs. It allows for custom scripting so you can detect whether all of the dependencies are installed.
If some of them are not installed then with some scripting the installer can download and install the 3rd party dependencies before installing your app. Some help with that can be found at the Code Project article. (http://www.codeproject.com/KB/install/dotnetfx_innosetup_instal.aspx)
The only problem with this route is the scripting language is in pascal.
Just a question, is the company you work for supplying the boxes because if you are then couldn't you pre-install the software? At least that way there is one less thing that can go wrong.

WIX is a fairly flexible way to create the installer (although the learning curve can be quite a bit as the documentation still is lacking). That would probably be your best bet for installing the components that are actually your product's artifacts. Have it check that the required components are installed, but I wouldn't try to launch installers off of it. Instead, like Seth mentioned, write a Powershell script/VBScript (or Console application) that will do the component checking and launch the old installers for user in the order necessary. Of course you would need a way to capture when the installer finishes before continuing on (don't know if VBScript really has that capability, so Powershell/Console app may be a wise choice). And the final installer called would be your product. This way if there's reboots required the installer can be ran the exact same way and would just keep checking for required components and firing off installers as needed.

How do I set up an ASP.NET build server?

I want to create an ASP.NET build server for the first time since I've never used it.
Does anyone have a tutorial or resource on how to make an ASP.NET build server?
Or can anyone tell me how it's done?

If by "create" you mean "setup a build server" then I suggest you take a look at TeamCity from JetBrains.
TeamCity is a multi purpose build server and can be used to build ASP.NET projects as well. You can get up and running for free, and its very easy to set up, compared to CruiseControl.Net.
Take a look at MSBuild to see how to do specific ASP.NET build stuff.
MSBuild reference
How to use MSBuild to do ASP.NET compilation (video)
You might need something from the msbuildtasks open source task collection
If you really want to create your own build server from scratch (but why?), I can't help you.

You could make a build server using CruiseControl.NET which can build your project.
CruiseControl.Net Tutorial – Part 1
CruiseControl.Net Tutorial – Part 2
There is no ASP.NET build server as such.

Do you have a one-click build script? If not, you should create that first. Once you are able to run a single command and get a complete build, then it is easy to set up CruiseControl or some other build server.

Given the strength of the build servers out there it's really not sensible to spend any time developing your own.
You will, however, need at the minimum
a one-click build script
a source code repository (e.g. Subversion, TFS, or even [shudder] SourceSafe)
a server to use as a build box (I use a virtual image)
You may also find a one-click deployment script written using something like Powershell to be useful, too.
Note that a very effective alternative to CruiseControl.NET and TeamCity is Hudson. Although it's written in Java it's ridiculously simple to get going with a J2EE server like Tomcat.
The key strength of Hudson is the range the plug-ins, which allow you to monitor most version control systems and then not just build (through MSBuild or even the command line) but also run unit tests, acceptance tests, and so on.

You might look at Web Deployment Projects -- they allow you to build your site and merge all DLLs into a single file, for a fully pre-compiled site. You can use it with MSBuild.
An option on the automation side is Team Foundation Server's (TFS) automated builds. TFS also includes source control, bug tracking and many other features you may or may not need.