ASP.net kennt die Referenzen nicht, da es kein Projekt, sondern eine Anwendung ist. Es sucht die gebrauchten assemblies im \bin Ordner, wenn sie in \build liegen, werden diese natürlich nicht gefunden.
Einem IOrderedEnumerable kannst du nichts hinzufügen, es ist eine sortierte Sequenz. Du kannst natürlich über List<T> l = new List<T>(input) eine Liste draus machen, allerdings ist diese nicht mehr sortiert.
Es gibt eine 64 bit und 32 bit Version der dll (da kommste auch net drumherum, weils auf unmanaged APIs zugreift, wenn ich mich recht erinnere). Auf deinen Entwicklungsrechnern funktioniert es, weil die verschiedenen Versionen im GAC sind, aber auf den anderen nicht, weil du entweder die 32 bit Version auf 64 bit ausführen willst oder umgekehrt.
Zwei Möglichkeiten:
1. Mit einem Installer richtig ins GAC schreiben
2. Ohne Installer eine 32 bit und eine 64 bit Version mit der entsprechenden DLL anbieten.
Ich benutz zumeist Entity Framework. Ist durch die Autogeneration sehr einfach zu bedienen, macht aber bei komplexeren Schemas öfters kopfzerbrechen. Nachteil wäre außerdem die fehlende platform unabhängigkeit.
public void startTimer()
{
snaketimer.Interval = 25;
snaketimer.Tick += new EventHandler(snaketimer_Tick);
snaketimer.Start();
}
Jedes Mal, wenn du das Spiel neustartest, wird ein weiterer EventHandler hinzugefügt, somit wird snaketimer_Tick im ersten Spiel einmal pro Tick, im zweiten zweimal, im dritten dreimal etc aufgerufen. Da es auch ohne die Methode funktioniert, wirst du den Timer im Designer erstellt haben und dort auch die snaketimer_Tick als Handler hinzugefügt haben. Du brauchst die explizite Registrierung also nicht.
Es gibt auch container, die das injecten über eine property zulassen, und das zumeist auch lazy, d.h. erst wenn du es brauchst. Um irgendeine Referenz auf dein Logging interface wirst du aber nicht herum kommen.
Die Datei liegt unter (Win 7) %localappdata%\Local\company\programm_guid
Der Pfad ist tatsächlich abhängig vom Ort des Programmes, selbst die Debugversion im VS hat einen eigenen.
Persönlich würde ich das selber serialisieren und in %appdata% schreiben. Ich denke mal, dass es um eine Benutzungsbeschränkung geht? Bei normalen Benutzern dürfte das ausreichen, bei programmierern wird sowas simples eh nichts bringen, vorallem wenn du den sourcecode nicht obfuscatest.
Haben sie endlich die contentfarmen gekillt? Gut so! Es geht einfach nur tierisch auf die Nerven, wenn man nen SO post findet, merkt, dass es nicht das Problem ist, und dann erstmal 10 Seiten rausfiltern kann, weil es GENAU der gleiche Post ist.
Bis jetzt nichts festgestellt, was meine Suchgeschwindigkeit ändert.
tom-essen wieso denn das?
Das sind doch die Standardmethoden die das .NET Framework bereitstellt.
Du solltest dich an die naming conventions im framework halten, dann treten solche Missverständnisse nicht auf - XMLEdit sollte hier xmlEdit oder xml heißen, damit klar wird, dass es eine lokale variable ist. XMLEdit deutet durch die Großschreibung am Anfang auf eine Klasse hin.
.. na dann teste doch mal den RAM, wie es die Fehlermeldung schon besagt.
Ich bezweifel, dass es am RAM liegt. Eher wird im code versucht auf Speicherbereiche zuzugreifen, die dem Prozess nicht gehören, und da hat die managed Umgebung natürlich was gegen.
seit kurzem wird jeweils der Post, der unter der Maus ist, komplett mit underline versehen. Das trägt der Lesbarkeit nicht wirklich bei, wo genau ist der Sinn dahinter?
Du musst dir überlegen, wie genau die Daten eingelesen werden, und woran die einlesende Funktion erkennen soll, dass zb. ein integer, oder ein string mit Länge X oder oder oder anfängt.
Das hört sich nicht nur komplex an, es ist es auch. Am besten solltest du dir angucken, wie andere (offene) Datei bzw. Übertragungsformate es anstellen (Stichwort Header, Opcodes).
Ich würde nur den identifier in der db speichern, und die styles als resourcen. Somit hast du default styles und lädst dann dynamisch je nachdem welcher identifier aus der db kommt.
Benutzt du zufällig T4 Templates und generierst code aus der assembly? wenn ja, guck dir mal die T4 Toolbox extension sowie die dort enthaltene T4Toolbox.VolatileAssemblyProcessor für das VolatileAssembly tag an.
Du musst K, L auf Referenztypen restriktieren (also where K : class in der Methodendefinition, siehe Generische Typenbeschränkung). Damit du die id property benutzen kannst, muss K bzw L natürlich diese properties bieten, also müssen sie ein interface implementieren. Somit sähe die Beschränkung so aus:
public void Method<K, L>() where K : class, ISomething, where L : class, IAnything
{
}
Wenn man den Post zur Hand nimmt, dann ist aber schon die Fragestellung im ersten Post inkonsistent zur Überschrift ;)
Ich würd trotzdem gern eine Antwort dazu setzen.
Und zwar gestaltet sich meine Benutzung aktuell zwar noch im Rahmen der DI/IoC ("So while MEF can be used for composition, that's merely a small intersection of its capabilities relative to other IoCs", MEF (Managed Extensibility Framework) vs IoC/DI), aber da ich in Zukunft plane, Plugins zuzulassen, wird mir MEF da gut helfen können.
Okay, das war die technische Erklärung... der eigentliche Grund ist aber eher, dass es die erste DI/IoC Implementierung war, die mir beim Verständnis sehr geholfen hat. Erst dadurch habe ich wirklich gelernt, in DI zu "denken". Ich hatte zuvor sowohl Castle Windsor als auch Hiro versucht, was aber nicht auf Anhieb funktioniert hat. MEF dagegen war in der WAF Doc als Beispiel benutzt, und da ich da zuerst mit DI richtig in Berührung kam, habe ich es übernommen.
Ganz klar, es fehlt eine Configuration, die Assemblies werden bei jedem Startup gescannt, dadurch ist es schwer, den Dependency Tree wirklich zu testen. Ist neben der höheren Startupzeit gewiss ein Nachteil, ich denke aber, dass es sich mit den Vorteilen im Plugin Bereich definitiv lohnt.
Wenn du es weiter diskutieren möchtest, kannst du mir gerne eine PM schreiben.