Является ли использование сценариев Windows, особенно FileSystemObject, хорошей идеей? - PullRequest
Новая
       39

Является ли использование сценариев Windows, особенно FileSystemObject, хорошей идеей?

3 голосов
/ 17 мая 2010

Недавно меня попросили провести техническое обслуживание приложения VB6. Это включает в себя некоторые файловые операции ввода-вывода. Я считаю, что операции ввода-вывода, предлагаемые ссылкой на хост сценария Windows и использование FileSystemObject, намного удобнее, чем операции ввода-вывода, которые поставляются с VB6.

Но вызовет ли это проблемы из-за проблем безопасности или из-за того, что хост сценария будет отключен на компьютерах некоторых пользователей?

Обновление (20 августа 2012 г.). С тех пор как мы задали этот вопрос, мы трижды сталкивались с проблемой неработающего scrrun.dll среди 3000 клиентов. Мы должны были исправить это вручную через удаленную поддержку. Кажется, что иногда виноват вируссан.

Ответы [ 3 ]

4 голосов
/ 17 мая 2010

Как отметил в своем комментарии Роберт Харви, на практике это обычно не проблема. Вполне возможно, что scrrun.dll может быть либо не установлен, либо неправильно зарегистрирован на данном компьютере. Мы столкнулись с обоими сценариями при установке нашего собственного приложения VB6 на компьютеры клиентов.

Что касается отключения сценариев, мы фактически столкнулись с этой проблемой с другими приложениями (такими как Microsoft InfoPath) и обошли эту проблему, вызвав форму InfoPath (которая требовалась для ввода-вывода файлов). к VB6 DLL, которая использовала WSH FileSystemObject, так что, если что, вы можете обойти проблемы безопасности скриптов, используя библиотеку вместе с VB6. Насколько я знаю, параметры безопасности WSH применяются конкретно к реальным сценариям, а не к программам, в которых используются компоненты из среды выполнения сценариев.

Фактически, вы можете полностью отключить Windows Scipt Host на своем компьютере и по-прежнему получать доступ к компонентам WSH, таким как FileSystemObject, из приложения VB6.

3 голосов
/ 17 мая 2010

Файловый ввод-вывод в VB всегда имел некоторую синтаксическую «странность» из-за его наследования от Q / BASIC, но его просто использовать, если вы придерживаетесь прямого чтения / записи (избегая ввода строки / записи / получения). Использование собственных методов будет быстрее, чем FSO, и позволит избежать любых проблем с зависимостями, какими бы редкими они не были.

Другое соображение заключается в том, что если вы хотите выполнить IO двоичного файла, вам все равно придется использовать встроенные методы, поскольку FSO является только текстовым.

2 голосов
/ 17 мая 2010

Я иногда сталкивался с клиентскими компьютерами, где FileSystemObject не работал, возможно, из-за параноидальных ИТ-отделов, которые как-то его отключали. Теперь я стараюсь избегать FileSystemObject, если это возможно.

Обычно вы можете заменить FileSystemObject собственным кодом VB6 или вызовами API непосредственно в Windows API. Например, на превосходном сайте Карла Э Петерсона есть несколько замечательных объектов, полностью написанных на VB6.

Некоторые примеры

...