Repository navigation
Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages #6724
Description
#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
*.dllfile in the package's folder subtree and pass its full path toAdd-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 -Pathdoesn't find them - see link above (whereas creating a C#-based .NET Core console application based on the same package installed withdotnet add packagedoes).
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-TypeThat 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
Activity
thnk2wn commentedon May 20, 2018
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.
iSazonov commentedon Jul 30, 2018
How it correlates with Install/Uninstall-Module?
mklement0 commentedon Jul 31, 2018
Ilya (@iSazonov):
Install-Moduleis 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-Packagetoo, because the*-Packagecmdlets are an abstraction over all galleries / package sources, the inverse is not true: NuGet packages cannot be installed withInstall-Module.Is that what you were asking?
iSazonov commentedon Jul 31, 2018
Thanks!
Seems this can resolve #7259 too:
mklement0 commentedon Jul 31, 2018
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-Moduleto load NuGet packages [containing PowerShell modules].This issue suggest use of
Add-Typeonly[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 useAdd-Type, which is the cmdlet already used for loading assemblies.In short: My vote is to implement this issue only, instead of #7259.iSazonov commentedon Jul 31, 2018
.NET assemblies can contain cmdlets. We use this in our tests.
mklement0 commentedon Jul 31, 2018
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-Moduleon an assembly containing a cmdlet that isn't packaged as part of a module in order to import such cmdlets; I assume you meant:But it sounds like we're in agreement then, correct?:
No changes to
Import-Moduleare required; it is sufficient to makeAdd-Typeunderstand NuGet packages.mklement0 commentedon Jul 31, 2018
I've started a conversation about which proposal to consider (or perhaps find a synthesis) at #7259 (comment)
jptillman commentedon Jan 19, 2019
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?
KallDrexx commentedon Jan 23, 2019
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 :(.
aolszowka commentedon Feb 18, 2019
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?
12 remaining items
iSazonov commentedon Nov 9, 2019
MartinHBA Since you mentioned this, please add a link to an example/gist.
MartinHBA commentedon Nov 9, 2019
hi Ilya (@iSazonov) , you can find it here
edit: fixed link, thx
mklement0 commentedon Nov 9, 2019
MartinHBA, there's an extra char. at the end of your link's URL - the correct link is:
https://gist.github.com/MartinHBA/86c6014175758a07b09fa7bb76ba8e27
jzabroski commentedon Nov 9, 2019
aolszowka commentedon Oct 21, 2020
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:
Add-Typefor each of the dependency assembliesThis is a bit of a pain, especially because the
Microsoft.Data.SqlClient.SNI.runtimepackage 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.
netcorefan1 commentedon May 25, 2023
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.aolszowka commentedon Nov 29, 2023
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 -Pathphatmandrake commentedon Dec 7, 2023
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.
nonbob commentedon Dec 15, 2025
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