Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

  1. Given that the 3.5.4 release was no longer showing, I knew it wasn't a cache Rick sorted now anyway so all good! I'll trust that you say we're best not doing that then!
  2. Main page still shows the 3.5.4 release date (25th Feb) btw! Is there a way to make PDN use .NET framework v4 rather than 3.5 SP1 if both are installed (when deploying via MSI/GP)?
  3. For reference, this was a custom made MSI file using Winstall LE that has worked fine on all previous versions of PDN for WinXP for some years now (I only do this to include custom effects in the package). I decided to make an MSI using the /createmsi switch on the installer. This created the MSI for me but when I go to install, it says I must use the installer, even though this was an MSI created using the installer? I'm really lost now - any help greatly appreciated!
  4. I'm allocating an MSI of Paint.NET 3.5.4 to our network of 300+ machines (not all at once, but starting to get the ball rolling). We are starting to adopt Windows 7 and have built a few machines with Win7 on, however am finding that when Paint.NET installs on these (not installed locally, it gets the install files from a server through an automatic install) it throws the following error: After telling me about repairing, it then goes on to say.. On all computers, .NET Framework 3.5 SP1 and the above VS2008 package are installed prior to Paint.NET. As I say, this is fully automated and no
  5. I tried it, was still the same. I was guessing there had to be another factor (I never thought the plugin was faulty, as I had it working fine elsewhere). Interestingly, for this user, it wasn't creating the user files folder at all (I would expect it to). Turns out, quite amusingly, that the particular account I was testing with had ran out of disk space, so PDN was unable to write the user files folder to their area Pretty comical! More space, seems to be ok - just my luck! I guess it was just unfortunate that the smudge tool was one of the few I tested which needed to write the custom b
  6. Thanks for the response pyro. With over 700 users, manually creating folders for each user isn't desirable! Users have their own My Documents, which is mapped to a server share (rather than a local profile) - ie: profiles are roaming. I can understand PDN freaking out that it can't write the log file, however the program largely works fine (as do other plugins). I can't see access to "Paint.NET User Files" being an issue somehow, as they can write to their own unique My Documents area. It seems, from what you say, an issue specifically with custom brushes - do we need this? Can we not disable
  7. Thanks pyro - guess it'll have to be the hard way then!
  8. Trying to deploy PDN3.5 in an education environment, and have the smudge plugin applied amongst others. Whilst the smudge tool works for an admin user (who has access to the desktop), when I run it under a limited access account (student) it crashes. It can't write the crash log to the desktop for the reasons above, but more details shows the following: Hidden Content: File: C:\Program Files\Paint.NET\Effects\Smudge.dll Effect Name: pyrochild.effects.smudge.Smudge Full error message: System.UnauthorizedAccessException: Access to the path 'C:\Documents and Settings\All Use
  9. I'm looking to deploy PDN3.5 on our network here, so the preference is an MSI. I want to include several plugins in the installation - can this be done with the automated (unattended) MSI setup? I couldn't see any values for this, and my assumption is that the MSI is created as-is and deployable just with the custom settings (eg: nodesktopshortcut) that you specify? How would I manage to include plugins without having to manually create an MSI myself?
  10. We use PDN in an educational environment, and must, for the time being, use XP SP2, as SP3 has been tested and provides a lot of problems (we're looking at a few months until we can upgrade). Believe me, if we could use SP3, then I would get it on our computers right now, and it would sure free up space from each security update which has been released since SP2! It would be a shame if SP3 was the "minimum" requirement, for us at least. I have held off updating our custom MSI of 3.30 in hope we would soon deploy 3.5!
  • Create New...