Die 1. Preview vom ASP.NET MVC Framework ist draußen und ScottGu & Phil Haack haben bereits darüber gebloggt. Eine große Neuheit ist der Razor Syntax. Da das Tooling in diese Preview noch nicht soweit ist, fehlt standardmäßig jegliche Syntaxhighlighting in den “cshtml”. Mit einem kleinen Trick bekommt man wenigstens HTML Syntax Highlighting in den Views.

So sieht es nach der Installation aus: 

Etwas trist. Das wird sich aber bis zum Release von MVC 3 natürlich noch verbessern. Hoff ich jedenfalls

Trick zum HTML Syntax Highlighting

Rechtsklick auf eine “.cshtml” dann “Open with…”/”Öffnen mit…” auswählen und dort den HTML Editor auswählen. Wichtig wäre noch das man auf die Auswahl als “Default” markiert, damit man diese Prozedur nicht ständig wiederholen muss.

Danach hat man immerhin einfaches HTML Syntax Highlighting:

Diese einfachen, aber effektiven Tipp hab ich von Tatham Oddie. Super Idee, solange das MVC Tooling noch nicht fertig ist.

Ein Blick auf die Preview lohnt.

ShareThis

Der Extension Manager

Wer noch nie den Extension Manager erblickt hat, sollte unter “Tools” –> “Extension Manager” ihn mal aufmachen. Dort gibt es drei große Bereiche:

• Plugins welche ihr schon installiert habt.
• Die Online Gallery (quasi der AppStore)
• Und Updates für bereits installierte Plugins

Die meisten Plugins sind kostenlos, allerdings sind dort auch die professionellen Toolhersteller mit vertreten und man bekommt eine Testversion oder sonst was zum Download. So sieht er jedenfalls aus:

Die ersten beiden finde ich persönlich echt nützlich. Wer einen TFS hat wird sich auch über die TFS Power Tools freuen. Den Rest hab ich allerdings noch nicht wirklich ausprobiert

Productivity Power Tools

ScottGu hatte über die erste Version einen größeren Blogpost geschrieben. Seitdem ist aber auch ein neues Update rausgekommen. Dieses Update bringt z.B. den “Solution Navigator” mit – ein deutlich verbesserter Solution Explorer mit Suche und mehr Details. Fetzt.

Download entweder von hier oder per Extension Manager.

Power Commands

Die Power Commands erweitern das Kontext menü um ein paar Punkte. Einige davon sind recht praktisch.

Download entweder von hier oder per Extension Manager.

ShareThis

Ältere Posts editieren – ein Krampf

Entweder man nimmt den eingebauten WYSIWYG Editor von Wordpress/BloggingPlatformXYZ oder man lädt sich alle Artikel über “Datei –> Öffnen –> Blog”. Nachdem das Tool ewig die Liste erstellt hat, darf man dann noch ewig den richtigen Post suchen. Da ist User Experience groß geschrieben wurden

Das “Plugin” was Abhilfe schaff.

Zum Glück hat sich ein Microsofti entschieden ein kleines Plugin zu schreiben. Allerdings ist es kein gewöhnliches Windows Live Plugin, sondern eigentlich nur ein URL Handler. Über die Eingabe einer speziellen URL in den Internet Explorer öffnet sich der Windows Live Writer und lädt den entsprechenden Post runter.

Download & Install

Das Plugin kann man hier runterladen & installieren.

Ältere Posts editieren

Um einen älteren Post zu editieren gebt einfach eine URL nach folgenden Schema in den Internet Explorer ein (vielleicht geht auch Firefox, im Chrome ging es jedenfalls bei mir nicht) :

wlw://example.com/?postid=yourPostId

Die Post-Id findet man z.B. auch im Admin Bereich von Wordpress in der URL, wenn man einen Post editiert.

ShareThis

Vor einer ganzen Weile habe ich bereits darüber gebloggt, wie man das Email-Senden ohne einen richtigen SMTP Server auf seinem Entwickler PC testen kann. Über diverse Blogposts, z.B. dem hier von Alex, bin ich auf Smtp4Dev gestoßen. Fazit: Funktioniert gut & ungemein praktisch.

Smtp4Dev

Smtp4Dev ist ein kleines Tool, welches in der System Tray läuft und auf Port 25 lauscht. Wenn eine Mail eingeht, kommt auch ein kleine Info-Box:

Es gibt auch eine Übersicht mit allen eingegangen Mails:

Über “View” wird das Standard-Email Programm gestartet. Über “Inspect” kann man Details der Mail anschauen:

Was müsst ihr tun, damit es funktioniert?

• Smtp4Dev downloaden & installieren
• Sichergehen dass das Tool auch auf Port 25 lauscht:
• In der web.config die Smtp Settings auf Network & Localhost setzen:

	<system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network host="localhost"/>
      </smtp>
    </mailSettings>
	</system.net>

Mein Beispielcode stammt noch aus dem alten Blogpost, nur mit der Änderung in der web.config (& das ich es mit VS2010 bearbeitet habe)

[ Download Democode ]

ShareThis

Sobald mit mit VS2010 eine Solution öffnet, welche mit VS2008 erstellt wurde und unter .NET 3.5 oder älter läuft, kommt sofort der Konvertierungswizard und fragt ob man auch die .NET Framework Version 4.0 haben möchte.

Nach der Konvertierung wurden auch automatisch die MVC 2 dlls hinzugefügt. Für VS 2008 gibt es auch einen Konverter, weil man diverse Änderungen in den web.configs machen muss.

MvcHtmlString

Die Helper im MVC 2 geben nun ein MvcHtmlString anstatt eines einfachen Strings zurück. Das kann z.B. beim ActionLink Helper zu Problemen führen, da der MvcHtmlString nicht die Methoden eines normalen Strings enthält (z.B. Substring)

ValueProvider

Der Zugriff auf die ValueProvider ist jetzt anders geregelt. War vorher der Zugriff so:

ViewContext.Controller.ValueProvider["Bla"].AttemptedValue

So ist er nun so:

ViewContext.Controller.ValueProvider.GetValue("Bla").AttemptedValue

Render View To String

In einem HowTo ging es darum, wie man das Ergebnis eines Views als String zurückbekommt um dies z.B. für Email-Templates zu verwenden.

In diesem Stackoverflow Thread gibts auch eine MVC 2 kompatible Lösung.

RedirectToAction<>

Auch im neuen MVC 2 Framework gibt es kein streng typisiertes RedirectToAction. Dies befindet sich wieder in den Futures.

Für das Deployment

Wichtig ist natürlich auch, dass im IIS alles richtig konfiguriert ist.

Mehr Schwierigkeiten sind uns jedenfalls nicht aufgetreten – happy upgrading

ShareThis

Es kann ab und an sehr nützlich sein in die Interna des Frameworks reinzuschauen. Das sollte auch mit allen Libraries im .NET Framework mit ein paar Handgriffen funktionieren.

VS2008?

In dem Blogpost sind die Schritte mit VS2010 aufgezeigt. Mit VS2008 sollte es aber auch gehen, allerdings habe ich dies dort nie geprüft und bin eigentlich durch diesen Blogpost mal wieder auf die Möglichkeit aufmerksam geworden.

Tools –> Options –> Debugging

Die Einstellung müssen genau so eingerichtet sein:

Symbol Server einrichten

WIchtig ist es, dass man den Haken bei dem MS Symbol Server macht. Weiter unten kann man entweder sagen “Lad alle Module die du brauchst” oder man beschränkt sich auf ganz bestimmte, wie z.B. System.Data oder System.Web.Mvc für die ASP.NET MVC Geschichten.

Debug

Wenn man jetzt irgendwo einen Breakpoint setzt und ins Debugging geht, werden erst mal die Symbols runtergeladen – das kann eine kleine Weile dauern:

Dann noch die EULA akzeptieren:

Und fertig – jetzt sollte man irgendwo im .NET Framework sein

Unicode Fehlermeldung:

Komischerweise bekomm ich auf meinem System eine Fehlermeldung, dass etwas mit dem Encoding nicht stimmt. Debugging geht trotz der etwas lästigen Fehlermeldung.

Mehr Symbol Server von Microsoft

Das Microsoft Reference Source Code Center stellt alle Symbol Server bereit. Dort gibt es auch nochmal diese Anleitung. Viel mehr als das .NET Framework bieten Sie allerdings auch nicht wirklich an.

ShareThis

Für die Testbarkeit – das Szenario

Wir haben den simplen HomeController:

    [HandleError]
    public class HomeController : Controller
    {
        private IFooService _fooService;

        public HomeController(IFooService fooService)
        {
            this._fooService = fooService;
        }

        public ActionResult Index()
        {
            ViewData["Message"] = "Welcome to ASP.NET MVC!" + this._fooService.Bar();

            return View();
        }

        public ActionResult About()
        {
            return View();
        }
    }

Dieser nimmt im Konstruktor eine Implementation von IFooService entgegen. Der FooService wird in der Index Methode gebraucht. In einer realen Anwendung könnte dies z.B. ein Repository sein.

Der FooService:

    public interface IFooService
    {
        string Bar();
    }

    public class DummyFooService : IFooService
    {
        public string Bar()
        {
            return "DummyFooBar";
        }
    }

Durch den Einsatz des Interfaces könnten wir dies z.B. in einem UnitTest mocken.

Knackpunkt: Die Objekterzeugung

In einer normalen Anwendung könnte man, wie z.B. in diesem Post erklärt, recht einfach über den IoC Container die Implementation reingeben. Allerdings wird ein Objekt zum HomeController vom MVC Framework erzeugt – dies übernimmt die DefaultControllerFactory.

Zum Glück kann man auch eine eigene ControllerFactory schreiben. So würde es im Grunde aussehen:

// nur für Demozwecke. Im richtigen Beispiel nutze ich MvcContrib
public class ControllerFactory : IControllerFactory
{
    public IController CreateController(RequestContext context, Type controllerType)
    {
        return IoC.Resolve<IController>(controllerType.Name);
    }
}

Es gibt im MVC Framework momentan noch ein paar Ecken wo man nur über Umwege die Objekterzeugung steuern kann. Bei ActionFiltern wird es z.B. etwas kniffliger (geht aber wohl auch – vielleicht ein anderer Blogpost). Dies soll aber mit MVC3 besser werden

MvcContrib

Ich nutze dafür aus dem MvcContrib Projekt die WindsorControllerFactory, benötigt werden aus den vielen DLLs lediglich zwei:

Der Einstiegspunkt – Global.asax

In die Global.asax habe ich einfach noch eine “Bootstrapper” Methode eingebaut:

        protected void Application_Start()
        {
            Bootstrapper();

            AreaRegistration.RegisterAllAreas();
            RegisterRoutes(RouteTable.Routes);
        }

        private void Bootstrapper()
        {
            IWindsorContainer container = new WindsorContainer();
            // IFooService with DummyFooService
            container.Register(AllTypes.Pick().FromAssembly(typeof(MvcApplication).Assembly)
                    .WithService.FirstInterface());
            // Controller
            container.RegisterControllers(typeof(HomeController).Assembly);

            // Set the controller factory
            ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(container));
        }

Durch das nutzen der “WindsorControllerFactory” müssen auch alle Controller registriert werden. Dies geschieht in Zeile 16. In Zeile 19 wird dann die ControllerFactory gesetzt.

Fertig. Die richtige Implementation landet beim Aufruf des HomeControllers auch dort wo sie hin soll.

Für andere IoC Container

Phil Haack hat z.B. ein Post mit StructureMap gemacht. In diesem Post wird es mit Spring.NET gemacht.

Wenn es komplexer wird

In diesem Post von Corey Coogan ist ein komplexeres Beispiel erläutert. Jedenfalls hat mir der Blogpost recht viel gebracht und mein Blogpost soll es nur (etwas simpler) wiedergeben.

[ Download Democode ]

ShareThis

Für ein weiteres Jahr wurde ich von Microsoft mit dem ASP.NET MVP Award geehrt.

Allen anderen MVPs, welche auch renominiert wurden oder neu ernannt, gratuliere ich natürlich auch.

ShareThis

Das man mit SketchFlow UI Prototypen bauen kann, ist ja kein großes Geheimnis. In Blend 3 hat mich das Feature aber nicht völlig umgehauen. In Blend 4 gibt es ein nettes Mockup Sample, welches bereits das ein oder andere Control mitbringt und die Verwendung besser aufzeigt. Für Besitzer von Blend 3: Der Umstieg ist glaub ich sogar kostenlos auf die neue Version.

Wichtig: Das Sample

Dieses Sample Projekt beinhaltet einige Controls, die man wahrscheinlich regelmäßig braucht.

Auch der Umgang mit den Controls wird erläutert.

In diesem Projekt befinden sich mehrere komplexere SketchFlow Controls:

Auch die Verwendung von diesen wird erklärt:

Screenshots:

Auch der Umgang mit Animationen wird näher erläutert:

Wer weitere Controls für SketchFlow sucht könnte sich folgende Links anschauen:

• Mockup2Xaml
• Sketchables

Gefunden hab ich den Hinweis auf die neuen Funktionalitäten auf diesem Blog.

Vielleicht geb ich SketchFlow ja nochmal eine Chance, ansonsten greif ich wieder zu Powerpoint

ShareThis

Der Titel klingt recht "kompliziert”, ist es aber eigentlich gar nicht. Grundproblem: Wir haben ein Interface und mehrere Implementationen davon. In unserer Applikation wollen diese über Konstruktor-Injektion holen und nacheinander aufrufen. Mit dem ArrayResolver und Castle Windsor dies sehr einfach zu bewerkstelligen. Der Blogpost darf auch als “realer” Einstieg in das Thema Dependency Injection angesehen werden.

Grundlagen

Einen kleinen Einstieg hab ich hier bereits gegeben. In meinem Beispiel nutze ich Castle Windsor, genauso gut hätte ich wahrscheinlich ein anderes DI Framework nehmen können.

Benötigte Assemblies

Der Download von Castle Windsor kann erstmal etwas erschreckend sein. Benötigt werden diese 4 Dlls (Core/DynamicProxy2/MicroKernel/Windsor).

Mein (reales) Beispiel

Wir haben bei uns eine Applikation die auf einige Backend Systeme zugreift. Da die Backend Systeme ab und an “einschlafen” haben wir ein “WakeUpTool” geschrieben, welches nach einem bestimmten Intervall die Systeme auf Stand-by hält.

Wir haben bei uns ein “IWakeUpCommand” mit der simplen Methode “WakeUp”. Pro Backendsystem gibt es eine Implementation davon. Die einzelnen Aufwach-Befehle können völlig getrennt voneinander agieren. Wichtig ist nur, dass immer alle geladen werden.
Da es sein kann, dass nun noch ein weiteres Backend System dazu kommt (oder eins wegfällt), wollten wir die Verbindung zwischen ApplicationRunner und den einzelnen Commands so lose wie möglich gestalten.

Fake Beispiel

In meinem Beispiel, welches ihr ganz unten auch runterladen könnt, wird einfach nur ein ConsoleWriteLine ausgegeben.

In dem Beispiel gibt es das Interface “ICommand” mit der Methode “Exceute” und 3 Implementationen.

Das Interface “IApplicationRunner” beinhaltet nur eine “Run” Methode. Dies ist mein eigentlicher Eintrittspunkt in die Applikationslogik.

Beispiel Command:

namespace CastleWindsorFindAllImplementations.Commands
{
    public class WakeUpCommand : ICommand
    {
        public void Execute()
        {
            Console.WriteLine("WakeUpCommand");
        }
    }
}

Der ApplicationRunner nimmt einfach ein Array an ICommands entgegen und ruft diese nacheinander auf. Keine große Magie.

namespace CastleWindsorFindAllImplementations
{
    public class ApplicationRunner : IApplicationRunner
    {
        private ICommand[] _commands;

        public ApplicationRunner(ICommand[] commands)
        {
            this._commands = commands;
        }

        public void Run()
        {
            foreach (ICommand command in _commands)
            {
                command.Execute();
            }
        }
    }
}

Castle Windsor Magie – wie der ApplicationRunner zu den Implementationen kommt!

Ganz am Anfang registrieren wir einen ArrayResolver für Windsor Castle. Nur damit kann unser “container” auch Arrays auflösen.

Die Zeile 7 erspart eine Menge tipparbeit. Damit wird dem Container (so wie ich es verstanden habe ) gesagt, dass er alle Interfaces suchen soll und dazu die passenden Implementationen registrieren soll. Suchen soll er zudem nur in dieser Assembly. Nur durch diesen Automatismus ist es auch erst elegant, weil man so einfach nur eine neuen Command hinzufügen muss und das Framework kümmert sich um die Auflösung. Man muss kein Setup etc. anpassen. Sehr praktisch, aber sicherlich wird es auch zu Problemen führen wenn es komplexer wird.

In Zeile 10 holen wir uns über den “container” unseren IApplicationRunner und sagen dann einfach nur “Run”. Windsor Castle hat als einzige Implementation unsere “ApplicationRunner” Klasse gefunden. Diese wiederrum braucht ein Array aus ICommands. Voodoo

    class Program
    {
        static void Main(string[] args)
        {
            IWindsorContainer container = new WindsorContainer();
            container.Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));
            container.Register(AllTypes.Pick().FromAssembly(typeof(ApplicationRunner).Assembly)
                    .WithService.FirstInterface());

            IApplicationRunner runner = container.Resolve<IApplicationRunner>();
            runner.Run();

            Console.ReadLine();
        }
    }

Was ist wenn ich einen konkreten Typ von ICommand haben will?

Dann hat man erst mal ein Problem, weil es so nicht vorgesehen ist. Was man machen kann ist bestimmten Komponenten innerhalb des “containers” einen Namen zu geben.

Fazit

Diese Methode ist äußerst praktisch wenn man einfach nur eine Liste von Implementationen nutzen will ohne sie explizit erst zu registrieren. Einen genauen Typen daraus wieder herauszupuzzeln ist allerdings schwieriger.

[ Download Democode ]

ShareThis

Wer auf mehreren Systemen über RDP Zugriff hat, der kann recht leicht den Überblick verlieren. Vor allem wenn man für jede Verbindung andere Credentials braucht. Microsoft hat vor kurzem den Remote Desktop Connection Manager freigegeben, der das Verwalten von RDP Sessions vereinfacht.

Ein paar nette Features seien hier noch erwähnt:

• Die Verbindungen können in einer Baum-Struktur gespeichert werden, ähnlich dem Windows Explorer.
• Für jeden Ordner oder jedes System kann man die Credentials hinterlegen
• Wer über einen Remote Gateway gehen muss kann diesen ebenfalls mit angeben.
• Kann auch sonst alles was der RDP Client im Windows kann.
• … und es ist kostenlos und es funktioniert recht gut

Ein kleiner Kritikpunkt: RDP Dateien kann man scheinbar nicht importieren, d.h. man muss die Verbindungsdaten nochmal eingeben.

Auf das Tool bin ich durch diesen Blogpost aufmerksam geworden.

[ Zum Download ]

ShareThis

Wir benutzen bei uns für den Build Prozess MSBuild und nutzen den Team Foundation Server. Wer eine ASP.NET Applikation baut bekommt diese in einem “PublishedWebsites” Ordner serviert. Jegliche andere Sachen werden aber einfach ins Bin/Release Verzeichnis kopiert. Da das nicht gerade besonders hilfreich ist, kann man das natürlich auch ändern – allerdings mit etwas basteln.

Was muss man tun um die Ordnerstruktur beizubehalten?

Eigentlich möchte man ja pro Applikation einen eigenen Output Folder haben. Leider baut der TFS alles und kopiert das Ergebnis einfach ins Release Verzeichnis.
In unserem Beispiel haben wir eine TFSBuild.proj Datei, welche momentan 3 Solutions baut.
Die Solutionnames sind bei uns natürlich etwas anders

• “Websolution1” enthält im Großen und Ganzen eine ASP.NET MVC Webseite.
• “Websolution2” enthält einen Webservice
• “WindowsSolution1” enthält einen Windows Dienst und einige andere Klassenbibliotheken.

Der TFS legt automatisch für ASP.NET Projekte einen “PublishedWebsites” Ordner an.

Hier mal direkt einen Ausschnitt aus dem TFSBuild.proj File:

    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/Websolution1.sln">
        <Targets></Targets>
        <Properties>OutDir=$(OutDir)</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/Websolution2.sln">
        <Targets></Targets>
        <Properties>OutDir=$(OutDir)</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/WindowsSolution1.sln">
      <Targets></Targets>
      <Properties></Properties>
    </SolutionToBuild>
  </ItemGroup>

  <PropertyGroup>
    <CustomizableOutDir>true</CustomizableOutDir>
  </PropertyGroup>

Wichtig ist die untere PropertyGroup und das der Wert “CustomizableOutDir” auf “true” gesetzt ist. Damit wird im Grunde der Default-Mechanismus des TFS ausgeschalten. Daher muss man in den Properties das OutDir mitgeben. Da es bei den Webseiten keine Problem gab setzt ich es wieder zum Standard.

Nun geht man in die Projektdatei von dem Windowsservice (welche in der WindowsSolution1) ist. Dort hab ich es wie folgt angepasst:

  <PropertyGroup>
    <PublishedApplicationOutputDir Condition=" '$(TeamBuildOutDir)'!='' ">$(TeamBuildOutDir)_PublishedApplications\$(MSBuildProjectName)</PublishedApplicationOutputDir>
    <PublishedApplicationOutputDir Condition=" '$(TeamBuildOutDir)'=='' ">$(MSBuildProjectDirectory)</PublishedApplicationOutputDir>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>$(PublishedApplicationOutputDir)</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

Wenn es vom TeamBuild gebaut wird gibt der TFS die Property TeamBuildOutDir mit rein und setzt entsprechend meinen gewünschten “PublishedApplication” Pfad.

Das ganze wird am Ende als OutputPath bestimmt und schon haben wir pro Windowsdienst / Klassenbibliothek etc. einen eigenen Output-Folder.

Meine Lösung stammt ursprünglich von diesem Blogpost. Hintergrund für das CustomizableOutDir Verhalten kann man in diesem Blogpost nachlesen.

Wenn man auf das Datum der Blogposts schaut, sieht man, dass das Problem schon etwas älter ist, aber ich bin jetzt erst drauf gestoßen

MSBuild

Wer einen Einstieg in MSBuild sucht, der findet eine klasse Serie auf Thorsten Hans seinem Blog: Das MSBuild Universum

PS: Natürlich geb ich keine Garantie ab, dass dies die ideale Lösung ist. Aber es baut erstmal

ShareThis

Laut Projektbeschreibung (“MVC Music Store is a tutorial application built on ASP.NET MVC 2. It’s a lightweight sample store which sells albums online, demonstrating ASP.NET MVC 2’s productivity features and data access via Entity Framework 4. See what you can do with MVC 2 in under 1000 lines of c# code!”) soll dieses Sample die “Produktivitätsfeatures” von ASP.NET MVC 2 zeigen. Mehr aber auch nicht.

Warum es nicht als Best Practices zu verstehen sein soll/sollte:

• Keine Unit Tests
• Leider spricht Microsoft viel zu häufig von Testbarkeit anstatt mal ein gutes Sample zu erstellen
• Die Controller enthalten DB/Repository Logik. Abfragen werden dort direkt gegen den Entity Framework Context gemacht. Das ist nicht schön und ist auch für die Testbarkeit der Super GAU.
• Fehlerbehandlung/Logging/Dependency Injection: Fehlt alles komplett.
• Lokalisierung: Fehlanzeige
• Profildaten speichern? MIt der (fragwürdigen) Profile API oder wie? Hier wird kein Ansatz gezeigt.
• Ayende hat sich die Anwendung in Hinsicht auf die Performance/Skalierbarkeit angeschaut: Da geht auch noch was.

IMHO ein netter Showcase was man in ein paar Stunden sicherlich zusammenbasteln kann, mehr aber auch nicht. Wie ein typisches Microsoft Sample halt ist – es zeigt recht gut die einfachen Anfänge, leider aber nicht die Feinheiten wenn es wirklich schwierig wird.

Wer sich die Funktionsweise von ASP.NET MVC 2 anschauen will, kann einen Blick reinwerfen, aber bitte nicht alle Konzepte übernehmen, sondern mit etwas Weitsicht handeln

ShareThis

Ein Kollege, der eine IIS6 Webapplikation auf IIS7 migriert, fragte mich was denn eigentlich dieses Validation Tag bedeutet. Unter ASP.NET 4.0 ist die Web.config um einiges schlanker, allerdings taucht das Validation und Modules Tag wieder auf. Was hat es mit den beiden Flags auf sich?

Migration auf IIS7

Der Post soll nur die beiden Properties beleuchten. Wer eine Migration auf von IIS6 auf IIS7 machen möchte, der sollte hier sich genauere Informationen besorgen.

system.webServer

Wer eine frische ASP.NET MVC Anwendung erstellt findet in der web.config diese Konfiguration:

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>

Validation: “validateIntegratedModeConfiguration”

Im Standardfall ist dies auf “false” gesetzt. Vor dem IIS7 hat man alle Handler & Module unter “System.Web” oder irgendwo in der web.config verstreut  reingeschrieben. Ab dem IIS7 wurde ein spezieller Bereich in der web.config für den Webserver eingerichtet: system.webServer. Mit dem IIS7 gibt es mehrere Möglichkeiten sich in den ASP.NET Prozess einzuklinken. Das ist der s.g. “Integrated” Mode.

Mit dem validation Tag & dem Property validateIntegratedModeConfiguration wird im Grunde nur geprüft ob die web.config vollständig richtig konfiguriert ist. Würde das Flag auf “true” stehen, würde eine Fehlermeldung kommen wenn unter in der web.config einfach so ein <HttpModules> stehen würde.

Da viele Anwendung aber trotzdem noch korrekt auf dem IIS6 laufen sollen und auch der interne Entwicklungsserver im Visual Studio (Cassini) auf IIS6 aufbaut, ist das Flag auf “false” gesetzt. Es wird im Grunde nur die Fehlermeldung ignoriert.

Modules: “runAllManagedModulesForAllRequests”

Wer auf dem IIS6 versucht hat “endunglose” URLs wie z.B.

http://code-inside.de/blog/2010/05/16/howto-visual-studio-immer-als-admin-starten/

Der musste entweder direkt am IIS etwas ändern oder etwas rumbasteln. Ähnliche Änderungen am IIS6 sind auch notwendig wenn man eine ASP.NET MVC Anwendung zum Laufen bekommen will.

Mit dem Flag “runAllManagedModulesForAllRequests” wird der IIS nur angewiesen alle registrierten “verwalteten” Module bei jedem Request zu durchlaufen:

Diese kann man pro Seite jeweils im IIS verwalten. Das Flag ist also nur ein Shortcut um die web.config nicht unendlich aufzublähen und damit man im IIS zentral dies steuern kann.

Statische Dateien, wie z.B. jpegs, durchlaufen nicht diese Module. “Statische Datein” können ebenfalls im IIS verwaltet werden.

ShareThis

Wer den richtigen IIS als Development Server nimmt, der wird das Problem unter Vista & Win7 kennen:
Solange die Benutzerkontensteuerung/UAC nicht ausgeschalten ist, muss man erst mühsam über *Rechtsklick* *Als Admin ausführen* klicken. Mit einem kleinen Trick spart man sich das Geklicke im Kontextmenü.

“Programm als Administrator ausführen”

Diese Einstellung kann man im Kompatibilitätstab in den Eigenschaften machen:

Bei einem Doppelklick auf ein .SLN File wird diese Exe aufgerufen:

C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VSLauncher.exe

Die normale Exe liegt dort:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

Diese Einstellung bei beiden Dateien machen. Ohne weitere Änderungen der UAC kommt weiter der “Warndialog” – allerdings vergisst man nun nicht mehr VS als Admin auszuführen und man muss nicht in Kontextmenüs nach dem “Als Admin ausführen” suchen.

Wer Desktop Programme entwickelt sollte sich allerdings im Hinterkopf behalten, dass sein Programm auch ohne Admin-Rechte laufen sollte – jedenfalls für den gewöhnlichen Nutzer.

ShareThis

Die Tipps gelten für Windows Server 2003 bzw. höhere Versionen – auch wenn es da deutlich einfacher geworden ist.

• Ist die richtige .NET Version auf dem Server installiert?
• Nachprüfen kann man das entweder über Programme/Software in der Systemsteuerung oder man schaut mal in den GAC (C:\Windows\assembly) ob dort .NET DLLs mit der nötigen Versionsnummer da sind.
• Wenn es nicht installiert ist: Einfach die neuste Version installieren.
• Ist auf dem Windows Server überhaupt der IIS installiert?
• Nachprüfen kann man das in der Systemsteuerung unter Software/Programme. Der IIS ist unter den Windows Komponenten zu finden.
• Wenn er nicht installiert ist: Den nächsten Punkt noch beachten.
• Ist im IIS die .NET Unterstützung mit installiert? Im IIS 7 gibt es so genannte “Anwendungsentwicklungsfeatures” – dort ASP.NET mit anklicken. Im IIS6 gibt es glaub ich was ähnliches.
• Jetzt muss man rausbekommen unter welcher Version die Anwendung laufen lassen möchte:
• Im IIS6 ist das etwas magisch. Auf 32bit Maschinen gibt es unter Eigenschaften einer Webseite einen ASP.NET Tab – auf einer 64bit Maschine muss man erst mal irgendwelche RegistryKeys umändern. Allerdings läuft bei mir eine ASP.NET MVC Anwendung im IIS6 auch ohne das ich diesen Reiter hab. Wer ihn sieht, sollte mal nachschauen ob dort evtl. ASP.NET 1.1 ausgewählt ist.
• Im IIS7 (und IIS7.5) wird dies über die Anwendungspools geregelt
• Ganz wichtig: asp_regiis.exe
• Diese Datei registriert macht ein paar wichtige Änderungen am IIS. Bis .NET 4.0 muss man diese Datei ausführen:
• C:\Windows\Microsoft.NET\Framework\v2.0.50727\asp_regiis.exe –i
• Ab .NET 4.0 gibt es eine neue Variante unter der Frameworkversion v4…
• Wenn man eine ASP.NET MVC Anwendung unter IIS6 zum Laufen bringen soll: Ein Wildcard Mapping auf die aspnet_isapi.dll & deaktivieren von “Verify that the file exists” unter den Konfigurationsoptionen im Basisverzeichnis Tab oder diese Tipps befolgen:

Wenn diese Punkte schon mal erfüllt sind, kann es z.B. noch ein Problem mit Schreibrechten geben bzw. wenn die Anwendung unter einem speziellen Account läuft zu Problemen kommen.

• Hat der User unter dem die Anwendung läuft Schreib- & Leserechte auf den Ordner. Siehe auch hier.
• Ist der User unter dem die Anwendung läuft auch Mitglied der Windows Gruppe IIS_WPG (IIS6) bzw. IIS_IUSRS

Wenn es nicht eine ganz exotische Anwendung ist, sollte diese spätestens nun auch laufen. Ansonsten lohnt ein Blick in den Windowslog. Wenn ich doch etwas vergessen habe, dann werde ich dies hier weiterführen

ShareThis

Die Autoren rund um das Buch “ASP.NET MVC 2 in Action”, darunter u.a. Jeffrey Palermo, haben das Manuscript auf GitHub für jeden einsehbar und herunterladebar zur Verfügung gestellt. Ab Ende Juli sollte es auch bei Amazon lieferbar sein. Wer das eBook sich so zulegen möchte um die Autoren zu unterstützen, der kann es auch hier kaufen.
Zum Manuscript. Mehr Information auf Jeffrey Palermos Blog.

ShareThis

Ich hatte heute mit einem kleinen XML Problem zu kämpfen. Bei der Generierung des XMLs trat der oben genannte Fehler auf. Problemlösung in kurz: “&”, “<” & “>” maskieren wenn man InnerXml setzt oder “vollständiges” Xml Element setzen.

Problemfall:

    class Program
    {
        static void Main(string[] args)
        {
            XmlDocument doc = new XmlDocument();
            XmlElement element = doc.CreateElement("element");
            element.InnerXml = "hello & good bye";
        }
    }

Dieser Code endet mit einer Exception. Entweder man setzt InnerText oder maskiert das “&”. Das gleiche gilt auch für “<” bzw. “>” z.B. mit HttpUtility.HtmlEncode. Wenn man komplettes, valides XML reingibt funktioniert es auch:

        static void Main(string[] args)
        {
            XmlDocument doc = new XmlDocument();
            XmlElement element = doc.CreateElement("element");
            element.InnerXml = "hello <test></test> good bye";
        }

Eigentlich völlig logisch. Problematisch wird es nur wenn man z.B. HTML Markup wie “<br/>” und vom User eingegebene Texte (wo auch ein “&” oder “<” drin stehen könnte) auftauchen. Da die Fehlermeldung mir recht nichtsagend war, hab ich mir gedacht es zu bloggen.

ShareThis

Gerade auf dem MS Technet Blog gefunden: MS Press stellt das Buch “Introducing Microsoft SQL Server 2008 R2” kostenfrei zum Download (PDF) / (XPS) bereit. Haupthemen: Database Administration & Business Intelligence Development

Database Administration

• SQL Server 2008 R2 Editions and Enhancements
• Multi-Server Administration
• Data-Tier Applications
• High Availability and Virtualization Enhancements
• Consoldidation and Monitoring

Business Intelligence Development

• Scalable Data Warehousing
• Master Data Services
• Complex Event Processing with StreamInsight
• Reporting Services Enhancements
• Self-Service Analysis with PowerPivot

ShareThis

Beispiel: IUserRepository mit der Methode “GetUser(Guid id)”

Wir stellen uns vor, wir hätten ein eines UserRepository was eine Get Methode besitzt, welche eine Guid als Parameter erwartet.

Was passiert wenn kein Ergebnis gefunden wird?

Thomas sein ursprünglicher Gedanke: Null.
Das Problem dabei: Man muss es prüfen und es wird nicht wirklich erwartet (einfach die vielen Kommentare lesen).

Jürgen Gutsch hat die vielen verstreuten Posts in einem Blogpost mal zusammengefasst.

Das was ich aus der Diskussion mitgenommen habe:

• Im Normalfall niemals NULL zurückgegeben
  • Man erwartet es nicht und es gibt bessere Varianten
• Wenn ein Objekt erwartet wird:
  • bei einer “Get” Methode eine Exception werfen wenn das gewünschte nicht gefunden wurde
  • evtl. eine “Find” mit speziellen Rückgabetypen (ReturnCodes/bool/IResultWrapper) oder “TryXXX” Methode mit einem out Parameter anbieten.
    • Um die Lesbarkeit zu erhöhen hat sich Ralf ein paar Gedanken gemacht
• Wenn eine Collection erwartet wird:
  • Eine leere Collection zurückgeben

Wichtig ist, dass die API intuitiv zu benutzen ist. NULL ist IMHO nicht wirklich intuitiv. Ich seh die ganze Sache auch aus Webentwicklersicht – ein Geräteprogrammierer mag das völlig anders sehen.

My 2 cents

ShareThis

ShareThis

Vor der .NET 4.0 Zeit: “The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" was not found”

Wer mit .NET 4.0 baut: “The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found”

Einfachste Fehlerbehebung: Visual Studio auf dem Build Server installieren.

Eine andere Variante: Einfach den WebApplications Ordner mit Inhalt (ein .target File + dll) kopieren.

Im Zusammenhang mit TeamCity ist mir dieser “Bug” bereits aufgefallen. Mit dem neuen TFS2010 hat sich das auch nicht geändert, daher der “nochmalige” Blogpost.

ShareThis

ShareThis

Vorbereitungen im IIS / Visual Studio

Mein Demoprojekt habe ich nach dieser (IIS als Entwicklungsserver nutzen) & dieser (.NET 4.0 & IIS 7.5) Anleitung konfiguriert – der Source Code entspricht dem Standard MVC Projekttyp.

Windows Konfiguration

Desweitern sollte man unbedingt die Windows Firewall ausschalten.

VMWare Konfiguration

Als letztes sollten die VMWare Netzwerkkonfigurationen auf “Bridged” gesetzt sein:

Das Theme VMWare Gast/Host System und Netzwerk ist hier ganz gut beschrieben.

IPConfig /renew

Nachdem das gemacht wurde empfiehlt es sich sich vom DHCP (die meisten Router haben per Default einen eingeschalteten DHCP) eine neue IP Adresse zu holen. Das ganze geht z.B. über den Kommandozeilenbefehl ipconfig/renew

Nun die aktuelle IP Adresse vom Windows auslesen und diese kann nun auch auf dem Mac in jegliche Browser eingegeben werden:

Egal ob im Chrome unter MacOSX:

Im iPhone Simulator:

Oder iPad:

Debugging?

Geht auch. Breakpoints die in der VM gesetzt werden, werden angestoßen sobald man z.B. mit dem iPad Browser die Seite besucht.

Erster Eindruck:

Grundsätzlich funktioniert diese Konstellation. Ob es immer Angenehm ist zwischen VM und den Simulatoren hin- und herzuwechseln wage ich zu bezweifeln, aber am Ende wird dies “angenehmer” sein als ein komplettes Deployment durchzuführen.

Wer kein VMWare Fusion benutzt kann wahrscheinlich eine ähnliche Einstellung auch im Parallels treffen – beide Produkte scheinen sich ja so oder so sehr zu gleichen

Den entscheidenen Tipp für den Brigded Mode fand ich auf dieser Seite.

ShareThis

“Der Handler "PageHandlerFactory-Integrated" weist das ungültige Modul "ManagedPipelineHandler" in der Modulliste auf.” (dt.)

1. Sicherstellen dass die Website unter .NET 4.0 läuft (siehe z.B. Default Website –> Erweiterte Einstellungen –> schauen ob der ASP.NET v4.0 AppPool ausgewählt ist).

2. In der CMD ASP.NET 4.0 installieren:

Für 64bit:

C:\Windows\Microsoft.NET\Framework64\v4.0.30128\aspnet_regiis.exe –ir

Für 32bit:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe –ir

ShareThis

Grundbegriffserklärung: Branching?

Ein Branch (dt. Zweig) ist eine quasi eine Kopie des IST Zustandes des Source Codes. So kann man z.B. 2 unterschiedliche “Entwicklungszweige” haben um verschiedene Sachen zu entwickeln – völlig voneinander losgelöst.

Merging?

Merging ist genau die Umkehroperation des branchings. Wenn man aus einem Hauptzweig einen “Entwicklerzweig” abgespaltet hat, möchte man diesen auch irgendwann wieder in den Hauptzweig zurückführen. Diesen Vorgang nennt man mergen.

Toolunterstützung

Ich werde in diesem Blogpost nur die Theorie erklären, allerdings sind beide Vorgänge in mir jedem bekannten Source Control Management System irgendwie mit dabei. Das System kennt also die Verzweigungen. Dies ist wichtig damit das System beim Merging wieder unterstützt.

Ein guten Guide (besonders im Zusammenhang mit dem TFS) zum Thema Branching & Merging befindet sich auf Codeplex.

Branching Strategien: “Basic Branching”

Das ist die simpelste Herangehensweise. Der Main-Pfad repräsentiert unser Hauptentwicklungszweig. Hierbei muss sichergestellt werden, dass man möglichst immer den Main-Zweig “stabil” lässt, sodass man theoretisch jederzeit ein neues Release rausgeben kann. Entwicklungsarbeiten würden nur im Development-Zweig gemacht. Am Ende einer Entwicklungsphase würde der Entwicklungszweig wieder in den Mainzweig “gemerged” und von dort aus wieder ein neuer Branch für einen neuen Release gezogen.

Was erreichen wir dadurch?

Man kann jedes Release nachvollziehen und die Entwicklung beeinträchtigt nicht den Mainzweig – was bei einem Hotfix z.B. wichtig wäre.

“Standard Branch Plan”

Dieses Vorgehensmodell könnte schon bei weniger komplexen Projekten ausreichen. Ziel ist es immer den Main Zweig absolut stabil zu halten.

Im Alltag wird man ein Entwicklungsprojekt X haben, welches nun z.B. in Version 1 released wurde. Nun gehen die Arbeiten für Version 1.5 im Entwicklungszweig gut voran, allerdings wurde ein Bug auf dem Live System gefunden. Direkt in dem Main Zweig den Bug zu finden und zu lösen kann Nebenwirkungen haben. Daher hat man noch einen “Service Pack” bzw. “Hotfix” Zweig. In diesem Zweig kann der Fehler gefunden werden und auch getestet werden. Wenn alles OK ist, kann man aus dem “Service Pack” bzw. “Hotfix” Zweig wieder nach Main mergen (also die Bugfixes nun auch im Main Zweig einchecken) und ein neues Release ausgeben.

“Advanced Branch Plan”

Hier wird noch zusätzlich ein direkter Hot Fix Zweig eingeführt. Dies kann man vielleicht ganz gut mit den Windows Service Packs und Hotfixes vergleichen. Kleinere Sachen werden in einem Hotfix Zweig gefixt. Der Hotfix wird dann weiter nach oben in den Service Pack Branch gemerged. Nachdem man einige Hotfixes gemacht hat kann man ein Service Pack rausgeben. In diversen Abständen sollten die Änderungen die im Service Pack Zweig sind natürlich auch wieder nach Main fliessen, damit man in der nächsten großen Version die alten Fehler nicht wieder drin hat.

Der Development Zweig – “Branch per Feature”

Diese drei Beispiele sind nur für die Produktivumgebungen wichtig gewesen. Für die Entwicklung kann man natürlich auch mehrere Entwicklungszweige anfangen. So kann man z.B. mehrere Entwicklungsteams getrennt voneinander arbeiten lassen oder man macht ein Branch für jedes Feature:

Jedes Entwicklungsteam kann für sich an einem Feature arbeiten. Nach einem gewissen Stand kann das Team auch für den Test einen eigenen Branch anlegen.

Egal wie komplex man es gestaltet. Der “Main” Zweig trennt die Entwicklung und das Produktivsystem. Man kann Änderungen die auf dem Produktivsystem gemacht wurden über den Hotfix –> Service Pack –> Main Zweig bis zu den diversen Development Branches durchreichen “Forward Integration” bzw. “Reverse Integration” sind hier die Stichwörter.

Wie kann das z.B. im Source Control aussehen:

Was vorher in den Bildchen schematisch erklärt wurde, kann im Explorer z.B. so aussehen. Dies ist in dem Fall der TFS Team Explorer. In der Version 2010 hat sich auch einiges in dem Gebiet getan. Als kleines Beispiel kann der TFS die Hierarchie sehr nett darstellen:

Weitere Ressourcen:

Alle Bilder stammen aus dem Visual Studio TFS 2010 Branching Guide – allerdings trifft die pure Theorie genauso z.B. auf SVN zu.

Ich versuche die verschiedenen Sachen in den nächsten Blogposts direkt mal mit einem TFS Projekt zu zeigen. Das Thema ist sehr groß und nicht mit einem Blogpost zu erschlagen. Hier ging es mir nur um die aller gröbsten Basics.

ShareThis

Gregor Biswanger “Zurück in die Zukunft mit Silverlight 4”

René Schulte “Silverlight Augmented Reality Toolkit”

ShareThis

Techtalk

Frank Prengel und Oliver Scheer stellen in fünf Terminen die Entwicklung für das Windows Phone 7 vor:

• 7. Juni 2010; München
• 8. Juni 2010; Köln
• 9. Juni 2010; Hamburg
• 10. Juni 2010; Berlin
• 15. Juni 2010; Karlsruhe

WebCamps – Make Web, Not War

Das WebCamp dauert zwei Tage und soll die Microsoft Web Platform euch näher bringen. Das WebCamp Tour quer durch die Welt hält auch in München. Sprecher (momentan) Jon Galloway & Christian Wenz.

Datum: 7. – 8. Juni
Preis: Kostenlos

ShareThis

schtasks

Hier mal der Syntax aus der MSDN für das Erstellen eines Tasks:

schtasks /Create
[/S system [/U username [/P [password]]]]
[/RU username [/RP [password]] /SC schedule [/MO modifier] [/D day]
[/M months] [/I idletime] /TN taskname /TR taskrun [/ST starttime]
[/RI interval] [ {/ET endtime | /DU duration} [/K]
[/XML xmlfile] [/V1]] [/SD startdate] [/ED enddate] [/IT] [/Z] [/F]

Anwendungsfall

Wir benutzen eine Batch-Datei für das “installieren” einer neuen Version. Mit einem Klick werden IIS 6 Websites, Windows Services und nun auch Scheduled Tasks entsprechend angepasst. Für uns am interessantesten war der “TR” Parameter mit dem man den genauen Pfad des Programm angibt und der “change” Befehl.

Wenn wir eine neue Version gebaut haben und auf den Server kopiert haben haben wir z.B. folgende Ordnerstruktur:

C:\Projektname\1.0.0.0\WindowsService1\windowsservice1.exe
C:\Projektname\1.0.0.0\Website1\…aspx…
C:\Projektname\1.0.0.0\ScheduledTasks1\scheduledtask1.exe

Wenn jetzt Version 1.0.0.1 dazukommt legen wir diesen in den “Projektname” Ordner. Im Version 1.0.0.1 Ordner liegt dazu noch das Batchfile zum “scharf” schalten der Version – keine große Magie, aber praktisch und falls doch was schief geht ist die alte Version auch noch vorhanden

ShareThis

Service Control – sc.exe

Diese Anwendung befindet sich im System32 Verzeichnis von Windows (typischerweise: C:\Windows\System32\sc.exe) und scheint von Windows XP bis Windows 7 dabei zu sein.

Was kann diese Tool?

Mit purem Halbwissen (ich kenn das Tool jetzt 0,5 Tage ) kann man Windows Service damit verwalten (anlegen, bearbeiten, löschen, starten, stoppen, abfragen…). Das ganze geht von der Kommandozeile und sogar remote.

z.B. um einen Dienst namens “NewService” auf dem Rechner “myserver” anzulegen:

sc \\myserver create NewService binpath= c:\windows\system32\NewServ.exe 

[SC] OpenSCManager FAILED 5: Access is denied.

Wenn man der Zielrechner nicht in derselben Domäne ist oder die Credentials auf dem System anders sind, wird diesen Fehler bekommen. Abhilfe schafft ein “net use” vorher:

NET USE \\PRODSRV\IPC$ /USER:<username you logon to PRODSRV with> <password you use on PRODSRV>

Wofür brauch ich das?

Im Zusammenhang mit unseren Automatisierungsbestrebungen mit dem TFS und MSBuild wollen wir auf unserer Entwicklungsplattform auch die Windows Services per Klick deployen – das ganze am besten auch noch einmal am Abend vollautomatisch -> “Nightly Build & Deploy”

Das NET USE und den SC Command werden im AfterBuild unseres MSBuild Scriptsausgeführt und dann wird der Dienst auf der Entwicklungsmaschine gestoppt, die neuen DLLs werden kopiert und wieder gestartet. Easy

Powershell?

Ich hab mich ehrlich gesagt bisher noch nicht an die Powershell rangewagt (bzw. sind solche “Admin” Aufgaben von mir täglich zu erledigen), aber wenn jemand spontan weiß, wie man das cool mit der Powershell machen kann, dann bin ich natürlich dafür ganz offen

ShareThis