Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Wie geht man mit Paketmanagement auf dem Client/Server um? Welche Technologien nutzt man?
[email protected]
myCSharp.de - Member



Dabei seit:
Beiträge: 407

Themenstarter:

Wie geht man mit Paketmanagement auf dem Client/Server um? Welche Technologien nutzt man?

beantworten | zitieren | melden

Hi...

ich wollte heute für einen Prototypen ein asp.net core 1.1 Projekt einrichten.

Technologien bzw. Libs die ich verwenden wollte:
asp.net core
typescript
jquery
knockout

Schön langsam bin ich am verzweifeln.

nuget nur noch für csharp-libs
bower für die client-libs (da muss man dann aber vorerst mal "git für windows" installieren damit überhaupt was funktioniert)

Typescript alleine geht ja noch einigermaßen (per tsconfig.json).
Aber das Handling der Definitions-Files für externe Libs (knockout, jquery) ist Wahnsinn. In asp.net-Projekten war es so, dass per Nuget alle Libs und auch die Definitionsfiles reingeholt wurden. TS-File erstellt und los geht's.

Jetzt braucht man erst mal NPM darüber muss man "Typings" installieren und darüber kann man sich dann die Definitions-Files holen (per CMD).

Kommt es nur mir so vor oder wurde hier mit VS2017/asp.net core bzw. dem Tooling hier alles verschlimmbessert?


lg
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15817
Herkunft: BW

beantworten | zitieren | melden

Webanwendungen bestehen heutzutage aus mindestens zwei Applikationen:

Client Anwendung (Single Page Application / Progressive Web Application)
JavaScript Basis
Angular, React, Aurelia
Pakete über NPM, evtl. Bower
Task Runner wie Angular CLI, Gulp...

Server Anwendungen (API)
ASP.NET Core
Pakete über NuGet

Muss natürlich im Backend nicht .NET sein, kann auch Java oder Node.. sein. Aber das war ja hier gefragt.

Mit VS2017 hat das alles prinzipiell relativ wenig zutun.
Alle Technologien hier sind mittlerweile unabhängig von irgendwelchen IDEs oder Editoren.
Du kannst für alles auch einfach nur Nodepad, Atom oder VSCode verwenden. Zudem die Kommandozeile.

Aber ja, die Web-Welt hat und bietet viele Technologien - und da führt auch kein Weg mehr dran vorbei.

Im Backend selbst (also ASP.NET Core) verwende ich ausschließlich VS2017.
Im Frontend verwende ich VSCode. Dieser Mix ist auch in diesem Tech-Stack relativ üblich.
Ich hab aber nichts am Tooling auszusetzen. Finde hier ist ein gewaltiger Schritt nach Vorn gelungen.
private Nachricht | Beiträge des Benutzers
Coffeebean
myCSharp.de - Team

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2459
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

Hallo [email protected],

wie Abt schon sagt macht man das besser in zwei versch. Applikationen.

Ich verwende clientseitig VSCode und schreibe Angular mit Webpack, Typescript. Abhängigkeiten via yarn (npm). Gulp/Grunt habe ich komplett rausgeschmissen, brauche ich auch für Cross-Platform nicht mehr (Electron/Cordova).

Serverseitig: VS2017 und ASP.NET Core mit NuGet.

Ist ein prima Mix :)

Bower ist nahezu tot. Es wird jedoch noch von vielen Libs verwendet. Für ein neues Projekte stattdessen einfach die (Dev) Dependencies von npm verwenden. Gibt keinen Grund mehr für Bower. Falls es eine lib nicht gibt kannst du die dir auch einfach in dein Repo ziehen und dann referenzieren (über Webpack/SystemJS)

Wegen den *.d.ts-Files: Wofür brauchst du die wirklich? Ich meine: Klar sind sie angenehm, absolut. Aber wenn du jQuery wirklich verwenden willst, kannst du auch plain Javascript oder jQuery ohne *.d.ts Files im *.ts-File schreiben. Und wenn du mit Angular unterwegs bist und wirklich über ein "document.getElementById(...)" oder "$(...)" nachdenkst bist du mit einer Direktive besser dran. Mit Aurelia etc. kenn ich mich nicht aus.

KnockOut braucht bei anderen Frameworks wie Angular/React auch gute Argumente. Habe es aber auch noch im Einsatz hier und da.

Typescript hier mit reinzubringen ist (fast) nicht ganz fair, weil es eine Prgrammiersprache ist. Und selbst da kommt Javascript raus. Dann müsste man auch sagen, dass C# und VB.NET (oder andere Sprachen des Frameworks) das ganze Serverseitig auch noch kompliziert machen. jQuery und Knockout sind wieder Frameworks. Ein weites Feld, aber eigentlich nicht allzu kompliziert :)

Gruss

Coffeebean
private Nachricht | Beiträge des Benutzers
[email protected]
myCSharp.de - Member



Dabei seit:
Beiträge: 407

Themenstarter:

beantworten | zitieren | melden

Vielen Dank für eure ausführlichen Antworten.

Ich denke ich muss mich was asp.net core bzw. das client-seitige Development betrifft noch detaillierter einlesen.

Hab zwar große Web-Applikationen mit Asp.net MVC / Knockout / Typescript entwickelt aber das ist jetzt doch ein größerer Schritt.
Zitat
Bower ist nahezu tot.
Da frag ich mich aber dann warum das asp.net - Team gerade Bower als quasi Standard für das Client-Package-Management hernimmt.

lg
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15817
Herkunft: BW

beantworten | zitieren | melden

Weil es immer noch Projekte gibt, die auf Bower basieren und daher ihre Dependencies holen.
Die Provider in VS sind alle generisch und können jederzeit erweitert oder ausgetauscht werden. In Zukunft wird das sehr wahrscheinlich WebPack werden.
Was Bower so gut gemacht hat und deswegen lieber benutzt wurde, ist halt der flat dependency tree. Das konnte NPM nie (kann dafür aber nun YARN) und hat immer wieder besonders auf Windows Maschinen Probleme gemacht.
Bower ist immer noch das größte Front-End Package Depot und unterstützt im Gegensatz zu YARN und NPM auch Komponenten, die kein JavaScript sind.
Bower lebt von GIT Repos und braucht keine Registry wie NPM/YARN/NuGet.

Der "Standard" ist aber halt eher NPM, aber da NPM - stand heute - keine deterministischen Ergebnisse liefern kann, ist NPM alleine eigentlich ein No-Go - und daher gibt es YARN.

Die Visual Studio IDE wird aber immer zu langsam sein, dass sie die modernsten Mittel der Webwelt abdecken wird.
Das hat auch Jeff Fritz(ich meine er wars) auf einer Konferenz in Tschechien betont. Dafür bewegt sich die Web-Welt einfach viel viel zu schnell.
Deswegen setzen die meisten hier auf VSCode und Konsorten.
private Nachricht | Beiträge des Benutzers
Coffeebean
myCSharp.de - Team

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2459
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

Hallo [email protected],

wie Abt sagt, bewegt sich die Web-Welt einfach zu schnell als dass das VS-Team Bower so schnell da rausextrahieren könnte. Bower wird noch von vielen Libs benutzt. Heute würde man aber nicht mehr damit starten.

Früher gabs auch die schon angesprochenen Probleme mit dem langen Pfad auf Windows Systemen. Das wurde aber behoben, so dass der Pfad nicht mehr so lang werden kann. Zu der Zeit hat man auch gesagt, dass Bower für die clientseitigen Abhängigkeiten da war, NPM für die Serverseitigen. Aber das ist auch überholt mittlerweile.

Für neue Projekte hat man NPM und Yarn und keinen Grund sich noch einen Paketmanager ins Haus zu holen. Es ist ja schon komplex genug :)

Gruss

Coffeebean
private Nachricht | Beiträge des Benutzers