Repository navigation
Support additional probing paths for assembly loading #3135
Description
In dotnet core, your dependency dlls do not have to be in the same folder as long as they are installed with nuget at additionalprobingpath.
If you do Add-Type in powershell on linux and then try to use the dll, it will fail with a dependency missing if the dependency is not in the same folder.
Is there a way to let powershell know net core additionalprobingpath? How is this supposed to work properly?
Activity
joeyaiello commentedon Feb 13, 2017
Oh, interesting, so sort of x-copyable GAC...Didn't realize they had done that already.
If I were to guess, I'd bet that it's probably due to the fact that we currently host an app-local copy of CoreCLR ourselves as opposed to picking up the system-wide "shared framework". Eventually, I think we plan to move to using the system-wide copy, though I'm not sure what the
Add-Typebehavior should be at that point.joeyaiello commentedon Mar 7, 2017
This absolutely needs to be answered to address the .NET Standard 2.0 "do we, by default, try and load old FullCLR modules?" question.
SteveL-MSFT commentedon May 15, 2017
even if we don't try by default (perhaps opt-in), we need the ability to load FullCLR assemblies stored in the GAC which seems to be the majority of in-box Windows PowerShell modules
[-]Question about additional probing path[/-][+]Support additional probing paths for assembly loading[/+]iSazonov commentedon May 16, 2017
It seems we need to think about the extra configuration option - whether or not to load old FullCLR modules. Perhaps consumers want to block it because of compatibility or performance.
SteveL-MSFT commentedon May 16, 2017
Ilya (@iSazonov) yes, loading of fullclr modules should be opt-in. perhaps we need some setting in StartupConfig
adityapatwardhan commentedon Jun 15, 2017
Andrew Savinykh (@AndrewSav) Do you have repro steps that I can use to look into this issue?
AndrewSav commentedon Jun 15, 2017
Aditya Patwardhan (@adityapatwardhan) Here you go.
Get yourself a clean Ubuntu 16.04 LTS.
Install Powershell as shown here: https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md#ubuntu-1604
Install .net as shown here https://www.microsoft.com/net/core#linuxubuntu
Before running step 4 at the link above, change hwapp.csproj and Program.cs as shown here. Then finish step 4.
Run the following commands:
Observe that "Passed" is printed:
Now run the following commands:
Observe an exception:
adityapatwardhan commentedon Jun 15, 2017
Andrew Savinykh (@AndrewSav) Thanks! This will be very helpful.
adityapatwardhan commentedon Aug 2, 2017
Andrew Savinykh (@AndrewSav) AdditionalProbingPath is a feature of dotnet / nuget.
dotnet runlooks up hwapp.runtime.dev.json to find the physical location on the nuget packages folder. Whendotnet publishis done the nuget dependency is copied over next to the hwapp.dll. And hence, the add-type scenario works as expected.Closing this issue as
dotnet publishresolves the issue. Please re-open if you do not agree with the resolution.undecided2013 commentedon May 13, 2019
I am having the same issue on Windows. I wrote a cmdlet targeting .net core 2.1. I 'publish' it. It creates a nuget package. Of course I cannot load that into powershell. So I go to the bin\Release\netcoreapp2.1 folder. I Add-Type the dll that contains the cmdlet. That works fine. I can now execute my cmdlet with -? and I get the help. Trying to execute it though and I get Could not load file or assembly '.......'. The system cannot find the file specified. This is an OSS assembly I got from nuget. This same code works fine as a console app but fails in powershell. So, the rules for finding referenced assemblies is not the same.
vexx32 commentedon May 13, 2019
Yep, there was a change in PS 6.2 which makes this a whole lot harder; see here: #9488