GotDotNet.Ru: основная лента

302 Redirect (временное перемещение) означает, что страница перемещается на временный адрес. 301 Permanent Redirect (перемещение навсегда) означает, что перенаправление идет на постоянный адрес.

Это важно потому что поисковые системы оценивают временные адреса ниже, чем постоянные. Таким образом, неправильное перемещение может грозить для владельцев сайтов понижением ссылочного веса и, как результат, снижением позиции в поисковой выдаче.

Читать полностью

Программирование

• How works automatic assembly versioning
  Принцип, по которому формируется автоматический номер версии сборки. Оказывается это все-таки особое представление текущего времени и даты.
• Creating x.509 certificates with Pluralsight self-cert
  Создаем self-signed X.509-сертификат программно.
• 60+ .NET libraries every developer should know about.
  Справочник по библиотекам, способным облегчить жизнь .Net-разработчика. Все основные вроде есть.
• System.Uri FAQ
  Неплохой обзор некоторых подводных камней, проявляющихся при работе с классом System.Uri.
• 10 заповедей для программистов
  Как говорится, ППКС.

Сеть

• ASP.NET: UpdatePanel and Master Pages
  Определяем обновление компонента UpdatePanel.
• The Kayak Framework: An easy way to speak HTTP with .NET
  Веб-сервер для ASP.NET. Использование IIS не всегда возможно и оправдано, тут то и вступают в дело небольшие самописные обработчики.
• Improving CSS With .LESS
  Занятные трюки для уменьшения объема CSS-скриптов, что самое приятное, производятся автоматически.
• Redirect from Http to Https in ASP.NET
  Включение SSL только для нужных страниц сайта.
• Discover which Control Raised a PostBack
  Определяем контрол, вызвавший отправку формы.

Базы данных

• SQL SERVER – Performance Comparison – INSERT TOP (N) INTO Table – Using Top with INSERT
  Особенности использования оператора TOP при вставке в базу данных результатов выполнения SELECT-а.
• Multiple Active Result Sets (MARS - ADO.NET 2.0)
  Малоизвестная фича ADO.NET 2.0 и выше – возможность иметь несколько активных запросов для одного соединения бд.

SharePoint

• Threads and Sharepoint
  Немного об особенностях использования потоков в портальных приложениях.

Содержание

• Обновление внебраузерных приложений
• Определение наличия сетевого соединения
• Архитектура внебраузерных приложений
• Отладка внебраузерных приложений
• Совместное использование кода и сборок в Silverlight и .NET

Обновление внебраузерных Silverlight приложений

В платформу Silverlight встроен асинхронный механизм обновления внебраузерных приложений. Разработчик ответственен за то, когда будет проверяться наличие обновлений для его приложения, а загрузка и установка происходят автоматически. Что требуется от разработчика.

1. Загрузить новую версию .xap файла Silverlight приложения на сервер.
2. При запуске внебраузерного приложения или в любой другой момент проверить наличие обновлений.
3. После окончания проверки Silverlight скачает новую версию приложения, которая будет установлена автоматически при следующем запуске. Разработчик может обработать событие окончания проверки и, например, показать пользователю сообщение о необходимости перезапуска приложения.

Давайте добавим возможность обновления в существующее внебраузерное приложение. Откроем C# код страницы App.xaml. И в конструкторе класса «App» подпишемся на событие «CheckAndDownloadUpdateCompleted».

this.CheckAndDownloadUpdateCompleted += 
new CheckAndDownloadUpdateCompletedEventHandler(App_CheckAndDownloadUpdateCompleted);

Данное событие окончания проверки на наличие обновлений в случае успеха срабатывает только после физической закачки новой версии на компьютер пользователя. К сожалению, нет возможности спросить у пользователя, хочет ли он скачивать и устанавливать найденное обновление.

Так как в следующий раз при запуске приложения пользователь уже будет работать с новой его версией, в обработчике события «CheckAndDownloadUpdateCompleted» уведомим пользователя об этом.

На предыдущей неделе, я работал над своим open source проектом WeBlog, я создавал HTTP Handler для обработки изображений. Я начал использовать HTTP Handler для изображений, потому что нуждался в механизме предотвращения дополнительной нагрузке(hotlinking). Единственным минусом в использовании HTTP Handler - уродливые URL адреса.

Читать полностью

Перевод статьи "Use ASP.NET 4 Browser Definitions with ASP.NET 3.5".

Мы обновили файлы определения браузера в ASP.NET 4, теперь они содержат информацию о таких браузерах и устройствах, как Google Chrome и iPhone. Вы можете использовать файлы определения браузера и в более ранних версиях ASP.NET, например в ASP.NET 3.5. Обновленные файлы определения информации и инструкции по установке могут быть найдены тут.

Изменения в файлах определения браузера могут вызвать проблемы обратной совместимости, если вы обновляете ASP.NET 3.5 проект до ASP.NET 4. Если у вас возникли такие проблемы, то у вас есть возможность загрузить старый файлы определения браузера в ASP.NET приложение.

Читать полностью

В ближайших нескольких постах предлагаю ознакомиться с новыми возможностями в WCF 4.0, особенно учитывая, что официальный выход .Net 4.0 запланирован на 12 апреля, т.е. осталось набраться терпения еще всего лишь на 35 дней!

Начнем мы знакомство с такого улучшения как упрощенная конфигурация.

Endpoint по умолчанию – позволяет не прописывать явно в секции <configuration> никаких конечных точек (endpoint).

ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService),
    new Uri("http://localhost/CalculatorService"), 
    new Uri("net.tcp://localhost/CalculatorService"));
serviceHost.Open();

Console.WriteLine("WCF Service is running.");
Console.WriteLine("Press <ENTER> to terminate service.");
Console.ReadLine();

serviceHost.Close();

<configuration>
</configuration>

WCF 4.0 автоматически сформирует конечную точку (endpoint) и присвоит ей соответствующие параметры, в частности, сопоставит схему http c BasicHttpBinding, а net.tcp - c NetTcpBinding. При это файл web.config не содержит никаких настроек, тэг <service> (и его подчиненные тэги - <endpoint>) в нем отсутствует.

Binding/behaivor по умолчанию (nameless behaivor) – позволяют сервису наследовать определенные по умолчанию привязки (binding) и поведения (behaivor), эти привязки и поведения определены на более высоком уровне иерархии (machine.config → rootweb.config → web.config и т.д.), что позволяет так же создавать гибкую иерархическую модель наследования настроек.

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="" maxReceivedMessageSize="9999999">
          <readerQuotas maxArrayLength="9999999"/>
        </binding>
      </basicHttpBinding>      
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

Для того чтобы применить поведение (behaivor) по умолчанию необходимо либо оставить его атрибут name незаполненным, либо пропустить его в определении.

ProtocolMapping – определяет сопоставление привязки (binding) и схемы/протокола (например, HTTP или NET.TCP ), которое применяется по умолчанию. Если обратиться к первому примеру (Endpoint по умолчанию), то имеено за счет ProtocolMapping для cхемы http использовался BasicHttpBinding. ProtocolMapping поддерживает иерархическое определение, т.е. machine.config → rootweb.config → web.config и т.д.. Это позволяется определить сопоставление как глобально, так и локально.

<protocolMapping>
  <add scheme="http" binding="basicHttpBinding"/>
  <add scheme="net.tcp" binding="netTcpBinding"/>
  <add scheme="net.pipe" binding="netNamedPipeBinding"/>
  <add scheme="net.msmq" binding="netMsmqBinding"/>
</protocolMapping>

или

<protocolMapping>
  <add scheme="http" binding="basicHttpBinding"/>
  <add scheme="net.tcp" binding="netTcpBinding"/>
</protocolMapping>
<protocolMapping>
  <clear scheme="http" />
  <add scheme="http" binding="customBinding"
   bindingConfiguration="binaryHttp" />
</protocolMapping>
<bindings>
  <customBinding>
    <binding name="binaryHttp">
      <binaryMessageEncoding/>
      <httpTransport/>
    </binding>
  </customBinding>
</bindings>

Стандартные endpoint (атрибут kind) - позволяет для конечных точек (endpoint) определить набор постоянных значений (значений по умолчанию). Например, конечная точка (endpoint) метаданных всегда реализует контракт IMetadataExchange, тогда как WebHttpEndpoint всегда соответствует определенное поведение (behaivor). Стандартные конечные точки (endpoint) как раз позволяют определить набор значений по умолчанию единожды и далее ссылаться на созданную стандартную конечную точку (endpoint), именованную сущность. Стандартная конечная точка (endpoint) может быть задана на любом уровне иерархии.

<services>
  <service>
    <endpoint isSystemEndpoint="true" kind="udpDiscoveryEndpoint" />
  </service>
</services>
<standardEndpoints>  
  <udpDiscoveryEndpoint>
     <standardEndpoint multicastAddress="soap.udp://239.255.255.250:3702" /> 
  </udpDiscoveryEndpoint>
</ standardEndpoints >

.SVC-less конфигурация – позволяет не создавать отдельно файл .svc для сервиса, а определить соответствие между адресом сервиса и контрактом, который он реализует, на логическом уровне (web.config).

<system.serviceModel>
    <serviceHostingEnvironment>      
      <serviceActivations>
        <add relativeAddress="Calculator.svc" 
         service="CalculatorService"/>
      </serviceActivations>
    </serviceHostingEnvironment>
    <services>
      <service name="CalculatorService">
        <endpoint binding="webHttpBinding"
           contract="ICalculatorService" />        
      </service>
    </services>
</system.serviceModel>

Веб-каст с примерами по обсуждаемым возможностям можно найти на портале TechDays.ru - "WCF 4.0 в примерах. Часть 1.".

Введение

Как Вы, наверное, знаете, Silverlight приложения могут работать не только внутри, но и вне браузера (OOB, Out-of-Browser). При этом внебраузерные Silverlight приложения фактически устанавливаются на компьютер пользователя и запускаются с него, а не по сети, как в случае с традиционными Silverlight приложениями, что позволяет внебраузерным приложениям работать и в условиях отсутствия сетевого соединения. Ярлык такого приложения при установке располагаться в меню «Пуск» и/или на рабочем столе (всё зависит от выбора пользователя), оно отображается в диалоге установки и удаления программ операционной системы наравне с обычными Windows приложениями. Если же внебраузерное приложение ещё и является доверенным (trusted), то оно получает доступ к некоторым ресурсам компьютера за пределами традиционной для Silverlight приложений песочницы (sandbox). Например, доверенное приложение может обращаться к части файловой системы компьютера, а не только к изолированному хранилищу (isolated storage), сетевым ресурсам, не требуя обязательного наличия на сервере файла кросс доменной политики (cross domain policy file), а также доверенное внебраузерное Silverlight приложение может взаимодействовать с COM (Component Object Model) объектами, такими, как, например, объекты автоматизации Microsoft Office. И, конечно же, это далеко не полный список дополнительных возможностей доверенных внебраузерных приложений.

Также стоит сказать, что каждое Silverlight приложение может работать вне браузера, если это явным образом разрешил разработчик, поставив всего одну галочку в свойствах проекта в Visual Studio или написав несколько строк на XML, если Visual Studio по каким-то причинам не используется. Поставить галочку просто, но таким образом нельзя получить всех преимуществ работы вне браузера. Ведь для внебраузерных приложений доступны многие программные интерфейсы (API – Application programming interface), не доступные в браузере. Это и оповещения (notifications), и управление параметрами окна внебраузерного приложения, элементы управления WebBrowser и HTMLBrush, а также широчайшие возможности доверенных внебраузерных приложений, о которых упоминалось выше.

Silverlight клиент для Facebook

Многие web разработчики не любят создавать настольные приложения, в том числе и по причине трудности их обновления. Действительно, если мы имеем web приложение, то в большинстве случаев все пользователи работают с последней его версией. Более того, версия у всех одна и та же. В случае же с настольными приложениями мы получаем трудности не только с их обновлением, но ещё и с их установкой.

Внебраузерные Silverlight приложения – это попытка привнести достоинства web приложений в мир настольных. Silverlight практически полностью берёт на себя заботы по обновлению внебраузерных приложений, и во многих случаях разработчику задумываться об этом почти не надо. Требуется написать буквально одну строчку кода, а дальше всё происходит автоматически. В дополнение к обновлению, установку и удаление внебраузерных приложений также полностью берёт на себя платформа.

Надо отметить, что любые Silverlight приложения, в том числе внебраузерные, одинаково хорошо работают как на Windows, так и на MacOS X. При этом обе платформы официально поддерживаются компанией Microsoft и все возможности внебраузерных приложений доступны на каждой из них. Единственной зависимой от платформы возможностью является взаимодействие с COM объектами, которые присутствуют только в Windows.

Кроме того существует проект Moonlight, который обеспечивает работу Silverlight приложений на операционной системе Linux. Это проект с открытым исходным кодом, разрабатываемый компанией Novell при некоторой поддержке со стороны Microsoft. Наблюдается небольшое отставание Moonlight от официальной версии Silverlight, поэтому, если Вы хотите, чтобы Ваши приложения работали и на Linux тоже, не забудьте их протестировать на совместимость с Moonlight.