Probleme mit der „Online Gallery“ im Visual Studio beseitigen

Wenn man sein Visual Studio hinter eine Proxyserver betreibt, so kann es passieren das die „Online Gallery“ nicht funktioniert. Möchte man dies ändern so muss man je nach Visual Studio, eine der folgenden Dateien ändern:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config (Visual Studio 2010)
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe.config (Visual Studio 2012)
Die Online Gallery ist offline

Die „Online Gallery“ ist offline

Dort findet man einen Block der in etwa so aussehen sollte:

<system.net>
  <settings>
    <ipv6 enabled="true"/>
  </settings>
</system.net>

Dort fügt man den Tag:

<servicePointManager expect100Continue="false" />

innerhalb des „settings“ Tag hinzu. Nach einem Neustart des Visual Studios, sollte auch die „Online Gallery“ wieder funktionieren.

Visual Studio 2012 hübsch machen

Wenn man das Visual Studio 2010 oder 2008 gewöhnt ist, so kommt der erste Start der 2012 Version des Studios einem kleinen Schock gleich. Die Oberfläche sehr kontrastarm und ungewohnt. Auch das Menü wirkt mit seinen groß geschriebenen Einträgen sehr gewöhnungsbedürftig.

Das Visual Studio 2012 nach einigen "Tuning"-Maßnahmen

Das Visual Studio 2012 nach einigen „Tuning“-Maßnahmen

Das Problem mit den Farben bekommt man relativ schnell mit der Erweiterung Visual Studio 2012 Color Theme Editor in den Griff. Diese bietet beim Neustart des Visual Studios die Möglichkeit das Farbschema seinen Bedürfnissen anzupassen.

Dem Menü kommt man nur durch einen beherzten Eingriff in die Registry bei. Hierzu wird im Registrybaum zur Stelle:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General

navigiert und dort ein „DWORD“ mit dem Namen „SuppressUppercaseConversion“ und dem Wert „1“ angelegt. Nach einem Neustart des Studios ist dann auch das Menü wieder normal.

Script#

Bei der Entwicklung wundert man sich ab und an, was für interessante Projekte in den Weiten des Netzes so umherschwirren. So unter anderem das Projekt Script#. Dabei handelt es sich um eine Erweiterung für das Visual Studio 2012 mit welcher es möglich ist C# Quelltext (so er gewissen Kriterien genügt) in JavaScript umzuwandeln, bzw. zu compilieren.

Die Erweiterung welche im Quelltext unter https://github.com/nikhilk/scriptsharp zu finden ist, steht dabei unter der Apache Lizenz und ist somit freie Software. Nach der Installation fügt sie dem Visual Studio neue Projekttypen hinzu, mit welchen man anschließend arbeiten kann. Leider gibt es von Script# keine MonoDevelop Variante, so das man im Moment zwingend an das Visual Studio gebunden ist. Allerdings findet sich in der Roadmap folgender Satz:

In terms of code contribution, it would be especially interesting to see the development of import libraries for common libraries, so they are easily usable right out of the box. It would also be interesting to see the development of complementary tools/addins, adding support to other IDEs (esp. MonoDevelop) and other such complementary projects. Or you might be interested in the very core, i.e. the compiler itself.

Also wenn sich jemand bemüßigt fühlt, das ganze für MonoDevelop in Angriff zu nehmen, der muss nun nicht mehr auf die Einladung warten. Die offizielle Projektseite von Script# ist unter http://scriptsharp.com/ zu finden.

Testen mit NUnit

Testbasierte Entwicklung ist schon eine schöne Sache, vor allem bei größeren Projekten. Mit Hilfe sogenannter Unit-Tests kann man dabei automatisiert überprüfen ob der zu testende Softwareteil noch immer die Ergebnisse liefert, die erwartet werden. Meist ist es so, dass man in größeren Softwareprojekten etwas ändert und damit implizit an anderen Stellen Fehler einbaut, welche ohne Unit-Tests gar nicht bzw. erst später auffallen.

Für die Entwicklung unter .NET/Mono mit Hilfe des Visual Studios habe ich mich dabei für NUnit entschieden, da man dieses im Gegensatz zu MsTest auch unter Linux und Mac OS X nutzen kann. Damit sich das ganze bequem in das Visual Studio integriert nutze ich TestDriven.NET welches unter http://www.testdriven.net/ bezogen werden kann. Der persönliche Gebrauch ist dabei kostenlos.

Nach der Installation von TestDriven.NET kann man sein Visual Studio starten und mit der testbasierten Entwicklung beginnen. Dabei hat man zwei Möglichkeiten dies zu lösen. Die erste Möglichkeit ist es die Tests in ein extra Projekt zu verlagern so das diese nicht in der zu testenden Software vorkommen. Bei der zweiten Möglichkeit werden die Tests direkt im zu testenden Projekt geschrieben (z.B. in einen Namespace „Tests“).

Als Beispiel sei folgende Klasse gegeben:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Project
{
	public class FooBar
	{
		public int A { get; private set; }
		public int B { get; private set; }
		public int C { get; private set; }

		public FooBar(int a, int b, int c)
		{
			A=a;
			B=b;
			C=c;
		}
	}
}

Die Klasse „FooBar“ nimmt dabei im Konstruktor die drei Variablen a, b und c entgegen und weist sie den jeweiligen Eigenschaften der Klasse zu. Um nun zu testen ob diese Zuweisung funktioniert schreiben wir eine entsprechende Test-Unit. Dazu erstellen wir eine Klasse namens: „FooBarTest.cs“:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace Project
{
	[TestFixture]
	public class FooBarTests
	{
		[Test]
		public void TestNewFooBar()
		{
			FooBar fooBar=new FooBar(13, 24, 47);

			Assert.AreEqual(13, fooBar.A);
			Assert.AreEqual(24, fooBar.B);
			Assert.AreEqual(47, fooBar.C);
		}
	}
}

Diese Testklasse testet nun ob die Werte die im Konstruktor angegeben werden auch wirklich in den entsprechenden Eigenschaften landen. Dazu wird zuerst das NUnit Framework mittels:

using NUnit.Framework;

eingebunden. Mittels des Attributes „[TestFixture]“ sagen wir dem NUnit Framework das sich in dieser Klasse Unit-Tests befinden. Bei diesem Attribut gibt es einige Einschränkungen, so darf die Klasse z.B. nicht abstrakt sein, näheres dazu erfährt man auch in der Dokumentation.

Das Attribut „[Test]“ über der Funktion „TestNewFooBar“ teilt dem Framework mit das es sich bei dieser Funktion um einen Unit-Test handelt, welcher überprüft werden soll. Dazu legen wir in der Funktion eine Instanz von „FooBar“ an und übergeben die entsprechenden Werte an den Konstruktor.

Mittels der „Assert.AreEqual“ Funktion (weitere „Assert“ Funktionen findet man in der Dokumentation) überprüfen wir ob die Werte auch bei den Eigenschaften A, B und C angekommen sind. Wäre dies nicht der Fall so würde der Tests fehlschlagen.

Nachdem ein Test für die entsprechende Klasse geschrieben wurde, klickt man im Visual Studio mit der rechten Maustaste auf die Testklasse und wählt dort „Run Test(s)“ aus. Möchte man mehrere Tests laufen lassen so muss einen übergeordneten Ordner auswählen. Wenn alles richtig gemacht wurde, sollte man folgende Ausgabe sehen:

------ Test started: Assembly: Project.exe ------

1 passed, 0 failed, 0 skipped, took 3,07 seconds (NUnit 2.6.0).

Falls ein Fehler aufgetreten ist so sieht das ganze so aus:

------ Test started: Assembly: Project.exe ------

Test 'Project.FooBarTests.TestNewFooBar' failed: 
  Expected: 47
  But was:  0
	FooBarTests.cs(19,0): bei Project.FooBarTests.TestNewFooBar()

0 passed, 1 failed, 0 skipped, took 1,66 seconds (NUnit 2.6.0).

Findet man einen Fehler bei einem Test sollte man schauen wodurch dieser verursacht wird und ihn beheben. Wenn man nun bei der späteren Entwicklung Fehler findet (und beseitigt), welche durch keinen Tests abgedeckt sind, so sollte man gleich einen entsprechenden Test dafür schreiben, damit dieser Fehler nicht ein weiteres Mal auftreten kann.

Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/NUnit
http://de.wikipedia.org/wiki/XUnit

Eazfuscator.NET in neuer Version

Seit März gibt es den freien (wie Freibier) Obfuscator Eazfuscator.NET in neuer Version. Neu an dieser Version ist das sie beim obfuskieren des Quellcodes nun auch Optimierungen durchführt, so das die Anwendung im Optimalfall schneller läuft.

Das Eazfuscator.NET Fenster

Bezogen werden kann die neue Version unter http://www.foss.kharkov.ua/g1/projects/eazfuscator/dotnet/Default.aspx.

Weitere Informationen gibt es unter:
https://seeseekey.net/archive/4255
http://eazfuscator.blogspot.de/2012/03/high-level-optimization-for-net.html