de de de en it de de de en de de de de de de de de de de de de de de de de de de pl de de de en de en en de en en de de de de de de de en en de de en en de de de de de de en en de de de de de de en en de en en de en en de en de en en de de de de de de de de de de de de de pl de de de de de de kn kn de de en en de de de de de en de de en en de de de de de de de de pt es de en en en en war de en nb de de de en nl de de de cs de en en en de de en nl de de nb en en en en de en nb nb de sv en en nb de en sv fr de sv en sv en de en sv en en sv en de nb en en en sv fr en de nb nb de en sv en de de de de nb de de de en nl en nl nl en en en en nl en de de de nl en en de de en nl fr de nl en nl en de en nl en en nl en de de en en en nl fr en de de de de en nl fr de de en
Als ich vor kurzem gefragt wurde, ob ich meinen Test der neuen NDepend Version erneuern möchte, stimmte ich gern zu. Diese Software bezeichnet sich selbst als ein „Schweizer Taschenmesser für .NET und .NET Core Entwicklung Teams“. Es bietet vielfältige Möglichkeiten, um ein Projekt auf Code-technische Probleme und technische Schulden zu untersuchen und das auch über einen zeitlichen Verlauf in grafischer Form darzustellen bzw. die konkreten Veränderungen zu ermitteln.
Die Installation ist einfach und die Integration in Visual Studio ist optional, schnell gemacht und für mich ein echter Mehrwert, da ich bereits während der Entwicklung schnellen Zugriff auf alle relevanten Funktionen habe. Obwohl NDepend dann regelmäßig automatisch Analyseergebnisse sammelt, merkt man davon während der normalen Arbeit in Visual Studio nichts. Das ist bei Visual Studio Erweiterungen anderer Hersteller leider nicht immer der Fall.
Mit einem einfachen Klick auf einen großen Kreis erhält man eine kleine Übersicht, kann eine Analyse von Hand starten oder einfach ins Dashboard wechseln. Dort erhält man eine Einschätzung der Projektqualität. Das basiert auf einem sehr ausgefeilten Regelwerk, welches der Hersteller entwickelt hat. Ich habe das Regelwerk nicht selbst geändert. Ich habe schließlich das Projekt der Code-Analyse wieder aufgegriffen, weil ich das Tool als neutralen und unbestechlichen Auditor meiner Softwareprojekte sehe, der wesentlich mehr Erfahrung als ich in diesem Bereich hat. Die Darstellung des Dashboards beinhaltet eine anpassbare Übersicht. Bestandteil sind einmal Diagramme über die Entwicklung der Kennzahlen. Weiter ist, im Besonderen nach der Auswahl einer Vergleichsbasis, eine Darstellung der Projektbewertung jetzt und im direkten Vergleich zu finden. Das schließt eine nach Schweregrad gruppierte Übersicht der Anzahl der Vorfälle ein. Ein Klick auf diese Zahl bringt ein sofort in eine konkrete Übersicht der Vorfälle bzw. Probleme. Dies ist besonders dann hilfreich, wenn man eine Entwicklung einer Kennzahl vielleicht nicht so erwartet hat und man nun die Ursache ergründen möchte.
Hier beginnt jetzt aber auch der anspruchsvolle Teil! Man kann sehr leicht die einzelnen Vorfälle heraussuchen und bekommt die Fundstellen sogar angezeigt, wenn Sie nur der Vergleichsbasis zu finden waren, nun also entfernt oder korrigiert wurde. Ferner sieht man die Definition des Vorfalls in einer LINQ ähnlichen Sprache, mit einer ausführlichen Erklärung und weiteren externen Verweisen. Die Beschreibungen sind sehr gut, prinzipbedingt aber gerade am Anfang keine leichte Kost! Hier muss man schon einen festen Willen haben, das persönliche Niveau zu verbessern. Keine Verständnisprobleme bei englischen Texten sind auch hilfreich. Dann findet man in NDepend jedoch einen idealen Partner.
Ein Prunkstück, auf das der Hersteller besonders stolz ist, ist der Dependency Graph. Der Name ist Programm! Grenzen scheint es für dieses Modul nicht wirklich zu geben. Man kann mit einer sehr hohen Geschwindigkeit das Zusammenspiel der eigenen oder externen Klassen, Namensbereichen oder Funktionen anschauen und durch viele, oft sehr sinnvoll vorbelegte Optionen, übersichtlich gestalten. Das kann sehr hilfreich bei der Sichtung oder Umgestaltung von Codebereichen sein. Die Leistungsklasse wird eindrucksvoll durch die Präsentation der .NET Core 3 Klassen gezeigt. In meinen eigenen aktuellen Projekten ist mir die Struktur jedoch extrem vertraut. Darum ist steht bei mir das Modul nur in der zweiten Reihe, für viele andere Entwickler wird das sicher nicht gelten.
Kommen wir noch zur Einschätzung des Preises. Dieser liegt ungefähr im Bereich der JetBrains-Tools. Da der Kundenkreis merklich kleiner sein wird, ist das bezogen auf den Funktionsumfang mehr als fair. Positive muss hier erwähnt werden, dass NDepend einer permanenten Entwicklung unterliegt und man trotzdem nicht den Eindruck bekommt, dass die Fertigstellung erst beim Kunden geschieht. Das obligatorische Subscription-Model ist damit gerechtfertigt. Im Vergleich zu meinen älteren Versionen empfinde ich beispielsweise die Integration innerhalb Visual Studio wesentlich umfangreicher und runder.
Fazit: Vermisst habe ich lediglich die Kombination der Analyse mit einer Versionsverwaltung wie SVN oder Git. Das ist schade und stellt sicher noch ein großes Potential für die Zukunft dar. Mein persönliches Highlight von NDepend bleibt ganz klar die große Menge an vordefinierten Regeln. Diese sind sauber definiert, gut gruppiert, flexibel anpassbar und vor allen Dingen gut mit den passenden Hilfethemen verbunden.
25. April 2017 Mario Noack Keine Kommentare
Vor gut 3 Jahren habe ich hier eine Bewertung von NDepend veröffentlicht. Nun ist vor kurzem der Hinweis auf eine größere Aktualisierung eingetroffen. Diese neue Version habe ich wieder unter die Lupe genommen und in aktuellen Projekten mit Visual Studio 2015 getestet. Für alle Programmierer, welche dieses Tool nicht kennen:
NDepend ist eine Software, mit der die Softwarequalität eines .NET-Programms überprüft werden kann. Für die Überprüfung und Auswertung stehen sehr viele Möglichkeiten zur Verfügung. Durch historische Betrachtungsmöglichkeiten kann ebenfalls eine zeitliche Entwicklung der Qualität geprüft und sichergestellt werden.
Die Installation war vertraut, es ist ein wenig Handarbeit angesagt, die einen Software-Entwickler in keinster Weise vor Fragen stellt. Danach ist das PlugIn in Visual Studio einsatzbereit oder mal kann eine lokale Version nutzen. Jetbrains Resharper beispielsweise nimmt einem bei der Installation etwas mehr Arbeit ab, wirklich schneller ist man aber damit aber nicht fertig. NDepend legt eigene Projektdateien zu einem Visual Studio Projekt an. Damit ändert sich am eigentlich Projekt nichts und Entwickler ohne NDepend und auch die Versionsverwaltung werden nicht beeinflusst. Das gibt einen großen Pluspunkt von mir!
Ich habe NDepend mit Projekte im WinForm, Asp.Net Webform und Asp.Net MVC Bereich ausprobiert. Hier gab es viele sinnvolle Warnungen und Fehler, die im geprüften Quellcode korrigiert werden sollten. Bei Asp.Net mit WebForms wurden aber auch die Zusammenhänge zwischen Aspx-Formular und Code nicht erkannt, was in sehr vielen Fehlern resultierte, die nicht korrigiert werden können. Hier wird der Hersteller sein Regelwerk noch prüfen.
Apropos Regeln: Es ist eine klare Ausrichtung auf den professionellen Entwickler mit einem Sinn für guten wartbaren Code erkennbar. Alle vordefinierten Regeln sind gut erklärt und über eine interne Linq-ähnliche Sprache anpassbar.
Wie viele Softwarefirmen haben auch die Macher von NDepend ihr Lizenzmodell auf eine Jahresgebühr gestellt. Das ist nachvollziehbar, da ein Produkt wie NDepend eigentlich permanent weiterentwickelt und aktualisiert werden muss, um mit Visual Studio und neuen Funktionalitäten eingesetzt zu werden. Ob der Preise zu hoch oder tief ist, sollte jeder für sich entscheiden. Wer die Softwarequalität seines Teams im Auge behalten will, wir aber sicher nicht an den Kosten scheitern.
Sprung in der Identity Spalte beim SQL Server 2012
23. August 2016 Mario Noack Keine Kommentare
Kurz nach der Migration einiger Datenbank von einem SQL Server 2008 auf einen SQL Server 2016 ist aufgefallen, dass es große Sprünge in den Identity-Spalten gab, die nicht durch verworfene Datensätze erklärt werden konnten. Dabei ging es jeweils um Sprünge von ca. 1000 oder sogar 10.000. Die Ursache ist in der MSDN zu finden:
The identity property on a column does not guarantee the following: … Consecutive values after server restart or other failures – SQL Server might cache identity values for performance reasons and some of the assigned values can be lost during a database failure or server restart. This can result in gaps in the identity value upon insert.
Dieser Sprung beträgt bei Spalten mit bigint aber bis zu 10.000, bei Spalten mit int immerhin noch 1.000. Da ist sehr viel und bringt einen in einen Erklärungsbedarf. Basierend auf diesem Beitrag lässt sich das Problem leicht nachstellen:
CREATE TABLE MyTestTable(Id INT IDENTITY(1,1), Name VARCHAR(255));   DECLARE @i INT = 100000   While @i > 0 BEGIN INSERT INTO MytestTable (Name) VALUES ('Test2') SET @i = @i-1 END
CREATE TABLE MyTestTable(Id int Identity(1,1), Name varchar(255)); Declare @i int = 100000 While @i > 0 BEGIN Insert into MytestTable (Name) values ('Test2') Set @i = @i-1 END
Während diese Schleife läuft (das Problem tritt nur bei Tabellen in Verwendung auf!), den SQL Server neu starten. Dann
INSERT INTO MyTestTable(Name) VALUES ('Mr.Jackson');   SELECT Id, Name FROM MyTestTable ORDER BY Id DESC;
insert into MyTestTable(Name) values ('Mr.Jackson'); SELECT Id, Name FROM MyTestTable ORDER BY Id Desc;
Damit sollte das Problem sichtbar sein. Eine Option ist die Nutzung von Sequenzen mit der NOCACHE Option, anstatt auf IDENTITY Spalten zu setzen. Wenn diese Option zu aufwendig ist, kann auch die Option -T272 für die komplette Instanz genutzt werden. Damit ist das alte Verhalten (bis SQL 2008) wiederhergestellt.
Es bleibt noch anzumerken, dass das TRACE Flag T272 das Caching-Verhalten für die Generierung von Identity-Werten deaktiviert. Negative Auswirkungen auf die Performance beim Erzeugen neuer Datensätze sind somit möglich.
Daten per SQL INSERT ohne Schlüsselspalte kopieren
5. August 2015 Mario Noack Keine Kommentare
Immer wieder steht man vor der Aufgabe, Datenmengen innerhalb einer Tabelle zu kopieren. Typisierte Datenzugriffsschichten, wie das Entity Framework, bieten zwar viel Komfort, lassen aber zukünftige DDL Updates außen vor. Ein Update des Datenmodells, speziell mit ergänzten oder gelöschten Spalten erzwingt dann automatisch ein Update der Anwendung, wenn die Kopierfunktion vollständige Kopien anlegen soll. Bei oft geänderten Tabellen wir das zu einem Problem. Zudem sind komplexere Kopieroperationen direkt auf dem Server mittels einer StoredProcedure meist wesentlich schneller.
Hier bietet sich natürlich die Lösung mit einem INSERT SQL an:
INSERT INTO MyTable SELECT mt.* FROM MyTable mt;
INSERT INTO MyTable SELECT mt.* FROM MyTable mt;
Das Problem mit diesem Befehl sind aber IDENTITY Spalten, die nicht übergeben werden dürfen. Dies kann man natürlich durch Angabe der Spaltennamen umgehen. Damit landet man aber wieder am Anfang des Problems. Die Spaltennamen müssen fest definiert oder zuvor aufwändig ermittelt werden.
Eine andere Lösung lässt sich jedoch über temporäre Tabellen entwickeln. Man erstellt mit SELECT INTO eine temporäre Tabelle mit den benötigten Daten. Deren Identity-Spalte kann man problemlos verwerfen und danach funktioniert ein INSERT INTO ohne Problem:
CREATE PROCEDURE dbo.CopyTable @SourceId BIGINT AS SET NOCOUNT ON;   IF OBJECT_ID('tempdb..#MyTable') IS NOT NULL DROP TABLE #MyTable;   SELECT mt.* INTO #MyTable FROM MyTable mt WHERE mt.Id = @SourceId;   ALTER TABLE #MyTable DROP COLUMN Id;   INSERT INTO MyTable SELECT mt.* FROM #MyTable mt;   IF OBJECT_ID('tempdb..#MyTable') IS NOT NULL DROP TABLE #MyTable;   SET NOCOUNT OFF; GO
CREATE PROCEDURE dbo.CopyTable @SourceId bigint AS SET NOCOUNT ON; IF OBJECT_ID('tempdb..#MyTable') IS NOT NULL DROP TABLE #MyTable; SELECT mt.* INTO #MyTable FROM MyTable mt WHERE mt.Id = @SourceId; ALTER TABLE #MyTable DROP COLUMN Id; INSERT INTO MyTable SELECT mt.* FROM #MyTable mt; IF OBJECT_ID('tempdb..#MyTable') IS NOT NULL DROP TABLE #MyTable; SET NOCOUNT OFF; GO
Ein weiterer Vorteil ist das einfach Aktualisieren der neuen Datenmenge in der temporären Tabelle.
3. September 2014 Mario Noack Keine Kommentare
Wenn man LINQ-Abfragen etwas dynamischer zusammen bauen möchte, sehnt man sich schnell nach den alten SQL Strings zurück. Das war völlig flexibel, aber auch fehleranfällig. Ein von mir abonnierter Blog hat das Thema aufgegriffen und eine kleine Lösung dafür vorgestellt: Klick hier.
Allerdings fand ich das Vorgehen mit Expressions sehr kompliziert, zumindest für diesen Sachverhalt. Ich habe darum das Beispiel einmal auf meine Herangehensweise umgebaut:
private static void Main(string[] args) { var people = new List () { new Person() { Firstname = "Carl", Lastname = "Sample" }, new Person() { Firstname = "Mark", Lastname = "Schulz" } };   var filtered = people.AsQueryable();   var queryFirstnames = true; var queryLastnames = true; var searchValue = "l";   if (queryFirstnames) { filtered = filtered.Where(p => p.Firstname.Contains(searchValue)); } if (queryLastnames) { filtered = filtered.Where(p => p.Lastname.Contains(searchValue)); }   Console.WriteLine(filtered.Count()); Console.ReadKey(); }
private static void Main(string[] args) { var people = new List () { new Person() { Firstname = "Carl", Lastname = "Sample" }, new Person() { Firstname = "Mark", Lastname = "Schulz" } }; var filtered = people.AsQueryable(); var queryFirstnames = true; var queryLastnames = true; var searchValue = "l"; if (queryFirstnames) { filtered = filtered.Where(p => p.Firstname.Contains(searchValue)); } if (queryLastnames) { filtered = filtered.Where(p => p.Lastname.Contains(searchValue)); } Console.WriteLine(filtered.Count()); Console.ReadKey(); }
Da die Abfrage von LINQ erst so spät als möglich ausgeführt wird, können auch mehrere Bedingungen hintereinander gehängt werden, oder eben auch nicht. Dadurch entsteht automatisch eine AND Verknüpfung. Möchte man eine OR Verknüpfung, so leidet die Lesbarkeit etwas, da man dann mit LINQ Union arbeiten muss.
Nachteil meiner Lösung ist aber, dass man den Zugriff auf die Daten und den Zusammenbau der Abfrage zusammen codieren muss. Sofern das kein Problem darstellt, finde ich diesen Weg etwas übersichtlicher.
KategorienDatenbank, Microsoft .NET Tags: LINQ
Große Aufzählungen im .NET Framework
13. Juli 2014 Mario Noack Keine Kommentare
Neulich wurde ich mit der Definition einer besonders umfangreichen Aufzählung konfrontiert. Da hierfür die magische 32Bit Grenze überschritten wurde, war ich skeptisch. Ein Test ergab, das diese Skepsis in der Tat berechtigt war. Folgende Deklaration:
public enum Big { Small = 1 << 1, Medium = 1 << 8, Large = 1 << 40 }
public enum Big { Small = 1 << 1, Medium = 1 << 8, Large = 1 << 40 }
erzeugt dann das Problem. Bis hier:
var enumTest = Big.Small; Debug.Assert(enumTest == Big.Small); enumTest = Big.Medium; Debug.Assert(enumTest == Big.Medium); enumTest = Big.Large; Debug.Assert(enumTest == Big.Large);
var enumTest = Big.Small; Debug.Assert(enumTest == Big.Small); enumTest = Big.Medium; Debug.Assert(enumTest == Big.Medium); enumTest = Big.Large; Debug.Assert(enumTest == Big.Large);
erscheint alles in Orndung, ein Ausgabetest:
var enumTest = Big.Small; Console.WriteLine(enumTest); enumTest = Big.Medium; Console.WriteLine(enumTest); enumTest = Big.Large; Console.WriteLine(enumTest);
var enumTest = Big.Small; Console.WriteLine(enumTest); enumTest = Big.Medium; Console.WriteLine(enumTest); enumTest = Big.Large; Console.WriteLine(enumTest);
zeigt aber dann das Problem. Die Definition Medium und Large sind intern identisch:
Zur Lösung des Problems muss man zwei Änderungen durchführen. Einmal ist der Aufzählungstyp von long abzuleiten und die Basiszahl für die Bitverschiebung muss ebenfalls eine long-Zahl sein:
public enum Big: long { Small = 1L << 1, Medium = 1L << 8, Large = 1L << 40 }
public enum Big: long { Small = 1L << 1, Medium = 1L << 8, Large = 1L << 40 }
Das Ergebnis bestätigt die korrekte Ausführung. Bei der Nutzung von 64 Bit ist aber dann vorerst wirklich Schluss!
KategorienMicrosoft .NET Tags: C#, Microsoft .NET
27. April 2014 Mario Noack Keine Kommentare
Als ich vor kurzem gebeten wurde, mir NDepend anzuschauen, sagte ich sofort zu. Diese Software versprach mir Unterstützung in der Entwicklung und Überwachung von sauberem Code, ganz im Sinne von CCD. Nach dieser Sichtung habe ich verstanden, dass die Autoren der Software eine großartige Arbeit geleistet haben. Man erhält ein ungeheuer ausgefeiltes Stück Software, das den Entwickler zu Anfang mit der Fülle und dem Umfang von Dialogen und Optionen schlicht überfährt. Man lernt aber schnell, dass es scheinbar unvermeidbar war, damit die Software in unterschiedlichen Bedingungen eingesetzt werden kann. Ich rate jedem, der seinen NET-Sourcecode verbessern möchte oder im Team Fehlentwicklungen im Auge behalten will, sich die Zeit der Einarbeitung zu nehmen. Es lohnt sich!
Überprüfung des eigenen Codes
Als Einstieg sollte man sich diese Seite anschauen: GettingStarted. Dort wird als Video und alternativ in einer reich bebilderte Anleitung dargestellt, wie leicht NDepend mit dem eigenen Projektmappen verbunden werden kann. Dieser Vorgang funktioniert sehr gut und schnell. Die Original-VS-Projekte werden nicht angefasst, die NDepend-Verknüpfung kann auch leicht wieder gelöst werden. Eine SVN-Integration wird dadurch nicht beeinträchtigt.
Dann kann man sich bereits mittels des über das NDepend-Menü erreichbaren DashBoards einen Überblick verschaffen. Diese Beispielgrafik von NDepend stellt natürlich einen späteren Stand dar, zeigt aber die Fülle Informationen: Für mich war besonders wichtig, dass man sogar einen Überblick erhält, ob im Lauf der Zeit immer mehr Regeln verletzt wurden. Das hilft in der Team-Kontrolle! Weiterhin kann aus diesem DashBoard heraus leicht geprüft werden, welche Regeln verletzt wurden und vor allen Dingen: an welcher Stelle im Source! Regeln, welche man nicht für wichtig erachtet, kann man leicht deaktivieren. Alle Regeln liegen auch in einer gut kommentierten LINQ-ähnlichen Sprache vor, was die Anpassung leicht macht. Hier steht zusätzlich zu jeder NDepend eigenen Funktion eine gute Hilfe im Maus-Tooltip zur Verfügung.
Man stellt schnell fest, dass es nicht immer sinnvoll und praktikabel ist, gleich den kompletten Code Regelkonform zu gestalten, sprich alle Regel-Verletzungen zu entfernen. NDepend bietet hier die Möglichkeit, Basisstände als Vergleich heranzuziehen. Somit werden nur noch neuere Regelverletzungen angezeigt, was natürlich gerade für den Start sinnvoll ist. Als Start kann man dazu, wie in der nebenstehenden Grafik dargestellt, die historische Speicherung der Werte auf Always stellen. Damit hat man bereits nach der ersten NDepend-Überprüfung einen Vergleichsstand zur Verfügung, was den Start stark erleichtert.
NDepend eignet sich nicht für den Programmiereinsteiger. Man muss ein Interesse an Clean Code haben und auch schon diverse Regeln kennen und anwenden, LINQ darf kein Fremdwort mehr sein. Dann bietet NDepend eine sehr gute Untersützung. Wenn man für diesen Schritt bereit ist, bietet das Tool einen hervorragenden Start in die permanenten Prüfung und Überwachung von Code-Regeln, zumal sogar für die Integration in Buildserver gesorgt wurde. NDepend liefert ein umfangreiches Set an Regeln, sauber gruppiert, bereits mit. Eigene Regeln können aus dem Code extrahiert werden. Als absolutes Power-Feature bewerte ich die Definition einer Baseline für vergleichende Berichte. Damit können alte Probleme leichter ausgeblendet werden.
Eine Bewertung zum Preis fällt schwer: Die Dialog von NDepend wurden mit sehr viel Liebe erstellt. Praktisch überall stehen sinnvolle Optionen, Verknüpfungen zu Hilfethemen und Tooltips zur Verfügung. Der Preis erscheint hierfür eigentlich zu gering. Aus der Sicht der Programmierer, die bei Clean-Code oft nicht gerade offene Türen einrennen, ist der Preis dann wieder wirklich sinnvoll und mit Blick auf den Funktionsumfang mehr als fair.
KategorienCCD, Microsoft .NET Tags: CCD, NDepend
SQL User mit Login verbinden
12. Februar 2014 Mario Noack Keine Kommentare
Regelmäßig nach einer Wiederherstellung einer bestehenden Datenbank auf einem neuen Server müssen die Logins, die serverseitig gespeichert und angelegt werden, mit dem User der Datenbank verbunden werden. Ansonsten erhält der Login auf die Datenbanken einfach keinen Zugriff.
Dafür gibt es drei Möglichkeiten:
Man kann den User in der Datenbank entfernen und den User einfach auf Serverebene neu anlegen. Das SQL Managmentstudio bietet hierbei die Möglichkeit, die Rechte auf einer Datenbank zu erteilen. Aber dabei verliert man ALLE bereits konfigurierten Rechte, die der User in der Datenbank hatte. Diese Lösung ist somit nicht empfehlenswert.
Der Microsoft SQL Server bietet die Procedure sp_change_users_login, mit der ein neu angelegter Login im Server mit dem User der Datenbank verbunden werden kann. Ich nehme dafür eigentlich immer einen identischen Namen, um Verwechslungen zu vermeiden:
EXEC sp_change_users_login 'Update_One', 'User1', 'User1';
EXEC sp_change_users_login 'Update_One', 'User1', 'User1';
Dieser Befehl muss für jeden User in jeder Datenbank ausgeführt werden, kann aber leicht in einem Skript vorbereitet werden.
Abgelöst wird diese vorstehende Procedure durch folgenden SQL Befehl: ALTER USER. In der Anwendung kann man dann schreiben:
ALTER USER User1 WITH LOGIN = User1;
ALTER USER User1 WITH LOGIN = User1;
Auch dieser Befehl muss für jeden User in jeder Datenbank ausgeführt werden und kann leicht in einem Skript vorbereitet werden.
11. Januar 2014 Mario Noack Keine Kommentare
Auf einem frisch installierten Windows 8.1 Rechner kam es bei der Nutzung des signtool’s zur Fehlermeldung
Signtool requires CAPICOM version 2.1.0.1
Die CAPICOM kann man bei Microsoft herunterladen, allerdings bleibt der Fehler dann bestehen.
Die Lösung ist die manuelle Registrierung der CapiCom.dll:
regsvr32 "C:\Program Files (x86)\Microsoft CAPICOM 2.1.0.2 SDK\Lib\X86\CapiCom.dll"
regsvr32 "C:\Program Files (x86)\Microsoft CAPICOM 2.1.0.2 SDK\Lib\X86\CapiCom.dll"
Probleme mit Visual Studio Formular Designer
11. Januar 2014 Mario Noack Keine Kommentare
Beim Öffnen großer Formulare in Visual Studio Formular Designer (WinForms) tritt teilweise das Problem auf, dass Visual Studio 2012/2013 wegen eines Problems beendet wird. In der Ereignisanzeige wird dabei ein Problem in der KERNELBASE.dll vermerkt.
Die Lösung ist dann eigentlich trivial: Es muss der Dienst Performance Logs & Alerts (pla) gestartet werden.
Es besteht nun die Vermutung, dass der Formulardesigner einfach eine Performance-Warnung melden wollte und das nicht konnte, weil der Dienst nicht aktiv war.
KategorienMicrosoft .NET Tags: Fehlersuche, Microsoft .NET, Visual Studio
MCPD Windows® Developer 3.5
MCSA SQL Server 2012
MCSE: Data Management and Analytics
32Bit 64Bit Acronis Administration Ado.Net Asp.NET Backup C# CCD Clipboard Datum Druckertreiber Encryption EPS Event Fehlersuche Genauigkeit Ghostscript IIS Internet Explorer Literatur Microsoft .NET NDepend Office365 PDF Powershell PStill RegEx Registry ReSharper RSA SQL String SVN Tortoise UAC Vista VistaDB Visual Studio VS2008 Windows Windows 7 Word WordToPDF Zwischenablage