В приложении нужно определить public классы, унаследованные от System.ServiceProcess.ServiceBase и System.Configuration.Install.Installer. Для наследника ServiceInstaller нужно указать атрибут [RunInstaller(true)]. Эти классы описывают службу. Установка и удаление выполняется статическими методами класса System.Configuration.Install.ManagedInstallerClass. О ManagedInstallerClass в MSDN написано только то, что это класс для внутренних нужно .NET Framework и он не предназначен для непосредственного вызова из кода пользователя. Пример использования этого класса можно найти в реализации утилит, которые поставляются вместе с .NET Framework.
Полный пример кода:
пятница, 24 декабря 2010 г.
суббота, 18 декабря 2010 г.
Создание тестового SSL сертификата, настройка HttpListener
Основан на How To: Walkthrough Using HttpListener as an SSL Simple Server
Я раньше не работал с SSL. И когда в одном проекте возникла необходимость использовать SSL, я обнаружил, что нет простого объяснения того, как можно создать SSL сертификат. Результатом поиска стала эта статья. Она основана на англоязычном варианте и расширена информацией полученной из собственного опыта.
Я раньше не работал с SSL. И когда в одном проекте возникла необходимость использовать SSL, я обнаружил, что нет простого объяснения того, как можно создать SSL сертификат. Результатом поиска стала эта статья. Она основана на англоязычном варианте и расширена информацией полученной из собственного опыта.
среда, 27 октября 2010 г.
Сравнение кириллицы в SQLite без учета регистра
У SQLite есть одна особенность. Сравнение строк без учета регистра, функции изменения регистра работают только для ASCII-символов. Это особенность может принести немало хлопот, если нужно строить запросы с использованием, например, кириллицы.
Например, если в колонке str сохранены значения “VaLuE”, “value”, то запрос SELECT * FROM tab WHERE str LIKE “value” вернет две строки. LIKE по-умолчанию не чувствителен к регистру. Если в базе данных сохранены значения “ЗнАчЕнИе” и “значение”, то такой же запрос вернет только одну строку.
Для решения подобных задач SQLite предоставляет механизм переопределения встроенных функций и правил сравнения в пользовательском коде. Ниже пример кода на Python, который выполняет переопределение:
Например, если в колонке str сохранены значения “VaLuE”, “value”, то запрос SELECT * FROM tab WHERE str LIKE “value” вернет две строки. LIKE по-умолчанию не чувствителен к регистру. Если в базе данных сохранены значения “ЗнАчЕнИе” и “значение”, то такой же запрос вернет только одну строку.
Для решения подобных задач SQLite предоставляет механизм переопределения встроенных функций и правил сравнения в пользовательском коде. Ниже пример кода на Python, который выполняет переопределение:
среда, 20 октября 2010 г.
Изменился формат вывода bytea в PostgreSQL 9.0
После перехода на PostgreSQL 9, в одном из приложений, в разработке которого я учавствую, начала возникать ошибка при получении и десериализации данных, которые хранятся в базе данных в поле типа byte. В приложении используется библиотека Npgsql.
Причиной возникновения ошибки стало изменение формата вывода данных типа bytea. До версии PostgreSQL 9 форматом вывода по умолчанию был escape. Начиная с версии PostgreSQL 9 форматом вывода по умолчанию стал hex. Библиотека Npgsql этих изменений еще не учитывает.
Я нашел два способа решения этой проблемы. Первый, это изменение параметра bytea_output в конфигурационном файле postgresql.conf. Нужно убрать комментарий и установить значение escape. Второй способ, это в клиентском коде преобразовать массив из hex-формата в обычный массив байт. Что из себя представляет hex-формат можно прочитать здесь. Вот быстро набросанный код, который получает исходный массив байт:
Скорее всего есть более цивилизованные способы, но я их пока не нашел. :)
Причиной возникновения ошибки стало изменение формата вывода данных типа bytea. До версии PostgreSQL 9 форматом вывода по умолчанию был escape. Начиная с версии PostgreSQL 9 форматом вывода по умолчанию стал hex. Библиотека Npgsql этих изменений еще не учитывает.
Я нашел два способа решения этой проблемы. Первый, это изменение параметра bytea_output в конфигурационном файле postgresql.conf. Нужно убрать комментарий и установить значение escape. Второй способ, это в клиентском коде преобразовать массив из hex-формата в обычный массив байт. Что из себя представляет hex-формат можно прочитать здесь. Вот быстро набросанный код, который получает исходный массив байт:
- using (var reader = command.ExecuteReader())
- {
- reader.Read();
- data2 = (byte[])reader[0];
- byte[] data3 = new byte[(data2.Length - 1) / 2];
- for (int i = 0; i < data3.Length; ++i)
- {
- var hi = byte.Parse(((char)data2[(i + 1) * 2 - 1]).ToString(), NumberStyles.AllowHexSpecifier);
- var lo = byte.Parse(((char)data2[(i + 1) * 2]).ToString(), NumberStyles.AllowHexSpecifier);
- data3[i] = (byte)((hi << 4) | (lo & 0x0F));
- }
- }
Скорее всего есть более цивилизованные способы, но я их пока не нашел. :)
понедельник, 4 октября 2010 г.
Ресурс с статьями и примерами исходных кодов
На stackoverflow.com нашел ссылку на интересный ресурс Programming tutorials and source code examples. Наверное, у каждого программиста есть набор собственных шаблонов, готовых решений. На java2s.com собрано большое количество примеров на разных языках программирования. Начиная c примеров работы с памятью в C и заканчивая шаблонами HTML+CSS.
пятница, 30 июля 2010 г.
Python. Масштабирование изображений
С целью изучения Python-а слелал поделку для изменения размеров фотографий в пакетном режиме.
Для работы с изображениями я использовал библиотеку PIL. В Ubuntu эта библиотека предустановлена. В Windows нужно устанавливать самостоятельно. Я использую Python версии 2.7 под Windows. PIL для работы с Python 2.7 можно скачать с effbot.org.
Вот код сценария:
Параметры командной строки описаны в начале сценария. Сценарий принимает два обязательных параметра: -d – путь, -p – новый размер изображения в процентах. Пример вызова:
python imgresize.py –d «C:\Photos» –p 50
В результате выполнения сценария в каталоге «C:\Photos» будут созданы файлы с именами начинающимися на «r_» и размером в два раза меньше исходных.
Для работы с изображениями я использовал библиотеку PIL. В Ubuntu эта библиотека предустановлена. В Windows нужно устанавливать самостоятельно. Я использую Python версии 2.7 под Windows. PIL для работы с Python 2.7 можно скачать с effbot.org.
Вот код сценария:
# Resize image # Command line: # python imgresize.py -d <directory> -p <percentage> import os, sys from PIL import Image directory_ = sys.argv[sys.argv.index("-d") + 1] percentage_ = int(sys.argv[sys.argv.index("-p") + 1]) filenames_ = os.listdir(directory_) for filename_ in filenames_[:]: path_ = directory_ + "\\" + filename_ if not os.path.isfile(path_): continue try: image_ = Image.open(path_) size_ = (image_.size[0] * percentage_ / 100, image_.size[1] * percentage_ / 100) if percentage_ < 100: image_ = image_.resize(size_, Image.ANTIALIAS) else: image_ = image_.resize(size_, Image.NEAREST) image_.save(directory_ + "\\r_" + filename_) print path_, "=>", "r_" + filename_, " OK " except: print path_, "\n", sys.exc_info() print "Finish"
Параметры командной строки описаны в начале сценария. Сценарий принимает два обязательных параметра: -d – путь, -p – новый размер изображения в процентах. Пример вызова:
python imgresize.py –d «C:\Photos» –p 50
В результате выполнения сценария в каталоге «C:\Photos» будут созданы файлы с именами начинающимися на «r_» и размером в два раза меньше исходных.
среда, 7 июля 2010 г.
Ошибка UnicodeDecodeError в демонстрационном проекте Django
Буквально на днях начал осваивать web-программирование. Начать решил с Python 2.7 + Django 1.1. После прочтения введений восхищению не было предела (оно есть до сих пор).
Трудность появилась при попытке реализовать пример, приведенный в введении в Django. Трудность заключалась в том, что при попытке загрузить войти в административную часть новосозданного сайта, все отображалось не так как в примерах, а без стилей. При этом в журналах отладочного сервера выдавалось следующее сообщение:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 280, in run
self.result = application(self.environ, self.start_response)
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 709, in __call__
mime_type = mimetypes.guess_type(file_path)[0]
File "C:\Python27\lib\mimetypes.py", line 295, in guess_type
init()
File "C:\Python27\lib\mimetypes.py", line 356, in init
db.read_windows_registry()
File "C:\Python27\lib\mimetypes.py", line 261, in read_windows_registry
for ctype in enum_types(mimedb):
File "C:\Python27\lib\mimetypes.py", line 251, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
Наличие исходников стандартной библиотеки Python-а позволило найти проблему довольно быстро. Я использую Windows XP. В моем случае проблема заключалась в том, что в реестре в разделе [HKEY_CLASSES_ROOT\CLSID\{4063BE15-3B08-470D-A0D5-B37161CFFD69}\EnableFullPage\MIME] содержались подразделы содержащие в названии кириллицу. При удалении этих разделов они автоматически пересоздавались. Поэтому помогло переименование, просто заменил кириллицу латиницей.
Понятно, что это частный случай и настройки системы. Но возможно, эта заметка позволит кому-нибудь сэкономить время.
--
Mihail 2 ноября 2012 г., 22:06
Для тех у кого в registry Windows 7 нет русских ключей, но проблема осталась - переименуйте сетевое имя компьютера с русского на английский языки.
--
Casufi5 декабря 2012 г., 19:06
Решение исправлением библиотеки: http://softwaremaniacs.org/forum/django/31707/
Трудность появилась при попытке реализовать пример, приведенный в введении в Django. Трудность заключалась в том, что при попытке загрузить войти в административную часть новосозданного сайта, все отображалось не так как в примерах, а без стилей. При этом в журналах отладочного сервера выдавалось следующее сообщение:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 280, in run
self.result = application(self.environ, self.start_response)
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 709, in __call__
mime_type = mimetypes.guess_type(file_path)[0]
File "C:\Python27\lib\mimetypes.py", line 295, in guess_type
init()
File "C:\Python27\lib\mimetypes.py", line 356, in init
db.read_windows_registry()
File "C:\Python27\lib\mimetypes.py", line 261, in read_windows_registry
for ctype in enum_types(mimedb):
File "C:\Python27\lib\mimetypes.py", line 251, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
Наличие исходников стандартной библиотеки Python-а позволило найти проблему довольно быстро. Я использую Windows XP. В моем случае проблема заключалась в том, что в реестре в разделе [HKEY_CLASSES_ROOT\CLSID\{4063BE15-3B08-470D-A0D5-B37161CFFD69}\EnableFullPage\MIME] содержались подразделы содержащие в названии кириллицу. При удалении этих разделов они автоматически пересоздавались. Поэтому помогло переименование, просто заменил кириллицу латиницей.
Понятно, что это частный случай и настройки системы. Но возможно, эта заметка позволит кому-нибудь сэкономить время.
--
Mihail 2 ноября 2012 г., 22:06
Для тех у кого в registry Windows 7 нет русских ключей, но проблема осталась - переименуйте сетевое имя компьютера с русского на английский языки.
--
Casufi5 декабря 2012 г., 19:06
Решение исправлением библиотеки: http://softwaremaniacs.org/forum/django/31707/
суббота, 29 мая 2010 г.
Простота программного кода
Простота программного кода - существенный фактор, который облегчает дальнейшее его сопровождение.
пятница, 2 апреля 2010 г.
Как открыть консоль из проводника
Иногда бывает нужно выполнить какую-нибудь операцию в консольном окне. При этом желательно открыть консольное окно в текущей папке проводника Windows. Для того чтобы это сделать, нужно зажать клавишу Shift и правой клавишей мыши открыть контекстное меню для нужной папки. При этом в контекстном меню будет доступен пункт 'Open command window here'.
вторник, 2 марта 2010 г.
Утилита Wixsubst
Для создания пакетов инсталляции я использую WiX. На мой взгляд, это простой, удобный и интенсивно развивающийся инструмент с хорошими возможностями. Для того чтобы ускорить процесс разработки своих WiX-проектов я написал небольшую утилиту wixsubst.
Утилита wixsubst предназначена для автоматической герерации WiX-кода на основании списка файлов на диске. Уже существует утилита paraffin, которая решает эту задачу. Но она предполагает ведение файла-шаблона. А это, на мой взгляд, не всегда удобно.
Когда я решил написать свою утилиту, я хотел решить следующие задачи:
Утилита работает следующим образом. Список файлов формируется на основании XML-комментария. XML-комментарий разбит на две части, заголовок и окончание. В заголовке описываются параметры. При вызове утилиты выполняется замена кода между заголовком и окончанием. Вложенные XML-комментарии не поддерживаются.
***
Пример
Нужно создать пакет инсталляции для проекта:
Для этого в WiX-файле "myproject.wix" пишу следующий код:
И вызываю wixsubst с параметром "myproject.wix". В результате вызова файл "myproject.wix" будет содержать следующий код:
Все повторные вызовы инструмента wixsubst, не будут модифицировать файл myproject.wix, пока не изменится список файлов проекта. Например, будет добавлена новая библиотека или конфигурационный файл.
***
Как показано в примере утилита wixsubst принимает один параметр - имя WiX-файла. Wixsubst можно вызвать и с двумя параметрами. В этом случае первый параметр будет именем файла-шаблона, а второй - именем результирующего файла.
Заголовок XML-комментария должен начинаться с ключевого выражения "#def filesubst". После ключевого выражения должно следовать описание параметров. Описание каждого параметра должно быть задано следующим образом "#def [имя параметра]: [значение параметра] #end".
Wixsubst поддерживает следующие параметры:
Шаблон, описанный в значении параметра subst может содержать специальные переменные "filename" и "path". Имя переменной нужно ограничивать символом "%". Вместо переменной filename будет подставляться имя файла без указания пути. Вместо переменной path будет подставляться имя файла с указанием пути.
Окончание XML-комментария представляет собой постоянное ключевое выражение "#end filesubst".
Для вызова утилиты из Visual Studio можно настроить External Tool (пункт меню Visual Studio Tools > External Tools, затем Add...). Пример настройки:
В результате появится пункт меню Tools > WixSubst. При выборе этого пункта меню будет обработан текущий WiX-файл.
Скачать утилиту можно здесь. Предложения, замечания приветствуются.
Утилита wixsubst предназначена для автоматической герерации WiX-кода на основании списка файлов на диске. Уже существует утилита paraffin, которая решает эту задачу. Но она предполагает ведение файла-шаблона. А это, на мой взгляд, не всегда удобно.
Когда я решил написать свою утилиту, я хотел решить следующие задачи:
- удобный вызов из редактора; в качестве параметра можно передать только имя WiX-файла;
- простые правила написания шаблона;
- возможность многократно вызывать утилиту для одного и того же WiX-файла для обновления списка файлов проекта;
Утилита работает следующим образом. Список файлов формируется на основании XML-комментария. XML-комментарий разбит на две части, заголовок и окончание. В заголовке описываются параметры. При вызове утилиты выполняется замена кода между заголовком и окончанием. Вложенные XML-комментарии не поддерживаются.
***
Пример
Нужно создать пакет инсталляции для проекта:
| C:\MyProject\MyProject.exe C:\MyProject\MyProject.exe.config C:\MyProject\Lib\Lib1.dll C:\MyProject\Lib\Lib1.xml C:\MyProject\Lib\Lib2.dll C:\MyProject\Lib\Lib2.xml |
Для этого в WiX-файле "myproject.wix" пишу следующий код:
| ... <Directory Id="INSTALLLOCATION" Name="MyProject"> <Component Id="ProjectFilesComponent" Guid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"> <!--#def filesubst #def directory: C:\MyProject #end #def exclude: MyProject.exe #end #def subst: <File Sourse="%path%" Vital="yes"/> #end--> <!--#end filesubst--> </Component> <Directory Id="LibDirectory" Name="Lib"> <Component Id="LibComponent" Guid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"> <!--#def filesubst #def directory: C:\MyProject\Lib #end #def mask: *.dll #end #def subst: <File Id="%filename%" Source="%path%" Vital="yes"/> #end--> <!--end filesubst--> </Component> </Directory> </Directory> ... |
И вызываю wixsubst с параметром "myproject.wix". В результате вызова файл "myproject.wix" будет содержать следующий код:
| ... <Directory Id="INSTALLLOCATION" Name="MyProject"> <Component Id="ProjectFilesComponent" Guid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"> <!--#def filesubst #def directory: C:\MyProject #end #def exclude: MyProject.exe #end #def subst: <File Sourse="%path%" Vital="yes"/> #end--><File Sourse="C:\MyProject\MyProject.exe.config" Vital="yes"/> <!--#end filesubst--> </Component> <Directory Id="LibDirectory" Name="Lib"> <Component Id="LibComponent" Guid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"> <!--#def filesubst #def directory: C:\MyProject\Lib #end #def mask: *.dll #end #def subst: <File Id="%filename%" Source="%path%" Vital="yes"/> #end--><File Id="Lib1.dll" Source="C:\MyProject\Lib\Lib1.dll" Vital="yes"/> <File Id="Lib2.dll" Source="C:\MyProject\Lib\Lib2.dll" Vital="yes"/> <!--#end filesubst--> </Component> </Directory> </Directory> ... |
Все повторные вызовы инструмента wixsubst, не будут модифицировать файл myproject.wix, пока не изменится список файлов проекта. Например, будет добавлена новая библиотека или конфигурационный файл.
***
Как показано в примере утилита wixsubst принимает один параметр - имя WiX-файла. Wixsubst можно вызвать и с двумя параметрами. В этом случае первый параметр будет именем файла-шаблона, а второй - именем результирующего файла.
Заголовок XML-комментария должен начинаться с ключевого выражения "#def filesubst". После ключевого выражения должно следовать описание параметров. Описание каждого параметра должно быть задано следующим образом "#def [имя параметра]: [значение параметра] #end".
Wixsubst поддерживает следующие параметры:
- directory - папка из которой нужно получить список файлов, обязательный параметр;
- exclude - список файлов, которые нужно исключить; файлы разделяются ";";
- mask - маска файлов, которые нужно выбрать;
- subst - шаблон кода WiX, который будет повторен для каждого найденного файла;
Шаблон, описанный в значении параметра subst может содержать специальные переменные "filename" и "path". Имя переменной нужно ограничивать символом "%". Вместо переменной filename будет подставляться имя файла без указания пути. Вместо переменной path будет подставляться имя файла с указанием пути.
Окончание XML-комментария представляет собой постоянное ключевое выражение "#end filesubst".
Для вызова утилиты из Visual Studio можно настроить External Tool (пункт меню Visual Studio Tools > External Tools, затем Add...). Пример настройки:
В результате появится пункт меню Tools > WixSubst. При выборе этого пункта меню будет обработан текущий WiX-файл.
Скачать утилиту можно здесь. Предложения, замечания приветствуются.
четверг, 11 февраля 2010 г.
Сведения о предустановленных версиях .NET
Оригинал статьи: Which Version of .NET is Built into Windows?
На диаграмме ниже приведены сведения о предустановленных версиях .NET в различных версиях Windows. Диаграмма также показывает опции включения .NET по-умолчанию.
На диаграмме ниже приведены сведения о предустановленных версиях .NET в различных версиях Windows. Диаграмма также показывает опции включения .NET по-умолчанию.
пятница, 22 января 2010 г.
Плановое резервирование базы данных PostgreSql с помощью batch
Известно, что для сохранности базы данных нужно создавать резервные копии. Причем создание резервных копий должно выполняться автоматически, а не тогда, когда об этом вспомнит администратор. В этой статье я хочу поделиться опытом создания bat-файлов, позволяющих настроить плановое резервное копирование базы данных PostgreSql с использованием планировщика Windows.
Особенностью планового резервного копирования является то, что пользователь не следит за ходом выполнения операции и не может проконтролировать результат. Исходя из этого, обязательным требованием является ведение журналов с информацией о результатах резервного копирования. Ниже приведен пример BAT-файла, который выполняет резервное копирование базы данных PostgreSQL, ведет журнал с информацией о датах и результатах выполнения, сохраняет подробные сведения о ходе выполнения каждой резервной копии в отдельный текстовый файл и в случае неудачи отображает диалоговое окно с сообщением.
backup.bat
Сведения о большинстве команд, примененных в "backup.bat" достаточно распространены. Информацию о назначении каждой команды можно получить путем вызова из командной строки следующей команды: "[Имя команды] /?". Я хочу акцентировать внимание на нескольких менее известных моментах.
Строки 15, 16 выполняют переход в папку в которой находится файл "backup.bat". "%0" возвращает имя bat-файла; "%~d0" и "%~dp0" возвращают соответственно диск и путь к bat-файлу. Подробные сведения о работе с параметрами файла можно посмотреть по этой ссылке.
В строке 19 формируется строковое представление даты и времени в нужном формате. При формировании происходит обращение к переменным окружения DATE и TIME, которые хранят текстовое представление даты и времени соответственно. После имени переменной указывается строка вида ":~m,n", где m - позиция в строке, n - количество символов.
В строке 27 вызывается утилита резервного копирования pg_dump.exe. Вызов выполняется с применением команды CALL, это позволяет дождаться завершения утилиты и проанализировать результат выполнения. Вызов утилиты завершается строкой "2>%LOGPATH%". Эта строка означает что поток ошибок STDERR, номер которого 2, приложения pg_dump.exe перенаправляется в файл, имя которого сохранено в переменной окружения LOGPATH. Так как приложение pg_dump.exe выводит все сообщения в стандартный поток ошибок, то в файле LOGPATH будет сохранен подробный отчет о выполнении резервного копирования.
В строках 37 и 42 выполняется перенаправление вывода в файл backup.log. Перенаправление осуществляется оператором ">>". Различие между операторами ">" и ">>" в том, что первый каждый раз создает новый файл, затирая ранее записанные данные, а второй - дописывает данные в существующий файл. Таким образом можно вести журнал с подробными сведениями о результатах резервного копирования.
После создания и проверки bat-файла для создания резервных копий можно создавать задание планировщика Windows. Задание также может быть создано из командной строки. Для этого можно воспользоваться командой SCHTASKS. Ниже приведен пример использования этой команды.
schedule.bat
В результате выполнения schedule.bat будет создана задача "Резервное копирование". Параметры задачи можно посмотреть и изменить через оконный интерфейс. Использование bat-файла для создания задания планировщику может быть полезным в случаях, когда настройку резервного копирования нужно выполнять многократно.
По аналогии можно настроить выполнение скриптов обслуживания базы данных, удаление устаревших данных, резервное копирование отдельных таблиц истории в конце месяца, ...
Особенностью планового резервного копирования является то, что пользователь не следит за ходом выполнения операции и не может проконтролировать результат. Исходя из этого, обязательным требованием является ведение журналов с информацией о результатах резервного копирования. Ниже приведен пример BAT-файла, который выполняет резервное копирование базы данных PostgreSQL, ведет журнал с информацией о датах и результатах выполнения, сохраняет подробные сведения о ходе выполнения каждой резервной копии в отдельный текстовый файл и в случае неудачи отображает диалоговое окно с сообщением.
backup.bat
|
Сведения о большинстве команд, примененных в "backup.bat" достаточно распространены. Информацию о назначении каждой команды можно получить путем вызова из командной строки следующей команды: "[Имя команды] /?". Я хочу акцентировать внимание на нескольких менее известных моментах.
Строки 15, 16 выполняют переход в папку в которой находится файл "backup.bat". "%0" возвращает имя bat-файла; "%~d0" и "%~dp0" возвращают соответственно диск и путь к bat-файлу. Подробные сведения о работе с параметрами файла можно посмотреть по этой ссылке.
В строке 19 формируется строковое представление даты и времени в нужном формате. При формировании происходит обращение к переменным окружения DATE и TIME, которые хранят текстовое представление даты и времени соответственно. После имени переменной указывается строка вида ":~m,n", где m - позиция в строке, n - количество символов.
В строке 27 вызывается утилита резервного копирования pg_dump.exe. Вызов выполняется с применением команды CALL, это позволяет дождаться завершения утилиты и проанализировать результат выполнения. Вызов утилиты завершается строкой "2>%LOGPATH%". Эта строка означает что поток ошибок STDERR, номер которого 2, приложения pg_dump.exe перенаправляется в файл, имя которого сохранено в переменной окружения LOGPATH. Так как приложение pg_dump.exe выводит все сообщения в стандартный поток ошибок, то в файле LOGPATH будет сохранен подробный отчет о выполнении резервного копирования.
В строках 37 и 42 выполняется перенаправление вывода в файл backup.log. Перенаправление осуществляется оператором ">>". Различие между операторами ">" и ">>" в том, что первый каждый раз создает новый файл, затирая ранее записанные данные, а второй - дописывает данные в существующий файл. Таким образом можно вести журнал с подробными сведениями о результатах резервного копирования.
После создания и проверки bat-файла для создания резервных копий можно создавать задание планировщика Windows. Задание также может быть создано из командной строки. Для этого можно воспользоваться командой SCHTASKS. Ниже приведен пример использования этой команды.
schedule.bat
|
В результате выполнения schedule.bat будет создана задача "Резервное копирование". Параметры задачи можно посмотреть и изменить через оконный интерфейс. Использование bat-файла для создания задания планировщику может быть полезным в случаях, когда настройку резервного копирования нужно выполнять многократно.
вторник, 19 января 2010 г.
Полезный ресурс для работы с bat-файлами
На днях решал задачу автоматизации резервного копирования базы данных PostgreSQL. Было два возможных решения: написать свое приложение на C# или использовать bat-файлы. Я остановил свой выбор на втором решении, которое мне показалось более гибким (для изменения не требуется дополнительных программных средств) и быстрым в решении. В результате с помощью bat-файлов были решены следующие задачи:
В процессе решения задачи узнал много нового о возможностях bat-файлов. Ответы на все вопросы, возникавшие в процессе работы нашел на сайте Rob van der Woude's Scripting Pages. На мой взгляд, отличный ресурс, который можно рекомендовать.
Наверное, в одном из следующих сообщений выложу пример скрипта для создания резервной копии.
- Вызов внешнего консольного приложения (pg_dump).
- Обработка STDERR консольного приложения.
- Генерирование имени файла резервной копии с включением имени базы данных, даты и времени резервного копирования.
- Ведение журнала (текстовый файл) успехов/неудач резервного копирования.
- Отображение диалогового окна в случае неудачного резервного копирования.
- Создание пользователя операционной системы от имени которого будет вызываться задание резервного копирования.
- Создание задачи для планировщика задач Windows.
В процессе решения задачи узнал много нового о возможностях bat-файлов. Ответы на все вопросы, возникавшие в процессе работы нашел на сайте Rob van der Woude's Scripting Pages. На мой взгляд, отличный ресурс, который можно рекомендовать.
Наверное, в одном из следующих сообщений выложу пример скрипта для создания резервной копии.
суббота, 16 января 2010 г.
При переходе на Windows 7 перестали открываться скрипты в PgAdmin III
Вопрос:
При переходе на Windows 7 возникла проблема с открытием файлов SQL-скриптов в PGAdminIII (верчия 1.10.1). Все скрипты, сделанные в пердыдушей системе Windows XP SP3, перестали открываться. То есть, при попытке открыть файл скрипта содержимое файла не отображается на экране, окно редактирования скрипта остается пустым. При этом вновь созданные файлы скриптов сохраняются и открываются нормально.
Решение:
При сравнении файлов созданных в предыдущей и текущей системе я обратил внимание, что файлы созданные в предыдущей системе, сохранены в кодировке Windows 1251, а файлы созданные в новой системе сохранены в кодировке UNIX UTF8. Для ставнения файлов я использовал редактор Notepad++.
В результате поиска и сравнения настроек PGAdmin III в Windows XP и Windows 7 я обнаружил что решением вопроса является установка значения False для параметра WriteUnicodeFile в ветке реестра HKEY_CURRENT_USER\Software\pgAdmin III. После установки значения стали открываться файлы созданные как в Windows XP так и в Windows 7.
При переходе на Windows 7 возникла проблема с открытием файлов SQL-скриптов в PGAdminIII (верчия 1.10.1). Все скрипты, сделанные в пердыдушей системе Windows XP SP3, перестали открываться. То есть, при попытке открыть файл скрипта содержимое файла не отображается на экране, окно редактирования скрипта остается пустым. При этом вновь созданные файлы скриптов сохраняются и открываются нормально.
Решение:
При сравнении файлов созданных в предыдущей и текущей системе я обратил внимание, что файлы созданные в предыдущей системе, сохранены в кодировке Windows 1251, а файлы созданные в новой системе сохранены в кодировке UNIX UTF8. Для ставнения файлов я использовал редактор Notepad++.
В результате поиска и сравнения настроек PGAdmin III в Windows XP и Windows 7 я обнаружил что решением вопроса является установка значения False для параметра WriteUnicodeFile в ветке реестра HKEY_CURRENT_USER\Software\pgAdmin III. После установки значения стали открываться файлы созданные как в Windows XP так и в Windows 7.
пятница, 1 января 2010 г.
Упрощения языка WiX v3 (перевод)
Ссылка на оригинал сообщения: Simplifying the WiX v3 language
Атрибут Feature для элемента Component
У элемента Component теперь есть атрибут Feature; при установке этого атрибута, Component становится частью соответствующего Feature. Таким образом, следующие примеры кода эквивалентны:
и
Component/@Feature позволяет указать только один Feature для Component. Для того, чтобы поместить Component в несколько Feature, нужно использовать элемент Feature или FeatureRef и ComponentRef. Добавление атрибута Feature, это всего лишь способ упростить наиболее общий случай помещения одного Component в один Feature.
Теперь значение по-умолчанию для атрибута Id определяется именем файла (без указания пути), указанным в значении атрибута Source. Затем, как сказано выше, значение по-умолчанию для атрибута Name определяется равным значению атрибута Id. Такие правила позволяют определить элемент File следующим образом:
Эквивалентным определением будет:
Упрощения языка WiX v3
Два новых изменения, упрощающих работу с WiX, будут доступны в следующем недельном релизе WiX v3. Изменения направлены на упрощение разработки пакетов инсталляции и на уменьшение избыточности.Атрибут Feature для элемента Component
У элемента Component теперь есть атрибут Feature; при установке этого атрибута, Component становится частью соответствующего Feature. Таким образом, следующие примеры кода эквивалентны:| <Component Id="FooComp" Feature="BarFeature" ... /> |
и
| <Component Id="FooComp" .../> ... <FeatureRef Id="BarFeature"> <ComponentRef Id="FooComp"/> </FeatureRef> |
Component/@Feature позволяет указать только один Feature для Component. Для того, чтобы поместить Component в несколько Feature, нужно использовать элемент Feature или FeatureRef и ComponentRef. Добавление атрибута Feature, это всего лишь способ упростить наиболее общий случай помещения одного Component в один Feature.
Значения по-умолчанию для File/@Id и File/@Name из File/@Source
Обычно, при определении элемента File, указывается несколько атрибутов с одинаковыми значениями. Например, значения атрибутов Id, Name и Source включают имя файла. В WiX v3 предусмотрено определение значений по-умолчанию для некоторых атрибутов элемента File, например, значение атрибута Name по-умолчанию определяется значением атрибута Id.Теперь значение по-умолчанию для атрибута Id определяется именем файла (без указания пути), указанным в значении атрибута Source. Затем, как сказано выше, значение по-умолчанию для атрибута Name определяется равным значению атрибута Id. Такие правила позволяют определить элемент File следующим образом:
| <File Source="$(env.Bits)\foo\bar\baz.exe" /> |
Эквивалентным определением будет:
| <File Id="baz.exe" Name="baz.exe" Source="$(env.Bits)\foo\bar\baz.exe" /> |
О чем этот блог
Я буду использовать этот блог для публикации сообщений о собственных работах и для публикации новостей, обзоров и т.п. об интересующих меня технологиях.
Подписаться на:
Сообщения (Atom)