build NuGet and Zip packages from TeamCity

[blairconrad]

essentially the same as castleproject/Core#49:

Update the source and create a TeamCity build configuration ("Pack") to automatically build NuGet packages and a comprehensive Zip file for the Windsor projects.

I can take this. (Also, I thought I created this issue about 9 hours ago, but can't find it.)

[blairconrad]

@kkozmic, @jonorossi
Sorry to be a bother, gentlemen, but you've proven helpful in the past.

I may be overlooking something obvious, but I'm not sure how to make the remoting package. I see it, and I see the project in the source code, but I'm not seeing a build of the Remoting DLL either in my sandbox or in the artifacts on TeamCity.

Ideas?
Thanks. I'd like to say this'll be the last you hear of me, but I doubt it.

[jonorossi]

@blairconrad Not a bother at all, you are getting things done.

I recall @kkozmic removing the old remoting facility, and here is the commit dffc726. According to the diff stat @kkozmic got rid of the unit tests but accidentally left the actual code. Just ignore it for now.

[blairconrad]

Perfect. Thanks.

[blairconrad]

Everything needs a good checking-over, which I should get to on the weekend sometime, but I'm cautiously optimistic.

[blairconrad]

In order to head off any surprises when the PR comes in, I mostly did the same thing here as for Castle.Core, but here are some deviations and notes:

1. We needed to inject the version of Castle.Core that we depend on into the NuGet packages. Windsor doesn't import a nupkg, so I'm having buildscripts\Get-NuGetVars.ps1 make do with the first three components of the ProductVersion of \lib\NET40\Castle.Core.dll. Why NET40? Why not. It's easy to change to another version of the DLL.
   I think safest would be to actually use the NuGet package in the build, but that may be tricky, and is a little too "interfere with the fundamental aspects of the build" than I was hoping to get into today. (Although, if we were going to interfere with the build a lot, I'd have other suggestions… but I digress.)
2. I noticed most of the nuspecs had a copyright ending in 2013. Rather than change to 2014, I'm using the current year. This won't affect (for example) License.txt.
3. I made 2 NuGet Pack steps - one for most packages, and one for Windsor-log4net and Windsor-NLog, since these appear to have no content (I think they just exist to suck in the appropriate Castle and Windsor logging package dependencies), they couldn't be built with -Symbols

[blairconrad]

@kkozmic, I noticed one difference in the nupkgs that I'm creating. A few of the text files, notably

• readme.txt (sourced from buildscripts/readme.txt, which I added)
• Changes.txt, and
• License.txt

all have LF line endings in the new nupkgs, but CRLFs in the old ones.

I use a smart editor, so no skin off my nose, but the notepadders may be sad.

I've tried and tried and tried to repair the files, but kept failing. I'm not a strong Gitter, but I think this is tied to ca095b9, specifically the new .gitattributes file. All the files that have LFs at the end of their lines have been modified since then.

If this is intentional and expected, then I'll carry on. However, if we want CRLFs in the files, I'm at a bit of a loss. Could you tell me how you'd like me to proceed?

Thanks/sorry.

[blairconrad]

Of course, the bad line endings on the text files is something that can always be corrected after this issue is done, but before release. If I do my job right, we'll still pick up the files, however they're line-ended.

[kkozmic]

hmm, good find re: line endings. Don't worry about it, I'll have a look into that. Like you said, it doesn't directly affect this issue.