Forenbeiträge von BhaaL Ingesamt 656 Beiträge
@Bhaal:
Da sind deine Infos etwas Lückenhaft.
Für Intellicense wird nur die XML-Datei benutzt, diese Angaben stehen nicht
in der DLL.
Deshalb muss eben sowohl die DLL als auch die XML-Datei zur verfügung stehen.
Interressant, wusste ich bis dato nicht.
Und tatsächlich, auch im Windoof-Ordner unter Framework liegen die Dinger.
Man lernt ja nie aus 😉Hätte aber schwören können, dass die Infos als Metadaten in das Assembly eingebettet werden
Gruß, BhaaL
Also, am XML Documentation File liegt das sicher nicht!
Das Ding ist zum einen dazu da, dass man per externem Tool (NDoc, Sandcastle,...) Helpfiles als API-Dokumentation generieren kann, und zum anderen warnt der Compiler zusätzlich, wenn öffentlich sichtbare Methoden nicht kommentiert wurden.
Versuch bitte mal, die DLL im Object Browser (oder vielleicht noch besser, im Reflector) aufzumachen, ob dort Kommentare drin sind. Findest du dort auch nix, steht mit ziemlicher Sicherheit nichts in den Metadaten der DLL - einfach mal das Ding neu kompilieren, möglicherweise vorher prüfen, ob die Summary-Kommentare richtig gesetzt sind (/// <summary>text here</summary>) sowie keine Sonderzeichen drin sind (< und > müssen beispielsweise mit den jeweiligen HTML-Entities < > umschrieben werden).
Passt das alles, müssen wir auf einen anderen Guru warten, der weiß wo sich das Setting im Studio befindet, ich hab nämlich keins gefunden 😉
Gruß, BhaaL
Wenn du dir die Klasse (bzw. den Tab, der aufgeht) genauer ansiehst, steht drin "[from Metadata]". Das heißt, VS hat die Informationen über Reflection rausgeholt, genauso wie Intellisense das macht.
Normale Kommentare kommen da nicht rein 😉
Kannst dir ja mal per NetMassDownloader den Framework Source runterladen, da findest du auch nur <summary>-XmlDoc Kommentare, und keine normalen 😉
Gruß, BhaaL
Der Kommentar ist leider nur aus den Metadaten generiert, wär natürlich interessant zu wissen warum Microsoft dort nicht gleich die originalen <summary> und <param> Tags generiert, sondern normale Kommentare hinschreibt...
Parameternamen bis 3 Zeichen bekomm ich in meinem eigenen Sourcecode in eine Zeile, alles drüber wird umgebrochen.
Aber:
Benutze ich Methoden, die aus einem anderen Assembly kommen (anderes, referenziertes Projekt sollte theoretisch auch funktionieren), wird der Text immer in der gleichen Zeile angezeigt.
Natürlich auch fraglich, warum Microsoft hier keine einheitlichen Konventionen hat. Könnte mir höchstens vorstellen, dass man dadurch sofort merken soll, ob sich eine Methode im gleichen oder in einem anderen Assembly befindet 🤔
Gruß, BhaaL
Du könntest die Pre/Post-Build Events in eine Batch-Datei verpacken, und ein dezentes exit 0 als letzte Anweisung reinschreiben.
prebuild.bat
NET STOP servicename
exit 0
postbuild.bat
NET START servicename
exit 0
Pre-Build Event
$(ProjectDir)prebuild.bat
Post-Build Event
$(ProjectDir)postbuild.bat
In dem Fall sollte das exit 0 kein Problem sein, aber für andere Sachen (Kopiervorgänge, Checks ob Dateien existieren usw.) sollte kein silent exit rein, dort lieber eine anständige Fehlerbehandlung.
Hinweis:
$(ProjectDir) wird benötigt, um den richtigen Pfad zur Datei zu finden. Bekommst du den ominösen "The command xxx exited with code 9009."-Fehler, konnte dein Build-Event nicht ausgeführt werden, weil die Datei nicht gefunden wurde. Ist nicht immer offensichtlich, vor allem durch den komischen Exit Code.
Zum automatischen Attach kann ich leider nix sagen, zum Debuggen starte ich grundsätzlich direkt über die IDE; erst wenn das alles ohne Probleme läuft, würd ich das ganze als Service deployen und per net start aufrufen. Schlägt dann was fehl, kann man immer noch attachen und nachschaun 😉
Gruß, BhaaL
Hallo erstmal!
Ich versuche grade in einem meiner Projekte, Conditionals innerhalb des Project Files zu benutzen, um je nach Condition andere Assemblies und Defines reinzubekommen.
Mal kurz ein fiktives Setup, an dessen Beispiel ich das ganze veranschaulichen möchte:
Die Beispielapplikation soll mit einer anderen nicht-.NET-Applikation über COM reden. Dafür stellt die Applikation ein Interop-Assembly zur Verfügung.
Diese Applikation kann jetzt in verschiedenen Versionen vorliegen, die sich zwar nur minimal aber doch voneinander unterscheiden; Hauptpunkt ist der Unterschied in der DLL. Zumindest die Version ist unterschiedlich, und aufgrund einiger Änderungen zwischen den Versionen sind einige benötigte Methoden auch unterschiedlich in der Signatur.
Da gibts zum Beispiel diese Klasse in meiner Applikation:
using OtherApp.Interop;
static class AppInterop {
static void CloseDocument(string fileName) {
OtherAppClass oaClass = new OtherAppClass();
#if OTHER_APP_1_0
oaClass.CloseDocument(fileName);
#elif OTHER_APP_2_0
oaClass.CloseDocument(new Uri(fileName), false);
#endif
}
[...]
}
Überprüfungen und ähnliches sind zur Übersichtlichkeit weggelassen.
Wird die Applikation für OtherApp Version 1.0 kompiliert, soll das Interop Assembly dieser Version verwendet werden, und das Conditional OTHER_APP_1_0 definiert werden (hier gibts eine Methode CloseDocument, die direkt den Dateinamen nimmt).
Wird für OtherApp Version 2.0 kompiliert, soll selbstverständlich das andere Interop Assembly verwendert werden, sowie das Conditional OTHER_APP_2_0 definiert werden (2.0 hat die Signatur geändert, statt des Filename muss eine Uri rein, und man kann zusätzlich sagen, ob die Speicher-Abfrage unterdrückt werden soll).
Da ich auch unterschiedliche Build Configurations habe (Debug, Release, PerformanceTest, ...), wäre es Wahnsinn, zusätzlich zu diesen auch noch die Version zu definieren. Drum die Idee, einfach die Platform missbrauchen. Kurzerhand zwei neue Target Platforms angelegt, respektive Version 1.0 und Version 2.0 genannt.
Innerhalb der Property Group im Project File sieht das ganze nach einer kleinen Bearbeitung dann so aus:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DefineConstants Condition=" '$(Platform)' == 'Version 1.0' ">$(DefineConstants);OTHER_APP_1_0</DefineConstants>
<DefineConstants Condition=" '$(Platform)' == 'Version 2.0' ">$(DefineConstants);OTHER_APP_2_0</DefineConstants>
</PropertyGroup>
Die Referenzen sehen so aus:
<ItemGroup>
<Reference Condition=" '$(Platform)' == 'Version 1.0' " Include="OtherApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=123456789abcdef">
<HintPath>lib\Version 1.0\OtherApp.dll</HintPath>
</Reference>
<Reference Condition=" '$(Platform)' == 'Version 2.0' " Include="OtherApp, Version=2.0.0.0, Culture=neutral, PublicKeyToken=123456789abcdef">
<HintPath>lib\Version 2.0\OtherApp.dll</HintPath>
</Reference>
</ItemGroup>
Die Referenzen funktionieren soweit ich gesehen habe, allerdings bereiten mir die Constants in den jeweiligen PropertyGroups schwierigkeiten...
Wähle ich die Debug-Konfiguration (mit default "Any CPU"), ist nichts definiert, auch nicht meine "TRACE;DEBUG"-Conditionals.
Wähle ich Version 1.0 bzw. Version 2.0, wird aber korrekterweise "OTHER_APP_1_0" bzw. "OTHER_APP_2_0" definiert, "TRACE;DEBUG" fehlt nach wie vor.
Jetzt kommt das große ABER:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DefineConstants Condition=" '$(Platform)' == 'Version 1.0' ">'$(DefineConstants)';OTHER_APP_1_0</DefineConstants>
<DefineConstants Condition=" '$(Platform)' == 'Version 2.0' ">'$(DefineConstants)';OTHER_APP_2_0</DefineConstants>
</PropertyGroup>
Sieht auf den ersten Blick fürchterlich falsch aus, und ist es im Endeffekt auch (die Defines schlagen nicht an), funktioniert in irgendeiner Weise aber doch:
Wähle ich eine der beiden Konfigurationen, sehe ich korrekt definiert "'TRACE;DEBUG';VERSION_1_0", nur eben inklusive der Hochkommata. Lasse ich diese weg, sehe ich nur "VERSION_1_0".
Erst mal die Frage, kennt einer von euch dieses Problem/Phänomen, und weiß was man dagegen machen kann?
Die verwendete IDE ist Visual Studio 2008 Professional Edition, das Project File ist direkt bearbeitet (kein Import ala MSBee oder so).
Zum anderen, habt ihr ähnliche Setups, und wie habt ihr das gelöst? Findet ihr den "Missbrauch" der Platform Ok für sowas, oder würdet ihr das anders lösen?
Vorraussetzung wäre, dass das ganze einfach über die IDE eingestellt werden kann, und nicht irgendwie umständlich oder sogar nur über externe Build-Scripte; sollen ja andere Leute aus dem Projekt genauso verwenden können sollen, ohne vorher ne 3-stündige Einweisung zu bekommen 😉
Gruß, BhaaL