F# Wrong Order of Assemblies / nuget packages loaded....
See original GitHub issueDescribe the bug
I load all dependencies /nugetpackages at the top of the notebook file. but i got errors that the typ is unkown…
when i try this in dotnet core under cli this working correctly…
i have also the little jupyter file attached… it is easier to see the problem i think
Did this error occur while using dotnet try
or online?
-
dotnet-try
- [x ] .NET Jupyter Notebook
- [ x] online
What kind of error was it?
- User Interface (UI): For example the output never displayed
- Service Error: For example “The service is temporarily unavailable. We are working on it”
- [x ] Other: input.fsx (18,8)-(22,10) typecheck error The type referenced through ‘FShade.Imperative.Module’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘FShade.Imperative’.
Screenshots
Please complete the following:
- OS
- Windows 10
- macOS
- [x ] Linux (Please specify distro)
- iOS
- Android
- Browser
- [x ] Chrome
- Edge
- Safari
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:10 (5 by maintainers)
Top Results From Across the Web
Nuget Packages are there but missing References
So use the "Update-Package -reinstall" command to force reinstall the package references and content files into project.
Read more >Troubleshooting NuGet Package Restore in Visual Studio
When using packages.config, the error means that the package is not installed in the packages folder at the solution root.
Read more >Unable to resolve dependencies of NuGet packages
The cause for this error is that NuGet cache conflicts with the build of the site. Solution. To resolve the problem, perform the...
Read more >Question - Error using managed code with NuGet packages
Assembly 'Assets/Plugins/EmergentSim.dll' will not be loaded due to errors: Unable to resolve reference 'YamlDotNet'. Is the assembly missing or ...
Read more >Best Practices for Versioning NuGet Packages in ...
If the assembly version doesn't match what your application expects, then it will crash with an assembly load error.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
i revisited this issue, error reporting is much better now, all works now 😃 @dhabe1982
@dhabe1982,
Thanks for this, it is a really cool issue …
I took a look at this and I believe the order of #r shouldn’t really have impacted the compilation, so clearly we have some sort of bug.
My suspicion is that the type provider is initialized with references as soon as it’s dll referenced with “#r” rather than when we try to compile some code.
Given that references are discovered using “nuget” there is not really a good mechanism for modifying the #r order for discovered transient dll references, so we should probably try to nail down whether it is due to type provider initialization and figure out how to smooth out that experience.
In the meantime this works for me
Add a new cell at the front with it works by ensuring that FShade.Imperative is referenced and loaded before the type provider assembly is are loaded: