Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages

#6679 (comment) shows how hard it is to use a NuGet package installed via Install-Package in Powershell, for two reasons:

You must manually determine the platform-appropriate *.dll file in the package's folder subtree and pass its full path to Add-Type -Path (e.g., runtimes/linux-x64/... on a 64-bit Intel Linux system)
Even that by itself is not enough, if the package contains native helper libraries, because Add-Type -Path doesn't find them - see link above (whereas creating a C#-based .NET Core console application based on the same package installed with dotnet add package does).

Therefore, it would be great if Add-Type had built-in support for resolving both issues above, say with the following syntax:

## WISHFUL THINKING

# Install a NuGet package from the NuGet Gallery and add its types to the session.
Install-Package -Provider nuget Mono.Posix.NETStandard  | Add-Type

# Add the types of an already installed NuGet package to the session.
# Perhaps even download and install the package on demand.
Add-Type -Package Mono.Posix.NETStandard 

# Equivalent, via Get-Package.
Get-Package Mono.Posix.NETStandard | Add-Type

That is, when given a NuGet package [name], Add-Type would load the platform-appropriate assemblies and all their dependencies to make their types available to the current session.

Environment data

Written as of:

PowerShell Core v6.0.2

Would love this. Coming from Cake Build this was so easy with https://cakebuild.net/docs/fundamentals/preprocessor-directives. Given the widespread usage of nuget and likely need to leverage that from PS Core scripts it would seem this would be supported as a first class citizen.

How it correlates with Install/Uninstall-Module?

Ilya (@iSazonov)

Ilya (@iSazonov):

Install-Module is used for PowerShell modules from the PowerShell Gallery, whereas NuGet packages are .NET packages from the NuGet Gallery.

While PSGallery modules can be installed with Install-Package too, because the *-Package cmdlets are an abstraction over all galleries / package sources, the inverse is not true: NuGet packages cannot be installed with Install-Module.

Is that what you were asking?

Thanks!
Seems this can resolve #7259 too:

Install-Package "SomePackage"  | Add-Type -PassThru | Import-Module

Ilya (@iSazonov)

Ilya (@iSazonov):

While #7259 has the same goal in the abstract - making use of NuGet package easier - ~~it is a competing proposal in terms of implementation~~ [update: it isn't; said issue is about PowerShell modules only - see here].

Import-Module should support nupkg files #7259 suggests the use of Import-Module to load NuGet packages [containing PowerShell modules].
This issue suggest use of Add-Type ~~only~~ [for non-PS-module NuGet packages].

I don't think it's appropriate to integrate the functionality into Import-Module, because NuGet packages are .NET assemblies, not PowerShell modules; hence the suggestion to use Add-Type, which is the cmdlet already used for loading assemblies.

~~In short: My vote is to implement this issue only, instead of #7259.~~

.NET assemblies can contain cmdlets. We use this in our tests.

Ilya (@iSazonov)

Ilya (@iSazonov):

Yes, all compiled cmdlets come as part of assemblies, but they're typically packaged as part of a PS module.
However, good point about the need to use Import-Module on an assembly containing a cmdlet that isn't packaged as part of a module in order to import such cmdlets; I assume you meant:

(Install-Package "SomePackage" | Add-Type -PassThru).Assembly | Import-Module

But it sounds like we're in agreement then, correct?:

No changes to Import-Module are required; it is sufficient to make Add-Type understand NuGet packages.

I've started a conversation about which proposal to consider (or perhaps find a synthesis) at #7259 (comment)

Since this has been sitting on the back-burner for 7 months now with no comments or assignment, I'll ask the obvious: has anyone found a workaround solution that doesn't require waiting for this feature to be implemented?

I would like to know this too. We have a bunch of local development functionality that would be good for us to implement, such as seeding our local Azure Storage Emulator with local development data and a bunch of other local-only functionality that would make a lot more sense as powershell scripts than a catalogue of random tools in our C# projects. Unfortunately Powershell's limitations with importing nuget packages into the namespaces makes this difficult and we just opted for spamming our solution with misc projects :(.

I just wanted to chime in and say we're run into this as well.

Our use case is that we use several binaries from SQL Management Objects (SMO) which as of SQL 2017 are ONLY shipped as a NuGet Package in our various scripts for maintaining SQL Databases. It'd be really convenient to have Add-Type extended to support that scenario.

Anyone got any good ideas?

MartinHBA

edit: I finally get it done... only PS Core works

MartinHBA Since you mentioned this, please add a link to an example/gist.

Ilya (@iSazonov)

hi Ilya (@iSazonov) , you can find it here
edit: fixed link, thx

MartinHBA

MartinHBA, there's an extra char. at the end of your link's URL - the correct link is:
https://gist.github.com/MartinHBA/86c6014175758a07b09fa7bb76ba8e27

The correct link is https://gist.github.com/MartinHBA/86c6014175758a07b09fa7bb76ba8e27

…

On Sat, Nov 9, 2019, 5:08 PM Michael Klement ***@***.***> wrote: @MartinHBA <https://github.com/MartinHBA>, did you accidentally create a *private* Gist? The link yields a 404. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6724?email_source=notifications&email_token=AADNH7JT2ZDCB2KSSAXNDLLQS4YGPA5CNFSM4E4KKOOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUQJ2I#issuecomment-552142057>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADNH7NXW5AOK3EDGLSCIPLQS4YGPANCNFSM4E4KKOOA> .

MartinHBA

Is this on the roadmap for the PowerShell team at anytime?

The need to load in NuGet Packages (in this case the one that seems to keep coming up is the SMO Tooling, in addition to this thread here is another one dotnet/SqlClient#623) seems to be a pretty common scenario for a lot of developers.

The current work arounds (provided by MartinHBA and Michael Klement (@mklement0) in #11860) aren't super great. Massive kudos to you two though because you show up in many of these threads! Here's another public blog post that tries to work around the issue as well http://www.maxtblog.com/2020/03/streamlining-sql-server-management-objects-smo-in-powershell-7-revised/. While we appreciate that it is a way to move forward they all basically boil down to:

Copying the Appropriate DLL's out of the various referenced NuGet Packages (or creatively referencing them from their NuGet locations)
Performing an Add-Type for each of the dependency assemblies

This is a bit of a pain, especially because the Microsoft.Data.SqlClient.SNI.runtime package ships a native binary that will require you to determine if you're going to run x64 vs x86 and then have the native assembly sitting next to the managed assembly. This makes automating this in any type of pipeline wherein you do not have full control over the machine difficult.

The path of least resistance in these cases has been to build a "dummy" binary that pulls in all of the NuGet Packages into a single output and then commit this into version control. This completely subverts the powerful tooling that NuGet was supposed to provide to us to keep our repositories free from binaries.

Streamlining SQL Server Management Objects (SMO) In PowerShell 7 (Revised) – Max Trinidad – The PowerShell Front

I am wondering if installing and referencing a NuGet package in PWSH 7 is still problematic and buggy. I have built a simple nuget package in VS and I'm getting a long list of issues when trying to install and reference it in a script through Install-package.

This to my knowledge is still an issue; and often times in PowerShell I wish this would just work out of the box (for example just a few weeks ago it would have made this more accessible: https://stackoverflow.com/a/77328383/433069) until then your best bet is still to XCOPY Deploy the packages (extracting their contents) and doing Add-Type -Path

Stack Overflow
PowerShell - Changing MP4 Metadata (Right Click Properties)
I've been trying to find a way to edit the "Tags" section by swapping it with the "Title" section for MP4. The problem is that I can't do this with ExiftTool, MP3Tag, MediaMonke...

What are the odds the day I seriously look into this, after being confused for years, that the topic on my exact concern gets closed in the last hour?

I always thought I was just doing it wrong, not that the functionality was missing.

What are the odds the day I seriously look into this, after being confused for years, that the topic on my exact concern gets closed in the last hour?

I always thought I was just doing it wrong, not that the functionality was missing.

I have a PS (script) module in a gist https://gist.github.com/nonbob/c37b60d5c172b6d8f851b1dc92d2fc3a that addresses the load-assemblies-via-add-type-from-a-nuget-package-and-its-dependencies problem in a fairly generic way. More description here: https://stackoverflow.com/a/79846815/876993

Gist
Load DLLs from NuGet packages (as in Add-Type -Path) into PowerShell, including dependencies
Load DLLs from NuGet packages (as in Add-Type -Path) into PowerShell, including dependencies - AddNuGetType.psd1

Stack Overflow
Loading Assemblies from NuGet Packages
Sometimes in my PowerShell scripts, I need access to a specific DLL, using Add-Type -AssemblyName. However, the DLLs I need aren't always on the machine or in the GAC. For instance, I might want a ...

Navigation Menu

Repository navigation

Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages #6724

Environment data

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages #6724

Description

Environment data

Activity

thnk2wn commented on May 20, 2018

iSazonov commented on Jul 30, 2018

mklement0 commented on Jul 31, 2018

iSazonov commented on Jul 31, 2018

mklement0 commented on Jul 31, 2018

iSazonov commented on Jul 31, 2018

mklement0 commented on Jul 31, 2018

mklement0 commented on Jul 31, 2018

jptillman commented on Jan 19, 2019

KallDrexx commented on Jan 23, 2019

aolszowka commented on Feb 18, 2019

12 remaining items

iSazonov commented on Nov 9, 2019

MartinHBA commented on Nov 9, 2019

mklement0 commented on Nov 9, 2019

jzabroski commented on Nov 9, 2019

aolszowka commented on Oct 21, 2020

netcorefan1 commented on May 25, 2023

aolszowka commented on Nov 29, 2023

phatmandrake commented on Dec 7, 2023

nonbob commented on Dec 15, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions