Gerade gelesen:
http://www.reflector.net/2011/04/why-we-reversed-some-of-our-reflector-decision/
Today, we announced that we’re reversing some of this decision. We will still charge for .NET Reflector 7.x, but current users of Reflector will have the option of downloading a free, perpetual version of Reflector 6.8.
Sehr schön…
Schade, einfach nur sehr schade.
.NET Reflector ist ein wunderbares Tool, das viel Spaß, Freude macht und viel Arbeit erspart. Die Version 7 wird es nicht mehr als freies Tool geben, sondern $35 kosten.
Das Programm ist es wert, aber für mich als Privatprogrammierer relativ uninteressant. In den nächsten Wochen wollte ich sowieso mehr und mehr auf Mono portieren.
Die letzten drei ‘Tage’ saß in an einem Problem zu dem ich keine Lösung finde.
http://www.mycsharp.de/wbb2/thread.php?postid=3675244#post3675244
BTW: Warum zur Hölle erstellt ObservableCollection<T> eine Kopie der übergebenen Liste und arbeitet nicht direkt auf dieser…
Sehr coole Sache für den schnellen Test einer Funktion.
Mit Hilfe folgenden PowerShell-Skriptes kann ich nun den FBK kompilieren, verpacken und auf den Webspace hochladen. Leider gibt es in PowerShell keine funktionierende ZIP-Klasse, so dass ich hier auf 7-Zip zurückgreife:
msbuild FBK.sln /property:Configuration=Release
Remove-Item Deliverable -Force -Recurse
New-Item -type directory -f DeliverableCopy-Item -Recurse FBK/src/bin/Release/ Deliverable/
& ‘C:/Program Files/7-Zip/7z.exe’ a Deliverable/Release.zip ./Deliverable/Release/
Write-Host "Benutzername: " -NoNewline
$user = Read-Host
Write-Host "Kennwort: " -NoNewline
$password = Read-Host
$currentDirectory = (Get-Item .).ToString()
$File = "$currentDirectory/Deliverable/Release.zip"
$ftp = "ftp://depon.net/htdocs/www.depon.net/downloads/fbk.zip"
$webclient = New-Object System.Net.WebClient
$webclient.Credentials = New-Object System.Net.NetworkCredential($user,$password)$uri = New-Object System.Uri($ftp)
"Uploading $File…"
$webclient.UploadFile($uri, $File)
Das Skript besteht im Prinzip aus vier Teilen:
Mit einem Server-‘Gegenskript’ werde ich in Zukunft eine bestehende FBK-Instanz beenden, das ZIP-Archiv herunterladen, entpacken, an die richtige Stelle legen und das Spiel starten. Damit lassen sich die Deployment-Zeiten auf ein minimales Reduzieren.
Man nehme an, dass man folgendes Objekt besitzt:
[Serializable]
class Person
{
string name;
string prename;
}
Dieses Objekt wurde lange Zeit erfolgreich in einem Softwareprodukt genutzt und als Speichermedium wird die eingebaute .Net-Serialisierung genutzt (BinaryFormatter). Das Objekt wird mit den obigen zwei Eigenschaften gespeichert.
Auf Grund neuer Anforderungen erweitert man nun um eine Eigenschaft ‘age’, die den Standardwert ‘-1’ enthalten soll.
[Serializable]
class Person
{
string name;
string prename;
int age = –1;
}
Liest man nun eine schon vorhandene Serialisierung ein, so ist dieser Wert der serialisierten Objekte nicht auf –1 gesetzt worden, sondern auf 0. Der Grund liegt daran, dass die eingebauten Serialisierungsroutinen nicht den Standard-Konstruktur aufrufen.
Um nun einen Standard-Wert schreiben zu können, kann das OnDeserializing-Attribut verwendet werden. Die Klasse sieht nach der Verwendung folgendermaßen aus:
[Serializable]
class Person
{
string name;
string prename;
int age = –1;[OnDeserializing]
internal void OnDeserializing(StreamingContext s)
{
this.age = –1;
}
}
Diese Methode wird nun VOR der Deserialisierung aufgerufen und führt zu einem Setzen des Standard-Wertes.
Um mir einen Überblick über die Namespaces, Klassen und Typen des FBK zu verschaffen, habe ich mir ein kleines Hilfsprogramm geschrieben. Dieses inspiziert eine Assembly und gibt das Ergebnis in verschiedenen Formaten aus:
Das Programm ist unter http://www.depon.net/downloads/classbrowser.zip herunterladbar und über Kommandozeile aufzurufen:
ClassBrowser.exe Input.dll
[-exportformat=xml|csv|xmlclasstree]
[-compilergenerated=yes|no]
[-onlyclasses=yes|no]
Input.dll
Der erste Parameter wird immer als einzulesende Assembly gewertet.-exportformat=xml|csv
Optionaler Parameter, der festlegt in welchem Format die Ausgabe
des Programmes auf Standard-Out durchgeführt werden soll.
Wird kein Format angegeben, so erfolgt die Ausgabe im Xml-Format.-compilergenerated=yes|no
Optionaler Parameter, der festlegt, ob Compilergenerierte Klassen
und Methoden mit dem CompilerGeneratedAttribute ebenfalls angezeigt
werden sollen.
-onlyclasses=yes|no
Optionaler Parameter, der festlegt, ob nur Klassen angezeigt werden
sollen.
Ein kleiner Screenshot der mit ‘xmlclasstree’ erzeugten Xml-Datei.
Hin und wieder gibt es den Bedarf den Ablauf eines Programmes zu stoppen und in den Debugger zu springen. Visual Studio bietet hier die komfortable Möglichkeit der Haltepunkte (neudeutsch Breakpoints). Leider gibt es öfter Situationen, an denen ein einfacher Breakpoint nicht ausreicht. Dies ist insbesondere der Fall wenn die jeweilige Zeile 100fach ausgeführt wird, aber man nur bei einer bestimmten Nebenbedingung den Debugger auslösen möchte.
Diese Funktionalität nutze ich beim FBK. Wenn ich die Ausführung einer bestimmten Rolle testen möchte, trage ich in der Xml-Konfigurationsdatei das Attribut ‘debug’ ein.
<role type="mutateresources" id="BeerMutating" debug="True">
<input>
<resource type="Hop" amount="8" />
<resource type="Brewer" amount="8" />
</input>
<output>
<resource type="Beer" amount="8" />
</output>
<outputresearcheffects>
<researcheffect research="Brewery">
<multiplicator type="exponential"
factor="1"
base="1.1"
exponentoffset="0"
offset="0" />
</researcheffect>
</outputresearcheffects>
</role>
Wird diese Rolle nun ausgeführt, so hält Visual Studio die Ausführung an und ermöglicht ein einfaches Debuggen.
/// <summary>
/// Executes the role
/// </summary>
/// <param name="worldState">Current worldstate</param>
public void Execute(IWorldState worldState)
{
if (this.Role.IsDebug)
{
Debugger.Break();
}this.Role.ExecuteRole(this.RoleStatus, worldState);
}
Nettes Feature…
