Setting up a build environment 1

[Borvik]

I'm not really sure where to post this - there doesn't really seem to be a forum for it, so as my project is C#, this is where I'll ask.

I've never really had cause to setup a build environment before (being a solo developer releasing through click-once to coworkers only).

I want to get more organized and consistent for some of my other projects that I release to others (non-coworkers), so I wanted to setup a build environment. I've had a difficult time finding proper tutorials that really help.

My _main_ project I want to establish this for is a solution with 4 projects. A WinForms app, a dll, and two setup projects (32 and 64 bit). I would like to be able to sync the WinForms project Assembly version (1.0.*) with the version of each of the setup projects to make sure it will always properly upgrade.

To top it off, I'm also using visual studio online to do my source control which comes with some build minutes I can use every month. I'd LIKE to be able to use this as well, so I can easily kick off a build for distribution. There are also some third-party dlls used as well that were not obtained through NuGet.

Any good pointers/tutorials that anyone can point me to would be great!

Thanks.

 

[xwb]

The big problem is using Visual Studio online. Would building using the Community edition of visual studio be an option or are you totally tied to VS online?

 

[Borvik]

Yeah, I know that's a difficulty. I am already using the Community edition - I just really want an option where I can fire off a build and it will build both 32 and 64 bit builds without having to manually specify a build type, build one version, change the build type and build the other.

I figured I had some free build minutes and thought I'd use them _if_ I could - if not, no big deal - as long as I can make the build process easier.

 

[xwb]

Two options: have a look at msbuild and devenv.

For parameters msbuild /? or devenv /?

 

[Borvik]

Ok, just so anyone else who stumbles across this knows - I got my build working.

Regarding the 3rd party dlls - I included them in the source control, and made the build process reference them - and it worked, the build completed, then it was on to the setup project.

Because the Hosted build server was complaining about msi project types (standard setup project in VS) - I decided to go with the Wix toolset, as a version of it was supposed to have been on them. This did indeed work, though it took a while to figure out how to setup the wix file (no simple gui - unless you want to pay for one, which I didn't).

Then there was a difficulty, the program was installing (on client computers), but a warning kept popping up about control licensing that essentially kept the program from running. Essentially because the licensing for the 3rd party dlls wasn't installed on the Hosted build server, it wasn't really building properly, even though the build logs showed no errors. I found a solution though, the free tier of Visual Studio Online (or Team Services, or whatever it's really called) does allow 1 build agent to be connected to it. So I managed to install the build agent on a computer with the licensing and now the program works good.

I ran into one other snag, because it built the platforms separately one at a time - my project version numbers were not identical (used assembly version: 1.0.* to auto generate) - this was actually an issue because the program saved and checked that in a database to make sure and warn users if another user connected to the same database was running a newer version. I spent a bit of time trying to solve this, but in the end I found a free addin in the marketplace that I could install to my Visual Studio Online account called Colin's ALM Corner Build & Release Tools. This added a Version Assemblies task I could add to my build process that allowed me to sync to assembly versions with the Build Number.

Now everything is running smoothly - except for the bugs in the program, gotta squash those yet.

Hope that helps whoever finds this in the future.