Soms genereert het toevoegen van een WCF-servicereferentie een lege reference.cs

Soms genereert het toevoegen van een WCF-servicereferentie een lege reference.cs en kan ik nergens in het project naar de service verwijzen.

Is iemand dit tegengekomen?

Antwoord 1, autoriteit 100%

Over het algemeen vind ik dat het een code-gen-probleem is en meestalkomt het doordat ik een typenaamconflict heb dat niet kon worden opgelost.

Als u met de rechtermuisknop op uw servicereferentie klikt en op configureren klikt en deselecteert‘Typen hergebruiken in assemblages waarnaar wordt verwezen’, wordt het probleem waarschijnlijk opgelost.

Als je een bepaald aspect van deze functie gebruikte, moet je er misschien voor zorgen dat je namen worden opgeschoond.

Antwoord 2, autoriteit 10%

Zoals het geaccepteerde antwoord aangeeft, is een typereferentieprobleem bij het hergebruiken van typen waarschijnlijk de boosdoener. Ik ontdekte dat wanneer je het probleem niet gemakkelijk kunt bepalen, het gebruik van de opdrachtregel svcutil.exe je zal helpen het onderliggende probleem te onthullen (zoals John Saunders opmerkt).

Als verbetering is hier een snel voorbeeld van het gebruik van svcutil.

svcutil /t:code https://secure.myserver.com/services/MyService.svc /d:test /r:"C:\MyCode\MyAssembly\bin\debug\MyAssembly.dll"

Waar:

• /t:code genereert de code van de opgegeven url
• /d: om de directory voor de uitvoer te specificeren
• /r: om een ​​referentie-assemblage op te geven

Volledige svcutil-opdrachtregelreferentie hier: http://msdn.microsoft.com /nl-nl/bibliotheek/aa347733.aspx

Als je svcutil eenmaal hebt uitgevoerd, zou je moeten zien dat de uitzondering wordt gegenereerd door de import. U kunt dit type bericht ontvangen over een van uw typen: “het type waarnaar wordt verwezen kan niet worden gebruikt omdat het niet overeenkomt met het geïmporteerde DataContract”.

Dit kan eenvoudig zijn zoals gespecificeerd, in die zin dat er een verschil is in een van de typen in de assembly waarnaar wordt verwezen, van wat is gegenereerd in het DataContract voor de service. In mijn geval had de service die ik importeerde nieuwere, bijgewerkte typen van wat ik had in de gedeelde assembly. Dit was niet direct duidelijk omdat het in de uitzondering genoemde type hetzelfde bleek te zijn. Wat anders was, was een van de geneste complexe typen die door het type werden gebruikt.

Er zijn andere, meer complexe scenario’s die dit type uitzondering kunnen veroorzaken en resulteren in een lege reference.cs. Hier is een voorbeeld.

Als u dit probleem ondervindt en u gebruikt geen generieke typen in uw gegevenscontracten en ook niet IsReference = true, dan raad ik u aan om zeker te zijn dat uw gedeelde typen exact hetzelfde zijn op uw client en server. Anders loop je waarschijnlijk tegen dit probleem aan.

Antwoord 3, autoriteit 3%

Als dit gebeurt, kijk dan in het venster Fouten en het venster Uitvoer om te zien of er foutberichten zijn. Als dat niet helpt, probeer dan svcutil.exehandmatig uit te voeren en kijk of er foutmeldingen zijn.

Antwoord 4, autoriteit 3%

Ik zit al een hele dag met mijn hoofd op dit exacte probleem. Ik heb het zojuist gerepareerd. Hier is hoe…

De service moestdraaien over SSL (dwz het is op https://mydomain.com/MyService.svc )

Het toevoegen van een servicereferentie aan de WCF-service op een ontwikkelserver werkte prima.

Het exactimplementeren van dezelfde build van de WCF-service op de live-productieserver, vervolgens overschakelen naar de clienttoepassing en het configureren van de servicereferentie om naar de live-service te verwijzen, vertoonde geen fouten, maar de app zou’ t build: Het blijkt dat het Reference.cs-bestand van de servicereferentie helemaal leeg was! Het bijwerken van de servicereferentie maakte geen verschil. Het schoonmaken van de oplossing hielp niet. Het herstarten van VS2010 maakte geen verschil. Het creëren van een nieuwe blanco oplossing, het starten van een consoleproject en het toevoegen van een servicereferentie aan de live service vertoonde precies hetzelfde probleem.

Ik dacht niet dat het te wijten was aan conflicterende typen of zo, maar wat maakt het uit: ik heb de WCF-servicereferentie opnieuw geconfigureerd door het vinkje bij “Hergebruik typen in alle assemblages waarnaar wordt verwezen” uit te schakelen. Geen vreugde; Ik heb het vinkje terug gezet.

De volgende stap was om svcutilte proberen op de referentie-URL om te zien of dat zou helpen het probleem op te lossen. Hier is het commando:

svcutil /t:code https://mydomain.com/MyService.svc /d:D:\test

Dit leverde het volgende op:

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.

Daar was ik helemaal van geschrokken. Ondanks zwaar googelen en behoorlijk boos worden, en een carrière als buschauffeur heroverwegen, heb ik eindelijk overwogen waarom het goed werkte op de ontwikkelingsbox. Kan het een IIS-configuratieprobleem zijn?

Ik ging tegelijkertijd op afstand naar zowel de ontwikkelings- als de live-boxen en op elke startte ik de IIS Manager (met IIS 7.5). Vervolgens heb ik elke configuratie-instelling op elke doos doorgenomen en de waarden op elke server vergeleken.

En daar is het probleem: zorg ervoor dat onder “SSL-instellingen” voor de site “SSL vereisen” is aangevinkt en vink het keuzerondje Clientcertificaten aan voor “Accepteren”. Probleem opgelost!

Antwoord 5, autoriteit 2%

Ik heb gemerkt dat dit vaak voorkomt wanneer ik een referentie toevoeg, deze verwijder en vervolgens een service met dezelfde naam opnieuw toevoeg. De typeconflicten lijken te worden veroorzaakt doordat de oude bestanden ergens achterblijven die Visual Studio nog kan zien. Het enige wat ik moet doen om het te repareren, is opschonen voordat ik de nieuwe referentie toevoeg.

1. Verwijder de servicereferentie die problemen heeft.
2. Klik op de projectnaam in de Solution Explorerom het project te markeren.
3. Klik met de rechtermuisknop op de projectreferentie.
4. Klik bovenaan de contextlijst op het item Opschonen.
5. Voeg uw servicereferentie toe zoals u dat normaal zou doen.

Hopelijk helpt dit.

Antwoord 6

Ik had dit probleem met een Silverlight 5 geüpgraded van een vorige versie.

Zelfs het opnieuw toevoegen van de servicereferentie gaf me nog steeds een lege Reference.cs

Uiteindelijk moest ik een gloednieuw project maken en de servicereferentie opnieuw maken.
Dit is iets om te proberen als je hier meer dan een half uur aan hebt besteed. Zelfs als je vastbesloten bent om het oorspronkelijke project op te lossen, wil je dit misschien proberen om te zien wat er gebeurt en vervolgens achteruit werken om te proberen het probleem op te lossen.

Ik ben er nooit achter gekomen wat het probleem precies was, maar mogelijk is er iets in het .csproj-bestand niet geüpgraded of is er een instelling fout gegaan.

Antwoord 7

Als u onlangs een verzameling aan uw project heeft toegevoegd toen dit begon, kan het probleem worden veroorzaakt door twee verzamelingen die hetzelfde CollectionDataContract-kenmerk hebben:

[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="AItems", ItemName="A")]  // Wrong
public class CollectionB : List<B> { }

Ik heb de fout verholpen door door mijn project te bladeren en ervoor te zorgen dat elk kenmerk Nameen ItemNameuniek was:

[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="BItems", ItemName="B")]  // Corrected
public class CollectionB : List<B> { }

Toen heb ik de servicereferentie vernieuwd en alles werkte weer.

Antwoord 8

Mijn probleem was dat ik de “mex” aan het einde van mijn webservicelink had achtergelaten.

In plaats van “http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc /mex“

Gebruik “http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc>”

Antwoord 9

De techniek die voor mij werkte in mijn geval, nadat ik deze antwoorden tevergeefs had gelezen, was gewoon om al mijn contract te becommentariëren en de opmerkingen weg te halen totdat het niet meer werkt, op een binaire zoekmanier. Dat beperkt het aanstootgevende stukje code.

Dan hoef je alleen maar te raden wat er mis is met die code.

Enige feedback op fouten in de tool had natuurlijk geholpen.

Ik schrijf een webservicecontract. Ik had een placeholder-enum zonder leden. Dat is goed. Maar als ik het gebruik in een eigenschap van een andere klasse en de contract-dll op de client opnieuw gebruik, explodeert de codegen zonder foutmelding. Het uitvoeren van svcutil.exe hielp niet, het lukte alleen niet om een ​​cs-bestand uit te voeren zonder te vermelden waarom.

Antwoord 10

Het volgende wordt hier niet vermeld, en het was de oplossing die ik heb aangenomen (SvcUtils was handig bij het zien van de foutmelding. De fout die ik kreeg was echter een bericht van het wrapper type message cannot be projected as a data contract type since it has multiple namespaces. Dit betekent dat ik dit voorbeeld heb gevolgd en meer heb geleerd over wsdl.exevia ditbericht).

In mijn geval genereerde het eenvoudig uitvoeren van wsdl [my-asmx-service-address] een probleemloos .cs-bestand, dat ik in mijn project heb opgenomen en om de dienst te gebruiken.

Antwoord 11

Zoals @dblood aangeeft, zit de grootste pijn in de DataContractSerializer, die de typen niet correct hergebruikt. Er zijn hier al enkele antwoorden, dus ik zal beginnen met het toevoegen van enkele voor- en nadelen hierover:

• De ‘IsReference’-vlag veroorzaakt veel problemen, maar het verwijderen ervan is niet altijd de oplossing (specifiek: in situaties met recursie).
• Het onderliggende probleem is dat het datacontract op de een of andere manier niet hetzelfde is als de typenamen, ook al zijn ze dat soms (huh? Ja, je leest het goed!). Blijkbaar is de serializer nogal kieskeurig en is het erg moeilijk om het echte probleem te vinden.
• Het verwijderen van de ‘referentiecontroles’ uit de ‘Servicereferentie configureren’ werkt, maar laat je met meerdere implementaties achter. Ik gebruik echter vaak SOAP-interfaces in DLL’s. In de meeste volwassen SOA’s die ik ken, implementeren en uitbreiden meerdere service-interfaces dezelfde interfaceklassen. Het verwijderen van ‘use referenced types’-controles resulteert in een situatie waarin je objecten niet meer zomaar kunt doorgeven.

Gelukkig, als u de controle heeft over uw service, is er een eenvoudige oplossing die al deze problemen oplost. Dit betekent dat u nog steeds service-interfaces kunt hergebruiken in DLL’s – wat IMO een must-have is voor een goede oplossing. Zo werkt de oplossing:

1. Maak een aparte interface-DLL. Neem in die DLL alle DataContract en ServiceContract’s op; zet ServiceContract’s op uw interfaces.
2. Leid de serverimplementatie af van de interface.

3. Gebruik dezelfde DLL om de client samen te stellen met uw favoriete methode. Bijvoorbeeld (IMyInterface is de interface voor het servicecontract):

   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();
   

Met andere woorden: Gebruik niet de functionaliteit ‘servicereferentie toevoegen’, maar dwing WCF om de (juiste) servicetypes te gebruiken door de proxygeneratie te omzeilen. Je hebt deze lessen tenslotte al.

Pro’s:

1. Je omzeilt het svcutil.exe-proces, wat betekent dat je geen IsReference-problemen hebt
2. DataContract-typen en namen zijn per definitie correct; zowel server als client gebruiken immers dezelfde definitie.
3. Als u de API uitbreidt of typen uit een andere DLL gebruikt, blijven (1) en (2) geldig, dus u zult daar geen problemen ondervinden.

Nadelen:

1. A-sync-methoden zijn lastig, omdat u geen a-sync-proxy genereert. Daarom raad ik het niet aan om dit in Silverlight-toepassingen te doen.

Antwoord 12

Ik had ook het probleem van verbroken servicereferenties bij het werken met projectreferenties aan beide kanten (het serviceproject en het project met een verwijzing naar de service).
Als de .dll van het project waarnaar wordt verwezen bijvoorbeeld “Contoso.Development.Common” wordt genoemd, maar de naam van het project eenvoudigweg wordt afgekort tot “Common”, worden ook projectverwijzingen naar dit project gewoon “Common” genoemd. De service verwacht echter een verwijzing naar “Contoso.Development.Common” voor het oplossen van klassen (als deze optie is geactiveerd in de servicereferentie-opties).

Dus met verkenner opende ik de map van het project die verwijst naar de service en het “Common”-project. Daar bewerk ik het VS-projectbestand (.csproj) met Kladblok.
Zoek naar de naam van het project waarnaar wordt verwezen (in dit voorbeeld “Common.csproj”) en u zult snel het configuratie-item vinden dat de projectreferentie vertegenwoordigt.

Ik heb

gewijzigd

<ProjectReference Include="..\Common\Common.csproj">
<Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project>
<Name>Common</Name>
</ProjectReference>

naar

<ProjectReference Include="..\Common\Common.csproj">
<Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project>
<Name>Contoso.Development.Common</Name>
</ProjectReference>

Het belangrijkste is om de naam van de verwijzing te veranderen in de naam van de dll die het project waarnaar wordt verwezen als uitvoer heeft.

Schakel dan terug naar VS. Daar wordt u gevraagd om het project opnieuw te laden omdat het buiten VS is gewijzigd. Klik op de herlaadknop.

Hierna werkte het toevoegen en bijwerken van de servicereferentie precies zoals verwacht.

Hopelijk helpt dit ook iemand anders.

Met vriendelijke groet
MH

Antwoord 13

Ik heb gisteren tijdens de ontwikkeling met een soortgelijk probleem te maken gehad. Ik kwam erachter dat ik dezelfde naamruimte gebruikte in 2 verschillende versies van contracten.

We hebben 2 versies van contracten, bijvoorbeeld versie4 en versie5. Ik heb alle contracten van versie4 gekopieerd en de naamruimte van versie4 naar versie5 hernoemd. Terwijl ik dit deed, vergat ik de naamruimte te hernoemen van v4 naar v5 in een van de bestanden. Vanwege een naamruimteconflict was het bestand Reference.cs leeg.

Dit probleem is moeilijk op te lossen omdat u geen foutmelding krijgt tijdens het genereren van de servicereferentie. Om dit probleem te identificeren, zou ik alle nieuwe bestanden die ik had gemaakt handmatig valideren. Er zijn andere manieren om dit probleem op te lossen. Dit is de eerste stap die u moet uitvoeren voordat u naar andere opties gaat.

Antwoord 14

Dankzij de post van John Saunders hierboven, die me een idee gaf om in het foutvenster te kijken. Ik was de hele dag bezig met mijn hoofd en ik keek naar het uitvoervenster voor een fout.

In mijn geval was de boosdoener ISerializable. Ik heb een DataContract-klasse met de eigenschap DataMember van het type Exception. U kunt geen DataMember van het type hebben met het ISerializable-sleutelwoord. In deze Exception is ISerializable zodra ik het verwijderde, alles werkte als een charme.

Antwoord 15

Bij een poging om dit probleem op te lossen met svcutil, ontving ik de fout waarnaar wordt verwezen in het antwoord van dblood (“het type waarnaar wordt verwezen kan niet worden gebruikt omdat het niet overeenkomt met het geïmporteerde DataContract”).

In mijn geval leek de onderliggende oorzaak een enum-type te zijn met het DataContract-attribuut, maar waarvan de leden niet waren gemarkeerd met het EnumMember-attribuut. De probleemklasse svcutilwaarnaar werd verwezen, had een eigenschap met dat enum-type.

Dit zou beter passen als commentaar op het antwoord van dblood, maar daarvoor is niet genoeg vertegenwoordiger…

Antwoord 16

In mijn geval had ik een oplossing met het VB Web Forms-project dat verwees naar een C# UserControl. Zowel het VB-project als het CS-project hadden een Service Reference naar dezelfde service. De referentie verscheen onder Service References in het VB-project en onder de Connected Services-groepering in het CS (framework)-project.

Om de servicereferentie bij te werken (dwz ervoor zorgen dat het bestand Reference.vb niet leeg is) in het VB-webformulierenproject, moest ik HET CS-PROJECT VERWIJDEREN, vervolgens de VB-servicereferentie bijwerken en vervolgens de CS toevoegen project terug in de oplossing.

Antwoord 17

Volg deze stappen:

1. Servicereferentie verwijderen
2. Visual Studio sluiten
3. Verwijder /Bin- en /Obj-mappen.
4. Open Visual Studio.
5. Voeg de servicereferentie toe.
6. Graag gedaan 🙂

Het lijkt erop dat er enkele verwijzingen in deze mappen zijn achtergelaten bij het toevoegen van de service, wat fouten veroorzaakt tijdens het automatisch genereren van code.