Laden...
Avatar #avatar-3248.png
Christoph K. myCSharp.de - Member
Softwareentwickler Köln Dabei seit 15.02.2009 821 Beiträge
Benutzerbeschreibung

Forenbeiträge von Christoph K. Ingesamt 821 Beiträge

31.03.2011 - 21:36 Uhr

Auf LazyLoading (Laden beim Aufklappen der Items) möchte ich verzichten. Ich möchte den Benutzer nicht nerven, dass er jedes mal die Items aufklappen muss.

Hi Heimwerkerking.

Das verstehe ich nicht ganz. Wenn du LazyLoading richtig implementierst, merkt der Benutzer doch gar nichts davon, dass die Daten lazy geladen werden?

31.03.2011 - 10:49 Uhr

Hi Leute,
ich hab folgendes Szenario:

Eine Präsentationsschicht (GUI, etc.) arbeitet mit einer Logigschicht auf Clientseite zusammen. Die Domänendaten der Logikschicht des Clients müssen auf Serverseite persistiert werden. Hierzu stehen entsprechende Services zur Verfügung.

Nun kommt es teilweise vor, dass die Präsentationsschicht ganz viele kleine Änderungen hintereinander an dem gleichen Domänenobjekt vornimmt. Meine aktuelle Implementierung schickt hierbei für jede "kleine" Änderung das komplette Domänenobjekt zum Server.

Meine beiden Lösungmöglichkeiten, die ich mir überlegt habe:

  1. Die Präsentationsschicht (die bei meiner Implementierung weiß, dass noch weitere Änderungen unmittelbar folgen) ruft nach allen Änderungen eine UpdateCompleted()-Methode auf der Logikschicht auf, die die Logikschickt dazu veranlasst, die Änderungen zu speichern.

  2. Jegliche Änderungen der Logigschicht setzen für das jeweilige Domänenobjekt ein IsDirty - Flag auf true. In Regelmäßigen Abständen (ca. alle 100ms) guckt die Logigschicht dann nach, was sie so zu speichern hat.

Wie würded ihr es machen ?

Viele Grüße
Christoph

30.03.2011 - 10:47 Uhr

Zum Repository Pattern gibt es auch einen schönen Artikel bei Microsoft:
Design Patterns: The Repository Pattern

30.03.2011 - 09:22 Uhr

Im einfachsten Fall über Events oder Flag-Variablen:

Sobald sich dein Domänenobject ändert und es den Drang verspürt gespeichert werden zu müssen, setzt du im Domänenobject eine Bool-Eigenschaft IsDirty auf true und / oder lößt ein Event aus (DomainObjectChanged).

Beide Dinge kannst du (auch in Kombination) von außen adaptieren, ohne dass du spezifischen Persistierungscode in deine Domänenschicht einbringen musst.

Der unschöne Seiteneffekt ist, dass die Eingenschaften, die gespeichert werden sollen öffentlich sein müssen (oder zumindest internal).

Gruß
Christoph

29.03.2011 - 23:05 Uhr

Ich trenne Domäne und Persistenz, indem ich die Entitys aus den Domänenobjekten generieren lasse. Hierbei muss ich die nötigen Domänobjekteigenschaften öffentlich deklarieren. Meine Entitys haben dann die Funktionen

  • fromDomainObject(domainObject)
  • toDomainObject(domainObject, entity)

Falls man jetzt noch möchte, dass auch die Persistenzschicht die Domänenobjekte nicht kennt, muss man sich eine Adaptationsschicht basteln.

Speichern tue ich die Objekte meist, indem ich sie als "schmutzig" markiere oder BitteSpeicherMich-Events schmeiße.

Gruß
Christoph

29.03.2011 - 17:32 Uhr

Wo ist denn das Problem dabei, dass sich die Clients beim Server melden, wenn sie eine von Ihm bezogene Datei geändert haben?

Die Clients initialisieren ja eh die Verbindung zum Server, dann können sie ihm doch auch einfach ab und an mitteilen, wenn sie eine Datei modifiziert haben.

Gruß
Christoph

29.03.2011 - 11:11 Uhr

Bei mir ist das nicht so. Kann es sein, dass du irgendwo in deinem Closing-EventHandler, nochmal das Window zustäzlich durch this.Close() schließen willst?

29.03.2011 - 11:01 Uhr

Kannst du deine Codeausschnitt mal posten?

29.03.2011 - 08:44 Uhr

Das binden eines Brushes erfolgt ganz einfach, indem du diesen im ViewModel per Property anbiertest. Das Property muss einen öffentlichen getter haben.

public Brush GreenBrush { get; private set; }

Im View bindes du das ganze dann wie folgt:

Background={Binding GreenBrush}

Gruß
Christoph

29.03.2011 - 07:50 Uhr

Ich würde erstmal schauen, ob eine Gerade von a nach b das Hindernis trifft. Wenn nicht ist das der kürzeste Weg. Wenn die Gerade das Hinderniss trifft, dann vergleichst du Umlaufweg links mit Umlaufweg rechts.

28.03.2011 - 20:49 Uhr

Schonmal folgendes probiert:

<ItemsControl ItemsSource="{Binding Areas}">
            <ItemsControl.ItemContainerStyle>
                <Style>
                    <Setter Property="Canvas.Left" Value="100" />
                </Style>
            </ItemsControl.ItemContainerStyle>
..usw...
</ItemsControl>

Gruß
Christoph

28.03.2011 - 20:36 Uhr

Was probierst du da genau?
Bist du sicher, dass du das ItemsPanelTemplate und nicht das ItemsTemplate setzten willst ?

28.03.2011 - 17:45 Uhr

So weit ich mich erinnern kann wird das MouseButtonDown - Event bei Silverlight nicht geworfen.

Macht es mehr Sinn beim MouseButtonUp-Event die Position zu ermitteln und anhand dieser dann herauszufinden ob sich da ein RadioButton befindet...?

Kommt drauf an was du vor hast. Wenn du es mir sagst, sag ich dir ob es vielleicht ne bessere Methode gibt 😄

Gruß
Christoph

28.03.2011 - 16:35 Uhr
eine Instanz von Model erzeuge ich in meiner ViewModelBase.
Da meine ViewModels von dieser erben und ich in jeder View die Farben benötige.

Erben heisst aber nicht, dass alle mit der selben Instanz arbeiten! Es sei denn, du erzeugst eine statische Instanz (was du aber aus anderen Gründen nicht tun solltest).

Daher probiere dein Model (bzw. deine Domainlogik) immer eine Schicht tiefer zu halten als die ViewModel schicht und sie den ViewModels im Constructor zu injizieren.

Gruß
Christoph

28.03.2011 - 14:24 Uhr

Hi Scooby,

globale Variablen hört sich schon mal unschön an. Am besten gibst du jedem Objekt, was mit diesen "globalen" Variablen arbeiten soll eine Instanz von einem Objekt mit, indem du diese "globalen" Variablen verwaltest.

Diesem Verwaltungsobject kannst du dann auch direkt Events spendieren, die ausgelöst werden, wenn sich die Variablen ändern.

Dem ViewModel deines MainViews (dort wo sich die Hintergrundfarbe ändern soll) übergibst du auch eine Instanz (vermutlich wird sie auch dort erzeugt, da es ja eines der ersten ViewModels ist, das erzeugt wird). Hier reagierst du auf die Events dementsprechen, dass sich die Properties zur Bestimmung der Hintergrundfarbe ändern.

Gruß
Christoph

28.03.2011 - 12:11 Uhr

Auf unschöne Art:
Wenn du das Item bestimmen kannst, auf das das Kontextmenü angezeigt wird, erhälst du das ViewModel immer über den gecasteten DataContext des Items.

Auf schöne Art:
Das ViewModel des Items bestimmt sein ContextMenu schon im ViewModel, indem es auch hier die Struktur des Menüs durch ViewModels vorgibt. Das ContextMenu ist ja auch ein HeaderedItemsControl und der ItemsSource kann wiederrum an ContextMenuEntryViewModels gebunden werden. Da du die ContextMenuEntryViewModels auf ViewModel - Ebene erzeugst, hast du hier kein Problem anderen ViewModels zu erreichen.

Gruß
Christoph

28.03.2011 - 12:08 Uhr

Ja, das meinte ich mit Liste (hab mich wohl unglücklich ausgedrückt 😃 ).

Wenn du dein TabControl über ItemsSource befüllst, kannst du doch einfach die ItemsSource an eine durch ICollectionView gekapselte Liste binden. Durch ICollectionView bekommst du über die CurrendChanged Eigenschaft mit, wenn sich die Selection ändert. Im EventHandler setzt du die Content-Property des ContentControl (bzw. die Property an die die Eigenschaft gebunden ist) dann auf ICollectionView.CurrentItem.ParamUC.

Gruß
Christoph

28.03.2011 - 10:46 Uhr

Du hast also eine Liste von Controls (ChartsKomponenten) und möchtest das ContentControl jeweils an das aktuell (Im Tab ausgewählte) Item binden?

28.03.2011 - 10:12 Uhr

Hi Alexander.

INotifyPropertyChanged => "Ich erzähle allen, wenn sich ein Property von mir ändert"

Von daher muss die Klasse, die das Property beinhaltet die Schnittstelle implementieren und auch das Event auslösen, wenn sich eine Property ändert.

Eine expemplarische Implementierung wäre demnach (ungetestet!):

public event PropertyChangedEventHandler PropertyChanged;

		protected void RaisePropertyChanged( string propertyName )
		{
			if ( PropertyChanged != null ) {
				PropertyChanged( this, new PropertyChangedEventArgs( propertyName ) );
			}
		}

Und der entsprechende Raise in deinem Fall:

RaisePropertyChanged("ParamUC");

Gruß
Christoph

28.03.2011 - 10:08 Uhr

Du kannst dir als Fausregel merken, dass dieser Mechanissmuss (automatische Selektion der grafischen Repräsentation von 'Daten') überall dort greift, wo du DataTemplate bzw. HierachicalDataTemplate verwenden kannst. Das gilt somit für alle ItemsControls und ContentControls.

Die Datenhaltung solltest du auf jeden Fall von den ViewModels trennen. MVVM müsste eigentlich V-VM-M heisten, da es besagt: Der View baut sich entsprechen der ViewModel-Struktur auf, welche auf der Bearbeitung der zu Grunde liegenden Daten erstellt wurde.
Sehr viele Leute bringen immer wieder zu viel Funktionaltität in die ViewModel, die da nicht hingehört. Für mich dient diese Schicht lediglich der Aufbereitung der Domänenlogik für den View.

Gruß
Christoph

28.03.2011 - 09:43 Uhr

Hi Alexander!

Vorab: "Mode=TwoWay" sollte nen Binding-Fehler werfen, wenn du nur nen Setter in der Property hast.

Das geht generelle: "<ContentControl Content="{Binding Path=ChartsKomponenten.ParamUC, Mode=TwoWay}" />"

Wichtig ist nur, dass wenn du das Property aktualisiert, es dem Binding-Mechnismuss von WPF über die INotifyPropertyChanged - Schnittstelle mitteilst.

Viele Grüße
Christoph

28.03.2011 - 09:36 Uhr

Hi Fabian,

habe mal alles, was du so erzählt hast und was sonst noch so wichtig ist, versucht in ein Beispeilprojekt zu verpacken:

  1. Das Projekt arbeitet mit dem MVVM-Pattern
  2. Die Zweige des Baumes werden dynamisch auf Anfrage nachgeladen
  3. Der Datentyp des ViewModels bestimmt die Repräsentation im GUI (Selektion durch DataType- Eigenschaft des HierachicalDataTemplate)
  4. Items können Kinder haben oder nicht (Hierzu entweder die ItemsSource des HierarchicalDataTemplate ungebunden lassen, oder ein normales DataTemplate verweden, oder die an die gebundene Collection leer lassen)

Viele Grüße
Christoph

28.03.2011 - 09:13 Uhr

Da kann ich mir gerade noch nicht vorstellen, wie ich das lösen soll. Ich müsste quasi ein ItemTemplate fest mit einer bestimmten Klasse verbinden, d.h. immer wenn ein Objekt dieser Klasse im TreeView auftaucht, wird ein entsprechendes ItemTemplate verwendet.

Ist das möglich? Kann ich Klassen eine Art Darstellung zuweisen?

Möchtest du, dass unterschiedliche Daten eine vollkommen andere Repräsentation im TreeViewItem haben, oder geht es dir nur darum, dass manche TreeViewItems weitere Children haben und andere wiederrum nicht?

Ich werde gleich mal ein Beispiel erstellen.

Viele Grüße
Christoph

27.03.2011 - 21:41 Uhr

Das Problem wird sein, dass das DataTemplate, welches du der Eigenschaft TreeView.ItemsTemplate zuweist schon von alleine in ein TreeViewItem eingebettet wird. Dementsprechen bettest du dein abgeleitetes TreeViewItem wiederrum in ein TreeViewItem ein.
Die Selektion wird somit von inneren TreeViewItem abgefangen.

Schnelle Abhilfe kannst du schaffen, indem du statt eines normalen DataTemplates ein HierarchicalDataTemplate erzeugst. Dieses HierarchicalDataTemplate hat wiederrum die Eigenschaft ItemsSource um Child-Element aufzunehmen.

Auf dauer kann es jedoch sinnvoll sein, wenn du dir mal das MVVM-Pattern ansiehst. WPF schafft es durch dieses Pattern die Struktur (und die Logik) der Anwendung von der grafischen Repräsentation zu trennen.

Gruß
Christoph

27.03.2011 - 20:56 Uhr

Hallo Tarion,

Environment.TickCount?
Das läuft auch weiter, wenn der Admin die Uhr umstellt.

Wird diese Variable nicht nach jedem Neustart resettet?


@Tarion
Was willst du denn damit erreichen?
Wenn es sich um eine Anwendung handelt, die mit einem Server kommuniziert könntest du z.B. die Uhrzeit bei jedem Start der Anwendung übertragen und lokal hochzählen.

Ein anderer Ansatz wäre es Zeitserver zu verwenden: Zeitserver aus C# ansprechen

Gruß
Christoph

27.03.2011 - 20:51 Uhr

Würde ich niemals so machen. Verstößt ja schon gegen das Prinzip "Eine Klasse pro Datei" und führt unweigerlich zum durcheinander. Einzige Ausnahme, wo ich mir sowas denken könnte wäre, wenn man intern in einer Klasse Enumerationen verwendet.

Warum stellst du dir nicht einfach die Frage: Was spricht dagegen es auf die normale Art und Weise zu machen?

Gruß
Christoph

27.03.2011 - 20:47 Uhr

Was verstehst du genau unter "lässt sich nicht selektieren" ?

Bevor du dich verrennst folgender Hinweiß:
Es ist generell unüblich, in WPF grafische Elemente abzuleiten um Funktionalitäten zu ergänzen. Wenn du mir genau sagst, was du erreichen willst, kann ich dir einen eleganteren Weg aufzeigen, die Sache zu bewerkstelligen.

Viele Grüße
Christoph

27.03.2011 - 17:01 Uhr

Die Entscheidung, ob du einen Basisklasse erstellen sollst oder nicht, hat nicht wirklich was mit MVVM zu tun, sondern eher damit, ob du genügend Gemeinsamkeiten findest, so dass sich eine Basisklasse lohnt.

Ich z.B. lasse alle meine ViewModels von einer ViewModelBase-Basisklasse ableiten, da ich von vorne herreich möchte, dass jedes ViewModel INotifyPropertyChanged implementiert. Die Implementierung hierfür schreibe ich nicht jedes mal neu, sondern lagere sie in die Basisklasse aus.

Kleiner Typ am Rande: Wenn du ViewModels erzeugst, dann benenne Sie nach den Modellen, auf denen Sie basieren:

ViewModel zur Item-Darstellung eines Autos: AutoItemViewModel
ViewModel zur Details-Darstellung eines Menschens: MenschDetailsViewModel
usw.

Viele Grüße
Christoph

09.01.2011 - 10:24 Uhr

Hi Leute,
ich bin gerade am überlegen, ob ich die Silverlight-Controls von DevExpress oder Telerik kaufen sollte. Vom Funktionsumfang machen sie ja ungefährt das gleiche.

Hat jemand von euch Erfahrungen mit den Bibliotheken gemacht und kann mir Entscheidungshilfe leisten?

22.12.2010 - 15:56 Uhr

Hi Leute,
wie kann ich alle referenzierten Dlls einer Anwendung ermitteln, die ich selbst erstellt haben (also keine FW-Dlls) ?

Also mir würde es weigentlich schon genügen, wenn es irgendein flag gibt, dass mir sagt, ob die assembly im global assembly cache vorhanden sind oder nicht.
Gibt es sowas ?

Grüße

22.12.2010 - 09:12 Uhr

Das wäre auch noch eine schöne Lösung.

Danke für eure Hinweise!

20.12.2010 - 10:46 Uhr

Also der Cache ist global und verwaltet sowohl die Elemente von Object A und Object B, da alle Objecte von einer gemeinsamen Basisklasse ableiten.

20.12.2010 - 10:05 Uhr

@herbivore:
Genau diese Überlegung hatte ich auch schon angestrebt. Allerdings mißfällt mir der Gedanke, es dem Objekt selbst zu überlassen sich in den Cache einzutragen. Da das Repository ja ein Element ist, welches die Controlle über die Objekte hat, fände ich es nicht so schön, das die Objekte auch das Repository bearbeiten könnnen.

Oder was meinst du ?

20.12.2010 - 09:25 Uhr

Das Problem ist, dass es sich hierbei nicht um feste Referenzen hadelt, sondern um veränderliche. Die Zuordnung kann sich stetig varriieren. Im Prinzip fragt Object B bei der Erstellung erstmal nach, welche Referenzen es hat und erstellt diese bei Bedarf. Leider kann dieser Bedarf manchmal auch schon bei der Konstruktion auftauchen. Wenn ich alle jemals referenzierbaren Objekte übergeben würde, so würde ich alle Objekte in den speicher laden müssen.

20.12.2010 - 08:36 Uhr

Hallo Leute, ich programmiere zur Zeit ein System, welches aus sehr stark verknüpften Objekten besteht. Diese Objecte werde zum Anfang alle aus einer Datenbank geladen. Bisher werden die Verknüpfungen im Konstruktor der Objekte hergestellt. Die Verknüpfungen sprechen hierzu ein zentrales Repository an. Wenn das Objekt noch nicht in Repositiory (Cache) geladen ist, so wird es aus der Datenbank nachgeladen.

Mein Problem was ich habe: Wird im Konstruktoraufruf eines belibigen Objektes bereits auf ein Verknüpftes Object zugegriffen, so wird dieses durch den Konstrukteraufruf von Object A erzeugt. Spricht Object A erzeugt indirekt Object B, ohne das Object A zu Ende initialisiert wurde. Spricht Object B nun ebenfalls im Konstruktor Object A an, reagiert das Repository so, dass es wieder eine Object A erzeugen will, da dieses ja noch nicht vollständig erzeugt ist und somit auch noch nicht im Cache geladet ist.

Meine bisherige Lösung hierzu ist die späte Initialisierung: Ich erzeuge erst Object A, speicher es im Cache ab und rufe danach die Methodhe Object.LateInitialize(...) auf. Hierdurch kann ich zumindest sichergehen, dass Object A im Cache ist.

Meine frage: Geht es besser ? Kennt ihr noch andere Patterns zu lösung des Problems ?

Gruß & Dank
MA

16.12.2010 - 12:04 Uhr

verwendetes Datenbanksystem: noch offen, vermutlich db4o

Hi Leute,
ich habe im Moment folgendes Denkproblem.

Ich habe ein System, was aus einem Netz verknüpfter Objekte besteht. Diese Object haben alle die selbe Basis, können jedoch eine belibige Ableitung dieser Basis sein.

Die Objekte kommunizieren auch untereinander und können in einer belibiger Art und Weise miteinander verknüpft sein. Wir haben also eine Art Objektgraf, nur das wir keine definierten Assoziationen haben, sondern alle Objekte belibig assoziierbar sind.

Nun geht es darum, dieses Objektnetzwerk zu speichern:
Die Problematik die hierbei auftaucht, ist die Frage danach, was der beste Weg ist.

Der erste Einfall, den kompletten Objektgraf in Gänze zu persistieren und zu laden ist sehr einfach möglich, führt jedoch dazu, dass die Speicher und Ladevorgänge und die Arbeitsspeicherbelastung sehr groß ist (es handelt sich bei dem Objektnetz um ein netz aus mehreren 100.000 Objekten).

Der zweite Eifall von mir war, die Verbindungen (ähnlich eines relationalen Datenbanksystem) in den Objekten nur über die Identität (eine Id) zu speichern. Will Objekt A nun mit Object B kommunizieren, so muss es letzendlich eine Anfrage an die Datenbank stellen, Objekt B instaziieren und dann mit ihm kommunizieren. Der Nachteil hier ist es, dass für jede Kommunikationsanfrage ein Request an die Datenbank gesendet werden muss. Ihr könnt euch vorstellen, das dies unsagbar langsam wird, gerade wenn das System sehr viel interkommunikation durchführt.

Also meine Frage an euch: Wie würded ihr vorgehen?

Gruß & Dank

14.12.2010 - 09:42 Uhr

Hi Leute,
kennt jemand von euch ein Tool um die Code-Zeilen zu zählen ?
Also ich meine die Code-Zeilen der gesammten Solution.

Gruß & Dank

10.12.2010 - 15:55 Uhr

Hab grad gesehen, dass es das ContextMenu im Toolkit doch gibt. Deshalb gilt meine frage nun danach, ob es eine BestPractise gibt, dieses ContextMenue einzusetzten.

10.12.2010 - 14:13 Uhr

HI Leute,
könnt ihr mir sagen, was bei euch die BestPractise ist, um in Silverlight ein Kontextmenü einzubinden. Das ganze sollte möglichs MVVM - konform stattfinden.

Wie ich bisher weiß gibt es von Microsoft noch keinen vorgegebenen Weg, bzw. noch kein vorgefertigtes Control, daher wird man wohl nicht darum rumkommen eins selbst zu gestalten.

Gruß
MA

05.12.2010 - 12:33 Uhr

Das ist doch aber kein Problem. Lasse die Itemssoure von einer Basisklasse sein, von der HeaderVM und ItemVM ableiten. Im Datatemplate legst du dann verschiedene grafische Repräsentationen für HeaderVM und ItemVM fest.

05.12.2010 - 10:17 Uhr

Füge doch ein deinen ViewModels der Items zur Children-Source einfach immer einen statsichen Eintrag hinzu ?

05.12.2010 - 10:15 Uhr

Hallo zusammen,

ich benutez zur Zeit zur verwirklichung einer Client-Server-Lösung das MEF um auf Silverlight-Seite Assemblys zur Laufzeit hinzufügen zu können.

Bisher füge ich die Assemblys in Form von XAP - Dateien hinzu, indem ich sie mit dem DeploymentCatalog von einer bestimmten URI downloade.

Mit wäre es jedoch angenehmer, wenn ich die XAP-Dateien binär mit einem WCF-Service übertragen könnte, anstatt sie per URI bereit stellen zu müssen.

Ist dies möglich?

Gruß
MA

02.12.2010 - 13:19 Uhr

Hi Leute,

ich verwende den DataContractSerializer zur Serialisierun von Datenverträgen. Meine Datenverträge kennzeichne ich hierzu alle mit DataContract und die Properties die ich mit rein nehmen will mit dem DataMemberAttribute.

Leider nimmt der DataContractSerializer nicht nur die Properties mit, die ich kennzeichne, sondern auch öffentliche Properties, die serialisierbar sind.
Wie kann ich das unterbinden? Ich suche hier bewusst den weg, das er nur die Porperties serialisiert, die so geekennzeichnet sind.

Ich weiß, dass es bei DataContracs auch ein Ignore Attribute gibt, diesen Weg halte ich jedoch für sehr umständlich.

Gruß & Dank

02.12.2010 - 13:15 Uhr

Hier mal einen meiner Service-Facotrys, der Rest (deine speziellen Konfigurationen) sollten sich von alleine ergeben:

        /// <summary>
        /// Creates a new NetTcpService.
        /// </summary>
        /// <param name="baseUri">The base uri.</param>
        /// <returns>A new Instance of a NetTcpService.</returns>
        public static ServiceHost CreateNetTcpService(string server, int tcpServicePort, int mexPort, string endpointName, NetTcpService netTcpService)
        {
            // Creation the Uris.
            Uri mexUri = new Uri(string.Format("http://{0}:{1}/Mex", server, mexPort, endpointName));
            Uri serviceUri = new Uri(string.Format("net.tcp://{0}:{1}/{2}", server, tcpServicePort, endpointName));

            logger.DebugFormat("Creating new NetTcpService, ServiceUri: {0}, MexUri: {1}.", serviceUri, mexUri);

            // Creating the ServiceHost.
            ServiceHost serviceHost = new ServiceHost(netTcpService, serviceUri);
            
            // Define and configure the PollingDuplexHttpBinding.
            NetTcpBinding netTcpBinding = new NetTcpBinding();
        
            // Adding an Endpoint (with contract definition and endpoint definition).
            serviceHost.AddServiceEndpoint(typeof(INetTcpService), netTcpBinding, string.Empty);
            
            // Adding Metadata behavior.
            ServiceMetadataBehavior serviceMetadataBehavior = serviceHost.Description.Behaviors.Find<ServiceMetadataBehavior>();
            if (serviceMetadataBehavior == null)
            {
                serviceMetadataBehavior = new ServiceMetadataBehavior();
                serviceHost.Description.Behaviors.Add(serviceMetadataBehavior);
            }

            // Adding MEX endpoint.
            serviceHost.AddServiceEndpoint(ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpBinding(), mexUri);

            return serviceHost;
        }
02.12.2010 - 07:59 Uhr

Mir geht es nur um die Rohe definition, allerdings will ich nicht jeden Furtz in meinem reflektiertem Objekt, z.B. einer PropertyInfo auslesen und dann mühsam ins CodeDom übertragen. Ich dachte es gibt einen Weg die gesammten Informationen aus dem PropertyInfo Objekt in CodeDom zu übertragen um daraus ein entsprechendes Property zu erzeugen.

01.12.2010 - 16:04 Uhr

Hallo zsammen.

Was ist vorhaben ist, eine Klasse zu clonen, hierbei jedoch nur die öffentlichen Property-Member zu berücksichtigen.
Sonst soll jegliche Definition gleich sein.

Nun habe ich ja schon durch die Reflexion des Typen sehr viele Informationen zu den Sachen die ich erstellen will.
Gibt es eine einfach möglichkeit diese in das CodeDom-Modell zuübertragen?

zb. GenerateMemberFrom(PropertyInfo property);

???

28.11.2010 - 18:49 Uhr

Hey super, mit CheckAcess dürfe ich das auch so hinbekommen, wie ich es haben will, ich danke dir !

28.11.2010 - 18:30 Uhr

Hi Leute,
manche von euch hatten sicherlich schonmal das Problem, dass ihr z.B. bei der Entwicklung einer Bibliothek, den gleichen Code für das Zielframework .NET (native) und Silverlight schreiben musstet. Mein bisheriger Lösungsansatz war derjenige, dass ich ein native Projekt für .NET angelegt habe, dort "reelle" Dateien erstellt habe und diese Dateien per Link in meinem Silverlight - Projekt referenziert habe.

Dies nervt auf Dauer, gerade wenn jetzt noch irgendwann Windows Phone hinzukommt!

Seit Silverlight 3.0 ist es ja möglich, dass man Silverlight-DLLs auch unter .NET verwendet. Ich hab das ganze gerade mal evaluiert und so lange man kein plattformspezifischen Dinge einbindet, klappt es auf den ersten Blick relativ gut.

Es tun sich bei mir jedoch folgende Fragen auf:

  • Wirkt sich die Verwendung einer Silverlight.dll irgendwie auf die Performance aus, oder ist es lediglich ein Framework-Flag, was anders ist?
  • Wie kann man die Meldung des Compuilers "Auf das Projekt "SilverlightClassLibrary1" kann nicht verwiesen werden. Das Projekt, auf das verwiesen wird, hat eine andere Frameworkfamilie ("Silverlight") als Ziel." unterdrücken? Diese verhindert zwar nicht den Kompilierungsvorgang, nervt jedoch.

Vielen Dank
Ma

28.11.2010 - 18:22 Uhr

Hmm, also mein Problem ist folgendes:

Ich habe Threads, die Serviceaufrufe tätigen. Hierbei weiß ich jedoch nicht, ob die Threads "normale" Threads sind oder der UIThread sind. Wenn der Callback des Serviceaufrufs kommt, möchte ich deshalb genau an den Thread übergeben, der den Call ausgeführt hat.

Mein bisheriges Verständnis war, das ein Dispatcher ein Objekt ist, welches Code im Context eines (anderen) Threads ausführen kann. Daher dachte ich, dass ich den Dispatcher zu jedem belibiegen Thread bekommen kann.

Bitte klärt mich auf, wenn ich falsch liege.