You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've talked about this in the past but I can't find an existing issue for it.
It seems to me that V4.0 is a reasonable point for us to stop distributing the TeamCity extension in the Msi. Jetbrains can make the extension available on nuget and chocolatey and provide instructions as to how to add it to an msi installation - we can even help with the last - but as previously decided, we should stop distributing an extension for a particular CI solution when we don't do that for any others.
I think this will be one of the more controversial changes proposed - due to the number of users disrupted and the commercial concerns of JetBrains.
I don't disagree it would be the right approach if we were adding the TeamCity package now, but I do wonder if the benefits justify the disruption to users here in making the breaking change. I like to think more about this one, interested in what others think.
Should note that the console runner actually has a special option for enabling the teamcity extension.
IMO this would be a great opportunity to introduce an open way of enabling/disabling extensions by name on the command-line. We could use something like --enable <extension> or maybe --require <extension>, giving an error if the extension is not installed.
Did you mean #148 by any chance Mikkel? I was going to say the same. 🙂
Have thought about this more. Personally, I think this is another issue which doesn't have enough benefit to justify the inconvenience to users of the breaking change. Packaging the TC extension is essentially zero-cost, when we're already doing it for 4 other extensions. I think if any new CI provider was to approach us and ask for their extension to be included we would decline, but we should instead view this as a historic misjudgement which we maintain for backwards compatibility. So continue to package the extension.
It would be nice to get rid of the --teamcity flag through something like #148. That's another chunky feature to include in v4 however, and I'm not sure it's a priority.
Did you mean #148 by any chance Mikkel? I was going to say the same. 🙂
No. #441 contains the following comment (among other)
Edit edit: If there were a general way to enable/disable extensions on the command line (like the hardcoded one for --teamcity), @CharliePoole's declarative approach would be fine also. Don't we want such a feature? Shouldn't be hard to do, I think.
In addition to unbundling the extension, the console option --teamcity is now removed. In its place, use --enable NUnit.Engine.Listeners.TeamCityEventListener.
Activity
ChrisMaddock commentedon Jan 27, 2021
I think this will be one of the more controversial changes proposed - due to the number of users disrupted and the commercial concerns of JetBrains.
I don't disagree it would be the right approach if we were adding the TeamCity package now, but I do wonder if the benefits justify the disruption to users here in making the breaking change. I like to think more about this one, interested in what others think.
CharliePoole commentedon Feb 28, 2021
Should note that the console runner actually has a special option for enabling the teamcity extension.
IMO this would be a great opportunity to introduce an open way of enabling/disabling extensions by name on the command-line. We could use something like
--enable <extension>or maybe--require <extension>, giving an error if the extension is not installed.mikkelbu commentedon Feb 28, 2021
I like the idea of a more general solution than the hardcoded solution for teamcity -
--teamcityas discussed in #441.ChrisMaddock commentedon Feb 28, 2021
Did you mean #148 by any chance Mikkel? I was going to say the same. 🙂
Have thought about this more. Personally, I think this is another issue which doesn't have enough benefit to justify the inconvenience to users of the breaking change. Packaging the TC extension is essentially zero-cost, when we're already doing it for 4 other extensions. I think if any new CI provider was to approach us and ask for their extension to be included we would decline, but we should instead view this as a historic misjudgement which we maintain for backwards compatibility. So continue to package the extension.
It would be nice to get rid of the
--teamcityflag through something like #148. That's another chunky feature to include in v4 however, and I'm not sure it's a priority.Interested in what others think here.
mikkelbu commentedon Mar 13, 2021
No. #441 contains the following comment (among other)
CharliePoole commentedon Mar 13, 2021
#441 is more about the start-run count being zero. I just added a comment about that but we need to look further to fix it.
The comment @mikkelbu is referring to is actually more related to #148, although it came up in #441.
[-]Stop Distributing the TeamCity Extension[/-][+]Stop Bundling the TeamCity Extension[/+]CharliePoole commentedon Jun 21, 2025
In addition to unbundling the extension, the console option
--teamcityis now removed. In its place, use--enable NUnit.Engine.Listeners.TeamCityEventListener.CharliePoole commentedon Jun 26, 2025
This issue has been resolved in version 4.0.0-beta.1
The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org