Aracılığıyla paylaş

Hizmet Sözleşmeleri Tasarlama

Bu konu başlığı altında hangi hizmet sözleşmelerinin olduğu, bunların nasıl tanımlandığı, hangi işlemlerin kullanılabilir olduğu (ve temel alınan ileti alışverişlerinin etkileri), hangi veri türlerinin kullanıldığı ve senaryonuzun gereksinimlerini karşılayan işlemler tasarlamanıza yardımcı olan diğer sorunlar açıklanmaktadır.

Hizmet Sözleşmesi Oluşturma

Hizmetler bir dizi işlemi kullanıma sunar. Windows Communication Foundation (WCF) uygulamalarında, bir yöntem oluşturup özniteliğiyle OperationContractAttribute işaretleyerek işlemleri tanımlayın. Ardından, bir hizmet sözleşmesi oluşturmak için, işlemlerinizi öznitelikle işaretlenmiş bir arabirim içinde bildirerek veya aynı öznitelikle ServiceContractAttribute işaretlenmiş bir sınıfta tanımlayarak gruplandırın. (Temel bir örnek için bkz . Nasıl yapılır: Hizmet Sözleşmesi Tanımlama.)

Özniteliği olmayan OperationContractAttribute yöntemler hizmet işlemleri değildir ve WCF hizmetleri tarafından kullanıma sunulmaz.

Bu konuda, bir hizmet sözleşmesi tasarlarken aşağıdaki karar noktaları açıklanmaktadır:

  • Sınıfların veya arabirimlerin kullanılıp kullanılmaymayacağı.

  • Değiştirmek istediğiniz veri türlerini belirtme.

  • Kullanabileceğiniz değişim modelleri türleri.

  • Açık güvenlik gereksinimlerini sözleşmenin bir parçası yapıp yapamayacağınız.

  • İşlem girişleri ve çıkışları için kısıtlamalar.

Sınıflar veya Arabirimler

Hem sınıflar hem de arabirimler bir işlevsellik grubunu temsil eder ve bu nedenle her ikisi de WCF hizmet sözleşmesi tanımlamak için kullanılabilir. Ancak, doğrudan hizmet sözleşmelerini modellediğinden arabirimleri kullanmanız önerilir. Uygulama olmadan, arabirimler belirli imzalara sahip bir yöntem grubu tanımlamaktan başka bir şey yapmaz. Bir hizmet sözleşmesi arabirimi uygulayın ve bir WCF hizmeti uyguladınız.

Yönetilen arabirimlerin tüm avantajları hizmet sözleşmesi arabirimleri için geçerlidir:

  • Hizmet sözleşmesi arabirimleri, herhangi bir sayıda diğer hizmet sözleşmesi arabirimini genişletebilir.

  • Tek bir sınıf, bu hizmet sözleşmesi arabirimlerini uygulayarak herhangi bir sayıda hizmet sözleşmesi uygulayabilir.

  • Hizmet sözleşmesi aynı kalırken arabirim uygulamasını değiştirerek hizmet sözleşmesinin uygulamasını değiştirebilirsiniz.

  • Eski arabirimi ve yenisini uygulayarak hizmetinizin sürümünü oluşturabilirsiniz. Eski istemciler özgün sürüme bağlanırken, daha yeni istemciler daha yeni sürüme bağlanabilir.

Uyarı

Diğer hizmet sözleşmesi arabirimlerinden devralırken, ad veya ad alanı gibi işlem özelliklerini geçersiz kılamazsınız. Bunu yapmaya çalışırsanız, geçerli hizmet sözleşmesinde yeni bir işlem oluşturursunuz.

Hizmet sözleşmesi oluşturmak için arabirim kullanma örneği için bkz . Nasıl yapılır: Sözleşme Arabirimi ile Hizmet Oluşturma.

Ancak, bir hizmet sözleşmesi tanımlamak ve bu sözleşmeyi aynı anda uygulamak için bir sınıf kullanabilirsiniz. Sınıfa ServiceContractAttribute ve sınıf üzerindeki yöntemlere doğrudan OperationContractAttribute uygulayarak hizmetlerinizi oluşturmanın avantajı, hız ve basitliktir. Dezavantajları, yönetilen sınıfların birden çok devralmayı desteklememesi ve sonuç olarak aynı anda yalnızca bir hizmet sözleşmesi uygulayabilmesidir. Ayrıca, sınıf veya yöntem imzalarında yapılan tüm değişiklikler, bu hizmetin genel sözleşmesini değiştirir ve bu da değiştirilmemiş istemcilerin hizmetinizi kullanmasını engelleyebilir. Daha fazla bilgi için bkz. Hizmet Sözleşmelerini Uygulama.

Hizmet sözleşmesi oluşturmak için sınıf kullanan ve aynı anda uygulayan bir örnek için bkz . Nasıl yapılır: Sözleşme Sınıfı ile Hizmet Oluşturma.

Bu noktada, bir arabirim kullanarak ve bir sınıf kullanarak hizmet sözleşmenizi tanımlama arasındaki farkı anlamanız gerekir. Bir sonraki adım, bir hizmet ile istemcileri arasında hangi verilerin ileri geri geçirilebileceğine karar vermektir.

Parametreler ve Dönüş Değerleri

Bunlar olsa bile her işlemin bir dönüş değeri ve parametresi vardır void. Ancak, bir nesneden diğerine başvurular geçirebileceğiniz yerel bir yöntemden farklı olarak, hizmet işlemleri nesnelere başvuru geçirmez. Bunun yerine, nesnelerin kopyalarını aktarırlar.

Bir parametrede veya dönüş değerinde kullanılan her türün serileştirilebilir olması gerektiğinden bu önemlidir; başka bir ifadeyle, bu tür bir nesneyi bayt akışına ve bayt akışından bir nesneye dönüştürmek mümkün olmalıdır.

.NET Framework'teki birçok tür gibi ilkel türler varsayılan olarak seri hale getirilebilir.

Uyarı

İşlem imzasında parametre isimlerinin değeri sözleşmenin bir parçasıdır ve büyük/küçük harfe duyarlıdır. Aynı parametre adını yerel olarak kullanmak ancak yayımlanan meta verilerdeki adı değiştirmek istiyorsanız, bkz System.ServiceModel.MessageParameterAttribute. .

Veri Sözleşmeleri

Windows Communication Foundation (WCF) uygulamaları gibi hizmet odaklı uygulamalar, hem Microsoft hem de Microsoft dışı platformlarda mümkün olan en fazla sayıda istemci uygulamasıyla birlikte çalışacak şekilde tasarlanmıştır. Tam olarak birlikte çalışabilirlik sağlamak için, türlerinizi DataContractAttribute ve DataMemberAttribute öznitelikleriyle işaretlemeniz önerilir. Bu, hizmet operasyonlarınızın değiş tokuş ettiği verileri açıklayan bölüm olan veri sözleşmesini oluşturmaya yöneliktir.

Veri sözleşmeleri kabul stili sözleşmelerdir: Veri sözleşmesi özniteliğini açıkça uygulamadığınız sürece hiçbir tür veya veri üyesi serileştirilemez. Veri sözleşmeleri yönetilen kodun erişim kapsamıyla ilişkili değildir: Özel veri üyeleri seri hale getirilebilir ve genel erişim için başka bir yere gönderilebilir. (Veri sözleşmesinin temel bir örneği için bkz . Nasıl yapılır: Sınıf veya Yapı için Temel Veri Sözleşmesi Oluşturma.) WCF, işlemin işlevselliğini sağlayan temel SOAP iletilerinin tanımını ve veri türlerinizin iletilerin gövdesine ve dışına seri hale getirilmesini sağlar. Veri türleriniz serileştirilebilir olduğu sürece, işlemlerinizi tasarlarken temel alınan ileti değişimi altyapısını düşünmeniz gerekmez.

Tipik WCF uygulaması, işlemler için veri sözleşmeleri oluştururken DataContractAttribute ve DataMemberAttribute özniteliklerini kullanıyor olsa da, başka serileştirme mekanizmalarını da kullanabilirsiniz. Standart ISerializable, SerializableAttributeve IXmlSerializable mekanizmalarının tümü, veri türlerinizi bir uygulamadan diğerine taşıyan temel SOAP iletilerine serileştirmeyi işlemek için çalışır. Veri türleriniz özel destek gerektiriyorsa daha fazla serileştirme stratejisi kullanabilirsiniz. WCF uygulamalarında veri türlerini serileştirme seçenekleri hakkında daha fazla bilgi için bkz. Hizmet Sözleşmelerinde Veri AktarımıNı Belirtme.

Parametreleri ve Dönüş Değerlerini İleti Değişimleriyle Eşleme

Hizmet işlemleri, uygulamanın belirli standart güvenlik, işlem ve oturumla ilgili özellikleri desteklemek için gerektirdiği verilere ek olarak, uygulama verilerini ileri geri aktaran soap iletilerinin temel değişimiyle desteklenir. Bu durumdan dolayı, bir hizmet işleminin imzası, veri aktarımını ve bir işlemin gerektirdiği özellikleri destekleyebilecek belirli bir temel alınan ileti değişimi desenini (MEP) belirler. WCF programlama modelinde üç desen belirtebilirsiniz: istek/yanıt, tek yönlü ve çift yönlü ileti desenleri.

İstek/Yanıtla

İstek/yanıt deseni, istek gönderenin (istemci uygulaması) isteğin bağıntılı olduğu bir yanıt aldığı düzendir. Bir veya daha fazla parametrenin işleme geçirildiği ve dönüş değerinin çağırana geri geçirildiği bir işlemi desteklediğinden, bu varsayılan MEP'dir. Örneğin, aşağıdaki C# kod örneği bir dize alıp bir dize döndüren temel bir hizmet işlemini gösterir.

[OperationContractAttribute]
string Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute()>
Function Hello (ByVal greeting As String) As String

Bu işlem imzası, temel alınan ileti değişimi biçimini belirler. Hiçbir bağıntı yoksa, WCF dönüş değerinin hedeflendiği işlemi belirleyemez.

Farklı bir temel ileti deseni belirtmediğiniz sürece, void (Nothing Visual Basic'te) döndüren hizmet işlemlerinin bile istek/yanıt mesaj alışverişi olduğunu unutmayın. İşleminizin sonucu, bir istemci işlemi zaman uyumsuz olarak çağırmadığı sürece, istemci normal durumda boş olsa bile dönüş iletisi alınana kadar işlemeyi durdurur. Aşağıdaki C# kod örneği, istemci yanıt olarak boş bir ileti alıncaya kadar döndürülmeyen bir işlemi gösterir.

[OperationContractAttribute]
void Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute()>
Sub Hello (ByVal greeting As String)

Önceki örnek, işlemin gerçekleştirilmesi uzun sürüyorsa istemci performansını ve yanıt hızını yavaşlatabilir, ancak void döndürdüklerinde bile istek/yanıt işlemlerinin avantajları vardır. En belirgin olanı, SOAP hatalarının yanıt iletisinde döndürülebileceğidir. Bu durum, iletişim veya işlem sırasında hizmetle ilgili bir hata koşulunun meydana geldiğini gösterir. Bir hizmet sözleşmesinde belirtilen SOAP hataları istemci uygulamasına nesne FaultException<TDetail> olarak geçirilir ve burada tür parametresi hizmet sözleşmesinde belirtilen türdür. Bu, WCF hizmetlerindeki hata koşullarını istemcilere bildirmeyi kolaylaştırır. Özel durumlar, SOAP hataları ve hata işleme hakkında daha fazla bilgi için bkz. Sözleşmelerde ve Hizmetlerde Hataları Belirtme ve İşleme. İstek/yanıt hizmeti ve istemci örneğini görmek için Nasıl Yapılır: Request-Reply Sözleşmesi Oluşturma bölümüne bakın. İstek-yanıt düzeniyle ilgili sorunlar hakkında daha fazla bilgi için bkz. Request-Reply Hizmetleri.

Tek yönlü

WCF hizmet uygulamasının istemcisi işlemin tamamlanmasını beklememelidir ve SOAP hatalarını işlemezse, işlem tek yönlü bir ileti düzeni belirtebilir. Tek yönlü işlem, istemcinin bir işlemi çağırdığı ve WCF iletiyi ağa yazdıktan sonra işlemeye devam ettiği işlemdir. Bu genellikle giden iletide gönderilen veriler son derece büyük olmadığı sürece istemcinin neredeyse hemen çalışmaya devam etmesi anlamına gelir (verileri gönderirken bir hata olmadığı sürece). Bu tür bir ileti değişimi düzeni, istemciden hizmet uygulamasına olay benzeri davranışı destekler.

Bir mesajın gönderildiği ve hiçbirinin alınmadığı bir mesaj alışverişi, void dışında bir dönüş değerini belirleyen bir hizmet işlevini desteklemez; bu durumda bir InvalidOperationException istisnası fırlatılır.

Dönüş iletisi olmaması, işleme veya iletişimdeki hataları belirtmek için herhangi bir SOAP hatası döndürülemeyeceği anlamına da gelir. (İşlemler tek yönlü işlemler olduğunda hata bilgilerinin iletilmesi çift yönlü ileti değişimi deseni gerektirir.)

Bir void döndüren işlem için tek yönlü ileti değişimini belirtmek amacıyla, özelliği aşağıdaki C# kod örneğinde olduğu gibi IsOneWay olarak true ayarlayın.

[OperationContractAttribute(IsOneWay=true)]
void Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute(IsOneWay := True)>
Sub Hello (ByVal greeting As String)

Bu yöntem önceki istek/yanıt örneğiyle aynıdır, ancak özelliğini IsOneWay olarak ayarlamaktrue, yöntemin aynı olmasına rağmen hizmet işleminin bir dönüş iletisi göndermediği ve giden ileti kanal katmanına teslim edildikten sonra istemcilerin hemen döndüreceği anlamına gelir. Örnek için bkz . Nasıl yapılır: One-Way Sözleşmesi Oluşturma. Tek yönlü desen hakkında daha fazla bilgi için bkz. One-Way Hizmetleri.

Dubleks

Çift yönlü desen, hem hizmetin hem de istemcinin tek yönlü veya istek/yanıt mesajlaşması kullanarak birbirinden bağımsız olarak birbirlerine ileti gönderebilmesiyle karakterize edilir. Bu iki yönlü iletişim biçimi, doğrudan istemciyle iletişim kurması gereken hizmetler için veya olay benzeri davranış dahil olmak üzere ileti değişiminin her iki tarafına zaman uyumsuz bir deneyim sağlamak için kullanışlıdır.

çift yönlü desen, istemciyle iletişim kurmak için ek mekanizma nedeniyle istek/yanıt veya tek yönlü desenlerden biraz daha karmaşıktır.

Çift yönlü sözleşme tasarlamak için, bir geri çağırma sözleşmesi tasarlamanız ve bu geri çağırma sözleşmesinin türünü hizmet sözleşmenizi CallbackContract işaretleyen özniteliğin ServiceContractAttribute özelliğine atamanız gerekir.

Çift yönlü desen uygulamak için istemcide çağrılan yöntem bildirimlerini içeren ikinci bir arabirim oluşturmanız gerekir.

Hizmet oluşturma ve bu hizmete erişen bir istemciyle ilgili bir örnek için, Nasıl yapılır: Çift Yönlü Bir Sözleşme Oluşturma ve Nasıl yapılır: Çift Yönlü Bir Sözleşme ile Hizmetlere Erişme başlıklarına bakın. Çalışan bir örnek için bkz. Duplex. Çift yönlü sözleşmeleri kullanma sorunları hakkında daha fazla bilgi için bkz. Çift Yönlü Hizmetler.

Dikkat

Bir hizmet çift yönlü bir ileti aldığında, yanıtın nereye gönderileceğini belirlemek için gelen iletideki ReplyTo öğesine bakar. İletiyi almak için kullanılan kanalın güvenliği sağlanmazsa, güvenilmeyen bir istemci hedef makineninkiyle kötü amaçlı bir ileti gönderebilir ve bu da hedef makinenin ReplyTohizmet reddine (DOS) yol açabilir.

Out ve Ref Parametreleri

Çoğu durumda, in parametrelerini (ByVal Visual Basic'te) ve out ile ref parametrelerini (ByRef Visual Basic'te) kullanabilirsiniz. Hem out hem de ref parametreleri bir işlemden veri döndürüldüğünü gösterdiği için, aşağıdaki gibi bir işlem imzası, işlem imzası void döndürse bile bir istek/yanıt işlemi gerektirir.

[ServiceContractAttribute]
public interface IMyContract
{
  [OperationContractAttribute]
  public void PopulateData(ref CustomDataType data);
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContractAttribute()> _
Public Interface IMyContract
  <OperationContractAttribute()> _
  Public Sub PopulateData(ByRef data As CustomDataType)
End Interface

Tek özel durumlar, imzanızın belirli bir yapıya sahip olduğu durumlardır. Örneğin, istemcilerle iletişim kurmak için yalnızca bir işlemi bildirmek için kullanılan yöntem NetMsmqBinding dönerse void bağlamasını kullanabilirsiniz; çıkış değeri, ister dönüş değeri, ister ref ister out parametresi olsun, olamaz.

Buna ek olarak, out veya ref parametrelerinin kullanılması, işlemin değiştirilmiş nesneyi taşımak için bir temel yanıt iletisine sahip olmasını gerektirir. İşleminiz tek yönlü bir işlemse çalışma zamanında bir InvalidOperationException özel durum oluşturulur.

Sözleşmede İleti Koruma Düzeyini Belirtin

Sözleşmenizi tasarlarken, sözleşmenizi uygulayan hizmetlerin ileti koruma düzeyine de karar vermeniz gerekir. Bu, yalnızca sözleşmenin uç noktasındaki bağlamaya ileti güvenliği uygulandığında gereklidir. Eğer bağlama güvenliği kapalıysa (yani, sistem tarafından sağlanan bağlama System.ServiceModel.SecurityMode değerini SecurityMode.None olarak ayarlarsa), sözleşmenin ileti koruma düzeyine karar vermeniz gerekmez. Çoğu durumda, ileti düzeyi güvenlik uygulanmış sistem tarafından sağlanan bağlamalar yeterli bir koruma düzeyi sağlar ve her işlem veya her ileti için koruma düzeyini göz önünde bulundurmanız gerekmez.

Koruma düzeyi, bir hizmeti destekleyen iletilerin (veya ileti bölümlerinin) imzalanıp imzalanmadığını, imzalanıp şifrelenmediğini veya imzalar ya da şifreleme olmadan gönderilip gönderilmediğini belirten bir değerdir. Koruma düzeyi çeşitli kapsamlarda ayarlanabilir: Hizmet düzeyinde, belirli bir işlem için, bu işlem içindeki bir ileti için veya ileti bölümü. Bir kapsamda ayarlanan değerler, açıkça geçersiz kılınmadığı sürece daha küçük kapsamlar için varsayılan değer olur. Bağlama yapılandırması sözleşme için gerekli en düşük koruma düzeyini sağlayamıyorsa bir özel durum oluşturulur. Sözleşmede açıkça hiçbir koruma düzeyi değeri ayarlanmazsa bağlama yapılandırması, bağlamanın ileti güvenliği varsa tüm iletiler için koruma düzeyini denetler. Bu, varsayılan davranıştır.

Önemli

Bir sözleşmenin çeşitli kapsamlarının tam koruma düzeyinden ProtectionLevel.EncryptAndSign daha az olacak şekilde açıkça ayarlanıp ayarlanmayacağına karar vermek genellikle artan performans için bir miktar güvenlikle işlem gören bir karardır. Bu gibi durumlarda, kararlarınızın işlemleriniz ve onların değiş tokuş ettikleri verilerin değeri etrafında dönmesi gerekir. Daha fazla bilgi için bkz . Hizmetlerin Güvenliğini Sağlama.

Örneğin, aşağıdaki kod örneği sözleşmede ProtectionLevel veya ProtectionLevel özelliğini ayarlamaz.

[ServiceContract]
public interface ISampleService
{
  [OperationContractAttribute]
  public string GetString();

  [OperationContractAttribute]
  public int GetInt();
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContractAttribute()> _
Public Interface ISampleService

  <OperationContractAttribute()> _
  Public Function GetString()As String

  <OperationContractAttribute()> _
  Public Function GetData() As Integer

End Interface

Varsayılan bir ISampleService (ki bu varsayılan WSHttpBinding, yani System.ServiceModel.SecurityMode) olan bir uç noktadaki Message uygulamasıyla etkileşim kurarken, bu varsayılan koruma düzeyi olduğundan, tüm iletiler şifrelenir ve imzalanır. Ancak, bir ISampleService hizmet varsayılan BasicHttpBinding ile kullanıldığında (varsayılan SecurityModeolan None), bu bağlama için güvenlik olmadığından ve koruma düzeyi yoksayıldığından (yani, iletiler şifrelenmediğinden veya imzalandığından) tüm iletiler metin olarak gönderilir. SecurityMode olarak değiştirildiyseMessage, bu iletiler şifrelenir ve imzalı olur (çünkü bu artık bağlamanın varsayılan koruma düzeyi olacaktır).

Sözleşmenizin koruma gereksinimlerini açıkça belirtmek veya ayarlamak istiyorsanız, özelliği (veya daha küçük bir kapsamdaki ProtectionLevel özelliklerden herhangi birini) hizmet sözleşmenizin gerektirdiği düzeye ayarlayınProtectionLevel. Bu durumda, açık bir ayar kullanmak için bağlamanın kullanılan kapsam için en az bu ayarı desteklemesi gerekir. Örneğin, aşağıdaki kod örneğinde, ProtectionLevel işlemi için bir GetGuid değeri açıkça belirtilmiştir.

[ServiceContract]
public interface IExplicitProtectionLevelSampleService
{
  [OperationContractAttribute]
  public string GetString();

  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.None)]
  public int GetInt();
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.EncryptAndSign)]
  public int GetGuid();
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContract()> _
Public Interface IExplicitProtectionLevelSampleService
    <OperationContract()> _
    Public Function GetString() As String
    End Function

    <OperationContract(ProtectionLevel := ProtectionLevel.None)> _
    Public Function GetInt() As Integer
    End Function

    <OperationContractAttribute(ProtectionLevel := ProtectionLevel.EncryptAndSign)> _
    Public Function GetGuid() As Integer
    End Function

End Interface

Bu IExplicitProtectionLevelSampleService sözleşmesini uygulayan ve varsayılan WSHttpBinding'yi (WSHttpBinding'nin varsayılanı olan Message, yani ) kullanan uç noktasına sahip bir hizmet aşağıdaki davranışa sahiptir:

  • İşlem GetString iletileri şifrelenir ve imzalanır.

  • İşlem GetInt iletileri şifrelenmemiş ve işaretsiz (düz) metin olarak gönderilir.

  • İşlem GetGuidSystem.Guid şifrelenmiş ve imzalanmış bir iletide döndürülür.

Koruma düzeyleri ve bunların nasıl kullanılacağı hakkında daha fazla bilgi için bkz. Koruma Düzeyini Anlama. Güvenlik hakkında daha fazla bilgi için bkz . Hizmetlerin Güvenliğini Sağlama.

Diğer İşlem İmzası Gereksinimleri

Bazı uygulama özellikleri belirli bir işlem imzası türü gerektirir. Örneğin, NetMsmqBinding bağlantısı, bir uygulamanın iletişimin ortasında yeniden başlatılabildiği ve hiçbir iletiyi kaçırmadan kaldığı yerden devam edebilmesi için dayanıklı istemci ve hizmetleri destekler. (Daha fazla bilgi için bkz. WCF'deki kuyruklar.) Ancak, dayanıklı işlemlerin yalnızca bir in parametre alması ve dönüş değeri olmaması gerekir.

Bir diğer örnek de işlemlerde türlerin Stream kullanılmasıdır. Parametre ileti gövdesinin Stream tamamını içerdiğinden, bir giriş veya çıkış (parametre ref , out parametre veya dönüş değeri) türündeyse Stream, işleminizde belirtilen tek giriş veya çıkış olmalıdır. Ayrıca, parametre veya dönüş türü Stream, System.ServiceModel.Channels.Message veya System.Xml.Serialization.IXmlSerializable olmalıdır. Akışlar hakkında daha fazla bilgi için bkz. Büyük Veri ve Akış.

Adlar, Ad Uzayları ve Gizleme

Sözleşmelerin ve işlemlerin tanımındaki .NET türlerinin adları ve ad alanları, sözleşmeler WSDL'ye dönüştürüldüğünde ve sözleşme iletileri oluşturulup gönderildiğinde önemlidir. Bu nedenle, hizmet sözleşmesi adlarının ve ad alanlarının, Name ve Namespace gibi özellikler ve ServiceContractAttribute, OperationContractAttribute, DataContractAttribute, DataMemberAttribute ve diğer sözleşme öznitelikleri gibi tüm destekleyici sözleşme öznitelikleri kullanılarak açıkça ayarlanması kesinlikle önerilir.

Bunun sonucunda adlar ve ad alanları açıkça ayarlanmamışsa, derlemede IL gizlemenin kullanılması sözleşme türü adlarını ve ad alanlarını değiştirir ve genellikle başarısız olan değiştirilmiş WSDL ve kablo değişimleriyle sonuçlanır. Sözleşme adlarını ve ad alanlarını açıkça ayarlamaz ama karartma kullanmayı planlıyorsanız, sözleşme türü adlarının ve ad alanlarının değiştirilmesini önlemek için ObfuscationAttribute ve ObfuscateAssemblyAttribute özniteliklerini kullanın.

Ayrıca bakınız

  • Last updated on