-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forever fix core releases (v5) #330
Conversation
…, this will help in libraries where Castle.Windsor is a transitive dependency and NuGet upgrades cause assembly binding errors.
…get master green again but it will break when we release Castle.Core again, more work to do here.
…eFacilityTestCase. Ignoring this for now, we need to get Castle releases sorted, Core releases break Windsor releases. This takes priority.
Closing this pull request because of my comment #327 (comment) and #336.
|
Reviewing your comments and then will review the PR. No problems! Like where this is going :) |
@jonorossi
If we merge this and release a new major version of Castle.Windsor before deploying Castle.Core, then we wont ever have to worry about release drama with the "magic strings" in LoggingFacility
The magic strings have been traded out for some new facilities with strong typing and proper NuGet references:
Castle.Facilities.Logging.NLog
Castle.Facilities.Logging.Log4net
This has also highlighted the fact that these are not yet netcore compliant because their respective service counterparts in Castle.Core have not been upgraded yet. This was slightly hidden and not very obvious.
Personally, I am all for smooth releases what do you think?