Move builds from TeamCity to AppVeyor

[jeremymeng]

@jonorossi Please confirm that this is something that we can help now.

Related discussion: castleproject/Core#241 (comment)

part of #145.

[ghost]

I would fork the project and get something basic working in VS2017 supporting NET45 using a new solution.

Use side-by-side csproj files like I did in Core. The only one I would leave as-is, is the Castle.Facilities.WcfIntegration.Demo.

We should theoretically be able to get a build going in AppVeyor that passes supporting this framework moniker with tests passing without breaking anything in teamcity.

This set's us up nicely to have a FEATURE_BUILD_FLAG discussion for Windsor once we start targetting netstandard1.3, like so https://github.com/castleproject/Core#conditional-compilation-symbols.

[jonorossi]

I've just created a refactor-build branch in the Windsor repo to allow the same.

[ghost]

Hi @jeremymeng

Just an update on my work in Castle Core.

@jonorossi - has approved my latest changes in the https://github.com/castleproject/Core/commits/refactor-build branch.

We now have an approved approached for net45 on appveyor. I am busy upgrading NUnit and then I have to start targetting netcoreapp1.0 in Castle Core tests. This is the bulk of the work left, I suspect implementing TravisCI should be the easy part.

If you have any questions please fire away.

[alinapopa]

What is the plan for the three WcfIntegration projects? Are they going to be removed? @Fir3pho3nixx you mentioned about not building Castle.Facilities.WcfIntegration.Demo, however the project Castle.Facilities.WcfIntegration.Tests depends on it. Should the tests that depend on Castle.Facilities.WcfIntegration.Demo be pulled out?
Also I have another question; when getting to build on AppVeyor, how do I know if the TeamCity build was broken or not?

[jonorossi]

What is the plan for the three WcfIntegration projects? Are they going to be removed?

I'm not sure why @Fir3pho3nixx said leave the WCF Demo one as is, it shouldn't be any work to get it building on .NET 4.5 using the new tooling, and it looks like you've already done the work now. I'd like to see the existing WCF projects go across and we can look at reducing them later, however obviously no one is expecting any .NET Core/Standard support for those projects.

Also I have another question; when getting to build on AppVeyor, how do I know if the TeamCity build was broken or not?

We haven't bothered setting up a TeamCity build for the refactor-build branch in Castle Core, and I know some of those embedded resource changes will break the TeamCity build. I don't think it really matters, once we are happy with the new build I assume we'll delete the old files and rename the new csproj files before merging; we've always got git tags for old releases. @Fir3pho3nixx is that what you were thinking?

[ghost]

Sorry guys, all I meant was don't upgrade it to the new vs2017 multi targeting format.

[ghost]

@jonorossi - happy to go with a hard cut over for this. Running tests for both takes twice the amount of time.

[alinapopa]

@jonorossi I've tried to update the Castle.Core version referenced by Windsor from 3.3.0 to 4.0.0, and many tests fail. Are there major breaking changes between these two versions I should be aware of?

[jonorossi]

I've tried to update the Castle.Core version referenced by Windsor from 3.3.0 to 4.0.0, and many tests fail. Are there major breaking changes between these two versions I should be aware of?

There are some breaking API changes especially around things that were in Castle.Core.Internal that Windsor really shouldn't be using (reason for #163) which is one of the reasons for the major version number change, however generally I don't expect any major functional breaking changes.

Maybe it is best to get these build changes done with Castle Core 3.3.0 as a like-for-like with master's old build scripts, then do the dependency upgrade?

[alinapopa]

@jonorossi @Fir3pho3nixx What is needed at this time on Windsor with regard to Travis CI?

[jonorossi]

What is needed at this time on Windsor with regard to Travis CI?

I'd say nothing. We currently don't build/test Windsor on Mono with TeamCity so no need to start under this work, it sounds like it'll be much easier in a month or two. It is important for Castle Core because of the wide use of Castle DynamicProxy.

[jonorossi]

Edited issue title to reflect no need for Travis at the moment.

[jonorossi]

What's left to do:

• Get unit tests showing in "Tests" tab
• Versioning
• NuGet packaging

This is what the "Pack" configuration on TeamCity does for Windsor, we need to work out what we need and how to do the same hopefully without all the mess.

Artifact Dependencies:

Castle.Windsor-NET45-%dep.bt132.build.counter%.zip!/** => .\build\NET45\NET45-Release\pkg
-:Castle.Windsor-NET45-%dep.bt132.build.counter%.zip!/bin/*.Demo.*

Parameters:

• CastleCoreVersion=1.0.1
  • text description='Castle Core Version to depend upon' display='hidden' label='Castle Core Version' regexp='\d+\.\d+\.\d+(.+)?' validationMode='regex'
• CurrentYear=2000
  • text description='Copyright Year' display='hidden' label='Copyright Year' regexp='20\d\d' validationMode='regex'
• ReleaseVersion=1.0.0
  • text description='Release version number' display='hidden' label='Version' regexp='\d+\.\d+\.\d+(.+)?' validationMode='regex'
• env.​release_​build=false
  • checkbox checkedValue='true' description='whether this build is intended for public release (i.e. controls whether a prerelease package is generated)' display='normal' label='release build' uncheckedValue='false'

Build Steps:

• PowerShell buildscripts\Get-NuGetVars.ps1
• NuGet Pack: "Pack Assembly Packages"
  • Specification files:
    • buildscripts/Castle.EventWiringFacility.nuspec
    • buildscripts/Castle.FactorySupportFacility.nuspec
    • buildscripts/Castle.LoggingFacility.nuspec
    • buildscripts/Castle.SynchronizeFacility.nuspec
    • buildscripts/Castle.WcfIntegrationFacility.nuspec
    • buildscripts/Castle.Windsor.nuspec
  • Version: %ReleaseVersion%
  • Properties
    • Configuration=Release
    • CastleWindsorVersion=%ReleaseVersion%
    • CastleCoreVersion=%CastleCoreVersion%
    • CurrentYear=%CurrentYear%
• NuGet Pack: "Pack Dependency-Only Packages"
  • Specification files
    • buildscripts/Castle.Windsor-log4net.nuspec
    • buildscripts/Castle.Windsor-NLog.nuspec
  • Version: %ReleaseVersion%
  • Properties
    • Configuration=Release
    • CastleWindsorVersion=%ReleaseVersion%
    • CastleCoreVersion=%CastleCoreVersion%
    • CurrentYear=%CurrentYear%

Artifacts:

• build/nuget/**
• BreakingChanges.txt => Castle.Windsor.%ReleaseVersion%.zip
• Changes.txt => Castle.Windsor.%ReleaseVersion%.zip
• License.txt => Castle.Windsor.%ReleaseVersion%.zip
• buildscripts/ASL - Apache Software Foundation License.txt => Castle.Windsor.%ReleaseVersion%.zip
• buildscripts/readme.txt => Castle.Windsor.%ReleaseVersion%.zip
• build/NET45/NET45-Release/pkg/bin/Castle.Facilities.* => Castle.Windsor.%ReleaseVersion%.zip!/lib/net45
• build/NET45/NET45-Release/pkg/bin/Castle.Windsor.* => Castle.Windsor.%ReleaseVersion%.zip!/lib/net45

[jonorossi]

A whole bunch of the packaging can be simplified now that we have a single "job" building and packaging, and we can transition from manual nuspecs to the csproj file, hopefully keeping common things in a common file.

I don't think we need the ability to specify the Castle Core version, it should be defined in source control and much of the other manual packaging stuff will be taken care of by MSBuild generating the nupkg.

[jonorossi]

Great work @alinapopa. Do you need any more info to progress with the remaining items? Can we package Windsor using the .NET CLI?

• Change after_build to on_finish
• Versioning - control the version number from one place
• NuGet packaging - build a nupkg with the .NET 4.5 .dll, .pdb and .xml

[alinapopa]

@jonorossi under the buildscripts folder there are nuspec files for Castle.Windsor-log4net and Castle.Windsor-NLog. There are no projects in the solution with these names. What are they created from?

[alinapopa]

Also @jonorossi I am getting a warning for project Castle.Facilities.WcfIntegration that the description is too long:

MSBuild\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(104,5): warning : Issue found with package 'Castle.WcfIntegrationFacility'.
MSBuild\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(104,5): warning : Issue: Consider providing Summary text.
MSBuild\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(104,5): warning : Description: The Description text is long but the Summary text is empty. This means the Description text will be truncated in the 'Manage NuGet Packages' dialog.
MSBuild\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(104,5): warning : Solution: Provide a brief summary of the package in the Summary field.

And I can't move it in the Summary field because the Summary field is no longer supported
https://docs.microsoft.com/en-us/nuget/schema/msbuild-targets
Please can you reword the description to make it shorter?
Thanks!

[jonorossi]

under the buildscripts folder there are nuspec files for Castle.Windsor-log4net and Castle.Windsor-NLog. There are no projects in the solution with these names. What are they created from?

As mentioned in #220 (comment) these are "Dependency-Only Packages". I don't know exactly the reason for them, and git history and issues isn't providing much info, I assume they are there to ensure when you install the logging facility the right version of Castle.Core-{log4net,NLog} gets installed to match Castle.Core, but that would only work if you installed that package rather than the logging facility directly, so I guess there usefulness might not be all that great however they are still used by quite a few people looking at nuget.org so we'll want to keep them for now.

I am getting a warning for project Castle.Facilities.WcfIntegration that the description is too long

It looks like the threshold is 300 characters and we've got 401 in the description. I'm happy for the description to get truncated when it is show as the summary, and for the warning to stay for now.

[ghost]

@alinapopa - Your input helped quite a bit when it came to translating the old nuspec properties to the common.props for Castle.Core whilst packaging NuGets. Many thanks!

I have submitted my last PR for tag based publishing Castle.Core using AppVeyor: castleproject/Core#259

There is still a pending discussion about clean up: castleproject/Core#241

Anything I can help out with down here?

[alinapopa]

@Fir3pho3nixx This item is pretty much done (the only thing that should be added is the CLSCompliant attribute on the assemblies; using the latest test adapter may not be a good idea at this time because there are some issues with it).
I think it is a good time to discuss what are the next items, to make progress toward porting Windsor to .NET Core.

[ghost]

@alinapopa - How far away are we from publishing the nugets using appveyor?

Once this is done, we are ready to start implementing the build feature symbols like in Core. FEATURE_APPDOMAIN, FEATURE_SERIALIZATION, FEATURE_SECURITY_PERMISSIONS and FEATURE_REMOTING are the big ones I can think of just off the top of my head. This will help us unlock a a version of Windsor that targets netstandard.

[alinapopa]

@Fir3pho3nixx

How far away are we from publishing the nugets using appveyor?

We're three open PR's away:
#233 , #232 , #231

[ghost]

I am free now.

We should try expedite a release of #235.

Can I close #233 and take this one? I have just finished doing it in Castle Core.

[ghost]

@jonorossi - Can we create a milestone with the version number in it (for releasing #235)? I can then tag this issue with that milestone. Can we also add a label to indicate progression from "up for grabs" to "assigned" or something similar? This would be very handy for knowing what is outstanding or what is in flight.

[alinapopa]

@Fir3pho3nixx

Can I close #233 and take this one?

Yes that sounds like a good idea

[ghost]

@jonorossi - Can we change this issue to include TravisCI, this is a solved problem in Castle Core? I plan to implement it here.

[jonorossi]

Can we create a milestone with the version number in it

Since this version also includes dropping Silverlight, .NET 3.5 and 4.0 support what version number do you want? At first I was going to just go 3.5, but now thinking this is 4.0 and .NET Core support can be in 4.1?

Can we also add a label to indicate progression from "up for grabs" to "assigned" or something similar?

I would think removing the "up-for-grabs" label and assigning the issue to yourself would be the best indication that you are working on it? "up-for-grabs" is the label used for new contributors to the project that would be a good starting point, not just anything that needs to be done. i.e. following the convention many hundreds of projects have been doing over the last 5 or so year, and the web site.

Can we change this issue to include TravisCI, this is a solved problem in Castle Core? I plan to implement it here.

There is likely a heap of failing unit tests on Mono so not just as simple as adding a travis.yml file, I'd prefer if we delayed it to another task to get this work done so we can get the next release out. Thoughts? Also see my comment above: #220 (comment).

[ghost]

Going with version 4.0 sounds perfect.

I mistakenly thought we were good on the mono side, if this is the case, you are right ... let's hold off for now.

Thanks for explaining how the labels work.

I will move on to getting the tag based deployments working after I have resolved the changes needed for my PR in Castle Core.

[alinapopa]

@jonorossi I think the removal of System.Security.AllowPartiallyTrustedCallers assembly attribute from Windsor should be listed under "Breaking Changes"

[jonorossi]

I think the removal of System.Security.AllowPartiallyTrustedCallers assembly attribute from Windsor should be listed under "Breaking Changes"

Responded by creating #248.

[ghost]

Just double checking, we are not supporting net35 || net40 for this right?

[ghost]

IMHO - It is a shame we are not harmonising our framework support with castle core here.

[ghost]

Status Update: Have 2 PR's in play #259 && #260

I am getting new internet next week, so hopefully I can pick up the pace soon! :)

[jonorossi]

Just double checking, we are not supporting net35 || net40 for this right?

IMHO - It is a shame we are not harmonising our framework support with castle core here.

I'm unsure exactly what you are asking. If you want to also support .NET 3.5/4.0 in Windsor just as 3.4 does I don't mind, but obviously it is additional work. We really should keep .NET 3.5/4.0 support in Castle Core for a bit longer.

[alinapopa]

The conditional compilation symbols for building on 3.5 and 4.0 were removed #185 #195 #197

[jonorossi]

The conditional compilation symbols for building on 3.5 and 4.0 were removed #185 #195 #197

Thanks, yer we did explicitly make the decision in #185, it wasn't just an off the cuff decision. I think we should continue with .NET 4.5+ only, really don't need that extra work.

[ghost]

@jonorossi not sure if you are checking your mail, my internet is fixed now. Do you think we can do a release and close out the appveyor issues in Core & Windsor? Would like to close these out before I pick up something else.

[jonorossi]

not sure if you are checking your mail, my internet is fixed now. Do you think we can do a release and close out the appveyor issues in Core & Windsor? Would like to close these out before I pick up something else.

Sorry about that, I started looking into it the other night after your email and found a few problems but didn't get it finished and forget to reply. Will try to sort that out tonight.

[ghost]

No worries, if there is anything I can help with please let me know.

[ghost]

I think we are good to go here. @jonorossi - can we close this out?

[jonorossi]

Yep, #275 is now merged.