.NET requirement bloating install size

I love writing in Scrivener on both my Linux home system, my iPad and my “carry everywhere writing machine”, which tends to vary but is definitely a very cheap, low power Chromebook with Linux installed, with very low RAM and disk space.

That has worked eminently well for me. Until the requirement for .NET 4.6.2 appeared. That has exploded the Scrivener Wine directory from around a hundred megabytes to 2.2 gigabytes, which just doesn’t work on cheap Chromebooks.

The strange thing is that RAM usages is not affected much, and it does not seem like there are hardly any calls to .NET while it runs. But if I remove these two gigabytes of pretty much unused bloat, Scrivener no longer starts.

Is this going to be a permanent state going forward, or will this issue be resolved later on?

The new licensing library provided by Paddle requires the .NET 4.6.2 (or later) libraries, which is not something L&L have any control over.

Does it need to be included in the install? I don’t know much about .net or windows, but that seems like a shared library would do better here. .net seems to be installed on most windows machines, and can be replicated on linux using Mono. So why bundle it automatically if we probably have a copy of it already on disk?

As far as I know, the .NET installer isn’t included in the download package for Scrivener. However, if you don’t have the right version installed, then you need to install it, and each .NET version can be a fairly hefty amount of space. Many version of .NET are backwards compatible, though, so once you install (say) 4.6.2, you may no longer need separate runtimes for 4.5 installed. This can vary a lot between versions of Windows (which version of the .NET runtime they come installed with or allow you to install as an optional feature) and how your .NET apps were programmed, however, so you may need to experiment.

They can choose what licensing library they use, surely.

This is really annoying, since the Linux version of Scrivener (which clocks in at 64 megabytes, including spell checking and all required libraries, in an AppImage) is perfect for a Chromebook, and has by far enough features to allow me to do all my work on it - but can not interoperate with the iOS version.

So I will have to switch something out. And the problem is, if I go for an even smaller Chromebook to try to replace the iPad, the problem remains… so I’m not sure how to proceed here. I really don’t want to switch to a more expensive “carry everywhere” machine; the iPad is costly enough that I don’t want to carry THAT everywhere, even.

Maybe I will see how the Linux AppImage runs under qemu on a jailbroken Android tablet. But then I need to get hold of such a tablet.

Just want to say that not having to honk around with stuff like this is one reason I’ve stayed with Windows rather than experimenting with Linux, which (I understand) requires or at least invites more system-level gear adjusting. Not that I don’t love that kind of thing; but I’m getting too old to want to spend time on it.

The point of all that being that I really hope that once v. 3 is out the door, and the inevitable urgent uncaught bugs are repaired, L&L’s first order of business will be to find another license server. Paddle seems desperately broken, based on reports I’ve seen here. I have managed to decline all the proffered updates, and am still on v. 1.9.9, without any issues. But when I move up to v. 3, I dread having to deal with this.

Rather the opposite. Linux requires pretty much no system-level gear adjusting. It works out of the box. Windows requires a lot more. And Windows also invites a lot more. There is precious little to mess with in Linux, unless you have special requirements - and if you do, you need to mess with that regardless of OS.

Sounds like my second- and third-hand knowledge of Linux is seriously out of date! Glad to know that it is now more user friendly. At any rate, I really hope I’m not going to have to try to figure out my .NET version to run Scrivener 3 on Windows.

I think there are a couple of different things going on here. The original poster referenced using WINE which tells me they are running Linux but running Windows inside of their Linux installation to run Scrivener.

The bloat is unfortunate, for sure, but I’ll weigh in here as I also happen to be a software engineer primarily focused on .Net. Scrivener uses an older .Net version. Even 4.6.2 has been supplanted by 4.7.2, but these are also what are considered the “full framework” versions of .Net. Microsoft has a newer platform (.Net Core) that is smaller, more performant, and most importantly, cross platform.

I’m wondering if there’s an opportunity here for the Scrivener folks to look at leveraging .Net Core. I’d even be happy to chat a bit with the business and engineers about migration and opportunity. I’m still waiting on the Scrivener 3 Windows update. If .Net Core were used as the underlying tech stack (assuming the licensing component supports it), Scrivener may also be able in the future to roll out Windows, Mac, and Linux versions in unison and do so with far less dependency overhead and bloat.

In doing a touch more digging, Paddle is actually a third party licensing service. They do provide an SDK that can be used to access their services and it appears to only work with full framework out of the box. One could push Paddle to provide Netstandard (compatible with both full framework and .Net Core) versions of their SDKs, or the developers could choose to integrate with Paddle themselves and skip the SDK, thus removing the strict full framework requirement.

That is exactly the issue. The application grew by 2+ gigabytes, without adding ANY end user benefit. That’s a rather horrific amount of bloat for an application that used to be mean, lean, under 100 megs, and focused on allowing writing on pretty much any computer, no matter how small and weak. The Scrivener 3 beta ran just fine on my Chromebook until the .NET requirement was added. Now it doesn’t. And for what?

Not quite. Think of WINE as another API.

With that much of a size increase I think they need to consider an alternative licensing provider.

Yes I’m aware, just wanted to simplify a bit for non or less technical readers.

Let’s be clear: you’re throwing this lovely hissy cow because you are using the application in an undesigned manner with best-effort support AND it’s still working, but you’re upset about it because it upsets the optimization for your corner case that is explicitly called out as NOT supported?

That is one way to word it. Another is that I am pointing out what is happening, and explaining clearly my case so as to not have it mistaken for a general compliant, or for being an issue in use cases where it’s not.

I could, of course, have avoided being specific, in the hopes that the problem would seem larger, and perhaps garner more attention.That did not really occur to me until your comment. I try for good communication and clear explanations of what I am bringing up, and also for being clear with whether what I bring up matters to me or not. And this matters to me.

Of course I am upset that a writing solution I have used for a few years now to great effect suddenly no longer works. It’s rather annoying, especially with the immense convenience it gave me. Now I’m back to trying out new methods to gain that convenience back, and thus far the only solutions I see will cost me at least a few hundred euros and a bunch of hours of work.

Easy… no need to snipe. That’s another very valid viewpoint but let’s be civil about it. Even my previous comments about the technology chosen are drastically over simplified for example.