Antonio Rodríguez

I agree that SCD is desirable in the cases where file corruption prevents paint.net from opening. But it will not eliminate those scenarios. In an SCD setup, the files in the private copy of the .NET Framework can get corrupted as well, which would create the same trouble. It just would be "easier" to fix for inexperienced users: just reinstall the apparent culprit (paint.net in this case), instead of the runtime that contains the broken DLL (.NET Framework). The biggest problem with space is not the installer's size, but the installed application's disk footprint. In my 8.25 TB system (240 GB SSD plus two 4 TB hard drives) it isn't a problem at all, but, even today, they sell many laptops and tablets with just 128 or 256 GB of disk space where you have to fit Windows, applications and data. 7-Zip would make the download smaller, and I'd love to see it in everybody's computer - just as paint.net, it's fast, free and powerful. In fact, I put both 7-Zip and paint.net in all my friends' computers! But somehow many people prefer to use (unpaid) WinRAR or WinZip. Go figure... Anyway, I digress. I agree that an SCD installer would solve problems and free some of your time. But how much trouble is offering both options? I have no experience with recent versions of Visual Studio (I switched to web development about 10 years ago after 15 years developing commercial Windows applications and, yes, dealing with DLL corruption on customers' systems), and I'm not up to date with the recent advances, so bear with me. How much time/effort would it take to create both SCD and traditional installers? Is it even possible without having to maintain two different Visual Studio solutions? If possible, can both builds be automated to save you time?

Some numbers on self-contained deployment. Currently, paint.net's installer (version 4.2.16) weights 12.2 MB, and once installed on a 64-bit machine it takes 111 MB of disk space (including a 56 MB Staging directory, but not counting the .NET Framework, which is shared with many other applications). The self-contained portable version package is 77.7 MB (more than six times the current installer) and, when uncompressed, it takes 192 MB of disk space, which, with the corresponding Stagging directory (assuming it takes the same as the portable archive itself, which I believe is a reasonable assumption) would go up to about 270 MB (two and a half times the current version). Also, installing a private copy of the .NET Framework would negate any bug and security fixes deployed through Windows Update, which I think is a bid disadvantage. All of this just because a small percentage of users are having problems with broken system libraries (which can be fixed with many available tools: System File Checker, the .NET Framework installer, even System Restore). Offering a portable or self-contained version is useful in itself. It helps people with those problems, and allows you to test a new version without going through the full setup process (which is even more interesting in the case of pre-release versions!). But I don't think there is need to make it the default option. IMHO, it would be a lot better to just offer both options at download time: traditional installer and self-contained/portable version. That way, we could save *a lot*, both on your bandwidth usage and our disk occupation! That said, I like it very much to be able to test a pre-release version without touching my working installation. Since I depend on paint.net for my workflow, in the 16 years I've been using paint.net I have never tried to install an alpha or beta version. But this is the first time that have dared, because it didn't involve any risk. That's very good! Edit: I tried to post this in the build 7894 thread, which introduced the self-contained deployment, but it got closed while I was writing. Hope I have posted to the right place!