Интересная проблема с WCF wsHttpBinding через Брандмауэр
просто поместите ваш цикл while внутри CoRoutine, и пока ваш запрос не будет обработан до возврата дохода. когда это будет сделано, вызовите метод, в котором вы хотите использовать свои данные:
IEnumerator MyMethod()
{
var reader = new WWW(filePath);
while (!reader.isDone)
{
yield return; // <- use endofFrame or Wait For ore something else if u want
}
LoadingDoneDoData(reader.bytes);
}
void LoadingDoneDoData(bytes[] data)
{
// your Code here
}
3 ответа
Вы могли бы попытаться украсить свой класс обслуживания:
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
Я не знаю о решении от Mitch Baker, никогда не пробовал его. Но это включает изменение сгенерированного кода. Существует другой способ обойти это.
Я предполагаю, что Вы сгенерировали клиентский код с помощью svcutil.exe, дав адрес MEX, который указывает на брандмауэр. Когда Вы делаете это, вся необходимая конфигурация добавляется к App.config (или Web.config). Однако адрес сервиса в конфигурации укажет на реальный сервисный адрес (поскольку в WSDL регистрируют адрес сервисного подоконника быть адресом реального сервиса).
Так, что я думаю, решит эту проблему:
Сгенерируйте клиентский код путем предоставления адреса MEX (например: http://:Port-X/service/wcfservice.svc?wsdl). Это будет, генерировал всю необходимую конфигурацию.
При вызове клиентского конструктора дайте URI брандмауэра как EnpointAddress и название конфигурации сгенерированной конфигурации. Таким образом, клиент отправит сообщение, как будто оно отправляло его службе, но адресу брандмауэра:
клиент = новый ServiceClient (endpointConfigName, новая Система. ServiceModel. EndpointAddress ("http://:Port-X/service/wcfservice.svc"));
Более безопасный способ справиться с этим - установить ListenUri конечной точки на URL-адрес службы, а адрес конечной точки - на внешнюю конечную точку, куда клиенты отправляют сообщения. Таким образом, служба «доверяет» сообщениям, направленным только на этот адрес, а не только на ЛЮБОЙ адрес.