to post messages and comments.

← All posts tagged programming

MS анонсировали ".NET Standard 2.0"
Looking at the various flavors of .NET there is a lot of common BCL code that is not tied to App Models (WinForms, WPF, ASP.NET, etc). These APIs will be part of .NET Standard 2.0, which will be released at the same time, resulting in APIs being consistent across .NET Framework, .NET Core and Xamarin. It will be much easier to write portable code that can run on all the major .NET platforms, targeting .NET Standard 2.0.
blogs.msdn.microsoft.com

не юзайте, люди, wcf duplex, ибо это зло бажное.

вот что у меня было:

если при классическом вызове (с клиента на сервер), происходит ошибка, то клиент получает Fault, который катит вместо Exception'а.

а в сценарии с Дуплексом и Callback'ом, если случается ошибка на клиенте при ответе серверу, то пипец. ошибка никуда не едет, сервер получает timeout, у channel'ов (с обоих сторон) State видится, как Open (т.е. все окей, работать можно), но общаться они больше не могут.
про ошибку можно узнать только под дебагером либо из логов.

вот пара нюаснсов:
— если пакет оказался больше чем мог бы быть (ограничение на maxReceivedMessageSize/maxArrayLength) то сервер получает timeout, но канал остается работоспособнымж
— если пакет не смог сериализоваться (KnownType не прописан), то наступает ад — сервер получает timeout exception, каналы думают, что они открыты, работать больше не могут, ивенты типа Faulted/Closed не вызываются.

я тут подумал, раз в логах видно, то можно кастомного WCF FaultHandler'а написать, навесить его через IEndpointBehavior. но и тут жопа — fault handler срабатывает только при классических ошибках — при запросе от клиента к серверу. при работе с коллбэком (FaultHandler я навесил на все каналы, на в том числе и на Callback-channel, причем на обоих сторонах — на клиенте и на сервере) он тупо не срабатывает.

гугл ответа не подсказал, на стек-оверфлоу ничего толкового не нашел.
писать самим MS как-то влом (хотя периодически это делаем на msconnect и на форумах), потому что уже запланировали переписать архитектуру, чтобы было без коллбеков.

только что узнал, что C#5 не умеет вот такой код

public async Task<IEnumerable<string>> GetItemsAsync() {
string item1 = await GetSomethingAsync();
yield return item1;

string item2 = await GetSomethingElseAsync();
yield return item2;
}

таки async/await не везде языком поддерживается

день открытий.
сегодня узнал, что для того, чтобы объект жил в виде ключа для Dictionary<T,V>
правильнее реализовать не метод Equals()
а интерфейс IEquatable<T>
это и рекомендуемый подход (msdn), и не придется переопределять метод GetHashCode()