Доступ к блоку.NET от классического ASP
Трудно сказать без дополнительной информации о TaskCard и других объектах, но вы должны попытаться объявить некоторую переменную final и попытаться напечатать хеш-код для объекта, чтобы проверить, действительно ли он такой же instance или другие экземпляры, семантически равные:
for (Iterator<TaskCard> i = taskManager.getTaskCards().iterator(); i.hasNext();) {
TaskCard taskCard = i.next();
taskCard.updateTask();
ReturnInterface<String> returnInterface = new TaskReturnIterface(taskManager, taskCard);
Task task = taskCard.getTask();
// Mark this as "final" so you can use it as is in any internal anonymous class:
final ProtocolInterface selectedProtocol = task.getDevice().getSelectedProtocol();
selectedProtocol.setTask(task);
selectedProtocol.setReturnInterface(returnInterface);
System.out.println("[1] selectedProtocol device=" + selectedProtocol.getDevice().hashCode());
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
System.out.println("[2] selectedProtocol device=" + selectedProtocol.getDevice().hashCode());
}
});
}
Казалось бы, есть некоторые связи между объектами, которые могут либо печатать один и тот же вывод, либо использовать один и тот же объект в бэкэнде. Особенно эта часть:
ProtocolInterface selectedProtocol = task.getDevice().getSelectedProtocol();
selectedProtocol.setTask(task);
selectedProtocol.setReturnInterface(returnInterface);
выглядит странно, поскольку selectedProtocol кажется каким-то образом привязанным к самому устройству, привязанному к задаче, тогда вам придется снова ставить его задачу?
Это в основном делать task.getDevice().getSelectedProtocol().setTask(task), который выглядит так, как будто есть какая-то лазейка, которую вы должны проверить ...
Кроме того, SwingUtilities.invokeLater() является своего рода зарезервированным для обработки графического интерфейса, так что вы можете захотеть удалить его (если он не выполняет GUI ...).
3 ответа
Другая вещь проверить: удостоверьтесь, что Ваш блок .NET установлен быть COM Видимый.
У меня были проблемы в прошлом с вызовом блоков.NET от Классика ASP. Я думаю, что это было одной из этих нескольких проблем, с которыми я столкнулся по пути.
Одна из вещей, которые я должен был сделать, чтобы заставить вещи работать, состояла в том, чтобы удостовериться, что Пул приложений для сайта ASP использовал те же идентификационные данные в качестве анонимного пользователя (по умолчанию, это использует "Пользователя системы" или что-то как этот). Таким образом, я закончил тем, что создал нового локального пользователя (удостоверяющийся, что это - член группы IIS_WPG), и использование это и для анонимного пользователя IIS и для идентификационных данных Пула приложений.
Это - неприятная область, хотя, приложение я использовал ее для, был упакованный продукт, и мы нашли, что некоторая машина была завинчена таким способом, которым мы просто не могли заставить Классика ASP к вызовам .NET работать даже после большой тонкой настройки полномочий и т.п..
Править:
Я предполагаю, что должен сказать, что я не утверждаю, что это изменение решит эту конкретную проблему, просто что это было одним из изменений, которые мы должны были внести для разбирания Классика ASP-> работа кода.NET над широким спектром случайных клиентских серверов.
Это ошибочное средство "Недопустимая строка класса" - другими словами, вызов к CreateObject перестал работать, потому что объект имени не может быть найден подсистемой OLE. Причины включают:
- Вы действительно не выполняли regsvr32 на сервере, в конце концов.
- Вы выполнили regsvr32, но он сообщил об ошибке.
- Кто-то изменил безопасность со стороны реестра, это препятствует тому, чтобы подсистема OLE читала все или часть дерева HKEY_CLASSES_ROOT.
- Название объекта, который Вы пытаетесь создать, было написано c орфографическими ошибками или неправильное.
- Определите, является ли это проблема полномочий
Добавьте анонимного пользователя (используемый IIS) к Группе администраторов. Тестовая страница затем работала, доказывая, что это была проблема полномочий. Не забывайте удалять анонимного пользователя IIS из Группы admin!
- Определите, является ли это проблема полномочий файла:
После удаления Анонимного пользователя от Группы admin добавьте аудит отказа к файлу (smtpsvg.dll), который определит, получало ли к файлу когда-либо доступ (отсутствие события отказа). Если это не, это проясняет, что отказ до доступа к файлу, но разрешения и полномочий файла/каталога проверки удостовериться, что анонимный пользователь IIS может получить доступ к файлу.
- Проверьте полномочия реестра
Используя Regedt32, действительно найдите на smtpsvg.dll. Проверьте полномочия на ключ (и sub ключи), и удостоверьтесь, что анонимный пользователь считал права. Сделайте находку на идентификаторе класса, который содержит значение местоположения и версию, и проверьте те полномочия также.
источник: http://forums.digitalpoint.com/showthread.php?t=21069