NerdonRails

smells like Team Foundation Server mit Sharepoint-Integration

ich werfe mal IronJS in den Raum, eine Javascript-Implementierung in F# die auf der DLR aufsetzt, evtl gehts damit

Ich würde das ganze via Rekursion lösen: var rootElements = acc.GetRootElements(allItems); var result = acc.BuildTree(rootElements, allItems); public class Item { public Int32 Id { get; set; } public Int32? ParentId { get; set; } public List<Item> Children { get; set; } public Item(Int32 id, Int32? parentId = null) { this.Id = id; this.ParentId = parentId; } } public class TreeAccumulator { public IEnumerable<Item> GetRootElements(IEnumerable<Item> allItems) { var rootElements = from current in allItems where current.ParentId == null select current; return rootElements; } public IEnumerable<Item> BuildTree(IEnumerable<Item> itemsToBeProcessed, IEnumerable<Item> allItems) { foreach (var current in itemsToBeProcessed) { var children = from actual in allItems where actual.ParentId == current.Id select actual; current.Children = children.ToList(); this.BuildTree(current.Children, allItems); } return itemsToBeProcessed; } }

Einfach die Spalte als Identity definieren und gut ist.

Nein, Extension-Methods kann man im Gegensatz zu normalen Methoden wie von dir Aufgeführt auf ein Objekt aufrufen. Also sowas wie myTreeView.Refresh() anstatt MyStaticClass.NormalRefresh(myTreeView). Syntaktischer Zucker der zu besserer Lesbarkeit beiträgt. Weiterhin bieten Extension-Methods die möglichkeit, Klassen, die sealed sind um Methoden zu erweitern. So könnte man z.B. Int32 um eine IsEven()-Method erweitern. public static class Extensions { public static Boolean IsEven(this Int32 value) { return value % 2 == 0; } } 2.IsEven() // => true Weiterhin wäre das ref bei deiner Methode nicht nötig, da alles bis auf Datentypen die von Struct ableiten (Int32, Double, enums etc.) Referenzdatentypen sind.

Das liegt daran das DoEvents der fiese weg ist eine Forms-Applikation reaktiv bleiben zu lassen auch wenn der Thread mit krams ausgelastet ist, sprich die Form reagiert / wird dann neu gezeichnet und friert nicht ein. Bei einer Konsolen-Applikation muss nichts neu gezeichnet werden, zumindest nicht in der Art wie bei Forms-Applikationen. Deswegen ist DoEvents auch nur im System.Windows.Forms-Namspace vorhanden, dessen Assembly bei Konsolenanwendungen jedoch nicht referenziert wird da unnötig.

public static class ExtensionMethods { public static void Refresh(this UIElement uiElement) { uiElement.Dispatcher.Invoke(new Action(() => {}), DispatcherPriority.Render); } } Evtl. mit dem Code oben das element neu rendern.

Wie bei allem was nur begrenzt Sinn ergibt gilt folgendes: weil mans kann

Ok, dann werfe ich folgendes in den Raum: Die Exe als Launcher und der Rest wird in DLLs verpackt die dann via IoC (z.B. Microkernel) zur Laufzeit nachgeladen werden. Das dürfte dem noch am nächsten kommen.

Indem man das Programm ausführt. Was im danach im Speicher passiert steht hier: C# Heap(ing) Vs Stack(ing) in .NET: Part I Sonstige Stichworte: C, Pointer, Heap, Stack

IL, ByteCode, CaaS => Google CLR With C#, Third Edition => Amazon

no problem

adapterB würde dir hier z.B. ein StoreAllContinuation-Objekt zurückgeben das WithDataFrom() zur Verfügung stellt welches eine DataCollectContinuation zurückgibt die dann mit einem instanzierten DataTransformator die Daten aufbereitet und der ersten Continuation zur Verfügung stellt. Be der Komposition der Klassen ist dann etwas Phantasy und Arbeit gefragt. Die Lösung dürfte dann aber sauberer, wiederverwendbarer und besser lesbarer sein.

service ist nicht gleich webservice. Über "Add ServiceReference" können meines wissens nach nur soap-services direkt konsumiert werden, da nur soap dinge wie objekt-metadaten zu objekt-serialisierung mitliefert (ok, VS versteht da auch OData, mein Fehler) Also entweder einen entsprechenden WCF-Soap-Service erstellen und den dann mit VS-Boardmitteln konsumieren, oder z.B. einen Rest- oder OData-Service via WCF schreiben und den dann evtl manuell verarbeiten oder einen Windows-Service schreiben der auf einem bestimmten Port auf eingehende verbindungen hört und den ganzen kram von nochmal von Hand nachimplementieren.

render :partial => 'editCustomer', :customer => @customer <% form_for :customer, customer, :url => { :controller => "customers", :action => "editCustomer", :remote=> true } do |f| %> <%= f.label :name %><br /> <% if @customer != nil %> <%= f.text_field :name %> <% else %> Objekt ist Nil <% end %> <% end %>

Ist aber ein sauberer Ansatz

Das klingt für mich nach Tests

Wenn du unit-tests gegen mit Linq2Sql oder EF fahren willst, würde ich dir empfehlen, den Datenkontext zu mocken. Der Datenbank-Ansatz ist ab einer gewissen Test-Anzahl einfach nicht mehr performant genug um die Test mehrmals am Tag laufen zu lassen. Als erstes braucht man dafür ein Objekt das Mock-Objectset dastellt: public class MockedObjectSet<T> : IObjectSet<T> where T : class { public MockedObjectSet(List<T> entityList) { if (entityList == null) { throw new ArgumentNullException("entityList"); } else { repository = entityList.ToList(); } } IList<T> repository; #region IObjectSet<T> Members public void AddObject(T entity) { repository.Add(entity); } public void Attach(T entity) { this.AddObject(entity); } public void DeleteObject(T entity) { repository.Remove(entity); } #endregion #region IEnumerable<T> Members public IEnumerator<T> GetEnumerator() { return repository.GetEnumerator(); } #endregion #region IEnumerable Members System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return repository.GetEnumerator(); } #endregion #region IQueryable Members public Type ElementType { get { return typeof(T); } } public System.Linq.Expressions.Expression Expression { get { return repository.AsQueryable<T>().Expression; } } public IQueryProvider Provider { get { return repository.AsQueryable<T>().Provider; } } #endregion #region IObjectSet<T> Members public void Detach(T entity) { this.DeleteObject(entity); } #endregion } Danach eine kleine extension die das erstellen des Mock-Objektes übernimmt: public static class MockExtensions { public static IObjectSet<T> AsObjectSet<T>(this List<T> entities) where T : class { return new MockedObjectSet<T>(entities); } } Als nächstes muss man aus der Klasse die von ObjectContext erbt ein Interface extrahieren. Das Interface wird benötigt um, z.B. in meinem Fall mit RhinoMocks, ein gemocktes Objekt zu erstellen. IDatabaseEntitiesContainer context = MockRepository.GenerateStub<IDatabaseEntitiesContainer>(); List<Customer> customersList = new List<Customer>() { customer }; IObjectSet<Customer> customers = customersList.AsObjectSet(); context.Stub(stub => stub.Customers).Return(customers); Über den gemockten Context kann man nun in aller Ruhe, nachdem man ihn mit Daten befüllt hat, linq-queries und Datenbank-Operationen testen ohne eine Datenbank anpacken zu müssen.

dreist

Stichwort: Kommandozeilen-Argument ?

Also für das Erstellen von Emails haben sich für mich XSLT-Templating & XSLT-Transformation als hervorragende Lösung herausgestellt. XSLT-Transformation sollte auch für das Erstellen von Textdateien funktionieren.

Im Zweifel: public void MyMethod<GenericParameter>() { string s = ""; Type t = s.GetType(); List<GenericParameter> l = new List<GenericParameter>(); } Ansonsten kann man generische Datentypen per Reflection erstellen. Siehe How to: Examine and Instantiate Generic Types with Reflection

falls du linq in verbindung mit sqlite benutzen möchtest, gibt es hier: LINQ with SQLite (linqtosql) - Stack Overflow eine ganze Reihe an Providern (Closed & Open Source)

ich würde dir statt sqlite, wenn es denn lokal sein muss, lieber zum SQL Server Compact raten, da man so technlogisch im Microsoft-Raum bleibt und nicht externen kram einbinden muss. SQL Server Compact gibt einem dann, ebenso wie sqlite, eine lokale Datenbank. Referenz: Entity Framework (SQL Server Compact) Und wenn du ganz verzweifelt bist nimm Access.

Funky: "reverse me".Aggregate("", (acc, c) => c + acc); Langweilig: new String(text.Reverse().ToArray())