Commented Issue: Problem with ghostscript delegate [963]

```
MagickNet.Initialize();
// MagickNet.Initialize(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "imagemagick"));
using(var collection = new MagickImageCollection("test.pdf")) {
// throws
}
```

Ghostscript is installed via the official package (both x86/x64).

The strange thing that i do not have this problem with our own implementation. We are currently
in the process of switching this one out with yours :)

By the way, it would be interesting if we could create separate nuget Ghostscript package with required
dependencies (gswin32.exe & friends bundled).

Would that violate the ghostscript license? Because then you could just use the new feature in Nuget 2.5 to
copy those dependencies into $(OutputPath) upon each build. What do you think? Would be awesome
to have PDF-support out of the box, without installing some thirdparty msi.

If the license agreement is not violated, we would have to patch ImageMagick so that it stops
looking in the registry for a valid ghostscript path.

I doubt this patch would be accepted upstream though.

What do you think?
Comments: ** Comment from web user: petersunde **

Okay, i finally solved it.

So, if you have both x86/x64 msi package installed for ghostscript, imagemagick will choose the x64
package first since that package overwrites the x86 registry settings. So if you run a 32bit
process and try to load imagemagick on a x64 machine this goes fubar.

Solution: Only ever ever install x86 msi package for ghostscript.

It's ok to close this issue now.