SFX Creator 4 Alpha

Iska · Отправлено: **09:51, 05-06-2011** | #**152**

Цитата MKN:

Экспорт произвести в обыкновенный одноимённый txt файл. Например, в ProductCode.txt и ProductName.txt »

Ясно.

Цитата MKN:

Для работы же, предложенного тобой vbs скрипта, местонахождение и исходного *.msi и результирующего txt файлов - рядом со скриптом vbs. »

Результирующие файлы ложатся рядом с «*.msi» — хорошо. Рядом со скриптом — это мне не нравится. Не есть правильно иметь кучу дубликатов скрипта по разным папкам.

Цитата MKN:

На кой нам получать ещё и ProductName ? »

Я хотел сразу и «ProductName» добавить в скрипт, но изначально такой вопрос не стоял — я и не стал делать сие.

Цитата MKN:

Данные из ProductCode.txt и ProductName.txt заносятся в соответствующие переменные и записываются в код нового созданного файла msi.nsi. Где он будет создан, не критично. К примеру, в C:/myMSInsi
В этот файл msi.nsi записывается »

Можно сделать, но мне нужно чёткое пояснение куда писать полученные значения «ProductName» и «ProductCode». По приведённому примеру мне не ясно.

Можно и просто поместить полученные значения в буфер обмена в нужном формате.

Подход:

Цитата kotkovets:

1. Исполняемый файл *.exe который заводится препроцессором NSIS и этот файл *.exe (vbs скрипт) заинклудит массив номерков в код NSIS на этапе компиляции проекта »

мне кажется более правильным. Кстати, а почему не просто *.vbs, безо всяких компиляций?

А в чём пишете NSIS-проекты? Скажем, редактор SciTE умеет передавать выделенный текст запускаемой внешней программе, равно скрипту, как аргумент командной строки, и получать результат работы из её stdout, который затем может быть сразу вставлен в редактируемый текст.

Цитата MKN:

PS DrWEB c ума сходит от этого скрипта и не даёт сохранять... Что делать ? »

Мне сложно что-либо сказать вразумительное по поводу столь неподобающего поведения DrWEB.

Цитата MKN:

И сдаётся мне что от vbs скрипта придётся отказаться из-за реакции на него антивирусов (пусть и не всех...).
Пользователь не должен страдать из-за этого. Если конечно Iska чего нибудь в скрипте не подправит...
И возможно придётся сконвертить vbs в exe. »

Конвертация скрипта в исполняемый файл только усилит подозрительность антивирусов.

Цитата MKN:

Скрипт должен без проблем автономно запускаться на машинах пользователей, у которых есть проблемы либо с скриптоассоциациями , либо чего то скриптовое не установлено или повреждено. Сплошь и рядом встречаю машины, где не возможно так просто запустить файлы VBS... »

«Сплошь и рядом» — не встречал такого.

В принципе, сбитые ассоциации легко обходятся прямым указанием исполняемого файла и пути к скрипту:

Код:

C:\WINDOWS\system32\wscript.exe "E:\Песочница\0057\GetProductCodeFromMSI.vbs"

или

Код:

C:\WINDOWS\system32\cscript.exe "E:\Песочница\0057\GetProductCodeFromMSI.vbs"

Не установлено — как такое может быть? Это ведь один из основных компонентов системы. Библиотеки, кроме того, входят в состав всех IE. Если повреждено — надо восстанавливать.

Очередное приближение:

Код:

Option Explicit

Const msiOpenDatabaseModeReadOnly = 0


Dim strArg
Dim strProperties
Dim strAllValues

Dim objDatabase


If WScript.Arguments.Count <> 0 Then
	strAllValues = ""
	
	For Each strArg In WScript.Arguments
		With WScript.CreateObject("Scripting.FileSystemObject")
			If .FileExists(strArg) Then
				If UCase(.GetExtensionName(strArg)) = UCase("msi") Then
					Set objDatabase = WScript.CreateObject("WindowsInstaller.Installer").OpenDatabase(strArg, msiOpenDatabaseModeReadOnly)
					
					strProperties =                 GetMSIProperty(objDatabase, "ProductName")    & vbCrLf
					strProperties = strProperties & GetMSIProperty(objDatabase, "ProductVersion") & vbCrLf
					strProperties = strProperties & GetMSIProperty(objDatabase, "ProductCode")    & vbCrLf
					
					With .CreateTextFile(.BuildPath(.GetParentFolderName(strArg), .GetBaseName(strArg) & ".MSIProperties.txt"), True, True)
						.Write strProperties
						.Close
					End With
					
					strAllValues = strAllValues & strProperties & vbCrLf
					
					Set objDatabase = Nothing
				Else
					WScript.Echo "File [" & strArg & "] in not a MSI file."
				End If
			Else
				WScript.Echo "File [" & strArg & "] not found."
			End If
		End With
	Next
	
	Copy2Clipboard strAllValues
Else
	WScript.Echo "Usage: " & WScript.ScriptName & " <msi file 1> <msi file2> … <msi file N>"
End If

WScript.Quit 0
'=============================================================================

'=============================================================================
Function GetMSIProperty(objDatabase, strProperty)
	With objDatabase.OpenView("SELECT * FROM Property WHERE Property = '" & strProperty & "'")
		.Execute()
		
		With .Fetch()
			GetMSIProperty = .StringData(1) & ":" & .StringData(2)
		End With
		
		.Close
	End With
End Function
'=============================================================================

'=============================================================================
Sub Copy2Clipboard(strValue)
	With WScript.CreateObject("InternetExplorer.Application")
		.Navigate("about:blank")
		
		.document.parentWindow.clipboardData.setData "text", strValue
		.Quit
	End With
End Sub
'=============================================================================

Скрипт принимает msi-файлы аргументами командной строки. Можно, например, создать ярлык к скрипту и бросать на него msi-файлы. В папке рядом с каждым msi-файлом будут созданы одноимённые им текстовые файлы по принципу «<Имя msi-файла>.MSIProperties.txt». В число извлекаемых свойств я включил имя пакета — «ProductName», версию — «ProductVersion» и «ProductCode». Помимо того данная информация будет помещена в буфер обмена (будет ли последнее работать с версиями IE > 6 — не знаю) в виде, наподобие: