Die Änderungen sind nicht groß, das sehe ich ebenso. Ich konnte nur die Web API in meinen Tests nicht mehr direkt in einem Executable (Console, WPF,...) Projekt einbinden bzw. hab dies auch nirgends als Beispiel gefunden. Das einzige was geht ist in einer WebApp, die will ich aber nicht in jedem Projekt haben. Sollte das weiterhin gehen wäre für mich alles in Ordnung, die Umsetellung von WebAPI 2 auf vnext ist denke ich nicht all zu schwer was den Code angeht, falls es eben geht.
Edit:
Nur nochmal als Zusammenfassung, bisher sah Selfhosting der Web Api in einer Executable (hier Console) so aus:
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
Das würde ich auch gern mit ASP.NET vnext Web API machen.
Diese beiden Stackoverflow-Threads fragen vermutlich das gleiche:
http://stackoverflow.com/questions/25403746/self-hosted-vnext-application
http://stackoverflow.com/questions/27787636/owin-hosting-asp-net-mvc-6-vnext
Und in einem steht es geht so nicht mehr, man muss sich eine WebApp basteln die dann wiederum ge-Selfhostet werden kann. Das ist aber nicht mein gewünschtes Ziel.
Hallo,
@MarsStein: Ich kenne die Möglichkeit mit WCF REST/JSON zu machen, allerdings war es ursprünglich nicht dafür ausgelegt (DataContract, DataMember,...) sondern eher für SOAP. Dennoch bleibt es eine Alternative, da hast Du recht!
@pinki: Mit vnext verschmilzt MVC mit Web Api, das ist ja das verwirrende 😉
@Abt: Mir ist klar das vnext noch nicht produktiv eingesetzt werden darf. Aber ich vermute das dies dann spätestens mit der BUILD Konferenz möglich ist. Es fühlt sich halt so an jetzt auf Web API 2 zu setzen wie wenn man jetzt noch ein Silverlight-Projekt startet. Man weiß es funktioniert, aber die neue technik ist da(steht vor der Türe) und meine eingesetzte Technik läuft aus.
Hier auch noch ein Link zu den Folien von der letzten Basta von Holger Schwichtenberg über die "Das ist neu und anders in ASP.NET 5.0 mit MVC & WebAPI 6.0":
http://it-visions.de/produkte/vortragsdetails.aspx?v=7925
Leider finde ich da auch nicht das passende. Evtl. schreib ich Ihm mal und frage konkret nach.
@MarsStein: WebAPI muss es nicht zwingend sein, REST/JSON aber schon. Ich sehe halt das die Zukunft immer mehr in Richtung REST geht und sobald ich zu Android/iOS schaue bleibt als Kommunikationskanal nur noch REST/JSON übrig. WCF im klassischen Sinne mit SOAP fällt gänzlich raus, mit JSON ggf. möglich.
@unconnected: Ich bin mir nicht 100% sicher, aber dein Artikel zeigt meiner Meinung nach das Selfhosting einer Web API 2.2 Anwendung (was bisher ja ging) und nicht von ASP.NET vnext Web API. Das sieht man daran das der Controller von ApiController ableitet anstatt wie bei vnext nur noch von Controller. Ein Beispiel dazu ist hier zu finden:
http://www.asp.net/vnext/overview/aspnet-vnext/create-a-web-api-with-mvc-6
Auf http://www.asp.net/vnext konnte ich eben leider bisher kein Beispiel finden bei dem die Web API in einer Executable gehostet ist.
Hallo zusammen,
ich google mich nun schon seit Stunden/Tagen kreuz und quer durchs Netzt und bin immer noch nicht schlau geworden.
Problemstellung: Es soll eine Client-Server Anwendung (im lokalen Netzwerk) erstellt werden bei der der Client mit dem Server via REST (JSON) kommuniziert. Aus verschiedenen Gründen (Zugriff auf lokals Dateisystem,...) läuft der Server als Windows-Dienst und nicht in einem IIS oder Azure (dies ist auch nicht geplant).
Nach kurzem googeln hätte ich für die Kommunikation beim Server Microsoft Web Api 2 als REST Framework vorgeschlagen das über OWIN Selfhost im Windows-Dienst gehostet wird. Fertig!
So und dann googelt man etwas genauer und findet Wald vor lauter Bäumen nicht mehr:
Mit dem in kürze kommenden ASP.NET vnext (man will ja immer mit der Zeit gehen) wird das bisher separate WebAPI ja in ASP.NET integriert. ASP.NET wird modular und kann nun auch unter anderem auf beliebigen Systemen gehostet werden (IIS, Selfhost, ...). Nun konnte ich niergends finden (und auch im Test mit Visual Studio 2015 CTP 6 und ASP.NET vnext erkennen) das man die WebAPI noch direkt in einer Executable (Consolen-/WPF-Applikation, Dienst,...) einbinden kann, sondern das ganze läuft stets in einer WebApp. Stimmt dies? Wenn ja, kann man mit ASP.NET vnext keine REST Service für normale Executables zur Verfügung stellen. Muss man in so einem Fall auf andere Frameworks wie Nancy oder ServiceStack zurückgreifen? Das fände ich sehr schade, weil man hier darauf hoffen muss dass diese Projekte in Zukunft noch weiterentwickelt werden.
Gruß
Maruu
Es müsste nicht zwingend eine GUID sein, hauptsache ein eindeutige ID. Ich hatte mir auch schon überlegt einen Hash über den Namespace+Containername+Controlname zu erstellen. Ändert man dann aber den Namen stimmt die ID auch nicht mehr. Es gibt also leider keine schnelle Lösung wie es aussieht.
Ok, hatte gehofft es gibt eine Möglichkeit. Den Weg über das AddOn will ich nicht gehen. Das Tool das die GUIDs prüft wäre eine Möglichkeit.
Der Code im Konstruktor ist nur da um initial eine GUID zu generieren. Das macht er auch gut. Beim zweiten mal wird die GUID dann von außen gesetzt. Leider scheint man den Designer nicht so einfach beinflussen zu können das er eben beim Kopieren eines Controls nochmal einen gewissen Code ausführt. Aber egal, ich werde es schon irgendwie anders geregelt bekommen 😉
Trotzdem vielen Dank!
@herbivore: Der Setter muss public sein damit die GUID auch dauerhaft gespeichert wird. Die GUID soll 1x beim ersten Erstellen (im Designer) generiert und danach nicht mehr verändert werden. Es geht nicht darum bei jedem Erstellen des Buttons eine neue GUID zu generieren, sondern nach möglichkeit nur beim ersten mal. Das funktioniert ja auch, nur leider nicht wenn der Button kopiert wird, hier wird auch die GUID kopiert statt eine neue erstellt.
Setze ich den Setter auf private, wird der Wert nicht in den Designer-Code übernommen.
Hallo zusammen,
für ein Projekt werden eigene UserControls benötigt. Dabei leite ich von der jeweiligen Basisklasse (z.B. Button, TextBox usw.) ab um die Grundfunktionalität zu erhalten. Nun soll jedes Custom-UserControl ein Property mit einer eindeutigen GUID erhalten. Dies hilft später das UserControl genau zu identifizieren und z.B. darauf in der Hilfe zu referenzieren.
Folgende Idee hatte ich:
public class GuidButton:Button
{
[DefaultValue(null)]
public string ControlGUID { get; set; }
public GuidButton()
{
ControlGUID = Guid.NewGuid().ToString();
}
}
So wird automatisch beim Erstellen des GuidButtons im Designer eine neue GUID generiert und im Designer Code hinterlegt.
Das Problem ist nun, arbeitet man mit dem Designer und kopiert einen GuidButton, wird ein neuer GuidButton erstellt aber die GUID wird mitkopiert und nicht neu erstellt.
Hier ein Beispiel:
//
// guidButton1
//
this.guidButton1.ControlGUID = "4446f5e2-068c-475c-bd52-5cd879afb3c8";
this.guidButton1.Location = new System.Drawing.Point(137, 89);
this.guidButton1.Name = "guidButton1";
this.guidButton1.Size = new System.Drawing.Size(75, 23);
this.guidButton1.TabIndex = 0;
this.guidButton1.Text = "guidButton1";
this.guidButton1.UseVisualStyleBackColor = true;
//
// guidButton2
//
this.guidButton2.ControlGUID = "4446f5e2-068c-475c-bd52-5cd879afb3c8";
this.guidButton2.Location = new System.Drawing.Point(137, 128);
this.guidButton2.Name = "guidButton2";
this.guidButton2.Size = new System.Drawing.Size(75, 23);
this.guidButton2.TabIndex = 1;
this.guidButton2.Text = "guidButton2";
this.guidButton2.UseVisualStyleBackColor = true;
Beides mal die selbe GUID, dies ist nicht gewollt. Lässt sich das verhindern?
Vielen Dank vorab für die Hilfe,
Hannes
Hallo zusammen,
ich versuche gerade eine Anwendung zu entwickeln die auf SAP Business one zugreift. Nun muss ich neben der Version 8.8.2 auch die neuste Version 9.0.0 der API unterstützen. SAP stellt die API als COM-Objekte zur Verfügung. Ich hab nun versucht über Visual Studio einen Verweis auf beide COM-Objekte hinzuzufügen, erhalte aber beim hinzufügen des zweiten COM-Objekt den Fehler:
Fehlermeldung:
Could not add a reference to {FC8030BE-F5D2-4B8E-8F92-44228FE30090}\9.0:Es ist bereits ein Verweis auf diese Typbibliothek vorhanden. Sie müssen den Verweis "SAPbobsCOM" löschen, bevor Sie diesen hinzufügen.
Problem ist vermutlich das beide COM-Objekte "SAPbobsCOM" heissen und sich nur in der Version unterschieden.
Beim COM-Verweis hinzufügen wird ja eine Interop-Dll (Interop.SAPbobsCOM.dll) erzeugt. Also hab ich mir beide DLLs nacheinander erzeugen lassen, beide DLLs umbenannt und als Verweis von Hand hinzugefügt. Dann jeder DLL einen Alias verpast und im Quellcode "external alias ..." verwendet. Beim kompilieren erhalte ich aber folgende Fehlermeldung:
Fehlermeldung:
Fehler 1 Es wurde bereits eine Assembly mit dem einfachen Namen "Interop.SAPbobsCOM, Version=8.8.0.0, Culture=neutral, PublicKeyToken=null importiert. Entfernen Sie einen der Verweise, oder signieren Sie die Verweise, damit sie parallel verwendet werden können. c:...lib\Interop.SAPbobsCOM.8.8.2.dll SAP
Leider komm ich jetzt nicht weiter. Wie kann ich zwei COM-Objekte mit dem gleichen Namen ("SAPbobsCOM") importieren und parallel ansprechen (ggf. durch unterschiedliche Namespace o.ä.)?
Gruß
Hannes
Hallo zusammen,
ich bin gerade dabei eine .NET 4.0 Anwendung zu bauen. Dabei soll auf ein Warenwirtschafts-Programm zugegriffen werden das eine COM Schnittstelle besitzt. Dieses Programm bringt jedoch alle 3 Monate eine Aktualisierung heraus die auch die COM-Schnittstelle aktualisiert. Wenn ich nun in Visual Studio eine Referenz hinzufüge und die COM-Komponente auswähle wird mir automatisch eine DLL dazu erstellt die den Zugriff kapselt, aber nur für jeweils die aktuelle Version der COM-Schnittstelle.
Ich habe nun das Problem das ich alle 3 Monate wenn sich die Schnittstelle ändert auch die Referenz aktualisieren muss. Weiterhin muss ich aber gleichzeitig auch die ältere Versionen der COM-Schnittstelle unterstützen. Daher meine Frage, gibt es eine Möglichkeit die Erstellung der DLL-Datei die die COM-Schnittstelle kapselt zu beeinflussen und ggf. den Namen und den Namespace darin anzupassen? So könnte ich den Namen und Namespace z.B. folgendermaßen nennen z.B. Wawi.v1_3_0.xyz, Wawi.v1_4_0.xyz usw. und im Programm selbst die passende Version auswählen.
Damit könnte ich alle paar Monate mein Programm aktualisieren und dazu mehrere der Versionen der COM-Schnittstelle der Warenwirtschaft ausliefern. Oder gibt es eine Alternative (z.B. Late Binding oder ähnliches)?
Gruß
Hannes