Code Access Security - ошибка Best Practice

[Vhaldemar]

Господа, помогите пожалуйста!

Проблема суть следующая: есть класс, свойство RunOn = 'Called from'.
В методе run используется объект класса TextIO:

void run()
{
TextIO logFile;
…
;
…
logFile = new TextIo("c:\\temp\\vhAPI_log.log", 'W');
…
}

При компиляции появляется ошибка Best Practice следующего содержания:
"TwC: Assert usage of API TextIo.new because it is protected by Code Access Security"

ВОПРОС: как нужно модифицировать код, чтобы этот Best Practice исчез?

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
1. Использование //BP deviation documented лишь преобразует error Best Practice в info Best Practice.
2. Использование соответсвующего "permission" ошику Бест Практиз не убирает
void run()
{
TextIO logFile;
FileIOPermission permission;
…
;
…
permission = new FileIOPermission("c:\\temp\\vhAPI_log.log", 'W');
permission.assert();
…
// invoke protected API
logFile = new TextIo("c:\\temp\\vhAPI_log.log", 'W');
…
}
3. Единственно когда ошибка НЕ появляется: если RunOn класса = "Client"
или метод, использующий TextIO является client static

Заранее спасибо!

[kashperuk]

А если permission.assert() сделать непосредственно перед new TextIO?

[mazzy]

Цитата:

Сообщение от Vhaldemar

При компиляции появляется ошибка Best Practice следующего содержания:
"TwC: Assert usage of API TextIo.new because it is protected by Code Access Security"

У вас Аксапта 4.0
В ней были изменены правила доступа кода к файловой системе, WinAPI, буферу обмена и т.п.
Для того, чтобы TextIO работал, его надо обрамить специальным классом.

Об этом хорошо написано в хелпе.
Например, здесь http://msdn.microsoft.com/en-us/libr...36(AX.10).aspx

Пример как надо обрамлять

public void run()
{
    QueryRun                qr;
    FileIoPermission        _perm = new FileIoPermission("c:\\000\\test.txt",'w');
    TextBuffer              textBuffer = new TextBuffer();
;

    qr = this.queryRun();
    while( qr.next() )
    {
        ...
        textBuffer.appendText("...something...");
    }

    _perm.assert();
    textBuffer.toFile("c:\\000\\test.txt");
    CodeAccessPermission::revertAssert();
}

[Vhaldemar]

Цитата:

Сообщение от kashperuk

А если permission.assert() сделать непосредственно перед new TextIO?

В том то и дело что .assert() делал непосредственно перед new TextIO..

[mazzy]

Цитата:

Сообщение от Vhaldemar

В том то и дело что .assert() делал непосредственно перед new TextIO..

Объявление переменной FileIoPermission в тексте метода должно стоять ДО объявления переменной TextIO.

[Vhaldemar]

Цитата:

Сообщение от mazzy

Объявление переменной FileIoPermission в тексте метода должно стоять ДО объявления переменной TextIO.

К сожалению это не влияет на присутвсвие TWC Best Practice: я объявил переменную FileIoPermission до переменной TextIO, но увы, вышеупомянутая ошибка Best Practice осталась..

Почему тогда она(ошибка) исчезает если RunOn класса = "Client"??

В принципе, если Best Practice о чем-то "ругает", то должен существовать подход, позволяющий этой "ругани" избежать, или я что-то не понимаю?

[gl00mie]

Цитата:

Сообщение от Vhaldemar

увы, вышеупомянутая ошибка Best Practice осталась..
Почему тогда она(ошибка) исчезает если RunOn класса = "Client"??

Одна из Best Practices - читать документацию и использовать поиск по форуму

Цитата:

Сообщение от Vhaldemar

В принципе, если Best Practice о чем-то "ругает", то должен существовать подход, позволяющий этой "ругани" избежать, или я что-то не понимаю?

Конечно, такой подход существует - он описан в документации, в частности, в Dynamics AX Writing Secure X++ Code

[DSPIC]

А если поставить breakpoint в соответствующем классе SysBPCheckXXXXX и посмотреть причину...?
(чисто технический подход )

[kashperuk]

Ну, ругань происходит, потому что если код работает с RunOn != Client, то это значит, что он может теоретически выполнятся на сервере, и пути будут уже не клиентские, а серверные. И файлы - серверные. А все, что касается сервера приложений, должно быть защищено - и это, думаю, разумно.
Соответственно, работать с файлами на сервере является Bad Practice.

По поводу же избежания - это сделать можно - если посмотрите класс WinAPIServer - увидите, что там нормально работает работа с файлами.

[Vhaldemar]

Цитата:

Сообщение от gl00mie

Одна из Best Practices - читать документацию и использовать поиск по форуму Конечно, такой подход существует - он описан в документации, в частности, в Dynamics AX Writing Secure X++ Code

Полностью с Вами согласен
"Dynamics AX Writing Secure X++ Code" документ мне знаком: в нем то и описываются(равно как и в msdn) пермишн-классы для всех "опасных" API в Аксапте, в том числе и FileIOPermission..

Непонятно только следующее: класс CCHTMLSave, sys-layer, runOn = "Called from", метод run(), в общем, аналогичная моей ситуация, ОДНАКО в качестве "антидота" на TWC Best Practice используется..правильно, //BP Deviation Documented

Причем это не единственный класс в DAX 4.0 с подобным подходом.
Получается что в данной ситуации - использование //BP единственный выход??