.Net не находит системные библиотеки, которые находятся в папке с установленным .Net. Программа начинает запускаться толко в том случае, если все необходимые библиотеки находятся в директории с программой (см багу 3286)
Запустил тестовую программу HelloWorld. Результаты: <wine@cellar bottle dotnet/net1.1>$ wwxp test.exe fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing" fixme:shell:URL_ParseUrl failed to parse L"System.DirectoryServices" fixme:shell:URL_ParseUrl failed to parse L"System.Messaging" fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess" fixme:shell:URL_ParseUrl failed to parse L"System.Data" Hello Всё работает! Хотя запрашиваемых библиотек в папке с программой нет. Возможно никакой баги нет. Чтобы это проверить надо попробовать использовать ещё какую-нибудь системную библиотеку, которая не обращается к System.Drawing.FontFamily
Написал тест, использующий System.Drawing.dll Тест лежит в /var/ftp/pub/Windows/Tests/DotNetTests/TestDrawing Тест прекрасно работает (необходима только сторонняя gdiplus.dll), хотя в текущем каталоге системных библиотек нет.
Бага проявляется на dotnet2.0
Были подозрения на: fixme:shell:URL_ParseUrl failed to parse L"System.Drawing" попробовал поставить shlwapi и shell32 сторонние. Ничего не изменилось. Значит проблема в другом.
Трейс по каналу file показал, что запрашивается много файлов из папки windows/assembly. Но в wine она пустая! Пробовал скопировать туда файлы с установленной .net2.0 на win2k3 - бага исчезла. Остаётся выяснить почему в процессе установки не создаются файлы в windows/assembly
Запускал установку с трейсом по каналу file, msi и shell. Ни одного упоминания папки assembly не нашёл.
Подозрительное сообщение в консоле при установке: err:msi:ITERATE_InstallService Control query failed! формируется SQL запрос: SELECT * FROM `Component` WHERE `Component` ='%s' далее он расшифровывается: fixme:msi:MSI_QueryGetRecord query='L"SELECT * FROM `Component` WHERE `Component` ='_X86"' fixme:msi:MSI_QueryGetRecord query='L"SELECT * FROM `Component` WHERE `Component` ='MSCORSVW_EXE_____X86.3643236F_FC70_11D3_A и передаётся: fixme:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Component` WHERE `Component` ='MSCORSVW_EXE_____X86.3643236F_FC70_11D3_A536_0090278A1BB8'" 0x8de550 почему берётся второе значение после расшифровки - пока не понятно. Ещё пока не понятно расшифровывается ли в итоге знечение `Component`, или так и остаётся.
(In reply to comment #7) > далее он расшифровывается: > fixme:msi:MSI_QueryGetRecord query='L"SELECT * FROM `Component` WHERE > `Component` ='_X86"' > fixme:msi:MSI_QueryGetRecord query='L"SELECT * FROM `Component` WHERE > `Component` ='MSCORSVW_EXE_____X86.3643236F_FC70_11D3_A > > почему берётся второе значение после > расшифровки - пока не понятно. Первый раз можно не считать, из-за нехватки входного буфера, это временное значение. И вообще, это было немного не то место. Возникает ошибка при втором запросе: fixme:msi:MSI_QueryGetRecord query='L"SELECT * FROM `ServiceControl` WHERE `Name` ='clr_optimization_v2.0.50727_32'"' Проблема в 2-х действиях: MSI_ViewExecute( view, NULL ); MSI_ViewFetch( view, &rec ); После них rec = NULL (как и было раньше)
Проблема в MSI_ViewFetch, точнее проблемы нет, она просто возвращает ERROR_NO_MORE_ITEMS. Получается, что запрашиваемого параметра в базе нет.
Попробовал установить следующим образом: 1) Устанавливается dotnet1.1 2) Устанавливается dotnet2.2 Всё прекрасно работает!!!! Даже не надо копировать виндовый l_intl.nls добавил описание установки на kb.etersoft.ru добавил отчёт на appdb.winehq.org.ru
переделал UNIVERSAL_NAME_INFO_LEVEL. лучше не использовать WNetGetConnection. нужно еще доделать REMOTE_NAME_INFO_LEVEL, почему-то структура заполняется неправильно, и написать тест.