Visual Studio 2010 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Visual Studio 2010 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

Pazar, Ekim 24, 2010

Visual guide to Windows Live ID authentication with SharePoint 2010 - part 1

Using Windows Live ID as login provider for SharePoint is a really huge thing. It makes the scenario for public facing web sites, extranets etc. much more easier, for instance there is no need to maintain passwords and users in the same degree. For SharePoint 2007 there is no native support for this, so I built a custom Live ID login provider (available at, but SharePoint 2010 has native support for claims based access. And that is what's on the menu for tonight...

This post, and the subsequent ones, will show you how to enable Windows Live ID on a SharePoint 2010 farm (SPF or SPS). I will do a visual approach using a lot of screenshots. It has not been an easy path since there are no official guidance on this subject (at the time of this writing), so I'm going to throw in a couple of steps where you can fail miserably while setting it up. Big thanks to Paul Schaeflein who also walked the hard path and took some hits to get this to work! Although there are a couple of available blog posts out there on this issue, some of the are very sparse on the details (why?) and some even contains faulty instructions. Just to safe up on this - the instructions works on my machines and I've been able to reproduce these steps a number of times. If you have any suggestions or comments, just leave them here and I'll try to (get someone to) answer them...

So what are we waiting for, let's get the party started. I have to warn you - if you don't like certificates - stop reading!


While I will explain more in details as we move along I think it is important to have a little heads up on claims based access and Windows Live ID. First of all (passive) claims based access is based on the simple scenario where a client/user (subject) trying to access a site (also called Relying Party/RP). This RP has distributed the login procedure to one or more trusted parties called Identity Providers (IP). In our case SharePoint is the RP and Live ID is the IP and you of course are the subject. When the subject tries to access the RP, the subject will be redirected to the IP where the actual logon process is taking place. By attaching cookies to the response and redirecting the user back to the RP with a set of (encrypted) claims the RP can finally authenticate the user. For a better understanding I recommend you to read A guide to Claims-based Identity and Access Control.

A little bit of claims

Windows Live ID (WLID) will take care of the login and send back a unique ID to the SharePoint site. This unique ID is the only claim WLID will give you. (Unfortunately you cannot get the correct e-mail address or the name of the user.) SharePoint will first verify the validity of the encrypted security token (containing the claims) before actually starting the AuthN and AuthZ process using the unique ID as username in SharePoint. You will later see how we give access to these unique ID's.

Another important thing to keep in mind is that WLID have two "zones"; INT and PROD. The PROD zone is what you normally use when logging in to Hotmail etc. The INT zone is used for development and testing and have a completely different account database, so you need to have accounts in the INT zone to continue, more about this in a little bit. You cannot skip the INT zone, you have to register your site there first before applying for approval in the PROD zone.

The steps provided here is only for the INT environment. For PROD it is basically the same and the post is long enough as it is...

Registering the site

MSMBefore even starting to configure the SharePoint site we need to register our site for usage with Windows Live ID. This is done using the Microsoft Service Manager web application located at You log in to this service using you normal (PROD) Windows Live ID account.

In the left menu click on Register Your Site (1). This will bring up the Register Your Site page where you should enter the name of your site, use a descriptive name (2) and the DNS Name of your site (3). The DNS Name is important! Here you must specify a DNS Name, which we will later change into a URI, or rather URN. Write something random such as

The DNS Name will be used as a SAML Audience when the security token is sent back and it will be verified by SharePoint. According to the SAML specification the audience must be a URI (a URN or URL). If you use a URL then WLID will for some reason remove the protocol from the audience when sending it back to the RP and SharePoint will throw an exception ([InvalidOperationException: This operation is not supported for a relative URI.] System.Uri.GetLeftPart(UriPartial part)). This might change in the future.

Finally you have to specify that you will use Windows Live ID (4). Click Submit to continue.


You will get a confirmation screen. Click Yes to confirm and proceed to the next step

MSM Confirmation

After a few seconds you will be presented with the results. If anything goes wrong you need to go back and edit your registration accordingly - but it shouldn't if you followed these steps.


Click on the Go to Manage Your Site link. In the drop-down (1) select the site that you just registered and then click on the Modify Editable Site Properties link (2).

Manage your site

The next screen allows you to edit the properties of the site. First of all check the Show advanced properties check box to enable more options.

Advanced stuff ahead...

First we need to rename the Domain name (1) and set our real domain name to use. Then we need to replace the dummy DNS name (2) with a URN, in this case I use urn:wictorslivesite:int. Remember not to specify a URL, it just won't work as of now. The third thing to edit is the Default Return Url (3); this must be an HTTPS url pointing to the /_trust/default.aspx page, for instance https://extranet.corp.local/_trust/default.aspx. This is the URL that the IP will post back the results to. Finally we have to edit the Expire Cookie URL (4). Just fix the URL and never mind the actual page (you can implement such a page if you feel to at a later time).

Options, options, options...

Then scroll down a bit on the page until you reach Override Authentication Policy, this step is crucial. Select MBI_FED_SSL in the drop-down. And when you're done click Submit (at the top of the page).


Verify and confirm your changes by clicking Yes on the next screen. Take a screenshot and/or notes all these changes.

Confirmation again

That's it. Your site is now configured. Actually you can configure a bunch of more features here - but stick to these as of now...


Let's move on to the SharePoint Server.


Claims based authentication uses certificates for encryption and signing and you have to trust the certificate of the IP on your SharePoint servers. The following steps must be done on all WFE's in the farm.

To get the IP certificate; browse to federation metadata URL: (this is for the INT zone). Then copy the inner text from the first X509Certificate node. Open up the Notepad application and paste the text and then save the file as LiveID-INT.cer. Make sure that you only get the inner text of the element.

XML en masse

Now you have the certificate in a file and you need to import it to the correct locations on the SharePoint Server(s). It is actually required to be stored locally on three different locations. Open mmc.exe and add the Certificates snap-in. When you select to add it you must first select to use the Computer Account to manage the accounts for and select to use the Local computer as computer to manage.

Expand the tree until you reach SharePoint > Certificates then right-click on the node and Select All Tasks > Import...


In the import wizard that appears locate the LiveID-INT.cer file you just created and then click Next > Next > Finish. That's the first one.

Repeat this procedure for the Trusted Root Certification Authority and Trusted People. Don't worry if you don't have a Certificates sub-node. It will be created when you import the certificate.

Even more certificates

Now we're one step closer and it is time to get dirty with some PowerShell. You could of course have done this step using PowerShell, but I leave that for another crafty blogger to show how... Just remember to do this on all WFE's!

Create the STS provider

To create the Trusted Identity Token Issuer, that we will use to configure as the login provider for the Web Applications, we fire up PowerShell. This step will not be that "visual" as the previous ones, since none of these commands can be run using the standard SharePoint user interface. I guess it's just a matter of time until someone makes a neat add-on with these simple commands...

I'll give you the script first and then explains all the involved steps:

1: asnp microsoft.sharepoint.powershell
2: $realm = "urn:wictorslivesite:int"
3: $certfile = "C:\Temp\LiveID-INT.cer"
4: $rootcert = Get-PfxCertificate $certfile
5: New-SPTrustedRootAuthority "Live ID INT Root Authority" -Certificate $rootcert
6: $emailclaim = New-SPClaimTypeMapping
-IncomingClaimType ""
-IncomingClaimTypeDisplayName ""
7: $upnclaim = New-SPClaimTypeMapping
-IncomingClaimType "
-IncomingClaimTypeDisplayName "UPN"
-LocalClaimType ""
8: $authp = New-SPTrustedIdentityTokenIssuer -Name "LiveID INT"
-Description "LiveID INT" -Realm $realm -ImportTrustCertificate $certfile
-ClaimsMappings $emailclaim,$upnclaim -SignInUrl "
-IdentifierClaim "

The first line just loads the SharePoint PowerShell Snapin (1), asnp is a shortcut for Add-PSSnapin and saves you a cpl of keystrokes. Then we set three local properties; realm corresponds to the DNS Name (that is the URN), certfile points to the location where you saved the LiveID-INT.cer file and the rootcert is the certificate loaded in as an object.

Make sure not to make any typos in the claims URN's - been there, done that!

Then we add the certificate to a SharePoint trusted Root Authority, using the New-SPTrustedRootAuthority cmdlet. You can verify that it is correctly imported by going to Central Adminitration > Security > Manage Trust:

Trusts in SharePoint

Then we need to create two claims mappings; one for e-mail (line 6) and one for the identifier (line 7). The claim mappings defines how the incoming claims are mapped to the SharePoint tokens. These two claims are then sent into the New-SPTrustedIdentityProvider cmdlet (line 8) and here is where the magic happens. This cmdlet creates a new trusted identity provider with a name and description, we instruct it which claims mappings to use and which claim is the identifier claim. We are also specifying the URL for the WLID (INT zone) login page.

Once these commands are executed, we are ready to head on over to the UI and create a Web Application. By all means, if you prefer to do the rest using PowerShell, feel free to do it.

If you are fiddling back and forwards using different registered Live ID services, you can switch the Realm using the DefaultProviderRealm property of the Trusted Identity Provider object (authp). Don't forget to call Update() on the object... You can only have one provider for each service, even if the realms differ.

Create the Web Application

Fire up Central Administration and go to Application Management > Manage web applications. Click New to create a new Web Application.

First of all you need to select to use Claims Based Authentication. Then enter a Name for your web application, use the port 443 (SSL) and (in this case) configure the host header to match the domain name that you entered while registering the WLID service. Just standard stuff so far.

Create the web application

Under Security Configuration make sure that you select Use Secure Sockets Layer (SSL).

SSL settings

Under Claims Authentication Types leave Windows Authentication enabled if you like, but make sure to check Trusted Identity Provider checkbox and then check the LiveID INT provider, the one we created using PowerShell.


Once done click OK to create the Web Application.

We're almost there just a few steps more...

Create the Site Collection

Once the Web Application is created you can directly click on the Create Site Collection link. Enter name and description for the site, and also specify which template to use.

Now it is time to give some permissions to this site collection. Assume that we did not select any Windows Authentication when creating the Web Application, then we can only add Live ID users, right?

If you don't have a WLID account in the INT domain it is time to get one now. Open up a new browser window. Go to and sign up for a new account or sign in using one of your existing INT accounts. (Stability of the INT domains are not 100% :-). When you have signed up or logged in click on Credentials and then View your unique ID.


You will now see a screen with your unique ID; write it down, copy it or remember it...

Magin number

Close the browser and return to the Central Administration where you started creating a Site Collection. Now paste or write this unique ID and append in the Primary Site Collection Administrator. But, make sure to convert all characters to lowercase, otherwise you will not be able to log in later:

Magic number becomes an admin

Then click OK to create the Site Collection.

Final configurations

Before browsing to the site we need to make some final adjustment in the IIS. To be precise we will add a certificate to the site. You can use a certificate that you have acquired for your site or when testing just use a Self-Signed, which I will show you here.

To create a Self-Signed certificate start the IIS Manager and select the server. In the Features View double-click the Server Certificates module.

Ouch, more certificates

Then click Create Self-Signed Certificate in the Actions bar to the right and follow the instructions. Mostly next-next-finish.

I'll make one myself

The final configuration is to use this certificate on the Web Application. Choose the Web Application you created in SharePoint in the IIS Manager (1), then click on Bindings (2), select to edit the only binding you have (3) and choose the SSL certificate you just created in the drop-down (4). Click OK and close everything down.

Advanced stuff

That's it! Let's see how it behaves...

Taking it for a test drive

Now open up a web browser and go to the web application you have created using the domain name you specified when creating it, make sure to use https. You should see the standard warning in the browser that the certificate is not valid (add it as trusted if you want to skip this warning in the future), otherwise just click the continue link.

Bump, we just hit a certificate again...

If you have several authentication providers you will see the new SharePoint 2010 Sign In screen with a drop-down where you can choose the authentication provider you would like to use to log in with. If you only have one, in this case the WLID, you will be redirected to the WLID Log In screen - the same will happen if you select LiveID in the drop-down.

Signing in...

If you get an error stating We're unable to complete your request, like below, you most certainly have not used the correct Realm when creating the trusted identity provider using PowerShell. Make sure that the Realm and the DNS Name in the Live ID Service Manager are exactly the same, case sensitive and all.

Ooops, you made a mistake!

The Windows Live ID sign in screen should look as expected, just the same as logging in to other Live ID services. Enter your INT username and password (remember this is still the INT zone).

We're getting there

If you remembered your username and password correctly you will very soon see the beautiful SharePoint 2010 scenery:

Ahhh. So beatiful!

Note that your username and display name will be exactly the same as the unique id you have for that user. How to fix this is scheduled for a later post :)

Next steps

So, there you have it. It's a handful of steps to complete and you have to make sure not to mistype anything. I will continue this series with some more info that could be of great use when setting this up - hopefully not as long as this one though...

Çarşamba, Eylül 01, 2010

SharePoint 2010 - Error occurred in deployment step ‘Recycle IIS Application Pool’

SharePoint 2010 icin Visual Studio 2010 uzerinde uygulama gelistirip deploy ettiginizde bazi guvenlik ve erisim hatalari alabiliyorsunuz. Bunlardan en belirgini ise asagidaki olandir.


Error occurred in deployment step ‘Recycle IIS Application Pool’: <nativehr>0×80070005</nativehr><nativestack></nativestack>Access denied


Cozumu ise oldukca basittir. Gelistirme yapmis oldugunuz kullaniciyi site collection administrator grubuna eklemis olmaniz gerekir. Sonrasinda sisteminizi logoff/logon (eger imkaniniz yoksa ayarlar 15 dakika sonra kendisini aktiflestirir) yaparak kullanabilirsiniz.


Ayrica gelistirme yaparken Visual Studio ‘yu Administrator olarak acmayi unutmayin!!!


Iyi gunler…

Cumartesi, Ağustos 14, 2010

SharePoint 2010 – Custom MasterPage ile Yönetilebilir Kod Kullanımı

MasterPage kavramı Asp.Net tabanlı geliştirilen orta ve büyük çaplı uygualamaların olmazsa olmazları arasında yer almaktadır. En büyük faydası ise web sayfası içerisinde 5-10 veya daha fazla sayfada kullanılacak olan tasarımın tekrar tekrar sayfaların markup kod kısmına eklenmesi yerine ortak bir şablon üzerinde alarak devam edilmesinin en doğru yol olduğu kavramı ile birleşerek bu sayfalar için taban şablon olarak kullanılmaktadır. Ayrıca tasarım öğeleri dışında arka plan kullanabileceğimiz CSharp ve VB.Net dillerini de kullanarak programatik anlamda da işlemler yapabilinmesi mümkündür. Tabii bu işlemleri uygulama geliştiricilerin tercih etmesinin başlıca sebebi ise bu tekniğin kolay olması ve kullanım rahatlığından kaynaklanmaktadır. Bu tür kolaylıklar yer alırken bu güzel özelliğin SharePoint içerisinde olmamasını beklemek belki de yapılabilecek en büyük yanılgılardan biri olacaktır. Peki aramızda daha önceden SharePoint ile uygulama geliştiren varsa bu işlem SharePoint 2007 de sadece SharePoint Designer (SPD) ile yapabilmekte ve kod ile işlem yapmak istediğimizde bayaa fazla tefarruatlı işlem yapmak gerekirdi. Bu işlemlerde SharePoint development işleminin en zor işlemlerinden biri olarak gösterilirdi. Şimdi geçmiş zamana laf atarak birşeyler yazdığıma göre 2010 sürümünde işlerin çok kolaylaştığını ve hadi hop hemen yapabileceğimi söyleyeceğimi düşünüyorsanız maalesef yanılıyorsunuz. Hala zor bir işlemdir. Ancak dökümante edilmesi ve kolay bulunması amacıyla bu yazımızda arka plan kod yardımı harici masterpage ‘I nasıl portal içerisinde kullanabileceğimizi incelemeye çalışacağız. Aslında makalenin başlığı ingilizce olmalıydı. Çünkü bu tanım yapacak olduğumuz işi daha net açıklamaktadır. SharePoint 2010 – Custom MasterPage Wıth Behind Code daha anlaşılır değil mi? Smile


MasterPage ‘I kod yardımı ile bize özel duruma getirmek için yine bir masterPage ‘e ihtiyacımzı olacaktır. Ayrıca SharePoint ile uygulama geliştiricen yazılımcılar (Yazılımcılar SharePoint Designer ‘I nedense pek sevmezlerde Smile ) SPD uygulamasını sevmeleri gerekmektedir. Çünkü her ne kadar işlemlerimizi Visual Studio 2010 üzerinde yapacak olsakta MasterPage üzerindeki tasarımsal işlemlerimizi design kısmını da görebildiğimiz için SPD üzerinde yapıyor olacağız. Yazıya başlamadan önce üzerinde değişiklik yapacağımız MasterPage ‘I hazırlamamız ya da bulmamız gerekecektir. Ben bu tür geliştirdiğim uygulamalar için SharePoint Server MVP ‘si Randy Drisgill ‘in hazırlamış olduğu Starter MasterPage I kullanıyorum. Burada gereksiz stil öğelerinden temizlenmiş MasterPage tasarımları bulunmaktadır. Üzerine işlem yapmak için oldukça yararlı bir kaynaktır.


Uygulama geliştirmeye başlamadan önce kullanacak olduğumuz MasterPage ‘I Portal sayfasının masterPage ve Page Layout larının yer aldığı Document Library ‘e eklemek gerekmektedir. Bu lokasyonu bulabilmek için Portal sayfasının üzerinde sol kısımda yer alan Sıte Actions seçeneğin Site Settings kısmına tıklıyor sonrasında karşımıza çıkan ekranda ise Galleries kısmında MasterPage olan bölümü seçerek listeyi açıyoruz. Sonrasında kullanacak olduğumuz MasterPage ‘I bu kısma ekliyoruz.




Artık uygulama geliştirmeye hazırız. Vısual Studio 2010 içerisinde Empty SharePoint Project şeması ile projeyi oluşturuyoruz.




Bir sonraki adımda geliştirecek olduğumuz uygulamanın hangi Portal üzerinde ve hangi düzeyde Deploy olacağınız sormaktadır. Biz bu kısımda Farm seçeneğini seçerek devam ediyoruz.



MasterPage ‘I kullanabilmek için projeye Module şemasını eklemek gerekecektir. Bunun için Projenin klasörünün üstüne sağ tıklama yardımı ile Add New Item seçeneğine gidiyoruz.



Açılan ekrandan içerisine MasterPage ‘I de ekleyecek olduğumuz Module şablonunu ekliyoruz.



Bu işlem sonrasında MaterPageModule ‘ün içerisine indirmiş olduğunuz _starter.master dosyasını ekliyoruz. Sonrasında ise Elements.xml dosyasının içeriğini aşağıdaki son haline getiriyoruz.


<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="">
  <Module Name="MasterPageModule" Url ="_catalogs/masterpage">
  <File Path="MasterPageModule\_starter.master" 
Url="MasterPageModule/_starter.master" />

Sırada yapmamız gereken işlem Projeye Feature eklemek olacaktır. Bunun için Features öğesinin üzerine sağ tıklama yaparak Add Features seçeneğine tıklıyoruz. (Otomatik olarak eklenmiş olma ihtimali de bulunmaktadır.)


Sonrasında Features içerisinde yer alan Itemslara göz atıyoruz.



Items yer almadığı için ve bize lazım olan Eventleri kullanmak olduğundan Feature1 ‘ın üzerinde sağ tıklama yardımı ile Add Event Receiver seçeneğini seçerek adımlara devam ediyoruz.



Bu işlem sonrasında Feature1.EventReceiver.cs isimli kod parçası oluştu. Bu kod parçasında yer alan comment ‘li metodlardan FeatureActivate ve FeatureDeactivating commentlerini kaldırıyoruz.


Metodları hazırlamış olduğumuz Feature ‘ın aktifleştiği anlarda ve tekrar kaldırıldığı zamanlarda yapacak olduğu işlemleri kontrol etmek amacıyla kullanıyor olacağız. Aktif duruma geldiğinde bizim hazırlamış olduğumuz harici masterPage pasif duruma geçtiğinde ise masterPage havuzunda yer alan herhangi bir masterPage I kullanıyor olarak ayarlıyoruz. pasif zamanlarda kullanacak olduğu MasterPage ‘I Adventure Works için hazırlanmış olan nightandday.master ‘I kullanıyoruz. 

public override void FeatureActivated(SPFeatureReceiverProperties properties)
    SPWeb currentWeb = (SPWeb)properties.Feature.Parent;

    currentWeb.MasterUrl = "/_catalogs/masterpage/_starter.master";
    currentWeb.CustomMasterUrl = "/_catalogs/masterpage/_starter.master";

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
    SPWeb currentWeb = (SPWeb)properties.Feature.Parent;

    currentWeb.MasterUrl = "/_catalogs/masterpage/nightandday.master";
    currentWeb.CustomMasterUrl = "/_catalogs/masterpage/nightandday.master";

Yapmış olduğumuz işlemler sonrasında ilk etapta projeyi deploy edip bir göz atalım bakalım. Biz Feature ‘ı aktifleştirdiğimizde gerçekten seçmiş olduğumuz masterpage varsayılan tasarım oluyor mu?



Kod yardımı ile MasterPage aktifleştirme işlemi başarılı olmuş gibi görünüyor. Şimdi ki adımımız ise masterPage üzerine Web.UI bileşenlerinden ekleyip bunların event v.b. değerlerini kullanmak olacaktır. Bu sebeple projeye Add Reference… yardımı ile System.Web.dll Microsoft.Sharepoint.Publishing.dll ‘ini ekliyoruz.





Referans ekleme işlemlerini tamamladıktan sonra MasterPage üzerinde bir kaç web kontrolü ekliyoruz. Bunun için SPD 2010 üzerinden MasterPage tabına tıklayarak karşımıza gelen MasterPage ‘ler arasından _starter.master I seçip içerisine Label ve Button kontrolü ekliyoruz.



_starter.master ‘a aşağıdaki kod parçalarını ekliyoruz.

<div id="divRibbonContainer" runat="server">

    <asp:Label runat="server" Text="Label" id="Label1"></asp:Label>

    <br />

     <asp:Button runat="server" Text="Button" id="Button1"></asp:Button>


MasterPageModule ‘un üzerinde sağ tıklama yaptıktan sonra yeni bir class file ekliyoruz ve içeriğini aşadağıdaki şekilde güncelliyoruz.



using System;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace MasterPageWithCodeBehind.MasterPageModule
    public class _starter : MasterPage
        protected System.Web.UI.HtmlControls.HtmlGenericControl divRibbonContainer;
        protected Label Label1;
        protected Button button1;

        protected void Page_Load(object sender, EventArgs e)
            divRibbonContainer.Visible = true;
            Label1.Text = "Hello World!";

            button1.Click += new EventHandler(button1_Click);

        void button1_Click(object sender, EventArgs e)
            Label1.Text = "Gidiyorum ben baska sayfaya";

Bu değişikliği de yaptıktan sonra artık uygulamayı derleyip projenin dll ‘ini oluşturabiliriz. Şimdi bu adımları gördükten sonra o kadar zor bir adım yokmuş ki şeklinde aklınızca cümleler uçuşuyor olabilir. Ancak maalesef bu teknik behind code da yapılan işlemlerin çalışması için yeterli değildir. Ilk olarak oluşturulan dll için PublicTokenKey oluşturup sonra bu token yardımı ile dll ‘I masterpage ‘e inherit etmek gerekecektir.


PublicTokenKey almak için dll ‘in bulunduğu yol ve sn.exe –Tp komutunu Vısual Studio Command Prompt üzerinde çalıştırmak gerekecektir.



Publıc Token Key ‘I aldıktan sonra şimdi oluşan dll ‘I MasterPage ‘e inherit etmemiz gerekmektedir. Bu işlem için alışık olduğumuz inherit işlemini uyguluyor olacağız.


<%@ Master language="C#" Inherits="" %>


Inherits özelliğini değerini ise aşağıdaki şekilde belirliyoruz.


MasterPageWithCodeBehind.MasterPageModule._starter, MasterPageWithCodeBehind, Version=, Culture=neutral, PublicKeyToken=db08a6e4fe0a07ee


Son olarak MasterPage ‘in inherit kısmı aşağıdaki gibi olacaktır.


<%@ Master language="C#" Inherits="MasterPageWithCodeBehind.MasterPageModule._starter, MasterPageWithCodeBehind, Version=, Culture=neutral, PublicKeyToken=db08a6e4fe0a07ee" %>


Bu işlem sonrasında artık projeyi deploy edip tekrar sonucu görebiliriz.



Sayfayı görüntülemek istediğimizde bize kullandığımız yöntemin güvenli olmadığı şekilde bir hata verdi. Bunun neden olduğunu kısaca açıklamak gerekirse, web uygulamaları geliştirirken IIS server varsayılan olan Inherits olarak kullanılan dosyaların DLL değil CS ya da VB kod olmasını beklemektedir. Bu iki değer dışında kullanılan bütün kod parçalarını ise sisteme zarar verebilecek tehtit olarak algılar ve çalışmasını engeller. Peki bizim yapmamız gereken nedir? SharePoint portalın web.config dosyasında yer alan SafeControl listesine bizim oluşturmuş olduğumuz dll ‘I eklemek olacaktır.


SharePoint portalin web.config ‘inin olduğu dosyaya erişmek için

C:\inetpub\wwwroot\wss\VirtualDirectories\80 yolunu kullanabilirsiniz. Web.config içerisine ekleyecek olduğumuz kod parçası ise aşağıdaki gibi olacaktır.


<SafeControl Assembly="MasterPageWithCodeBehind, Version=, Culture=neutral, PublicKeyToken=db08a6e4fe0a07ee" Namespace="MasterPageWithCodeBehind.MasterPageModule" TypeName="_starter" Safe="True" AllowRemoteDesigner="true" />


Değişikliği yapıp tekrar sayfayı çalıştırdığımızda yapmış olduğumuz değişikliklerin sorunsuzca çalıştığını gözlemlemiş oluruz.




Sonuç olarak bu yazımızda SharePoint ‘in ileri sevviye konularından biri olan kod yardımı ile CustomMaster page ‘I düzenleme ve üzerinden işlem yapma konusunu incelemeye çalıştık.


Umarım yararlı olmuştur.

Salı, Temmuz 13, 2010

Microsoft® Visual Studio® 2010 Professional Türkçe Dil Paketi

Microsoft® Visual Studio® 2010 Professional Türkçe Dil Paketi

Dil Paketi, Microsoft® Visual Studio® 2010 Professional İngilizce sürümü için bir eklentidir ve anadilinizdeki çoğu kullanıcı arabirimini görmenize olanak tanır.  Aynı zamanda sadece F1 tuşuna basarak MSDN’de Visual Studio® 2010 ve .NET Framework 4.0 için olan yerelleştirilmiş çevrimiçi yardım belgelerine erişebilirsiniz.  Bunun yanı sıra karşıdan yükleyip çevrimdışı erişime sahip olabilirsiniz. Şimdi karşıdan yükle

Salı, Mayıs 11, 2010

Visual Studio 2010 – Proje Pinlemek

Visual Studio 2010 ve Windows 7 üzerinde sıklıkla kullanılan projeleri, uygulama dosyalarını ya da kod bloklarını pinleyerek çok daha basit bir şekilde erişilebilmesine olanak vardır. Daha önceleri en son açılan projeler listesinde yer alanlar arasında istediğimiz proje var ise işimiz kolay oluyordu. Ancak eğer ki o liste açık değilse projenin kaydedildiği yeri bulup projeyi açmak gerekecekti. İşte bu tür zaman kayıtlarını engellemek için sık kullanılan projelerin pinlenebilmesi mümkündür.

İlk olarak Windows 7 ile başlangıç çubuğunda yer alan ikon yardımı ile pinleme işleminin nasıl yapılacağına göz atalım. Bu listede yer alan Visual Studio 2010 ikonunun üzerine sağ tıklama yaptığımızda en son açtığımız projeler bize listelenmektedir. Bu listeleme görüntüsüne JumpList deniyor. Jumplist ‘te yer alan projelerin üzerine geldiğimizde pinleme yapabilmek için ufak bir ikon gözüküyor.


Sağ tarafta yer alan pin ikonuna tıkladıktan sonra ise Recent bölümünün üstüne bir alan daha açılacak ve pinlenen projeler & uygulamalar görüntüleniyor olacaktır.


Windows 7 JumpList yardımı ile yapabileceğimiz bu işlemi Visual Studio 2010 üzerinden de son açılan projeler ekranından yapılabilmesi mümkündür.


Projeyi pinledikten sonra ne kadar fazla proje eklersek ekleyelim seçtiğimiz hep orada kalmaya devam edecektir.

Bu yazımızda basitçe Visual Studio 2010 ile kullandığımız projeleri nasıl pinleyerek daha rahat kullanabileceğimize değinmeye çalıştık.

Kolay gelsin.