C# Fehler: die Namen dürfen nicht identisch sein umschließenden Typ und Schnittstellen deklarieren Typen

Ich versuche, zu lauch ein service für appFabric für windows Azure. Ich bin zu implementieren und EchoService und ich brauche zu implementieren, indem Sie die Art und Weise und IEchoContract-Schnittstelle, die alle diese auf der server-Seite.
So ich gehen Sie wie folgt vor.

Auf dem IEchoContract.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;


namespace Service
{
[ServiceContract(Name = "EchoContract", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
interface IEchoContract
{
    public interface IEchoContract
    {
        [OperationContract]
        string Echo(string text);
    }
}}

Und auf EchoSErvice.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace Service
{
class EchoService
{
    [ServiceBehavior(Name = "EchoService", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public class EchoService : IEchoContract
    {
        public string Echo(string text)
        {
            Console.WriteLine("Echoing: {0}", text);
            return text;
        }
    }}}

Habe ich zwei Fehler, ich bin kein Experte für C#
Also erstmal eins: Wenn ich EchoService : IEchoContract ich habe 

'EchoService': member names cannot be the same as their enclosing type

Zweiten, als ich die öffentliche Schnittstelle IEchoContract

'IEchoContract' : interfaces declare types

Also bitte helfen. Thx.

InformationsquelleAutor 404Dreamer_ML | 2011-03-01
  1. 2

    Haben Sie erklärt, das interface und die Klasse zweimal erklären jeweils nur einmal.

    IEchoContract.cs:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace Service
{
    [ServiceContract(Name = "EchoContract", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public interface IEchoContract
    {
        [OperationContract]
        string Echo(string text);
    }
}

    EchoService.cs:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace Service
{
    [ServiceBehavior(Name = "EchoService", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public class EchoService : IEchoContract
    {
        public string Echo(string text)
        {
            Console.WriteLine("Echoing: {0}", text);
            return text;
        }
    }
}
    InformationsquelleAutor Andrew Hare
  2. 1

    Sollten Sie in Ihrem code, den Sie haben eine Klasse namens EchoSevice innerhalb einer Klasse mit dem Namen EchoService

    namespace Service
{
  class EchoService
  {
    [ServiceBehavior(Name = "EchoService", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public class EchoService : IEchoContract
    ...

    Versuchen, das entfernen der äußeren Klasse, wie es hat keine Bedeutung hier

    namespace Service
{
  [ServiceBehavior(Name = "EchoService", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
  public class EchoService : IEchoContract
  ...

    Müssen Sie die Entfernung Ihrer äußeren Oberfläche auch, da sind auch zweimal definiert (wohl auch der Grund, warum Ihre Klassen endete definiert sich doppelt so gut)

    • Bitte posten Sie Ihre jetzt aktualisierte Schnittstelle und die Klasse als edit oben, so können wir sehen, was das problem ist und beheben Sie Sie nach den Anweisungen, die Sie gegeben haben, indem Sie die Fragen.
    InformationsquelleAutor Øyvind Bråthen
  3. 0

    Definieren Sie eine Klasse EchoService in der EchoService Klasse - das ist nicht möglich. Entfernen Sie einfach die äußere "class EchoService", und Sie sollten in Ordnung sein.

    InformationsquelleAutor TheEye
  4. 0

    In EchoService.cs, Sie können nicht rufen Sie die interne Klasse EchoService, da Sie bereits eine Klasse EchoService oben. Dazu müssen Sie eine von Ihnen.

    • Sorry dude, ich bearbeitet habe, die falsche Antwort 🙂
    • Hehe keine Sorge 🙂
    InformationsquelleAutor Ian Devlin
Schreibe einen Kommentar