Корпорация Microsoft объявила о завершении разработки мобильной операционной системы Windows Phone 7. ОС достигла стадии "готова к производству", ее код больше меняться не будет.

Разработчики заявили, что Windows Phone 7 прошла больше проверок, чем какая-либо из мобильных платформ Microsoft. Так, ежедневно Windows Phone 7 в автоматическом режиме тестировалась на 10 тысячах устройств. Всего на автоматические проверки ушло полмиллиона часов, а на стресс-тесты - три с половиной миллиона.

Кроме того, ОС проверили тысячи независимых разработчиков ПО. Новую платформу поддерживает целый ряд производителей смартфонов, в том числе HTC, LG и Samsung.

Ведущие блога Windows Phone Blog также сообщили, что включили в новую систему более тесную интеграцию с крупнейшей социальной сетью Facebook. ОС будет поддерживать кнопку Like ("Нравится"), а пользователи смогут фильтровать список контактов в соответствии со списком друзей в Facebook.

В конце августа СМИ писали, что запуск Windows Phone 7 обойдется Microsoft в миллиард долларов, причем половина этой суммы придется на маркетинговые расходы. Ожидается, что первые смартфоны под управлением Windows Phone 7 появятся до конца года.

Я очень люблю женский голос, особенно тогда, когда женщина флиртует, заигрывает, хочет мужчину.... это непередаваемое внутреннее ощушение. Девушки, не бойтесь флиртовать. Те у кого получается хорошо флиртовать получают быстрее мужчину ну или его внимание, чем те, кто этого стесняется. Флирт заложен в вас с самого рождения... просто нужно научиться этим правильно пользоваться.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
  Id="DemoHelloWorldButton"
  RegistrationType="List"
  RegistrationId="101"
  Location="CommandUI.Ribbon">
    <CommandUIExtension>
      <CommandUIDefinitions>
        <CommandUIDefinition
         Location="Ribbon.Documents.New.Controls._children">
          <Button
           Idчитать далее...

В Москве снова дождь... ну что такое?

http://www.kedem.ru/calc/cdc/

When developing applications or custom solutions for SharePoint you will on several occasions have to store settings for you application of some kind. When developing database driven or other custom solutions you easily create a database table or make the settings in app/web.config file. You can of course use these approaches when developing for SharePoint, but there are some things to consider when doing this. This post will outline some approaches you can use to store your settings.

What I mean with application or solution settings is some kind of settings that you need for you application to work, such as a Url to a web service or a username and password. These settings are normally only editable by administrators, which requires you to have some security plans, and you need an interface to edit the settings.

Worth to have in mind is that SharePoint can span multiple servers and web applications, it also has the Site Collection and Site scopes which might need different settings if your application runs on several places.

Using a SharePoint List

Creating a database table for storing settings is not the best way in a SharePoint solution - you would use a SharePoint list for this instead. This is the easiest way. Creating a custom list with Title and a Value allows you to store all your settings in one place. There is no need to create a user interface, since you use out-of-the-box functionality and you can secure the list by using permissions on it. The drawback is you need some information (read other setting) that tells you where this list is located, so you're back on square one.

Using web.config

Using web.config is another way to store your settings. It's easy to store information in the appSettings element using a key/value combo. The .NET Framework have built-in functionality to read these settings and SharePoint has some (not so good working) features to deploy the settings in your farm with the SPWebConfigModification class. This approach can only be applied if your settings are web-application wide and you either deploy the settings with the SharePoint object model, which can be quite cumbersome, or manually edit the web.config file on all WFE's.

Create the My Site Web Application

We begin by first creating a Web Application that will eventually house our My Site Host and subsequent site collections.

Navigate to Central Administration / Application Management / Web Applications

Click New

Authentication: Select either Claims or Classic depending on your requirements.  I will select “Classic”

IIS Web Site: Create a new IIS web site (enter your details as per your requirements)

Authentication Provider: Select your preferred provider based on your requirements.

Public URL: Specify the URL that users will type to access their My Sites.

Application Pool: Create a new application pool and give it a descriptive name

As we have been utilizing the least privilege model whilst configuring our SharePoint farm in this series, we will click on Register a new managed account and enter the details for our My Site Application Pool Identity.  Note: This account will be required to be provisioned in Active Directory before you can proceed. e.g. In my example I have created an account called DOMAIN\sp_mysite.

Click OK

читать далее...

One of the coolest types of site column (or field) in SharePoint is the ‘Person or Group’ field type. This allows you to select people from the GAL using a nice little picker control. When users are selected, you benefit from all of the presence capabilities of SharePoint as shown in this screen shot:

I recently had to programmatically add users to one of these ‘person or group’ fields where I only had the Login Name (domain\user) of the user I was adding as an input. It took me a while to work out how to populate a ‘Person or Group’ field from code so I thought I’d share my findings. It is worth noting that my esteemed co-workers Nigel Bridport and Pete Mellish both helped with figuring out the right format for this.

In order to populate these fields, you need a very specific combination of the User ID (see below for how to get this), their full Login Name (domain\user) and some magic characters (;#). The actual formula is as follows

<UserID>;#<UserLoginName>

for example

10;#europe\mkearn

In actual fact, I found that if you are only entering one person, you only need the User ID, but I think it is best to add the alias if you can. If you wish to add multiple people it is the same formula but the different people are separated by ;# as shown below

<UserID1>;#<UserLoginName1>;#<UserID2>;#<UserLoginName2>;#<UserID3>;#<UserLoginName3>

for example

10;#europe\mkearn;#3;#europe\ashleyy;#12europe\johnc

Word of warning ….If you wish to add your ‘Multiple Person or Group’ field via a Feature or Site Definition, there are some key things you need to know about Multiple User fields. See George Bonney’s great article which give you all of the details on how to do this.

So now we have the right formula, how do we actually use it?

The UserID relates to the ID of the user within the site collection. This is fine but the chances are that not all users are members of the site collection. To address this, the SharePoint OM has a handy little method called SPWeb.EnsureUser() which accepts a Login Name of a user as a string and first checks if the user exists in the site collection, if it does not then it adds the user and returns an читать далее...