Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to install nuget packages that exists as part of MonoBleedingEdge #395

Closed
jmfGE opened this issue May 10, 2021 · 3 comments · Fixed by #431
Closed

Unable to install nuget packages that exists as part of MonoBleedingEdge #395

jmfGE opened this issue May 10, 2021 · 3 comments · Fixed by #431

Comments

@jmfGE
Copy link

jmfGE commented May 10, 2021

Description

I'm trying to install RabbitMQ.Client 6.2.1, but NuGetForUnity debug says the library is already installed. I drilled down and found it was finding that RabbitMQ is part of the library for the Unity Editor (under MonoBleedingEdge), but those libraries are not actually exposed to the Unity runtime environment.

"C:\Program Files\Unity\Hub\Editor\2021.1.2f1\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api\RabbitMQ.Client.dll"

  • NuGet Package: RabbitMQ.Client 6.2.1
  • NuGetForUnity Version: 3.0.2
  • Unity Version: 2021..2f1
  • Operating System: Windows 10
@jwittner
Copy link
Collaborator

jwittner commented May 10, 2021

Was worried this day would come. We need to either find out a way to determine dynamically what libraries in those folders are/aren't exposed to the runtime or we need to make a whitelist of ones in those folders to ignore in the test. The list of assemblies we're assuming are already included is gathered in this code.

Open to ideas for building up that list more intelligently / blacklisting assemblies from inclusion in that list even if they are under the folders. If we know there are whole folders we can ignore that'd be a great start!

@robin-moss
Copy link
Contributor

Could we not just exclude the MonoBleedingEdge folder from the search?

or could we use AppDomain.CurrentDomain.GetAssemblies() to find all active domains in Unity?

@robin-moss
Copy link
Contributor

Looks like AppDomain.CurrentDomain.GetAssemblies().Select(a => a.ManifestModule.Name) .Select(p => Path.ChangeExtension(p, null)); should work :)

robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Dec 21, 2021
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Dec 21, 2021
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Jan 6, 2022
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Mar 2, 2022
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Mar 2, 2022
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Mar 3, 2022
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Mar 3, 2022
robin-moss added a commit to robin-moss/NuGetForUnity that referenced this issue Mar 3, 2022
@JoC0de JoC0de linked a pull request Jan 8, 2023 that will close this issue
JoC0de pushed a commit to robin-moss/NuGetForUnity that referenced this issue Jan 8, 2023
JoC0de added a commit that referenced this issue Jan 8, 2023
fix: use reflection to find already imported libs #395
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants