Yanıtlar:
Genellikle bunun bir kod-gen sorunu olduğunu ve çoğu zaman çözemediği bir tür adı çakışması yaşadığım için buluyorum .
Hizmet referansınızı sağ tıklayıp yapılandır'ı tıklayıp "Başvurulan Montajlardaki Türleri Yeniden Kullan " seçeneğinin işaretini kaldırmanız sorunu çözecektir.
Bu özelliğin bir yönünü kullanıyorsanız, adlarınızın temizlendiğinden emin olmanız gerekebilir.
Kabul edilen yanıtın işaret ettiği gibi, türleri yeniden kullanırken bir tür referans sorunu muhtemelen suçludur. Sorunu kolayca belirleyemediğinizde buldum, sonra svcutil.exe komut satırını kullanmak (John Saunders'ın işaret ettiği gibi) altta yatan sorunu ortaya çıkarmanıza yardımcı olacaktır.
Burada bir geliştirme olarak svcutil kullanımına hızlı bir örnek.
svcutil /t:code https://secure.myserver.com/services/MyService.svc /d:test /r:"C:\MyCode\MyAssembly\bin\debug\MyAssembly.dll"Nerede:
Tam svcutil komut satırı başvurusu burada: http://msdn.microsoft.com/en-us/library/aa347733.aspx
Svcutil'i çalıştırdıktan sonra, içe aktarma tarafından özel durumun atıldığını görmelisiniz. Türlerinizden biri hakkında bu tür bir ileti alabilirsiniz: "başvurulan tür, içe aktarılan DataContract ile eşleşmediği için kullanılamıyor".
Bu, başvurulan derlemedeki türlerden birinde, hizmet için DataContract'ta oluşturulandan bir fark olmasıyla belirtildiği gibi olabilir. Benim durumumda, içe aktardığım hizmetin paylaşılan derlemede olandan daha yeni, güncellenmiş türleri vardı. İstisnada belirtilen türün aynı olduğu için bu kolayca görünmüyordu. Farklı olan, tür tarafından kullanılan iç içe geçmiş karmaşık türlerden biriydi.
Bu tür özel durumu ve sonuçta ortaya çıkan blank reference.cs dosyasını tetikleyebilecek daha karmaşık senaryolar da vardır. İşte bir örnek .
Bu sorunu yaşıyorsanız ve veri sözleşmelerinizde genel türler kullanmıyorsanız veya IsReference = true kullanmıyorsanız, paylaşılan türlerinizin istemcinizde ve sunucunuzda tamamen aynı olduğundan emin olmanızı öneririz. Aksi takdirde, büyük olasılıkla bu sorunla karşılaşırsınız.
Bu durumda, herhangi bir hata mesajı olup olmadığını görmek için Hatalar penceresine ve Çıktı penceresine bakın. Bu işe yaramazsa, svcutil.exeel ile çalıştırmayı deneyin ve herhangi bir hata mesajı olup olmadığını görün.
Bu tam sorunla bir gün boyunca başımı dayayordum. Sadece düzelttim. İşte böyle ...
Hizmet vardı SSL üzerinden çalıştırmak için (yani en bulunuyor https://mydomain.com/MyService.svc )
Bir geliştirme sunucusunda WCF hizmetine bir hizmet başvurusu eklemek gayet iyi çalıştı.
Dağıtma kesin hata istemci uygulamasına geçiş ve canlı servise noktaya hizmet başvurusu yapılandırarak sonra, canlı üretim sunucusunda WCF hizmeti aynı yapı görüntülenen ancak uygulamanın inşa olmaz: Bu hizmet referans en çıkıyor Reference.cs dosyası tamamen boştu! Hizmet referansını güncellemek bir fark yaratmadı. Çözeltinin temizlenmesi yardımcı olmadı. VS2010'u yeniden başlatmak bir fark yaratmadı. Yeni bir boş çözüm oluşturma, bir konsol projesi başlatma ve canlı hizmete bir hizmet başvurusu ekleme tam olarak aynı sorunu gösterdi.
Ben çakışan türleri ya da bir şey nedeniyle olduğunu düşünmüyordu, ama ne halt - Ben "Tüm başvurulan montajlarda türleri yeniden" işaretini kaldırarak WCF hizmet başvurusunu yeniden yapılandırdı. Sevinç yok; Onay işaretini geri koydum.
Bir sonraki adım, sorunun çözülmesine yardımcı olup olmayacağını görmek için referans URL'deki svcutil'i denemekti . İşte komut:
svcutil /t:code https://mydomain.com/MyService.svc /d:D:\testBu, aşağıdakileri üretti:
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 4.0.30319.1]
Copyright (c) Microsoft Corporation. All rights reserved.
Attempting to download metadata from 'https://mydomain.com/MyService.svc' using WS-Metadata Exchange or DISCO.
Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Schema with target namespace 'http://mynamespace.com//' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']
Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']
Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:service[@name='MyService']/wsdl:port[@name='WSHttpBinding_IMyService']
Generating files...
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata documents did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assemblies. Verify that you passed all the metadata documents to the tool.
Warning: If you would like to generate data contracts from schemas make sure to use the /dataContractOnly option.Bu beni tamamen şaşırttı. Ağır googlinge ve gerçekten çapraz geçmeye ve bir kariyeri bir otobüs şoförü olarak yeniden düşünmeye rağmen, nihayet neden geliştirme kutusunda iyi çalıştığını düşündüm. Bir IIS yapılandırma sorunu olabilir mi?
Hem geliştirme hem de canlı kutulara aynı anda uzak durdum ve her birinde IIS Yöneticisi'ni çalıştırdım (IIS 7.5 çalıştıran). Daha sonra, her bir sunucudaki değerleri karşılaştırarak her kutudaki her yapılandırma ayarını inceledim.
Sorun var: Site için "SSL Ayarları" altında, "SSL İste" seçeneğinin işaretli olduğundan emin olun ve İstemci Sertifikaları radyo düğmesini "Kabul Et" olup olmadığını kontrol edin. Problem çözüldü!
Bir başvuru eklediğimde, kaldırdığımda ve aynı ada sahip bir hizmeti yeniden eklediğimde bunu yaygın olarak buldum. Tür çakışmaları, Visual Studio'nun hala görebildiği bir yerde kalan eski dosyalar nedeniyle ortaya çıkıyor. Düzeltmek için tek yapmam gereken, yeni referans eklemeden önce temiz.
Bu yardımcı olur umarım.
Önceki bir sürümden yükseltilmiş bir Silverlight 5 ile bu sorunu vardı.
Servis referansını tekrar eklemek bile bana boş bir Reference.cs verdi
Sonunda yepyeni bir proje oluşturmak ve servis referansını yeniden oluşturmak zorunda kaldım. Bu iş için yaklaşık yarım saatten fazla zaman harcadıysanız denemeniz gereken bir şeydir. Orijinal projeyi düzeltmeye kararlı olsanız bile, sadece ne olduğunu görmek için bunu denemek ve ardından sorunu düzeltmek için geriye doğru çalışmak isteyebilirsiniz.
Asla sorunun tam olarak ne olduğunu anlayamadım - ama muhtemelen .csproj dosyasındaki bir şey yükseltilmedi veya bazı ayarlar yanlış gitti.
System.Xml.Linq- bu yüzden sürümleri değiştirdiyseniz tüm DLL sürümlerini kontrol
Yakın zamanda projenize bu bir durum oluşmaya başladığında bir koleksiyon eklediyseniz, sorunun nedeni aynı CollectionDataContract özniteliğine sahip iki koleksiyondan kaynaklanıyor olabilir :
[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="AItems", ItemName="A")] // Wrong
public class CollectionB : List<B> { }Projemi gözden geçirerek ve her Name ve ItemName özniteliğinin benzersiz olmasını sağlayarak hatayı düzelttim :
[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="BItems", ItemName="B")] // Corrected
public class CollectionB : List<B> { }Sonra servis referansını yeniledim ve her şey tekrar çalıştı.
Benim sorunum " mex " web servis bağlantımın sonuna bıraktı oldu .
" Http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc/mex " yerine
" Http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc " kullanın
Benim durumumda işe yarayan teknik, bu cevapları boşuna okuduktan sonra, tüm sözleşmemi ve artık işe yaramayana kadar bitleri bir arama biçiminde yorumlamaktı. Bu, rahatsız edici kod parçasını daraltır.
O zaman bu kodda neyin yanlış olduğunu tahmin etmelisiniz.
Elbette araçtaki bazı hata geri bildirimleri yardımcı olabilirdi.
Bir web hizmeti sözleşmesi yazıyorum. Hiçbir üye ile bir yer tutucu numaralandırma vardı. Bu iyi. Ama başka bir sınıfın bir özelliği kullanmak ve istemci üzerinde sözleşme dll yeniden kullanmak, kodgen hata iletisi ile patlar. Çalışan svcutil.exe yardımcı olmadı, sadece nedenini belirtmeden bir cs dosyası çıktısını veremedi.
Aşağıda listelenen ve benimsediğim çözüm oldu (SvcUtils hata mesajını görmek için yararlı oldu. Ancak, aldım hata oldu wrapper type message cannot be projected as a data contract type since it has multiple namespaces. Anlamı, ben bu ipucunu takip ve bu yazı wsdl.exeyoluyla öğrendim ).
Benim durumumda, sadece wsdl [ my-asmx-service-address ] çalıştırmak .cs, projeme dahil ettiğim ve hizmeti kullanmak için oluşturduğum sorunsuz bir dosya oluşturdu .
@Dblood'un işaret ettiği gibi, ana acı, verileri doğru şekilde yeniden kullanmayan DataContractSerializer'dadır. Burada zaten bazı cevaplar var, bu yüzden bunlar hakkında bazı profesyonel ve eksiler ekleyerek başlayacağım:
Neyse ki, hizmetinizi kontrol ediyorsanız, tüm bu sorunları çözen basit bir çözüm var. Bu, DLL'lerde hizmet arabirimlerini yeniden kullanabileceğiniz anlamına gelir - IMO, uygun bir çözüm için olması gereken bir şeydir. Çözüm şu şekilde çalışır:
En sevdiğiniz yöntemi kullanarak istemci oluşturmak için aynı DLL'yi kullanın. Örneğin (IMyInterface hizmet sözleşmesi arabirimidir):
var httpBinding = new BasicHttpBinding();
var identity = new DnsEndpointIdentity("");
var address = new EndpointAddress(url, identity, new AddressHeaderCollection());
var channel = new ChannelFactory<IMyInterface>(httpBinding, address);
return channel.CreateChannel();Başka bir deyişle: 'hizmet referansı ekle' işlevini kullanmayın , ancak proxy oluşturma işlemini atlayarak WCF'yi (doğru) hizmet türlerini kullanmaya zorlayın. Sonuçta, zaten bu sınıflara sahipsiniz.
Profesyonelin:
Eksileri:
Ayrıca her iki tarafta proje referanslarıyla çalışırken (servis projesi ve servise referans olan proje) kırık servis referansları sorunu yaşadım. Örneğin, başvurulan projenin .dll dosyasına "Contoso.Development.Common" adı verilir, ancak proje adı "Ortak" olarak kısaltılırsa, bu projeye yönelik proje başvuruları da yalnızca "Ortak" olarak adlandırılır. Hizmet, ancak sınıfları çözmek için "Contoso.Development.Common" için bir başvuru bekler (bu seçenek hizmet başvuru seçeneklerinde etkinleştirilirse).
Bu yüzden explorer ile hizmete ve "Ortak" projeye atıfta bulunan projenin klasörünü açtım. Orada VS proje dosyasını (.csproj) not defteri ile düzenleyin. Yenilenen projenin adını arayın (bu örnekte "Common.csproj") ve proje başvurusunu temsil eden yapılandırma girdisini hızlı bir şekilde bulacaksınız.
Değiştim
<ProjectReference Include="..\Common\Common.csproj">
<Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project>
<Name>Common</Name>
</ProjectReference>
için
<ProjectReference Include="..\Common\Common.csproj">
<Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project>
<Name>Contoso.Development.Common</Name>
</ProjectReference>
Önemli olan, referansın adını referans alınan projenin çıktı olarak sahip olduğu dll ismine değiştirmektir.
Ardından VS'ye geri dönün. Orada VS dışında değiştirildiği için projeyi yeniden yüklemeniz istenecektir. Yeniden yükle düğmesini tıklayın.
Bunu yaptıktan sonra ekleme ve güncelleme servis referansı beklendiği gibi çalıştı.
Umarım bu başka birine de yardımcı olur.
Saygılarımızla MH
Dün gelişme sırasında benzer bir sorunla karşılaştım. Sözleşmelerin 2 farklı versiyonunda aynı isim alanını kullandığımı öğrendim.
Sürüm4 ve sürüm5 gibi 2 sözleşme sürümümüz var. Sürüm4'teki tüm sözleşmeleri kopyaladım ve sürüm4'ten sürüm5'e tüm ad alanını yeniden adlandırdım. Bunu yaparken dosyalardan birinde ad alanını v4'ten v5'e değiştirmeyi unuttum. Ad alanı çakışması nedeniyle Reference.cs dosyası boştu.
Hizmet başvurusu oluşturulurken herhangi bir hata iletisi almadığınız için bu sorunu gidermek zordur. Bu sorunu tanımlamak için oluşturduğum tüm yeni dosyaları manuel olarak doğrularım. Bu sorunu çözmenin başka yolları da var. Bu, diğer seçeneklere gitmeden önce gerçekleştirmeniz gereken ilk adımdır.
Yukarıdaki Hata penceresine bakmak için bir fikir verdi John Saunders yazı sayesinde. Bütün gün başımı kesiyordum ve herhangi bir hata için Çıktı penceresine bakıyordum.
Benim durumumda suçlu ISerializable idi. Exception tür DataMember özelliği ile bir DataContract sınıfı var. ISerializable anahtar sözcüğüne sahip hiçbir DataMember türüne sahip olamazsınız. Bu İstisnada, kaldırdığımda ISerializable var, her şey bir cazibe gibi çalıştı.
Bu sorunu gidermeye çalışırken svcutil, dblood'un yanıtında belirtilen hatayı aldım ("başvurulan tür, içe aktarılan DataContract ile eşleşmediği için kullanılamıyor").
Benim durumumun altında yatan neden DataContract özniteliği olan, ancak üyeleri EnumMember özniteliğiyle işaretlenmemiş bir enum türü gibi görünüyordu. Belirtilen problem sınıfı svcutil, o enum tipinde bir özelliğe sahipti.
Bu, dblood'un cevabına bir yorum olarak daha uygun olurdu, ancak bunun için yeterli destek yok ...
Benim durumumda bir C # UserControl başvuru VB Web Forms projesi ile bir çözüm vardı. Hem VB projesi hem de CS projesi aynı hizmet için bir Servis Referansına sahipti. Referans, VB projesindeki Hizmet Referansları altında ve CS (çerçeve) projesindeki Bağlı Hizmetler gruplaması altında belirmiştir.
VB web formları projesinde hizmet başvurusunu güncellemek (yani Reference.vb dosyasının boş olmamasını sağlamak) için CS PROJESİNİ KALDIRMAK, sonra VB Hizmet Referansını güncellemem ve ardından CS projesini tekrar eklemem gerekiyordu. çözüm.
Bu adımları takip et:
Hizmet eklenirken kodun otomatik oluşturulması sırasında hatalara neden olan bazı referansların bu klasörlerde kaldığı görülmektedir.