Bungle

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!

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)?

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!

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 not done by logging on to the computer and whilst we probably could get it to install if installing manually, this isn't the approach we want to take. This particular MSI package works fine on the Windows XP computers (even without the VS2008 package). Could anyone shed some light? Thanks.

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 brush! Nevermind. Out of curiosity (and I have applied it as well), how does the revised plugin you attached just now differ?

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 it? I don't think our users would need custom brushes anyway! If not, I can see if I can enable access to the desktop and allow it to write its log.

Thanks pyro - guess it'll have to be the hard way then!

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 Users\Shared Desktop\pdncrash.log' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at System.IO.StreamWriter.CreateFile(String path, Boolean append) at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize) at System.IO.StreamWriter..ctor(String path, Boolean append) at PaintDotNet.Startup.UnhandledException(Exception ex) in D:\src\pdn\paintdotnet\src\PaintDotNet\Startup.cs:line 477 at PaintDotNet.Startup.Application_ThreadException(Object sender, ThreadExceptionEventArgs e) in D:\src\pdn\paintdotnet\src\PaintDotNet\Startup.cs:line 509 at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t) at System.Windows.Forms.Control.WndProcException(Exception e) at System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(Exception e) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd, Int32 nCmdShow) at System.Windows.Forms.Control.SetVisibleCore(Boolean value) at System.Windows.Forms.Form.SetVisibleCore(Boolean value) at System.Windows.Forms.Control.set_Visible(Boolean value) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.RunDialog(Form form) at System.Windows.Forms.Form.ShowDialog(IWin32Window owner) at PaintDotNet.Menus.EffectMenuBase.RunEffectImpl(Type effectType) in D:\src\pdn\paintdotnet\src\PaintDotNet\Menus\EffectMenuBase.cs:line 777 Whilst I haven't tried every plugin we have running, most I have and they haven't crashed yet. Any suggestions?

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?

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!