Wenn bei BlogEngine.NET eine Erweiterung aus- oder eingeschaltet wird kommt eine Meldung die einem mitteilt, dass auf die Web.config nicht geändert werden kann. Das kommt daher, dass der ExtensionManager versucht, bei einer Änderung des Status einer Erweiterung, das Blog neu zu starten. Versucht wird das in dem die Web.config geringfügig verändert wird. Bei einer Änderung der Web.config wird das Web automatisch neu gestartet.

Um den Fehler zu verhindern müsste man dem Account, unter dem das Web läuft, schreibrechte auf die Web.config geben. Wenn man einen eigenen IIS hat ist das kein Problem. Bei einem Shared Hosting geht das aber nicht immer. Ich kann z.B. auf den Dateien im root-Verzeichnis keine Rechte ändern. Die Web.config ist also immer schreibgeschützt für die Webanwendung. Dann kommt immer der Fehler.

Man kann das Web aber noch anders neu starten. Mit HttpRuntime.UnloadAppDomain(); erreicht man das selbe ohne die Fehlermeldung und gefühlt schneller. Angepasst werden muss folgendes.

In der ExtensionManager.cs:

public static void ChangeStatus(string extension, bool enabled)
{
    foreach (ManagedExtension x in _extensions)
    {
        if (x.Name == extension)
        {
            x.Enabled = enabled;
            BlogEngine.Core.DataStore.ExtensionSettings xs = new BlogEngine.Core.DataStore.ExtensionSettings(x.Name);
            xs.SaveSettings(x);
            SaveToCache();

            //string ConfigPath = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath + "Web.Config";
            //File.SetLastWriteTimeUtc(ConfigPath, DateTime.UtcNow);

            HttpRuntime.UnloadAppDomain();
            break;
        }
    }
}

In einem aktuellen Projekt entwickeln wir ein Tool das auf WPF basiert. Da gibt es eine zentrale Windows Anwendung die je nach Bedarf UserControls nach lädt. Alle Module werden also in UserControls realisiert und bei bedarf nachgeldaden.

Da es aber in zwischen dutzende Module sind mit einigen 100 UserControls artet das natürlich in der Toolbar aus. Jedesmal beim Kompilieren ist in der Toolbar die Hölle los. Wenn man in der Toolbar auch temporär ein paar Code Snippets sammelt, sie sind danach immer wo anders. Das hat mich sowas von …

Die Lösung dazu ist aber gut versteckt. Will man nicht das die Toolbox automatisch aktualisiert wird muss man das dem Visual Studio 2010 explizit mitteilen.

Extras –> Optionen –> Text Editor –> XAML –> Sonstiges –> Checkbox entfernen bei “Toolboxelemente automatisch ausfüllen”

Danach sieht die Toolbar schon viel besser aus.

Nicht mehr so überladen wie vorher.

Die Kategorien müssen allerdings noch Manuel entfernt werden. Sie verschwinden nicht einfach so.

So, jetzt wieder an die Arbeit.

Da war einiges nötig bis ich den dreh raus hatte bzw. den richtigen Tipp bekam.

Anforderung:

Ich habe ein ArrayList mit Objekten vom Typ Person drin. ArrayList deshalb weil die Kollektion COM Visible sein muss. Generics funktionieren da nicht.

Ich wollte aber den Komfort, typsichere Abfragen zu machen, auch auf einem ArrayList haben. Wenn man mal den Dreh bei LINQ to Objects raus hat will man es nicht mehr abgeben.

ArrayList arl = new ArrayList();
arl.Add(new Person(){ID= .......}); 

arl.Add(new Person(){ID= .......}); 

arl.Add(new Person(){ID= .......}); 
  
Person person = arl.Where(p => p.ID == ID).FirstOrDefault(); //Geht nicht.

Lösung:

Person person = arl.OfType<Person>().Where(p => p.ID == ID).FirstOrDefault();

Einfach zwischen der Kollektion und Where ein OfType<T>() reinhängen.

Und wie gesagt, ich hätte gerne auf Generics zurückgegriffen. Aber COM Visible geht damit nicht.

Das gestrige Posting VS2010 – Wahnsinnig hilfreiche Fehlermeldung hat wohl ein bisschen Verwirrung verursacht. Ich weiss jetzt noch nicht genau bei wem. Bei mir oder den Lesern. Deshalb hier nochmals ein Versuch mich zu erklären.

Den Reaktionen nach zu urteilen ist einigen ein Feature von Visual Studio nicht bewusst. Ich habe einige Mails bekommen, da offensichtlich die Kommentarfunktion im IE nicht will. :-( ReCaptcha ist jetzt ausgeschaltet und es sollte auch möglich sein Kommentare aus dem IE zu erfassen. Also nur zu.

Also hier mal detaillierter um was es genau geht. Ich nehme mir mal die Freiheit ein Mail zu zitieren das schön zeigt was ich meine.

Du verstehst da was falsch. Ein startprojekt ist _NICHT_ ein projekt das ein fenster oder eine konsole öffnet, bzw. einen eintrittspunkt hat. Das startup projekt ist das projekt, das geladen wird, wenn du den debugger anwirfst.

Davon _kann_ es nur _eines_ geben. Und zwar das, das im solution explorer fett dargestellt wird.

Es gibt also nix zu suchen: alles was die vs mitteilen will ist, das du einmal in den solution-explorer reinsehen musst: das projekt, das in fetter schrift aufgeführt ist, ist als "start-up project" markiert. Es hat aber keinen eintrittspunkt. Es kann nur eines davon geben, und das sollte auch bei 210 projekten mit 3x scrollen machbar sein. (zumindest auf meinen monitor passen ca. 90 projekte unternander...)

Der Autor des Mails geht davon hier aus.

Mit einem Rechtsklick auf ein Projekt kann dieses als Startprojekt definiert werden. Das ist dann fett markiert im Solution Explorer. Das ist auch die Regel. Ergebnis ist dann folgendes (F5).

In dieser Situation gebe ich allen recht die sagen, es kann doch nicht schwierig sein das richtige Projekt zu finden. Auch wenn ich 210 Projekte haben. Stimmt. Gebe ich euch recht.

Aber, und jetzt kommt das aber, Visual Studio kann mehr als NUR EIN Projekt starten. Diesen Dialog muss man aber kennen.

Rechtsklick auf der Solution und dann “Startprojekte festlegen”. Es heisst ja schon wunderbar Startprojekte.

Es erscheint folgender Dialog.

Und hier kann man definieren welche Projekte gestartet werden sollen. Ich habe jetzt alle auf starten gestellt. Zwei Konsolen, eine WPF Anwendung und eine Klassen Library. Es darf erwartet werden (F5) das die Fehlermeldung kommt.

Im Solution Explorer ist jetzt kein Projekt mehr fett markiert. Wenn man mehr als ein Projekt startet gibt es das “fette” Projekt im Solution Explorer nicht mehr.

Und jetzt nochmals. Wie so wird mir nicht gesagt welches Projekt nicht gestartet werden kann? Bei den 4 hier ist es noch einfach und ofensichtlich. Bei 210 Projekten ist es nicht mehr so einfach. Vor allem kann nichts sortiert werden. Ich kann also nicht kurz alle Projekte die gestartet werden an einen Haufen sortieren. #fail

Ich nehme also die ClassLibrary1 aus den Startprojekten raus.

Und jetzt tut es. Sieht so aus.

Also nochmals. Visual Studio kann mehr als ein Projekt auf einmal starten. Es kann auch mehr als ein Projekt debuggen. Und das ist ein sehr wertvolles Feature.

Im aktuellen Projekt haben wir für jedes Modul einen eigenen WCF Host. Diese müssen gestartet werden wenn man die Anwendung testen will. Wie sollten nun die 19 Hosts, die in einer Konsole realisiert sind, gestartet werden wenn nicht über dieses Feature? Über einen Batch oder so? Ich will die ja auch debuggen können.

Das sieht dann so aus. Nebst der eigentlich Anwendung werden noch 19 WCF Hosts gestartet.

Also viel Spass beim finden des falsche selektierten Eintrages in einer Liste mit 210 Projekten wenn einem Visual Studio zwar sagt das eines Falsch ist aber nicht welches.

So, hoffentlich ist mein Frustgrund genügend ausführlich erklärt. :-)

Ach ja. Diese Einstellungen sind Userspezifisch. Wenn also die *.suo Datei abhanden kommt macht man die Einstellungen nochmals. Und der Dialog ist nicht wirklich Userfreundlich.

Nett der Hinweis. Aber hilfreich ist er nicht.

Es seien nur mal die anzahl Projekte erwähnt. 210 Stück. Viel Spass beim suchen. Das werde ich jetzt nämlich machen müssen.

Ach ja. Ich habe auch in keinem “Ausgabe” Fenster irgend einen Hinweis gefunden.

Ach ja zwei. Spasseshalber habe ich auch noch die Eventlogs von Windows 7 angeschaut. Vielleicht gibt es dort ja einen Eintrag mit der Info um welches Projekt es geht. Na, was denkt ihr?

Genau.