Move builds from TeamCity to AppVeyor and Travis CI

[jonorossi]

These are the build configurations we've currently have in TeamCity with the configuration pulled apart from the set up. It would be great if they all went to using a build script rather than calling msbuild/xbuild directly.

I'm not sure exactly what we want to do but it might be time to move Castle Core to the new VS2017 tooling to support .NET Framework and .NET Core, this should hopefully make the NuGet packaging cleaner.

TeamCity: http://builds.castleproject.org/project.html?projectId=Core&tab=projectOverview AppVeyor: https://ci.appveyor.com/project/castleproject/core Travis CI: https://travis-ci.org/castleproject/Core

.NET 3.5

RELEASE_BUILD=false
VERSION_SUFFIX=
$ powershell buildscripts\Set-VersionInfo.ps1
$ msbuild /p:Configuration=NET35-Release /t:Package buildscripts/Build.proj

.NET 4.0

• Same as 3.5 with NET40-Release configuration

.NET 4.5

• Same as 3.5 with NET45-Release configuration

.NET Core

RELEASE_BUILD=false
VERSION_SUFFIX=
$ powershell buildscripts\Set-VersionInfo.ps1
$ build NETCORE
publish src\Castle.Core\bin\Release\netstandard1.3
publish src\Castle.Services.Logging.NLogIntegration\bin\Release\netstandard1.3
publish src\Castle.Services.Logging.SerilogIntegration\bin\Release\netstandard1.3

Mono (4.6.1)

RELEASE_BUILD=false
VERSION_SUFFIX=
$ xbuild /p:Configuration=NET45-Release /t:RunAllTests buildscripts/Build.proj
import nunit results build/NET45/NET45-Release/bin/test-results/nunit-results.xml
publish build/NET45/NET45-Release/bin/**/*

Pack

RELEASE_BUILD=%reverse.dep.*.env.release_build%
VERSION_SUFFIX=%reverse.dep.*.env.version_suffix%
$ powershell buildscripts\Set-VersionInfo.ps1
nuget pack
- spec:
  buildscripts/Castle.Core.nuspec
  buildscripts/Castle.Core-log4net.nuspec
  buildscripts/Castle.Core-NLog.nuspec
  buildscripts/Castle.Core-Serilog.nuspec
- properties:
  Configuration=Release
  CastleCoreVersion=%ReleaseVersion%
  CurrentYear=%CurrentYear%
publish:
  build/nuget/**
  BreakingChanges.txt => Castle.Core.%ReleaseVersion%.zip
  Changes.txt => Castle.Core.%ReleaseVersion%.zip
  License.txt => Castle.Core.%ReleaseVersion%.zip
  buildscripts/ASL - Apache Software Foundation License.txt => Castle.Core.%ReleaseVersion%.zip
  buildscripts/readme.txt => Castle.Core.%ReleaseVersion%.zip
  build/NET35/NET35-Release/pkg/bin/* => Castle.Core.%ReleaseVersion%.zip!/lib/net35
  build/NET40/NET40-Release/pkg/bin/Castle.Core.* => Castle.Core.%ReleaseVersion%.zip!/lib/net40-client
  build/NET40/NET40-Release/pkg/bin/Castle.Services.Logging.Log4netIntegration.* => Castle.Core.%ReleaseVersion%.zip!/lib/net40
  build/NET40/NET40-Release/pkg/bin/Castle.Services.Logging.NLogIntegration.* => Castle.Core.%ReleaseVersion%.zip!/lib/net40-client
  build/NET45/NET45-Release/pkg/bin/* => Castle.Core.%ReleaseVersion%.zip!/lib/net45
  build/SL4/SL4-Release/pkg/bin/* => Castle.Core.%ReleaseVersion%.zip!/lib/sl4
  build/SL5/SL5-Release/pkg/bin/* => Castle.Core.%ReleaseVersion%.zip!/lib/sl5

A custom "Pack" build has two fields you can manually specify:

• release_build - checkbox checkedValue='true' description='Defines whether this build is intended for public release to NuGet (as either a prerelease or final version, rather than a CI build)' display='hidden' label='Release build' uncheckedValue='false'
• version_suffix - text description='Defines an optional version suffix (e.g. -beta001)' label='Version suffix' validationMode='any' display='hidden'

[jonorossi]

@fir3pho3nixx have you seen Rob's most recent post about NUnit support: http://www.alteridem.net/2017/05/04/test-net-core-nunit-vs2017/

[ghost]

Whoa! I have been waiting for this. Will give it a spin this weekend. Thanks @jonorossi ... :1st_place_medal:

[ghost]

@jonorossi - Our VS2017 project structure now runs both netcoreapp1.1 and net461 tests equally on both windows(AppVeyor) and linux(TravisCI). This means are still good for cutting over and deleting all the old build stuff. It took quite a bit of messing around to get there. I will submit a separate PR with Robs alpha stuff (it uses NUnitLite at the mo).

Shall I get the NuGets publishing on tag for AppVeyor?

[ghost]

@fir3pho3nixx have you seen Rob's most recent post about NUnit support: http://www.alteridem.net/2017/05/04/test-net-core-nunit-vs2017/

@jonorossi - Yes I have, and when it works across all platforms it is going to be amazing :) It is alpha though, and I found it threw exceptions(Win32Exception) whilst trying to spawn new processes on startup for net461 targets on Linux(netcoreapp1.1 passed though).

Raised an issue here: https://github.com/nunit/nunit3-vs-adapter/issues/324

Look forward to this being released! I can simplify the msbuild quite a bit, like remove the RuntimeIdentifiers(and NUnitLite) which would be great.

[jonorossi]

Shall I get the NuGets publishing on tag for AppVeyor?

Sounds good, did you want to create an issue with how you are planning to implement it.

[ghost]

Happy to have the discussion here. We are nearly done.

For fortress merging to master = deploy. Here we are going for a tag/release strategy. We are going to need some setup before we can do this. Look at the fortress appveyor cfg below.

deploy:

  - provider: NuGet
    api_key:
      secure: Vyq5UyV3c6Ud2UH9ZQ89iUYO27f+d+lHRdALnJuFzLEgDi2Vdal7bNlerS07wSgQ
    skip_symbols: false
    artifact: fortress 
    on:
        branch: master

This behaviour can easily be changed by using https://www.appveyor.com/docs/deployment/#deploy-on-tag-github-and-gitlab-only.

I would need some help from you setting up the secure keys for this. You can do it easily by following these instructions: https://www.appveyor.com/docs/deployment/nuget/#provider-settings. Email the encrypted key to me and I will bake it in for you with the tag trigger behaviour.

Will also do a review of the NuGet packages and replicate the work you and Alina did down in Castle Windsor.

[ghost]

Last PR in for NuGet publish. https://github.com/castleproject/Core/pull/259

@jonorossi - Follow my instructions above and let me know how it goes! :)

Before we close out this issue, can we just quickly drop a note for how we want to deal with the legacy build platform? There is significant clean up we could be doing. We just need to weigh up the pros and cons of supporting VS2017--.

Mainly PR6 stuff.

[alinapopa]

buildscripts\CommonAssemblyInfo.cs has some assembly attributes such as CLSCompliant(true) that were lost during refactoring and would need to be added

[jonorossi]

@fir3pho3nixx @alinapopa sorry about the delay, I've been a bit busy the last couple of days.

Responding to everything at the moment.

Before we close out this issue, can we just quickly drop a note for how we want to deal with the legacy build platform? There is significant clean up we could be doing. We just need to weigh up the pros and cons of supporting VS2017

What exactly do you mean, are you concerned that users might not have VS2017 and so won't be able to build the software? I assume VS2017 Community would work in this case since this is an OSS project.

[ghost]

Do we delete everything and remove the VS2017 fluff from the csproj file names? Meaning do we go 100% VS2017?

[jonorossi]

Do we delete everything and remove the VS2017 fluff from the csproj file names? Meaning do we go 100% VS2017?

Yes, I'm happy to go all in using the new tooling, really no point beating around the bush since we've nearly got all the old functionality across. Means we also don't have to deal with annoying csproj files that list individual files.

If you are happy, I'm happy.

[ghost]

If it is OK, I am going to start the cleanup process.

[jonorossi]

If it is OK, I am going to start the cleanup process.

Go for it.

[ghost]

I have finished the clean up @ https://github.com/castleproject/Core/pull/261

CI on TravisCI and AppVeyor achieved! 👍

[ghost]

Removing APTCA as per : https://github.com/castleproject/Windsor/issues/248

[ghost]

@jonorossi - Just updating the issue with what we found in the PR's.

There is an issue compiling a net35 assembly found here: https://github.com/castleproject/Core/pull/261#issuecomment-303398033

Tracked By: https://github.com/Microsoft/msbuild/issues/1333

In the meantime, I am looking at work arounds to get this going.

[ghost]

By falling back to msbuild I think we have a tidy way of achieving this: https://github.com/castleproject/Core/pull/262

I have added relevant comments.

Also seeing correct framework monikers in the locally built NuGet packages.

I ildasm'ed the net35 version and can confirm we have the correct runtime now.

Another check would not hurt but I think we are good to go for releasing.

[jonorossi]

@fir3pho3nixx I'll have a dig through a diff tomorrow and get this merged if everything looks good. I want to get the last open pull request fixed up before release.

[ghost]

/CC #266

[jonorossi]

All merged to master, will be in v4.1.

[ghost]

Awesome!