Installation von ,,Microsoft.Data.SqlClient" via PS

[Ghost_Rider_R]

Hallo zusammen,

könnte mir bitte jemand alle Befehle zusammenschreiben, wie ich das ,,Microsoft.Data.SqlClient" Package via NuGet auf einem frisch installierten Windows 10 / 11 installiere?

Irgendwie drehe ich mich da aktuell im Kreis und komme auch mit Tante Google nicht zum Erfolg.

Vielen Dank schon mal dafür.

LG Ghost.

 

[madmax2010]

https://docs.microsoft.com/de-de/nuget/consume-packages/install-use-packages-powershell
woran scheitert es?

 

[Yuuri]

https://www.nuget.org/packages/Microsoft.Data.SqlClient/

Steht direkt ganz oben in sechs unterschiedlichen Möglichkeiten.

 

[burglar225]

Installiert man NuGet-Pakete überhaupt "in Windows"? Ich dachte die installiert man in seinem VS-Projekt oder so.

 

[Ghost_Rider_R]

...vielleicht kommen wir der Sache schon näher, installiert man die Pakete unter Windows oder im Projekt? Im Projekt ist mir das klar, wie es funktioniert nur wäre es halt schön, wenn ich zu meiner Anwendung nicht immer den ganzen Overhead an Dependencies übergeben müsste...

 

[madmax2010]

warum overhead? Importierst du zeug, dass du nicht brauchst?

du kannst Bibliotheken OS weit oder fuer Projekte installieren.

 

[Ghost_Rider_R]

Es scheitert daran, jedoch mach ich bestimmt etwas falsch:

Ich hätte gerne eine schlanke Anwendung und würde die Dependency gerne via PS Skript ausrollen, das war soweit mal mein Plan, also nicht mit dem Projekt. Da soll einfach nur die Anwendung.exe liegen und fertig.

Durch die eine Abhängigkeit sieht mein Bin-Verzeichnis jetzt so aus, davor waren einfach nur eine Handvoll DLLs drin und gut ist:

 

[Jesterfox]

NuGet Pakete werden ins Projekt installiert. Und beim kompilieren landen die DLLs dann mit im Ausgabeverzeichnis. Dadurch ist dann auch sichergestellt dass deine Anwendung genau die Version verwendet mit der du entwickelt hast.

 

[madmax2010]

kenne nuget jetzt nicht, aber vorher mal: nuget update ?

 

[Ghost_Rider_R]

warum overhead? Importierst du zeug, dass du nicht brauchst?

du kannst Bibliotheken OS weit oder fuer Projekte installieren.

Genau das ist mein vorhaben, ich möchte es OS Weit installieren, weiß aber nur, wie ich es innerhalb von meinem Projekt importiere und bekomme dadurch eine rießlige Projektdatei...

 

[madmax2010]

OS weit ist fast nie eine gute ide, weil du sehr oft die gleiche dependency in unterschiedlichen versionen brauchst. Oft implizit.
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/dependencies
https://lostechies.com/derekgreer/2011/09/18/dependency-management-in-net/
https://jfrog.com/blog/dependency-management-with-net-doing-it-right/

 

[Ghost_Rider_R]

NuGet Pakete werden ins Projekt installiert. Und beim kompilieren landen die DLLs dann mit im Ausgabeverzeichnis. Dadurch ist dann auch sichergestellt dass deine Anwendung genau die Version verwendet mit der du entwickelt hast.

Das wäre ja auch ok, wenn es eine Bibliothek wäre, aber das Ding zieht noch zig weitere Bibliotheken nach sich, daher hätte ich das gerne OS weit, wenn dies möglich ist, da ich auch bei anderen Projekten gerne darauf zurückgreifen würde. Aber mit der PS bekomme ich das irgendwie nicht hin...

 

[Jesterfox]

ich möchte es OS Weit installieren

Dazu bräuchte man einen Installer der die DLLs in den GAC packt... das ist meines Wissens aber so nicht vorgesehen.

 

[Ghost_Rider_R]

OS weit ist fast nie eine gute ide, weil du sehr oft die gleiche dependency in unterschiedlichen versionen brauchst. Oft implizit.

Da ich bei meinen Projekten immer auf ein und die selbe Bibliothek zurück greife, ist das für mich an der Stelle in Ordnung. Dann laufen entweder alle meine Anwendungen oder gar keine mehr, damit kann ich leben.

 

[Myron]

Dich stört also eigentlich mehr die Anzahl der DLLs in deinem Applikationsverzeichnis?

 

[Ghost_Rider_R]

Dazu bräuchte man einen Installer der die DLLs in den GAC packt... das ist meines Wissens aber so nicht vorgesehen.

Muss ich dann, nur weil ich einen Datenbankzugriff machen möchte, fortan 20 DLLs mit mir rumschleppen? das Projekt wird dadurch statt wenige KB so schon 10 MB groß und die Libs verwende ich häufig in unterschiedlichen Projekten...

Ergänzung (1. Dezember 2021)

Dich stört also eigentlich mehr die Anzahl der DLLs in deinem Applikationsverzeichnis?

So siehts aus und noch die Größe von 10MB.

 

[madmax2010]

Du nutzt halt libraries. diese nutzen andere libraries. die muessen halt mit
Das es so viele sind, deutet auch darauf hin, dass da leute sauber gearbeitet haben.

 

[Ghost_Rider_R]

Du nutzt halt libraries. diese nutzen andere libraries. die muessen halt mit
Das es so viele sind, deutet auch darauf hin, dass da leute sauber gearbeitet haben.

Das wäre ja an sich auch eine gute Sache, aber ich möchte diese halt gerne an einem zentralen Ort im System haben und nicht im Programmverzeichnis, da bei mir künftig diverse Anwendungen darauf zugreifen sollen und eben nicht nur diese eine. Wie mach ich das? ich bin leider immer noch kein Stück weiter...

 

[michi.o]

Eventuell ist das hier die Lösung. Habs nur grob überflogen, aber anscheinend kann man alle DLLs z.B. unter "C:/Program Files/dotnet/store" ablegen und dann mit einem Manifest darauf verweisen :
https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store

Bei meinem aktuellen Projekt werden DLLs von verschiedenen Stellen dynamisch hinzugefügt. Dort benutze ich das AssemblyResolve Event. Das könnte man vielleicht als Notlösung nehmen:

AppDomain.CurrentDomain.AssemblyResolve += CurrentDomainOnAssemblyResolve;

Assembly CurrentDomainOnAssemblyResolve(object sender, ResolveEventArgs args)
{
    var dirs = _dllDirectories;
    if (dirs == null) return null;

    foreach (var dir in dirs)
    {
        try
        {
            foreach (var file in Directory.GetFiles(dir))
            {
                if (file.EndsWith(".dll") || file.EndsWith(".exe"))
                {
                    try
                    {
                        var name = System.Reflection.AssemblyName.GetAssemblyName(file).FullName;
                        if (name == args.Name)
                            return Assembly.LoadFrom(file);
                    }
                    catch { /* ignore */ }
                }
            }
        }
        catch { /* ignore */ }
    }
    return null;
}