September 4, 2008
System.AddIn erlaubt es einem AddIns zu erstellen. Allerdings erzeugt der eigentlich sehr pracktische PipelineBuilder Code der nicht ohne weiteres funktioniert. Hier mal eine Reihe von Dingen die man prüfen sollte wenn die AddIns nicht gefunden werden:
- AddInStore.Update/Rebuild gibt ein String Array mit Warnungen zurück. Unbedingt auswerten!
- Bei Problemen als erstes immer das output Directory sofort löschen ( bis auf die *.VSHost.exe, die ist gelockt )
- Das Contract Interface muss mit Contract enden, in dem AddInView und im HostView fehlt dann die Endung.
- Der Contract muss sowohl das Contract Attribute haben als auch von IContract erben
- Das AddIn sollte das AddIn Attribute tragen sonst kann es nur über den Type gefunden werden.
- Referenzen auf HostView oder AddInView dürfen niemals Local Copy auf true haben.
- Die Directorystruktur mit Addins, Contracts usw muss strikt eingehalten werden
- Die vom Assemblynamen der vom Pipelinebuilder erzeugten Projekte heißen alle template.dll. Unbedingt ändern.
- Fehlermeldungen unterscheiden sich häufiger mal nach dem 2. Build.
Wenn nichts geht, mal alle obj Verzeichnisse und natürlich das output Verzeichnis von Hand löschen.
Für meinen Geschmack viel zu viele Möglichkeiten Fehler zu machen. Ich gebe zu der Einstieg in System.AddIn ist nicht gerade einladend. Ich bin mir auch noch nicht sicher ob sich der Aufwand wirklich lohnt, bisher konnte ich recht gut auf Versionierung verzichten und habe halt eine Neucompilierung bei neuer Schnittstelle gefordert. Geht solange es nur eine Handvoll Plugin Bauer gibt.
Noch wird mein AddIn nicht gefunden. Morgen weitersehen 
Leave a Comment » | 
AddIn, Lang:German | 
Permalink
Posted by gbegerow
August 3, 2007
I wanted a good visible Prompt with a shortend Path for common working directories. It consists now on the parts Historynumber of the current command, End of last command Time, the shortend path and a > Sign. Every Part is colored differently. The Full Path is shown in Title. Global foreground color is reset to white.
Feel free to use and modifiy it:
# prompt
function prompt {
$host.ui.rawui.windowtitle = "PowerShell - "+ (Get-Location).ToString()
$host.ui.rawui.foregroundcolor = "White"
$private:history = @(get-history)
if ($private:history.count -eq 0) {
$private:intCommandCount = 1
} else {
$private:intCommandCount = $private:history[$private:history.count - 1].ID +1
}
$private:location = @((Get-Location).ToString().replace($home, "~").replace("C:\entwicklung\","~"))
Write-Host -NoNewline -ForeGroundColor Yellow ("[$private:intCommandCount] ")
Write-Host -NoNewline -ForeGroundColor Gray @(Get-Date -format "HH:mm:ss " )
Write-Host -NoNewline -ForeGroundColor Yellow $private:location
" > "
}
Leave a Comment » | Lang:English, Powershell | Permalink
Posted by gbegerow
August 2, 2007
Subversion speichert seine Metadaten in .svn Verzeichnissen, die einen Bug in Webapplikationen bei Visual Studio 2003 triggern. Man muss einmal das Projekt ohne die .svn Verzeichnisse laden, danach erhält man bei jedem weiteren Öffnen zwar eine Fehlermeldung, das macht aber nichts, alle wesentlichen Daten liegen dann bereits unter C:\Dokumente und Einstellungen\username\VSWebCache\. Insbesondere beim neueinrichten eines Rechners vom Backup eines anderen Rechners kann das extrem lästig werden.
Wie immer ist der Retter in der Not die Powershell.
get-childitem -recurse -force -ErrorAction SilentlyContinue | where { $_.Name -eq ".svn" } | foreach { Rename-Item $_.FullName "_svn" }
get-childitem holt alle Dateien im aktuellen Verzeichnis und, dank -recurse, auch aus allen unterhalb. .svn wird standardmäßig als versteckt betrachtet, deshalb ist -force notwendig. Nach dem Umbenennen ist es natürlich nicht mehr möglich das Verzeichnis rekursiv zu durchsuchen, dies führt zu einer Fehlermeldung. Da .svn aber keiene .svn Ordner enthalten, schalten wir die Fehlerbehandlung für get-childitem einfach mit dem Standardparameter ErrorAction ab.
where filtert die Pipeline auf .svn Ordner.
Foreach führt dann das Rename auf dem absoluten Pfad der .svn Ordner aus.
Für die Rückrichtung müssen wir dann nur .svn und _svn vertauschen. (hier mal in Kurzschreibweise):
gci -r -fo -ErrorAction SilentlyContinue | ? { $_.Name -eq "_svn" } | %{ Rename-Item $_.FullName ".svn" }
Leave a Comment » | Lang:German, Powershell | Permalink
Posted by gbegerow
April 14, 2007
Immer wieder klasse wie flexibel man Alltagsaufgaben mit der Powershell lösen kann. Kürzlich mußte ich einige hundert Files unbenennen deren Namen auf -x86 endeten (mit verschiedenen Extensions). Eigentlich hätte das Installationsprogramm diesen String entfernen sollen, irgendwas war da aber schief gegangen. Lösung:
dir | % { rename $_.Name $_Name.replace("-x86", "") }
Erklärung: dir (oder get-childitems) legt alle dateien in die Pipeline, % ( oder For-Each) führt den Block für alle Elemente der Pipleine aus, $_ ist das aktuelle FileInfo oder DirInfo object. Der Name steht dann als ganz normaler String über die Eigenschaft Name zur Verfügung. Auf diesem Namen kann ich alle Methoden der .Net String Klasse verwenden, in diesem Fall replace. Ersetzen von “-x86″ durch den leeren String führt genau zu dem gewünschten Namen. Ein rename (oder Rename-Item) eledigt dann die eigentliche Arbeit.
Leave a Comment » | Lang:German, Powershell | Permalink
Posted by gbegerow
February 21, 2007
Hello Developers!
On this site I will start to post notes and experiences around different development themes. Come back soon.
Hallo Entwickler!
Auf dieser Site werde ich in nächster Zeit Notizen und Erfahrungen veröffentlichen.
Schaut bald wieder rein!
Georg “Wulf” Begerow
Leave a Comment » | Uncategorized | Permalink
Posted by gbegerow
Das Demo zeigt die Einbettung von IronPython in C# und die Manipulation der C# Daten durch IronPython Scripte.
Das Demo zeigt (kurz) die Erzeugung eines In Memory Assemblies via CodeDOM
Das Demo zeigt eine Reihe von Techniken für dynamisch komponierbare Anwendungen auf Basis von MEF.
Das Demo zeigt (kurz) die Erzeugung eines In Memory Assemblies via CodeDOM
