PluginBuilder and Vista ?

[erland]

Is it just my development setup that results in zip files from PluginBuilder that can't be unzipped by Windows Vista without warning messages ?

The users that have Vista and tries to unzip my plugins apparently get an error message saying "There is already a file with the same name as the folder name you specified".

There is a hotfix from Microsoft available:
http://support.microsoft.com/KB/952249

However, it's a bit strange that I've only seen reports regarding this from my plugins, so this makes me suspect that there might be some problem with my setup that casues this. It may also be that everyone else build their plugins on a Windows machine while I'm using Ubuntu 8.04.

So has anyone else seen this problem and knows any way to solve it so PluginBuilder generates zip files that are understood by Vista ?

[mherger]

> Is it just my development setup that results in zip files from
> PluginBuilder that can't be unzipped by Windows Vista without warning
> messages ?

On what machine are you creating them?

--

Michael

[erland]

> Is it just my development setup that results in zip files from
> PluginBuilder that can't be unzipped by Windows Vista without warning
> messages ?

On what machine are you creating them?

Ubuntu Linux 8.04

[pippin]

Ubuntu Linux 8.04

Same with iPeng and zips created on my Mac.
Seems Vista only likes Windows ZIPs

[peterw]

Then why use PluginBuilder? SC7 likes plain zip files just fine, so why bother with a tool that creates problems? I've never liked how PluginBuilder takes simple .pm text files and rolls them into .par files (makes it more of a pain to read & modify the source). And there's the bug some folks have run into where PB pulled in more Perl libs than were really needed. And PB's hard-coded list of file extensions it thinks are relevant. I just have "manifest" files for each plugin (derived from commands like "find MyPlugin -type f -print | grep -v ',v$'") and use plain old 'zip' from the command line. Nobody's written me about this Vista problem, but neither have I checked it myself (no access to any Vista machines).

[erland]

Then why use PluginBuilder? SC7 likes plain zip files just fine, so why bother with a tool that creates problems? I've never liked how PluginBuilder takes simple .pm text files and rolls them into .par files (makes it more of a pain to read & modify the source). And there's the bug some folks have run into where PB pulled in more Perl libs than were really needed. And PB's hard-coded list of file extensions it thinks are relevant. I just have "manifest" files for each plugin (derived from commands like "find MyPlugin -type f -print | grep -v ',v$'") and use plain old 'zip' from the command line. Nobody's written me about this Vista problem, but neither have I checked it myself (no access to any Vista machines).

PluginBuilder is the official way, I know I can do it manually but I think the official way at least should do it correctly. Although, I'm not sure the current way is incorrectly according to the zip standard, there might just be Microsoft that have interpreted it wrong.

It has been stated by Logitech developers that packaging plugins without a par file may stop working at some time.

I do agree with you that it was better before when we didn't have the par file as the source was easier to look at and patch if needed. However, the issue isn't really with the par file, the issue is with the zip file which the par file is packaged in.

By the way, I have to run a patched version of PluginBuilder, since the official one doesn't even generate a working plugin in my case:
http://bugs.slimdevices.com/show_bug.cgi?id=6980

[pippin]

The Vista .zip issue is NOT a plugin builder issue.
I see the same thing when I create regular .zip files on my Mac.

[peterw]

It has been stated by Logitech developers that packaging plugins without a par file may stop working at some time.

Can someone explain why the .pm source is bundled into a .par *within* the plugin's directory? I could understand why we might move to distributing .par files instead of .zip files if that makes the planned download/update manager's tasks easier, but what's the rationale behind making an additional .par inside each plugin's directory that contains virtually all the source code? This isn't like a J2EE deployment where a single .jar or .war file often contains dozens or hundreds of files.

Lest this look like a total flame, I'd like to say that I *do* like how SC7 allows plugins to include their own lib/ directories, so they can include code under namespaces other than Plugin::MyPlugin. When I get around to compiling Win32::SerialPort that will come in handy for PowerCenter.