.NET für Administratoren - Programmieren und Framework

Achtung: Administratoren
VBScript war gestern. Jetzt ist es Zeit sich mit .NET. Und PowerShell zu beschäftigen.

Das .NET Framework

Unter dem Begriff ".NET" laufen viele Dinge bei Microsoft zusammen. Angefangen hat das wohl noch vor Windows 2000 Server, welcher früher als "Windows.NET Server" bezeichnet wurde. Das ist aber lange her. Die großen Dinge passieren aber unter der Haube, dass Microsoft im gleichen Zeitraum eine neue Klassenbibliothek eingeführt hat: das .NET Framework. Mittlerweile hat sich ja rumgesprochen, dass dies eine leistungsfähige Library ist, die frühere Bibliotheken wie MFCMAPI, VBRUN*.DLL etc. verdrängen wird. Wenn Sie bislang nur Bahnhof verstehen, dann sollte Sie sich einfach merken, dass Entwickler "faul" sind und immer wiederkehrende Funktionen nicht von jedem Programmierer neu erfunden werden. Man greift auf Bestehendes zurück. Das waren früher unter DOS die "INT21h-Interrupts", unter Windows 3.x für viele die VBRUN-Runtime für Visual Basic Programme. Das .NET Framework ist aber nicht mehr nur eine weitere Bibliothek, sondern ein ganzes Stück weit moderner. Passend Dazu gibt es mit Visual Studio auch eine entsprechende EntwicklungsUmgebung. Das Framework selbst benötigen Sie aber auf dem Server in der passenden Version. Und da gibt es eine ganze Menge von

Version Enthält   Änderungen

1.1

1.1

nur 32bit

Version 1.0 und 1.1 waren die erste 32bit Version und enthielt einige Basisklassen. Da diese aber in 2.0 nicht weiter geführt werden, benötigen nur noch sehr alte Programme dieses Framework

2.0

2.0

32/64bit

Der erste "große" Wurf, der viel mehr Klassen aber auch keine Rückwärtskompatibilität zur alten Version enthielt. Man muss also 1.1 parallel installieren, wenn erforderlich

3.0

3.0 und 2.0

32/64bit

Trotz neuer Versionsnummer enthält diese Version auch die 2.0 Klassen

3.5

3.5, 3.0 und 2.0

32/64bit

Auch die 3.5 enthält alle Klassen von 3.0 und 2.0. Größere Änderungen waren hier die grafischen Elemente (WPF9

4.0

4.0

32/64bit

Frisch mit Visual Studio 2010 ist das .NET 4.0 Framework die aktuellste Version

4.5

4.5

32/64bit

Mit Visual Studio 2012 dazu gekommen.

.NET-Version 1.0/1.1 2.0 3.0 3.5 4.0 4.0
Version 32bit 32/64bit 32/64bit 32/64bit 32/64bit 32/64bit
1.0/1.1 Installationspaket

 

 

 

 

 

 

2.0 Installationspaket

 

 

 

 

 

 

3.0 Installationspaket

 

In 3.0 enthalten

 

 

 

 

3.5 Installationspaket

 

In 3.5 enthalten

In 3.5 enthalten

 

 

 

4.0 Installationspaket

 

 

 

 

 

 

4.0 Installationspaket

 

 

 

 

in 4.5 enthalten

 

Sie sehen, dass die erste Version (1.0/1.1) des .NET Framework ziemlich alleine steht und immer eigenständig installiert wird. Es ist also nicht so, dass die Version 2.0 die "neuere" 1.1 ist. 2.0 ist wirklich "neu" und nicht abwärtskompatibel. Sie müssen also .NET 1.1 immer nachinstallieren, wenn ein Programm noch auf 1.1 aufsetzen. Wer allerdings 3.5 installiert, bekommt 3.0 und 2.0 gleich mit. Erst das .NET-Framework 4.0 ist wieder ein kleines Paket, welches additiv zu 3.5 installiert werden kann. Alle .NET-Frameworks können parallel auf einem System installiert sein. Das können Sie auch schön im Windows Explorer sehen:

Je nach Betriebssystem ist ein Framework schon mit installiert oder über die Systemsteuerung zu installieren. Sie können aber auch immer die Frameworks von Microsoft herunterladen. Wobei die Version 2.0 NICHT die Version 1.x enthält. Version 3.0 enthält aber auch 2.0 und Version 3.5 beinhaltet 3.0 und 2.0. Erst Version 4.0 ist wieder eigenständig. Hinzu kommt, dass auch Drittprodukte DLLs in unterschiedlichen Versionen nebeneinander vorhalten können. Die früher als "DLL-Hölle" bezeichnete Problemstellung, dass unterschiedliche Programme unterschiedliche Versionen der gleichen DLL benötigt haben, ist damit auch Geschichte.

Visual Studio 2010 Express Editions verfügbar
http://www.microsoft.com/express/Downloads/#2010-Al

Visual Studio und andere Software für Schüler kostenfrei
https://www.dreamspark.com/default.aspx

Microsoft Visual Basic 2005 - Das Entwicklerbuch
1080 Seiten Visual Basic-Know-how zum kostenlosen Download! http://www.microsoft.com/germany/msdn/aktuell/news/MicrosoftVisualBasic2005DasEntwicklerbuch.mspx

Das .NET Framework 2.0 – Eine Einführung für Einsteiger und umsteiger
http://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0703-01.mspx
Get Sharper Now! - C# für Einsteiger und umsteiger
http://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0604-01.mspx
Get the BASICs mit VB.NET für Einsteiger und umsteiger
http://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0610-01.mspx

Small Basic
http://msdn.microsoft.com/de-de/devlabs/cc950524(en-us).aspx

Diese Seite wurde im November 2005, einige Tage nach der Veröffentlichung von Visual Studio 2005 und dem ..NET-Framework angefangen. Ich finde, dass es nun langsam an der Zeit ist, dass nicht nur eingeschworene Entwickler sich mit Programmierung beschäftigen, sondern dass gerade auch Administratoren den Kontakt zur aktuellen Entwicklung nicht ganz verlieren.

Warum soll ich programmieren ?

Natürlich stellen Sie sich die Frage, warum Sie als Administrator "programmieren" sollten. Aber programmieren heißt nicht gleich komplexe Probleme mit vielen tausend Zeilen Quellcode zu lösen, sondern programmieren steht einfach nur für die Schaffung von Lösungen mit eigenen Mitteln, wenn die mitgelieferten oder von Drittherstellern verfügbaren Programme nicht mehr ausreichend sind. Genau genommen ist auch ein BATCH-File, den Sie schreiben, ein Stück "Programm". Auch ein Word-Makro ist ein Stück weit programmieren. Und wenn Sie dann noch aus der Vielzahl der Tools aus dem Ressource Kit und anderen Quellen sich etwas "zusammen stricken", dann ist der Schritt nicht mehr weit, dies in einer EntwicklungsUmgebung mit effektiven Möglichkeiten zur Fehlersuche, aktiver Unterstützung durch eine Hilfe etc. zu machen. Und glauben Sie mir, es ist gar nicht so schwer.

Hier geht es los - Visual Studio Express Edition !

Früher haben Administratoren mit Batchdateien oder Shell-Skripten, Microsoft Basic oder Turbo Pascal ihre Lösungen gebaut. Dann gibt es die Zwischenzeit mit den verschiedenen Visual Basic Versionen und natürlich VBScript und VBA. Heute würde ich als Administrator einer Windows Umgebung konsequent mit ..NET anfangen. Natürlich sind viele Programme auf der MSXFAQ noch in VBScript geschrieben, aber dieser Basic-Dialekt ist nicht gerade "gut", da man schwer debuggen kann, fast keine Unterstützung bei der Entwicklung hat und man ohne entsprechende COM-Objekte quasi nichts machen kann. Und wenn Es dann doch eine kleine GUI werden soll, dann bedeutet das in VBScript die Nutzung z.B. des IE als "Formulareingabe".

Aber Microsoft macht es uns Administratoren sogar sehr einfach, da es mit Visual Studio 2004 sogar eine "Express Version" gibt, die kostenlos (bis zum 7. Nov 2006) verfügbar ist. Danach soll sie 49 US-$ kosten. Diese ist zwar nicht so umfangreich wie das vollwertige Visual Studio, aber für die meisten Administrativen Schritte vollkommen ausreichend.

http://msdn.Microsoft.com/vstudio/express/default.aspx
Sie können Visual Studio Express von Microsoft bis 7. Nov 2006 kostenfrei herunterladen aber müssen sich mit einem Passport Konto registrieren, um einen Aktivierungsschlüssel zu erhalten. Microsoft "weiß" also, wer eine Express Edition installiert hat. Nach dieser Zeit soll die Express Version kostenpflichtig werden. Also vorher laden und aktivieren.
Sie benötigen mindestens den Windows Installer 3.0 und das .NET 2.0 Framework als Voraussetzung.
Web-Installer: https://www.Microsoft.com/germany/msdn/vstudio/express/download.mspx
Englische ISO-Dateien http://msdn.Microsoft.com/vstudio/express/support/install/

Eine Vorschau auf die nächste Version gibt es auch schon
Visual Studio Express 2008 Beta http://msdn2.microsoft.com/en-us/express/future/default.aspx

Visual Studio SP1 für Vista http://www.microsoft.com/downloads/thankyou.aspx?familyId=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displayLang=de

  • C# oder VB (je ca. 70 MB)
    Die klassische EntwicklungsUmgebung für grafische und Kommandozeilenprogramme
  • Web (je ca. 70 MB)
    Wenn Sie keine EXE-Programme sondern ASPX-Anwendungen zur Ausführung auf einem Webserver erstellen wollen
  • SQL (je ca. 70 MB)
    Die Umgebung, wenn Sie für den SQL-Server z.B. Stored Procedures entwickeln
  • MSDN Express (ca. 250 MB)
    Die MSDN ist eigentlich eine DVD mit allen Microsoft Programmierschnittstellen. Die Express Version enthält alle wesentlichen Inhalte zur Nutzung des .NET Frameworks und sollten sie einmalig mit herunterladen und installieren

Wie sie sehen gibt es für jede Sprache eine Express Version. Leider gibt es keine Express Version, die alle Komponenten enthält. Sie können natürlich alle Herunterladen und installieren aber vielleicht suchen Sie sich einen Favoriten aus. Wer bislang mit VBScript gearbeitet hat, wird eher die Visual Basic Express Edition greifen. Wer sich aber mit der Syntax von C++, C# oder Java auskennt, dürfte sich in der C#-Version schneller zurecht finden.

Allerdings benötigen Sie natürlich dann das .NET Framework  2.0 auf allen Systemen, auf denen Sie ihre Skripte ausführen wollen. Wenn Sie wie ich die meisten Programme aber auf einem Management Server oder meiner eigenen Workstation starte, dann ist das keine Einschränkung. Nur bis sie das erste Anmeldeskript in .NET schreiben, dürfte vielleicht noch etwas Zeit vergehen.

Ehe Sie nun größere Projekte angehen, sollten Sie wissen, dass Programmieren auch immer einen Anspruch an den Entwickler stellt. Auf der Seite VBScript haben ich einige Regeln für das Entwickeln von Code geschrieben, die natürlich auch für die Entwicklung mit .NET gelten.

Welche Anwendung ?

Wenn Sie bisher mit VBScript oder Batchprogrammen gearbeitet haben, dann entspricht die "Commandline Application" am ehesten ihrem Profil. Schreiben Sie in Visual Studio einfach wie bisher ihre Programme und am Ende erhalten Sie eine ausführbare EXE-Datei. Nach dem Start unterstützt Sie

Wenn Sie sich selbst das leben etwas einfacher machen wollen, dann können Sie aber nun auch eine grafische Oberfläche entwerfen, in der Sie die Parameter eingeben und auch die Ausgaben anzeigen können. Losgelöst davon ist es in .NET sehr einfach möglich, Eventlogs zu generieren, Mails zu senden etc. Ihnen steht der komplette Werkzeugkasten des .NET Frameworks zur Verfügung.

Beispiel für VBScript und .NET 2.0

Wer bisher mit VBScript gearbeitet hat, wird natürlich zuerst damit versuchen, eine Anwendung für die Konsole zu bauen. Das ist mit Visual Basic 2005 Express sehr einfach möglich. Sie legen einfach mit dem Assistenten ein neues Projekt an und geben die Befehle ein. Ganz neu für VBScript Programmierer, die bislang nicht mit PrimalScript oder SystemScripter gearbeitet haben, ist die aktive Unterstützung bei der Eingabe der Befehle.

Aber Visual Basic 2005 Express ist noch leistungsfähiger. Am Beispiel von FINDSMTP habe ich einfach das VBScript Programm eingefügt. Der erste Durchlauf im Compiler hat dann wunderbar auch alle Fehlermeldungen und Warnungen ausgeworfen:

Also musste ich in der Liste nur die Fehlermeldung anklicken und im Editor korrigieren. Dabei waren folgende Änderungen erforderlich:

  • Ersetzen "wscript.echo" durch "system.console.writeline"
  • Ersetzen von wscript.quit(1) durch "exit sub"
  • Erweitern von (byval objArgs() as String)
  • Löschen von  Dim objArgs und "objArgs = WScript.Arguments"
    Diese Variablen werden direkt als Parameter verwendet.
  • Ersetzen "If objArgs.size = 1" durch "If objArgs.Length = 1"
  • Addieren von strADsPath="GC:"
    Der Compiler warnt sonst, dass es sein könnte, dass dieser String "leer" ist, wenn die FOR-Schleife keine Ergebnisse liefert.

Die Änderungen sind notwendig aber nicht wirklich schwerwiegend. Am Ende kommt dann ein ausführbares EXE-Heraus, welches auf jedem PC mit installiertem .NET Framework gestartet werden kann. Im Hintergrund hat Visual Basic Express natürlich eine ganz umfangreiche Verzeichnisstruktur angelegt.

Im Verzeichnis "bin/release" liegt dann die ausführbare EXE-Datei, die natürlich vom .NET Framework auf dem Zielsystem zur Ausführung übersetzt wird.

Sie werden nach einiger Zeit sich dann für Zusatzprogramme wie Subversion etc. interessieren, die ein Versionsverwaltung ermöglichen, so dass Sie Änderungen nicht gleich wieder überschreiben.

Hier ist der Source zum Übernehmen in ihre erste eigene Kommandozeilenanwendung:

Module findsmtp

    Sub Main(ByVal objArgs() As String)
        Dim oConnection 'As ADODB.Connection
        Dim oRecordset 'As ADODB.Recordset
        Dim strQuery 'As String
        Dim oCont 'As IADsContainer
        Dim oGC 'As IADs
        Dim strADsPath 'As String
        Dim SMTPAddress

        System.Console.WriteLine("FindSMTPMail: gestartet")
        If objArgs.Length = 1 Then
            SMTPAddress = objArgs(0)         'ersten Parameter der Kommandozeile lesen
        Else
            System.Console.WriteLine("FindSMTP: Bitte EINE Mailadresse als Parameter angeben")
            Exit Sub
        End If

        oCont = GetObject("GC:")     'Global Catalog server suchen
        strADsPath = "GC:" für Each oGC In oCont
            strADsPath = oGC.ADsPath
        Next

        System.Console.WriteLine("FindSMTPMail: Searching for:" & SMTPAddress)

        oConnection = CreateObject("ADODB.Connection")
        oRecordset = CreateObject("ADODB.Recordset")
        oConnection.Provider = "ADsDSOObject"  'The ADSI OLE-DB provider

        oConnection.Open("ADs Provider")
        strQuery = "<" & strADsPath & ">;(ProxyAddresses=*" & SMTPAddress & "*);ProxyAddresses,mail,cn,distinguishedName;subtree"
        oRecordset = oConnection.Execute(strQuery)

        If oRecordset.EOF And oRecordset.BOF Then
            System.Console.WriteLine("FindSMTPMail:" & SMTPAddress & "ist noch nicht benutzt")
        Else
            System.Console.WriteLine("FindSMTPMail: Besitzer =" & oRecordset.Fields("distinguishedName").value)
        End If

        oCont = Nothing
        oGC = Nothing
        oRecordset = Nothing
        oConnection = Nothing
        System.Console.WriteLine("FindSMTPMail: Beendet")

    End Sub

End Module

.NET 1.1 und Exchange 2007

Bei der Installation des .NET 1.1 Frameworks kann es passieren, dass Exchange 2007 OWA nicht mehr funktioniert. Dann hilft die Korrektur der IIS-Einstellungen

  • 894435 How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version of ASP.NET 2.0 on a 64-bit version of Windows
ASP 2.0 x64 wieder aktivieren

cscript %SYSTEMDRIVE%\inetpub\Administratorencripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
%SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

Debugging mit Fusion Log Viewer

Ohne EntwicklungsUmgebung und Quelltext o.ä. ist es für Administratoren natürlich nicht einfach, Fehler zu finde. Speziell Dienste und COM-Komponenten können ja schwer etwas auf die Konsole ausgeben. Aber auch hier gibt es seit .NET 2.0 eine Lösung, die auch Administratoren anwenden können. Man kann das .NET Framework anweisen, ein Debuglog zu schreiben und damit zumindest Fehler beim Laden von Assemblies etc. zu sehen. Über die Registrierung ist diese Ausgabe zu aktivieren. Ein Neustart ist nicht nötig.

Windows Registry Editor 5.0

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogPath" = "C:\fusionlogs"
"LogFailures" = 1
"ForceLog" = 1
"LogResourceBinds" = 1

Das Zielverzeichnis muss existieren. Zum Deaktivieren der Debug-Ausgaben müssen Sie die Schlüssel einfach wieder löschen oder die Werte auf "0" setzen. In dem Verzeichnis gibt es dann jede Menge unterverzeichnisse mit noch mehr HTM-Dateien. Eine erfolgreiche Initialisierung einer DLLs kann dann wie folgt aussehen:

Fusion Log HTML 

Hier wird "SYSTEM.XML" geladen und man sieht schön die Abhängigkeiten und dass diese alle aufgelöst werden können. Es gibt natürlich auch ein Tool, um diese Logs einfacher anzuzeigen. "Fuslogvw.exe". Sie müssen dazu aber zumindest das .NET SDK installiert haben.

fuslogvw Pfad

Hiermit können Sie dann auch per GUI die Protokolldatei einschalten, den Pfad vorgeben und sogar die Ausgaben der Programme übersichtlich analysieren:

Fusion Log Viewer GUI

Weitere Informationen finden Sie z.B. auch auf

.NET 3.0 und 3.5

Mittlerweile gibt es schon .NET 3.0 und sogar 3.5, so dass man als normaler Administrator schon fast die Übersicht verliert. Leider ist die Nummerierung von Microsoft aus meiner Sicht auch nicht glücklich gewählt, da .NET 3.0 eigentlich eine Übermenge von .NET 2.0 ist und neben dem .NET 2.0 auch die Erweiterungen WPF (Windows Presentation Foundation) und andere enthält.

.NET 2.0 selbst war aber kein Update von .NET 1.1, sondern man braucht beide Frameworks parallel, wenn man Programme ausführen möchte, die für das eine oder andere Framework entwickelt wurden.

NET 3.5 Download
http://www.microsoft.com/downloads/details.aspx?familyid=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en

Strong Name Validation

Ein großes Problem bei Programmen ist immer wieder die Anforderung, unerlaubte Veränderungen zu erkennen und dann die Ausführung zu verhindern. Zum einen will ein Entwickler oder eine Firma natürlich sicherstellen, dass niemand das Programm "hackt" oder Funktionen addiert, die getrennt bezahlt werden sollten. Aber auch als Kunde kann man durch solche Prüfungen sicherstellen, dass der Code nicht auf dem Weg oder bei der Installation verändert wurde.

Viele Administratoren können vielleicht noch den Begriff "Authenticode" oder digital signierte Skripte (VBA Entwicklung etc.) Auch das .Net Framework erlaubt entsprechende Prüfungen und Exchange 2007 nutzt diese Logik sogar, was sich in entsprechend großen Patchpaketen wiederspiegelt.

Im Gegensatz zum einfachen Authenticode geht die .NET Überprüfung sogar weiter. Es ist nicht nur eine Prüfung der einzelnen DLL auf unversehrtheit (Digitale Signatur) sondern auch im aufrufenden Modul kann eine ganz bestimmte DLLs mit Signatur vorgegeben werden. Wird auf einem System dann eine DLL durch eine neuere Version ersetzt, dann verweigert das aufrufende Programm die Zusammenarbeit, wen die originale DLL nicht mehr vorhanden ist. Zum Glück erlaubt .NET die parallele Installation von DLLs mit unterschiedlichen Versionen.

Auf der anderen Seite bedeutet dies, aber auch, dass ein Update einer einzelnen DLL auch einen Austausch aller aufrufenden Module erfordert und dies geht rekursiv bis zum obersten Code.

Ein weiteres Problem dieser Prüfungen ist, dass das Framework natürlich auch die Zertifikate selbst überprüfen will bzw. zumindest die Zertifikatrückruflisten erhalten muss. Das ist aber für Server in einem internen Netzwerk nicht immer einfach bzw. sogar ganz unmöglich. Solange die Firewalls und Proxyserver die Anfrage hart blockieren (also die TCP-Verbinden beenden oder einen Fehlercode liefern), sind kaum Probleme zu erwarten. Nur wenn ein Admin die Verbindung einfach "ins Leere" laufen lässt, dann kann dies zu Problemen führen.

So startet der Dienstkontrollmanager die Exchange Dienste und wartet ca. 30 Sekunden auf das "ok". Genau genommen startet er aber das .NET-Framework, welches dann die Programme nach einer Prüfung der Signatur lädt. Ein Timeout auf eine HTTP-Anfrage zum Zertifikatsserver kann aber bis zu 2min dauern. Als Ergebnis startet der Dienst nicht, weil der Dienstcontrollmanager nach 30 Sekunden aufgibt. Lösungen zu diesem Problem finden Sie auf der folgenden Seite und im KB-Artikel:

  • Authenticode
  • 944752 Exchange 2007 managed code services do not start after you install an Update rollup für Exchange 2007

In Kürze sind dies:

  • Zugriff auf "http://crl.microsoft.com" erlauben
    Das ist sicher der schnellste und einfachste Weg, zumindest wenn die Server überhaupt ins Internet kommen. Beim Einsatz eines Proxy-Server sollten Sie darauf achten, dass die Proxyeinstellungen mit "PROXYCFG" auch für LocalMachine gelten.
  • HTTP Timeouts anpassen
    Über die Werte "ChainURLRetrievalTimeoutMilliseconds" und "ChainRevAccumulativeURLRetrievalTimeoutMilliseconds" können Sie die Wartezeiten zum Abruf der Zertifikatssperrlisten konfigurieren. Dies kann auch über Gruppenrichtlinien erfolgen.
  • Dienstkontrollmanager anpassen
    Sie können hier eine längere Wartezeit einstellen, so dass die Dienste doch noch starten können. Der Wert "ServicesPipeTimeout" ist hierzu maßgeblich.
  • Lokale CRL
    Natürlich können Sie auch intern über entsprechende DNS-Einträge den Zugriff auf den Host "crl.microsoft.com" auf ihre eigene Webseiten verlinken und dort eine Kopie der CRL bereit stellen.
  • Proxy Error und Router "not reachable"
    Das Problem ist immer dann auffällig, wenn der Server wirklich auf einem Timeout warten muss. Wenn Sie in der Firewall oder auf dem Proxy die Abfrage aber aktiv "ablehnen", dann kommt der Timeout nicht zum tragen. Leider versuchen immer noch viele Administratoren genau dies zu verhindern, weil jemand dann ja um so schneller ein Netzwerk "proben" könnte. Das kann er aber so oder so und Zeit hat ein Angreifer meist auch. Sicherheit erreicht man eher durch die Erkennung solcher "Probings" und ordentlich zugangsgeschützte Systeme.

Für die meisten Leser der MSXFAQ wird es am einfachsten sein, die Microsoft URL für Alle erreichbar zu machen. Die meisten dürften dieses Problem gar nicht bemerkt haben, da Sie eh von Innen nach Außen keine großen Filter haben. Und alle anderen sollten in ihrer Firewall diese unerlaubten Anfragen schon bemerkt haben.

.NET per Kommandozeile

Auch wenn Visual Studio eine effektive EntwicklungsUmgebung ist, so sind Sie nicht verpflichtet, damit ihren Code zu schreiben. Man kann tatsächlich einfach mit Notepad oder einem anderen Editor auch .NET Sourcecode (C#, VB.NET etc) schreiben. Das .NET Framework alleine enthält den kompletten Compiler.

Sie können also ein einfaches C## Programm einfach wie folgt schreiben:

using System;

namespace msxfaq.net
{
	class Program
	{
		static void Main(string[] args)
		{
			Console.WriteLine("test");
		}
	}
}

Das Programm können Sie dann einfach kompilieren mit

c:\Windows\Microsoft.NET\Framework\v2.0.50727\csc msxfaqtest.cs

Danach haben Sie eine msxfaqtest.exe im aktuellen Verzeichnis, die direkt ausführbar ist.

Über den gleichen Weg können sie auch Funktionen und andere Komponenten sogar in DLLs verwandeln (Parameter /t:library verwenden) und damit anderen Programmen einfach zugänglich machen.

Ich würde ihnen aber nicht raten, damit größere Projekte zu entwickeln. Sie werden die Debugfunktionen und andere Hilfen einer vollwertigen EntwicklungsUmgebung sicherlich vermissen. Insofern ist .NET als Kommandozeile kein echter Ersatz für Skriptsprachen wie VBScript. Dann sollten Sie eher ein Blick auf die PowerShell riskieren.

Weitere Links