Yeah, that's what I've been saying for the past year throughout this whole fiasco, but they appear to be unresponsive to any suggestions on this issue. It's quite frankly very surprising to me that they wouldn't be moving in this direction already as part of a general maintenance plan for the software. It's just mind-boggling that they would still refuse to even discuss the idea of upgrading the .NET dependency given all the issues over the past year.
Apple's move to their own CPU architecture (and Microsoft's immediate plans to support it via future .NET updates) are a perfect example of why the modest investment of keeping up to date with new .NET releases would greatly benefit Connectwise (both with maintenance cost savings and improved performance/compatibility). Let Microsoft do the work of supporting the various platforms.
@Caitlin, Apple's platform changes likely will affect Connectwise even for MacOS clients in CC. Even if the existing client software will work under emulation, it will be slower and subject to any bugs created during the emulation process. Reasons to update your core platform dependencies are only going to continue to add up over time. The only real reason not to do this is some sad idea that you can try to convert on-premise customers over to your cloud platform to make more money. But the goodwill lost on your long-term on-premise customers is a much more valuable asset than any small number of on-premise to cloud conversions you might get. The on-premise option was what made ScreenConnect stand out from the rest of the cloud options long ago. Having a cloud platform is fine for those that want it, but if you make things hard for your on-premise customers be prepared to see people leave en masse with some other competitor that pops up to fill the void. And then you'd still likely have to invest in the .NET upgrades anyway in the future even for your cloud platform. All of this mess could be avoided if you simply invested now in upgrading the dependencies and actually supported your on-premise customers like Connectwise promised to do when they acquired ScreenConnect.
Caitlin, you failed to respond to the larger question--namely what are the future plans for Linux? This year should really have been the time to revamp the core architecture given Microsoft's huge push towards .NET Core (now called .NET 5 and also RTM as of 3 days ago). The old .NET Framework is now legacy code. Sure it will still be around for quite a while, but it's not what Microsoft themselves are using anymore and won't be receiving much attention at all.
Microsoft has a rapid iteration cycle planned for future .NET upgrades. Moving to this newer .NET architecture would highly benefit your Windows and Cloud infrastructure, and of course also would provide direct support for Linux and MacOS without any crazy Mono headaches.
Ideally this migration should have been going on this year with testing to be ready for .NET 5 RTM, but now is the time to finally pull the trigger to avoid years of headaches with a legacy platform that Microsoft doesn't really care about anymore as bugs creep in with future Windows OS releases. PLEASE DO THIS. I really can't imagine that it would require a ton of code rewriting since Microsoft has spent a lot of time on making the transition smooth. You could then put the Mono issue in the grave once and for all and still please your current (and likely future) Linux customers. You'd even gain MacOS compatibility again. And of course, Windows users would see performance improvements too. All on one unified codebase. This is really the perfect product to benefit from Microsoft's cross-platform .NET vision, and you'd be setting the stage for years of a well-maintained, efficient codebase that would reduce maintenance costs and make customers happy.
Yes, this situation is extremely frustrating. ConnectWise spent a ridiculous amount of time stringing us along to finally release an updated 20.2 "Linux-specific" version, and since then there has been no activity at all. The original thread with TONS of feedback was also closed (why was that necessary?).
The ConnectWise Control development team needs to commit to the required resources to modernize the codebase (for both Windows and Linux). If they don't then their user base will slowly fade away as the product ages on a legacy platform. I've said it many time before, but I'll state it again here since the old thread was closed: Move to .NET Core/.NET 5.x and you no longer have to deal with Mono or special Linux builds, as all the code will work on any supported .NET runtime environment. You'll gain increased performance on all platforms and won't be stuck dealing with tricky edge-case scenarios that Microsoft won't help with because they've moved on to newer, better things.
Please, please stick with your promises over the last several years that you won't abandon your long-time users and the Linux platform. It really shouldn't be a hard decision at all since you wouldn't have to dedicate special resources for a "Linux" version if you just migrated to the latest .NET architecture. Linux (and MacOS) compatibility would be there pretty much without you even needing to do anything extra at all. And then you'd also be current with the latest Windows platform features as well.
@Simon Sure, but I find it hard to believe that:
1) those extensions are very complex
2) those extensions have a ton of incompatible code that would necessitate a huge amount of refactoring
I still don't see extensions as being a big deal in this context. Just figure out what extensions are absolutely necessary and make sure those work with a .NET Core based CC from the start. After that any other extensions that are worthwhile could be migrated over time (or just replaced with new extensions). If the core project code is mostly in a good place to make the transition to .NET Core I'd think a single developer could probably get a very rough alpha up and running within a couple weeks (enough to at least start figuring out what components/extensions can't run under .NET Core).
Thanks for the response. I get that .NET 4.8 isn't "old" yet, but it clearly is a dead-end platform. I don't think it's fair to compare it to some of the previous .NET generations when Microsoft was still in their "support legacy forever" mentality. That just isn't the Microsoft of today which aggressively pushes mandatory updates and frequently iterates it's development platforms. I'm relatively sure .NET 4 code will still be able to run years down the road, but there will be no new code features from Microsoft to be taken advantage of and there will likely be a growing number of issues answered by Microsoft with something along the lines of "just upgrade your code to .NET 5+ and that problem goes away". There are also costs/challenges involved in waiting a long time to upgrade platforms, as it's a lot harder to make architectural changes if your upgrading to a platform 2 or 3 generations later than your existing platform.
Extensions that are super-important or used by CW would certainly need to be migrated, but are there really that many of them that are that important (and contain a lot of incompatible code)? Obviously I don't know your actual extension use but I'd guess this just isn't really a huge issue all things considered.
I'm not sure how to respond to the evaluation of "other architectural opportunities". If you're saying other potential changes would make it harder for CW to even offer an on-premise product, that would be an intentional direction change that goes against what has been promised both during the ScreenConnect acquisition and for years after. I know some companies do break their promises but I would hope that isn't a future outcome for CC--that would be horrible and you'd lose a lot of customers (a lot more than just Linux users). You'd also gain a bad reputation that would be hard to shake for a very, very long time.
In regards to a timeline for a .NET upgrade, I've suggested a few times that I'd be willing to wait a reasonable amount of time if there was a clear commitment and plan for the process. I know some people here (especially those who are experiencing major stability problems) aren't going to be very patient, but that doesn't mean there aren't Linux users that would be appreciative of a timeline and willing to wait. Just because some customers aren't willing to wait doesn't mean that the whole idea should be abandoned. I'm sure plenty of the customers who ended up migrating to Windows out of necessity would happily return to Linux if the issues were resolved. If the commitment was actually made and there was transparency throughout the process I think you'd see a lot more goodwill from people here. Having a "temporary" Linux release that is stable enough (such as is being worked on with the private beta) would also help during this time.
@JakeMorgan Why the silence on the issue of the .NET upgrade? I'm not understanding why there seems to be no willingness to even have a conversation on the topic. Even if Linux is out of the picture .NET 4.x is a legacy platform at this point. Is CC going to remain on .NET 4 indefinitely? That doesn't bode well for Windows users either.
You speak of the financial resources being used for Mono maintenance, but is the budget for CC overall (including your primary Windows target) so small that a basic upgrade of the core platform is not on the table? And if it is on the table, why wait a year or two when you could resolve all this mess now?
Can we at least have some discussion on the issue from people on the development team? I just don't get this mentality that if we ditch Linux everything is going to be perfect from now on...
@JakeMorgan Some additional feedback continuing from my previous post...
I think the general consensus with on-premise users is that extensions (at least in their current form) aren't all that useful. I know I can only speak for myself, but there are only a handful of extensions that I use (primarily involving things like adding some basic computer information or screenshots to the general tab). I think extensions certainly could be way more useful, but until you go back to allowing on-premise users to code custom extensions without having to get approval from Connectwise (even for private extensions that won't be on the marketplace) it's just too cumbersome for most organizations. Even the marketplace doesn't really have a huge number of truly useful extensions, and I'd be willing to bet 70%+ of the extensions have little to no use at all at this point. The bottom line is that extensions should not be holding ANYTHING back in regards to development of the core software. For people that absolutely need a specific extension they could stay with an existing version of CC that would be supported with security updates until the extension was migrated to the modernized CC platform. This seems like a reasonable approach to me, and the developers could then focus on a single .NET Core/.NET 5.x cross-platform build target with no Mono dependency at all. Any extension that was not incompatible with .NET Core would be immediately available, and others could easily be migrated one-by-one over as much as a couple years if necessary.
Sorry to be a broken record for people who have followed this issue for months, but to restate for clarification, Microsoft is unifying .NET Core and the full .NET Framework with the upcoming release of .NET 5. This new .NET 5.x supersedes .NET Core and .NET 4.x. Just about everything is cross-platform except for WinForms and WPF, and ASP.NET Web Forms are going away entirely. So if CC is going to ever support running on .NET 5.x then everything that has been mentioned will have to be done anyway (including fixing any incompatible extensions). Why not just start that process now? Honestly, if you had done that instead of trying to re-fork Mono you'd probably already be done and spent less time. I know it's not super helpful to point that out after the fact, but it is what it is. And as much as I want Linux compatibility, I think the real driving factor for moving away from legacy .NET code is actually the performance/stability for future Windows builds (including your cloud platform). I'd imagine that you'd see a lot of performance gains and reduced maintenance headaches that would more than cover the cost of the moderate amount of time spent upgrading the .NET platform dependency (especially since you already mentioned the codebase is in good shape for a move like that).
In regards to Linux and on-premise users like myself, the annual licensing renewal costs aren't nearly as cheap as you implied, so I think you probably have more money coming in from those users (as long as people renew their licenses) than you may think. Maybe you were thinking of customers paying for only 1 concurrent session? In any case, there definitely are savings compared to cloud plans, and even if the cloud product was heavily discounted I want to be in control of my own server for a variety of reasons too lengthy to mention here (not to mention that there is obviously no guarantee that any discounts wouldn't go away at some point). In terms of the Linux versus Windows issue, for users who don't already have a Windows server it really a lot to have to set up and maintain a Windows system when they already have capable Linux machines ready. As much as Windows has improved over the past decade there is still really no comparison with Linux for server applications in terms of maintenance and reliability (if the software itself is reliable of course). But again, I'm not arguing for Connectwise to maintain a separate Linux build--that's why this issue is so frustrating. All this craziness would just disappear if you embraced the future as Microsoft themselves are touting. Just about the only thing Linux-specific required might be a couple scripts related to installing the software, period. It's just really disheartening to see little to no interest in what seems to me to be the best option for the future of both CC and it's customers. I'm done ranting. But please, please take all this to heart. I have really enjoyed using CC and love the value it has provided (especially because of the Linux on-premise capability).
@JohnWorth Connectwise has made a mess with how this security update has been communicated (not unsurprising given the how disorganized they seem to be at the moment). Maybe the marketing/web team wasn't informed of the security patch releases? In regards to your specific worries about this vulnerability I think I can clarify (based on my own analysis). They actually have released patches for all versions going back to v19.2, so you don't have to upgrade to a new version of CC, only the latest build for your specific version. The language in the email is technically correct but still vague, and both the version check function as well as the download pages do a horrible job of presenting information that is easily understood in the context of patch builds versus upgrading to a new version of the software.
If you look at the download page and click on the release archive link you will see a download for version 19.4.29492.7513 with a date of 7/27/2020. This is the build you would want that includes the patch for the vulnerability if you want to stay on v19.4.
They also mention in the email that they aren't posting the vulnerability to the security bulletins page until August 5th to give people time to install the patches.
I'm not really understanding the issue with extensions holding back a .NET platform upgrade. What extensions exactly have code that is incompatible with a .NET Core recompile? There appear to be only a few things that can't be done under the current .NET Core release, and the only significant one I see is a lack of support for ASP.NET Web Forms (which really is an outdated legacy feature). Are most extensions really even using Web Forms at all? And if so, would it really take more than a small amount of time to update the extensions?
The bottom line is that Microsoft is dropping support for ASP.NET Web Forms in .NET 5.x, so it really is a dead-end platform at this point. If CC is not going to remain stagnant the migration will have to occur at some point (as I've mentioned many previous times in this thread). Why not simply commit to doing this now and solve both cross-platform compatibility and future Windows platform issues at the same time?
It's great to finally admit some failures, but to then just give up and tell Linux users to move to Windows or to cloud hosting is extremely frustrating. You have the capability to resolve things in a way that is beneficial to all users (on-premise Linux, on-premise Windows, and cloud customers) by simply investing a moderate amount of resources to get the entire platform modernized. Choosing to drop Linux support and stick with .NET 4.x for the foreseeable future is a horrible business decision (and goes completely against the promises made when Connectwise acquired ScreenConnect). That is stagnation, not active development. Please, please re-evaluate that plan. A little bit more resources spent on development now would allow you to reap a lot more rewards down the road.
If you actually read the multitude of posts I've made over the past many months (including one made just 4 days ago) you'd see that I absolutely am no defender of CW at all and certainly have been pressing them to resolve this issue and modernize their entire codebase so we can get rid of a reliance on Mono entirely. I wasn't even accusing anyone specific of not being civil at this point--I simply wanted to warn against going down that road. Not sure how my recommending against an avalanche of negativity right when someone from CW is posting for the first time equates to "ZERO sense of urgency". If she isn't already reading through the whole thread to see what's transpired I seriously doubt a bunch of new hostile comments are going to somehow enlighten her. What I want is engagement with the people who actually are in control of the product so we can continue to provide constructive feedback and not just continue to get silence. Obviously things have not been acceptable thus far, but they are either going to change for the better or they won't. We might as well give them a couple weeks after this change before continuing with the same old criticisms. That's all I'll say on this issue--take it however you want to.
Customer support service by UserEcho